From tanner at real-time.com Thu Feb 1 00:43:34 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 17:59:52 2005 Subject: [CF-Devel] [crossfire-cvs-admin@lists.sourceforge.net: [Crossfire-cvs] CVS update: client] Message-ID: <20010201004334.E28709@real-time.com> > Date: Wednesday January 31, 2001 @ 22:31 > Author: cvs > > Update of /home/cvs/CVS/client > In directory boltzmann.eecs.berkeley.edu:/tmp/cvs-serv24312 Last set of commits on the client? I'll roll a new rpm. -- 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 Thu Feb 1 00:31:09 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:52 2005 Subject: [CF-Devel] cfclient+burning hands+floorless maps References: <20010131141109.A6694@tukki.jyu.fi> Message-ID: <3A7902AD.393E95FE@scruz.net> "Pertti Karppinen (OH6KTR)" wrote: > > I just found (atleast on sgi O2 box) that when you cast burning hands or > similar spells o a map that has no floor tile, it leaves lot of spell images > to map. They get erased when You walk over them though. This is now fixed in cvs. > > Also, I may completely clueless coder, but why does following code compile > without warnings on gcc (client/x11.c at the bottom): > for (i=1; i if (pixmaps[i].pixmap && (pixmaps[i].pixmap!=pixmaps[0].pixmap)) { > XFreePixmap(display, pixmaps[i].pixmap); > pixmaps[i].pixmap=(Pixmap*)NULL; > if (pixmaps[i].mask) { > XFreePixmap(display, pixmaps[i].mask); > pixmaps[i].mask=(Pixmap*)NULL; > > pixmaps[i].pixmap and pixmaps[i].mask are both of type > Pixmap, not Pixmap *. > That code looks weird alltogether. Its pretty odd. I've fixed the cast. In reality, clearing the pixmap data/pointer probably should not be needed, as we should not be trying to access the images in any case. But I have made some other enhancements to the client. Notably, before if you disconnected from one server, often the client would crash because it would try to access that pixmap data (because inventory, map, or look window still had references). I've added code that now clears all that data. From mwedel at scruz.net Thu Feb 1 00:32:55 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:52 2005 Subject: [CF-Devel] Appendix A - Commands References: Message-ID: <3A790317.F214DBB2@scruz.net> Rick Tanner wrote: > What I was trying to say is I could update the Commands section on the > website, but I am unable to update the help commands in the game because I > do not have CVS access, and even if I did I still wouldn't know what to > do. > > If I provide the commands and summaries in something like .txt format, > could someone else follow through on this? Sure. the help commands are just simple text files. They should either be formatted for 40 characters wide or so, or better would be to only have line breaks between the paragraphs - in that way, the client will deal with wrapping the words in the appropriate place. From mwedel at scruz.net Thu Feb 1 00:36:52 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:52 2005 Subject: [CF-Devel] Performance of current CVS is awful? References: <200101312025.MAA25023@tesla.EECS.Berkeley.EDU> Message-ID: <3A790404.1CB7BFB4@scruz.net> Peter Mardahl wrote: > > Hello, > > I (and others: MiDS, rower) have noticed a huge drop > in performance. > > Perhaps maps are not being swapped out anymore, but instead, > the game is processing a great many maps? CPU use is > definitely greatly increased, to the point where it is > lagged on my dual-400MHz-CPU 256M system after a little play. Yeah, but this doesn't really help track down the problem much. Is this something that just happens after a lot of play? Does it happen right after server startup? Anything to help characterize this problem? The 'malloc command may give some idea if there is an actual memory leak. Otherwise, running it with profiling may give some clue where cpu use is going. From mwedel at scruz.net Thu Feb 1 01:23:33 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:52 2005 Subject: [CF-Devel] [crossfire-cvs-admin@lists.sourceforge.net: [Crossfire-cvs] CVS update: client] References: <20010201004334.E28709@real-time.com> Message-ID: <3A790EF5.5AEFDCAD@scruz.net> Bob Tanner wrote: > > > Date: Wednesday January 31, 2001 @ 22:31 > > Author: cvs > > > > Update of /home/cvs/CVS/client > > In directory boltzmann.eecs.berkeley.edu:/tmp/cvs-serv24312 > > Last set of commits on the client? For tonight. But I'm working on some new changes so that the client & server checksums the image data when the client caches them, and if the clients checksum differs from the server, it also requests a new image. That will be done sometime soon. But as I think about this, this creates an interesting scenario. Suppose two servers - one up to date, the other a bit behind with some older images. You connect to the up to date server, and the client updates the relevant images. You then connect to the old server, the checksums differ, so it once again grabs the images. You now go to the new server again, and once again it grabs the new images. I don't have an elegant solution to that problem. But presuming most of the servers you play on are up to date, this should still be better than right now where you can have really old images sitting around. I'll probably also add some option like so that it doesn't download the new images even if the checksums differ. From frankj at osc.no Thu Feb 1 01:39:48 2001 From: frankj at osc.no (Frank Tore Johansen) Date: Thu Jan 13 17:59:53 2005 Subject: [CF-Devel] Re: problems with crossfire In-Reply-To: <20010201064945.972923ECC@sitemail.everyone.net> Message-ID: (Added Cc: to the crossfire-devel list.) And are you absolutely sure that you already started the local server? Try running: /bin/crossfire -d > /tmp/cflog 2>&1 & /bin/cfclient -server localhost And after the error, look at and mail us the file /tmp/cflog. -Frank. On Wed, 31 Jan 2001, biggy. wrote: > we are using the cfclient, it says > cfclient -server localhost > Could not open ~/.crossfire > /keys, trying to load global bindings > Warning: could not convert seysym F28 into keycode, ignoring > Warning: could not convert seysym F34 into keycode, ignoring > Warning: could not convert seysym F30 into keycode, ignoring > Warning: could not convert seysym F32 into keycode, ignoring > Warning: could not convert seysym F27 into keycode, ignoring > Warning: could not convert seysym F29 into keycode, ignoring > Warning: could not convert seysym F31 into keycode, ignoring > Warning: could not convert seysym F33 into keycode, ignoring > Warning: could not convert seysym F35 into keycode, ignoring > Can't connect to server: Connection refused > > and we have suse 7.0, when i first start it in that way, i can see a quick flash of the program switching on and off. > > --- Frank Tore Johansen > > wrote: > >What client are you using? > > > >-Frank. > > > >On Wed, 31 Jan 2001, biggy. wrote: > > > >> Until recently i had an older version of crossfire where i could actually play without logging onto the internet, bu with the newest version it always tries to make me go onto the net, is there a way i could play without logging onto the internet? > >> > >> _____________________________________________________________ > >> Get your free email at: http://biggiesjoint.mail.everyone.net! > >> > > _____________________________________________________________ > Get your free email at: http://biggiesjoint.mail.everyone.net! > From michael.toennies at nord-com.net Thu Feb 1 06:50:19 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 17:59:53 2005 Subject: [CF-Devel] [crossfire-cvs-admin@lists.sourceforge.net: [Crossfire-cvs] CVS update: client] In-Reply-To: <3A790EF5.5AEFDCAD@scruz.net> Message-ID: Please give me a more detailed note of your checksum changes mark, when you are ready with them, so i can put them also in the dxclient in. Michael > Bob Tanner wrote: > > > > > Date: Wednesday January 31, 2001 @ 22:31 > > > Author: cvs > > > > > > Update of /home/cvs/CVS/client > > > In directory boltzmann.eecs.berkeley.edu:/tmp/cvs-serv24312 > > > > Last set of commits on the client? > > For tonight. But I'm working on some new changes so that the > client & server > checksums the image data when the client caches them, and if the clients > checksum differs from the server, it also requests a new image. > That will be > done sometime soon. > > But as I think about this, this creates an interesting scenario. > Suppose two > servers - one up to date, the other a bit behind with some older images. > > You connect to the up to date server, and the client updates the relevant > images. You then connect to the old server, the checksums > differ, so it once > again grabs the images. You now go to the new server again, and > once again it > grabs the new images. > > I don't have an elegant solution to that problem. But presuming > most of the > servers you play on are up to date, this should still be better > than right now > where you can have really old images sitting around. > > I'll probably also add some option like so that it doesn't > download the new > images even if the checksums differ. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From peterm at tesla.EECS.Berkeley.EDU Thu Feb 1 12:35:05 2001 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 17:59:53 2005 Subject: [CF-Devel] Performance of current CVS is awful? In-Reply-To: Your message of "Wed, 31 Jan 2001 22:36:52 PST." <3A790404.1CB7BFB4@scruz.net> Message-ID: <200102011835.KAA08562@tesla.EECS.Berkeley.EDU> Hello, I was able to trigger the performance by visiting a lot of maps in quick succession. That is why I think it may be due to maps not getting swapped out. PeterM > Peter Mardahl wrote: > > > > Hello, > > > > I (and others: MiDS, rower) have noticed a huge drop > > in performance. > > > > Perhaps maps are not being swapped out anymore, but instead, > > the game is processing a great many maps? CPU use is > > definitely greatly increased, to the point where it is > > lagged on my dual-400MHz-CPU 256M system after a little play. > > Yeah, but this doesn't really help track down the problem much. > > Is this something that just happens after a lot of play? Does it happen rig >ht > after server startup? Anything to help characterize this problem? > > The 'malloc command may give some idea if there is an actual memory leak. > Otherwise, running it with profiling may give some clue where cpu use is goin >g. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From frankj at osc.no Thu Feb 1 23:44:00 2001 From: frankj at osc.no (Frank Tore Johansen) Date: Thu Jan 13 17:59:53 2005 Subject: [CF-Devel] Re: problems with crossfire In-Reply-To: <20010202053304.9E62436F9@sitemail.everyone.net> Message-ID: Do you use the same keyboard as you used to? And is num-lock in the same position? (Should be unlighted) Function keys F28 to F35 seems to indicate that it must have been a pretty big keyboard. Anyway, you can probably type 'bind north 'bind northeast 'bind east 'bind southeast etc, and press the represented numberpad keys again. -Frank. On Thu, 1 Feb 2001, biggy. wrote: > ok, it works now thank you, but i still have one problem, it wont let me use the numberpad keys like i was able to use before, and i think thats what those warnings are > --- Frank Tore Johansen > >On Wed, 31 Jan 2001, biggy. wrote: > >> /keys, trying to load global bindings > >> Warning: could not convert seysym F28 into keycode, ignoring > >> Warning: could not convert seysym F34 into keycode, ignoring > >> Warning: could not convert seysym F30 into keycode, ignoring > >> Warning: could not convert seysym F32 into keycode, ignoring > >> Warning: could not convert seysym F27 into keycode, ignoring > >> Warning: could not convert seysym F29 into keycode, ignoring > >> Warning: could not convert seysym F31 into keycode, ignoring > >> Warning: could not convert seysym F33 into keycode, ignoring > >> Warning: could not convert seysym F35 into keycode, ignoring From mwedel at scruz.net Fri Feb 2 00:10:00 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:53 2005 Subject: [CF-Devel] new stat generation system. Message-ID: <3A7A4F38.3FF956B6@scruz.net> On irc discussion last night, there was some discussion about redoing the stat generation method. This mostly came about because peter was hacking the client so that it would automatically re-roll stats until some desired value is reached. Currently, the server enforces a total stats between 82 and 116. It was suggested that instead of rolling stats at all, just give the player the 116 total to distribute between the stats as desired (just as a note, if we do go this way, I would probably make that stat total easily setable, so someone who wants to make an easy server could make the total lower, while a hard server could have a lower total). The total probably needs to be lower in any case, as if you can just set the values, it will be easier to min/max the stats - right now, for example, it is difficult for a rolled stats to be much lower than 8. It appears the rolling method is 4d6, keep the best 3. As thinking about this, the easy way would be for the server to tell the player what the stat total is, enter amount for str, you have x points left, enter total for int, etc. But then I realized a better way would be for the client to handle all of this - basically, the server would tell the client to choose stats, total is 130. Client presents whatever way it wants for the player to set those to the different attributes, and when the player is done, the client sends back to server the values for str, dex, con, etc. Server verifies the values to make sure they are proper, and then moves along to race selection. Thoughts? Its some amount of work, but overall, the amount of code may be reduced in the server and client (code to roll the stats, swap, them, etc, is handled on the server, but the client has to deal with the actual interaction with the player.) From peterm at tesla.EECS.Berkeley.EDU Fri Feb 2 04:49:45 2001 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 17:59:53 2005 Subject: [CF-Devel] new stat generation system. In-Reply-To: Your message of "Thu, 01 Feb 2001 22:10:00 PST." <3A7A4F38.3FF956B6@scruz.net> Message-ID: <200102021049.CAA17096@tesla.EECS.Berkeley.EDU> > This mostly came about because peter was hacking the client so that it would > automatically re-roll stats until some desired value is reached. There will always be ways to abuse the game. I don't think this one is very severe: I'd rather see other ones fixed. > Currently, the server enforces a total stats between 82 and 116. It was > suggested that instead of rolling stats at all, just give the player the 116 116 is probably too high initially.... > if you can just set the values, it will be easier to min/max the stats - righ > now, for example, it is difficult for a rolled stats to be much lower than 8. > It appears the rolling method is 4d6, keep the best 3. Yes. That is how it works. > But then I realized a better way would be for the client to handle all of th > - basically, the server would tell the client to choose stats, total is 130. > Client presents whatever way it wants for the player to set those to the > different attributes, and when the player is done, the client sends back to > server the values for str, dex, con, etc. Server verifies the values to make > sure they are proper, and then moves along to race selection. There's nothing intrinsically wrong with this, but we have to make sure no one picks any one stat > 18. Race/Class modifiers can be added later. > Thoughts? Its some amount of work, but overall, the amount of code may be > reduced in the server and client (code to roll the stats, swap, them, etc, is > handled on the server, but the client has to deal with the actual interaction > with the player.) Even though a random rolling system is open to abuse, I think it is more fun in general than having to choose all the stats. Crossfire is open to *many* client side abuses: I don't see why we should treat this one specially and neglect all the rest. PeterM From jbontje at suespammers.org Fri Feb 2 06:30:35 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 17:59:53 2005 Subject: [CF-Devel] 100% CPU in gcfclient metaserver query mode Message-ID: <01020213303500.30526@debian> On my workstation I have a nice CPU monitor running... GKrellM (top or wmmon will do too). After playing a while with the gcfclient and finally exiting my server, I always get in the metaserver query mode (where you see a list of all servers). I noticed that my CPU got a continue load of 100%. Darth_bob also confirmed this on his system, I rechecked with the latest CVS version and it keeps eating my CPU. cfclient doesn't show this behaviour. Joris Bontje / MiDS From michael.toennies at nord-com.net Fri Feb 2 13:33:28 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 17:59:53 2005 Subject: [CF-Devel] new stat generation system. In-Reply-To: <3A7A4F38.3FF956B6@scruz.net> Message-ID: Iam in all ways a friend of points to destribute. I all other cases, i simply try as long as i got good points, because it makes a big difference when you start with wisdom 10 or str 20. So, giving the player points, and lets add him to stats is a good way. Also, you can play more easily your favorite chars. > > > On irc discussion last night, there was some discussion about > redoing the stat > generation method. > > This mostly came about because peter was hacking the client so > that it would > automatically re-roll stats until some desired value is reached. > > Currently, the server enforces a total stats between 82 and 116. It was > suggested that instead of rolling stats at all, just give the > player the 116 > total to distribute between the stats as desired (just as a note, > if we do go > this way, I would probably make that stat total easily setable, > so someone who > wants to make an easy server could make the total lower, while a > hard server > could have a lower total). The total probably needs to be lower > in any case, as > if you can just set the values, it will be easier to min/max the > stats - right > now, for example, it is difficult for a rolled stats to be much > lower than 8. > It appears the rolling method is 4d6, keep the best 3. > > As thinking about this, the easy way would be for the server to > tell the player > what the stat total is, enter amount for str, you have x points > left, enter > total for int, etc. > > But then I realized a better way would be for the client to > handle all of this > - basically, the server would tell the client to choose stats, > total is 130. > Client presents whatever way it wants for the player to set those to the > different attributes, and when the player is done, the client > sends back to > server the values for str, dex, con, etc. Server verifies the > values to make > sure they are proper, and then moves along to race selection. > > Thoughts? Its some amount of work, but overall, the amount of > code may be > reduced in the server and client (code to roll the stats, swap, > them, etc, is > handled on the server, but the client has to deal with the actual > interaction > with the player.) > _______________________________________________ > 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 Fri Feb 2 18:27:02 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 17:59:53 2005 Subject: [CF-Devel] CVS error Message-ID: <20010202182702.X17934@real-time.com> cvs server: failed to create lock directory in repository +`/home/cvs/CVS/arch/monster/angel': Permission denied cvs server: failed to obtain dir lock in repository +`/home/cvs/CVS/arch/monster/angel' -- 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 Fri Feb 2 21:25:55 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 17:59:53 2005 Subject: [CF-Devel] Blotzman gone? Message-ID: <20010202212555.D7183@real-time.com> $ cvs export -d crossfire-client-0.95.8 -D now client boltzmann.eecs.berkeley.edu: Connection refused cvs [export aborted]: end of file from server (consult above messages if any) ? -- 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 Fri Feb 2 21:27:59 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 17:59:53 2005 Subject: [CF-Devel] Blotzman gone? In-Reply-To: <20010202212555.D7183@real-time.com>; from tanner@real-time.com on Fri, Feb 02, 2001 at 09:25:55PM -0600 References: <20010202212555.D7183@real-time.com> Message-ID: <20010202212759.E7183@real-time.com> Quoting Bob Tanner (tanner@real-time.com): > $ cvs export -d crossfire-client-0.95.8 -D now client > boltzmann.eecs.berkeley.edu: Connection refused > cvs [export aborted]: end of file from server (consult above messages if any) > > ? > Ugh, sorry for the typo in the subject. -- 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 Feb 2 22:10:16 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:53 2005 Subject: [CF-Devel] Blotzman gone? References: <20010202212555.D7183@real-time.com> <20010202212759.E7183@real-time.com> Message-ID: <3A7B84A8.15091BD4@scruz.net> Bob Tanner wrote: > > Quoting Bob Tanner (tanner@real-time.com): > > $ cvs export -d crossfire-client-0.95.8 -D now client > > boltzmann.eecs.berkeley.edu: Connection refused > > cvs [export aborted]: end of file from server (consult above messages if any) > > > > ? > > > > Ugh, sorry for the typo in the subject. I just did a cvs update without any problems. I would try again - its possible boltzmann was doing or something else was going on making it temporarily unavailable. From mwedel at scruz.net Fri Feb 2 22:20:52 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:53 2005 Subject: [CF-Devel] 100% CPU in gcfclient metaserver query mode References: <01020213303500.30526@debian> Message-ID: <3A7B8724.1A113434@scruz.net> I've fixed the problem by adding a usleep for 10 milleseconds in the get_metaserver function. I'll commit the change shortly - I need to very that my imaging checksumming is all working right, as I have the directory I made that change to also has those changes. Joris Bontje wrote: > > On my workstation I have a nice CPU monitor running... GKrellM (top or wmmon > will do too). After playing a while with the gcfclient and finally exiting my > server, I always get in the metaserver query mode (where you see a list of > all servers). I noticed that my CPU got a continue load of 100%. > > Darth_bob also confirmed this on his system, I rechecked with the latest CVS > version and it keeps eating my CPU. cfclient doesn't show this behaviour. > > 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 scruz.net Fri Feb 2 22:39:03 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:53 2005 Subject: [CF-Devel] new stat generation system. References: <200102021049.CAA17096@tesla.EECS.Berkeley.EDU> Message-ID: <3A7B8B67.DA180137@scruz.net> Just as a note - I don't consider the client rolling stats until some player determined value is reached cheating. Its just a convenience to the player. The design behind the client/server protocl was not to trust the client with anything. So any other 'cheats' the client has are probably also really just conveniences (for example, caching the magic map could be done equally easily if a player did a window/screen area capture). I don't really consider any of that a cheat or problem. However, you (Peter) neglected to note the other client side abuses that are currently open. IF we do decide to let the player choose stats, the total probably will need to be lowered - but as said, I would make that easily tunable in the settings file for example. I would also say that even with player selection, a minimum selected stat of around 5 should perhaps be enforced. Its interesting to note that with a total of 116, that can amount to an average of slightly of 16 for the 7 stats. That seems really high if you think about it - the max starting rolled stat is 18. It basically means that if you could arrange it, you get 6 of your stats at 18, and the last at 8! One reason to enforce a mininum is for races selection - I otherwise see problems with players putting very low values in some stats and then asking/wondering why certain races are not availabel. The real answer is that a race is not available if the stat penatly for that race would reduce it below 1. For most all races, this is a non issue, as the penalties are pretty low (less than 5), and with the current method, it is hard to roll a stat less than that. Part of the server making sure the stat total was within range was also making sure the individual stats are within whatever the desired range. I more reasonable total if we let the player set stats might be around 84 - this presumes an average of 12, and also works out that you can max 3 of your abilities at 18, with the other 4 averaging 7.5 (which will give a minor penalty before race/class adjustments). OTOH, perhaps the high overall stats the current method give work out somewhat good because you get high stats in most things, and those other stats are needed - ie, most characters will eventually need to be able to read and perhaps cast spells and so on - if the stats are lower, this makes it harder later in the game (more stat potions to find). Perhaps the other problem is that the current roll stats gives a very wide range - 82->116. 44 point difference, or an average of about 6.5 points per stat. There is obviously a lot of incentive to re-roll those low ones. From joel at mamia.prninfo.com Fri Feb 2 17:58:40 2001 From: joel at mamia.prninfo.com (Joel South) Date: Thu Jan 13 17:59:53 2005 Subject: [CF-Devel] new stat generation system. In-Reply-To: from "Michael Toennies" at Feb 02, 2001 08:33:28 PM Message-ID: <200102022358.SAA02146@mamia.prninfo.com> Here's another idea. Why not make a set amount of stats,and a smaller amount like ten to add where ever you want. Like you could add them all to one stat or split them equally,ect. Then the stats added on by the class and race bonus. From joel at mamia.prninfo.com Fri Feb 2 19:23:23 2001 From: joel at mamia.prninfo.com (Joel South) Date: Thu Jan 13 17:59:53 2005 Subject: [CF-Devel] am i joined? Message-ID: <200102030123.UAA02342@mamia.prninfo.com> I noticed that when i send a reply it sends it to the writer of the message not to the mailing list. I recieve every email in the list,but i wonder if I did something wrong. From joel at mamia.prninfo.com Fri Feb 2 19:21:11 2001 From: joel at mamia.prninfo.com (Joel South) Date: Thu Jan 13 17:59:53 2005 Subject: [CF-Devel] "Pets" Message-ID: <200102030121.UAA02320@mamia.prninfo.com> Hi. I really think pets shouldn't dissapear when you enter a tightly confined area. Perhaps someone should make it that if the pet cannot fit in the new map,then it would stay behind in the previous one and wait for its owner to come back. I would like this,especially since i'm making a new mapset,in which a main character in my story joins you and follows you around like a pet. From mwedel at scruz.net Sat Feb 3 01:20:35 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:53 2005 Subject: [CF-Devel] am i joined? References: <200102030123.UAA02342@mamia.prninfo.com> Message-ID: <3A7BB143.FE6B4291@scruz.net> Joel South wrote: > > I noticed that when i send a reply it sends it to the writer of the message > not to the mailing list. I recieve every email in the list,but i wonder if > I did something wrong. That is normal behaviour - when someone sends a message to the list, it is still from the original sender. Depending on the mailer, you may have an reply-all function or the like which will also copy the list. From mwedel at scruz.net Sat Feb 3 01:26:42 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:53 2005 Subject: [CF-Devel] "Pets" References: <200102030121.UAA02320@mamia.prninfo.com> Message-ID: <3A7BB2B2.11F573C3@scruz.net> Joel South wrote: > > Hi. > > I really think pets shouldn't dissapear when you enter a tightly confined > area. Perhaps someone should make it that if the pet cannot fit in the new > map,then it would stay behind in the previous one and wait for its owner to > come back. I would like this,especially since i'm making a new mapset,in > which a main character in my story joins you and follows you around like a > pet. This isn't feasible with the way the code is currently done. First, their is no guarentee that the player will ever return to where they left their pets. Second, once the map is swapped out to disk, it is no longer possible to record in any reasonable fashion who the pet belongs to. The real solution is to make sure hte exit has some free space around it so that there will be space for the pests. There is seldom any good reason why this can't be done - usually, when entering a map, the player should not be immediately surrounded by monsters, so having a little space or small chamber that the exit is on should always be possible. From peterm at tesla.EECS.Berkeley.EDU Sat Feb 3 02:06:46 2001 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 17:59:54 2005 Subject: [CF-Devel] CVS problem fixed. Message-ID: <200102030806.AAA23239@tesla.EECS.Berkeley.EDU> From tanner at real-time.com Sat Feb 3 02:40:28 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 17:59:54 2005 Subject: [CF-Devel] CVS snapshot of client is slow? Message-ID: <20010203024028.D23692@real-time.com> Might be my link, but the cvs snapshot of the gtk client seemed very slow. Lack of sleep on my part? -- 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 Sat Feb 3 09:40:06 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 17:59:54 2005 Subject: [CF-Devel] Server pings Message-ID: Hm, since the first problems with server speed comes up here last week, i notice a bad increase in server pings. As i started the dx client, i have to mids or voldsboks server most times a ping of 100-180. Sometimes to mids a ping of <100 ms. Well, last times if start the client i have most times a ping of 350-450 to most server... thats normally the ping i have to tavern server. Now, as i started the client at 16.30 here in germany, i had a ping of >1500ms to mids, 900-1200ms to voldsboks.... other are nearly same high. The funny thing is, thats the server with not so many people online normally now have a better ping. I test then my ping to another online game, subspace. THe Server is in Finland and the ping there is all times same to CF servers in norway or finland and to mids. To the subspace servers at same time as i got the awful CF server pings i had a ping of 150ms - normal as in the last 3 month. There is no other conclusion: THE SERVER CODE IS BROKEN! You can test this with the dx client. Just start a server and monitor the ping with the client. The let others login and play. You should notice that the ping gets up and stands up also when people leave. Before last patches, we are with 12 people on mids, and the ping was under 200ms for me. Michael From pjka at cc.jyu.fi Sat Feb 3 13:08:21 2001 From: pjka at cc.jyu.fi (Pertti Karppinen (OH6KTR)) Date: Thu Jan 13 17:59:54 2005 Subject: [CF-Devel] gcfclient without dmalloc segfaults Message-ID: <20010203210821.A5115@tukki.jyu.fi> It seems, that gcfclient will segfault at start, when compiled without dmalloc lib, atleast on debian 2.2 system. I think same problem is occuring with cfclient also. The segfault comes about with -png graphics, so I suspect, that png.c might be the root of this problem. This sounds like a serious problem to me. Very serious. And 2nd note: We need a unique color for tell&say in gcfclient, as they trun white->black. Perhaps we need to add color to our selection? I vote for magenta, which displays with a lot of different background colors. (And is my favourite color along with pink) -- BSc. Pertti Karppinen |'Bridge Players | Systems Designer, University of Jyvaskyla, Finland | Do | http://www.iki.fi/~pjka/ | Office : +358 14 260 2088 | It | HAM: OH6KTR QTH: KP22UF | Cellular: +358 40 564 0786 | on the Table' | From mwedel at scruz.net Sat Feb 3 17:16:14 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:54 2005 Subject: [CF-Devel] gcfclient without dmalloc segfaults References: <20010203210821.A5115@tukki.jyu.fi> Message-ID: <3A7C913E.52685568@scruz.net> "Pertti Karppinen (OH6KTR)" wrote: > > It seems, that gcfclient will segfault at start, when compiled without > dmalloc lib, atleast on debian 2.2 system. > I think same problem is occuring with cfclient also. > The segfault comes about with -png graphics, so I suspect, > that png.c might be the root of this problem. > This sounds like a serious problem to me. Very serious. I've noticed this problem with running with purify at times. The problem is best I can tell the png.c file is correct now - the actual fault is happening within the png library - I need to compile a debugged version of that and see who is really at fault (ie, are we not passing an appropriately sized structure to it, or is libpng broken in some obscure way) > > And 2nd note: > We need a unique color for tell&say in gcfclient, as they trun white->black. > Perhaps we need to add color to our selection? I vote for magenta, which > displays with a lot of different background colors. (And is my favourite > color along with pink) What really needs to be done is change how the server communicates to the client the messages. Instead of hte server telling the client the color (NDI_BLACK for example), this needs to be re-done so the server tell the client the type of message it is (NDI_ATTACK, NDI_EXP_CHANGE, NDI_STAT_CHANGE, etc). The client can then choose the appropriate color (and a good/clever client might even have a color selector so the player can easily choose the appropriate colors they want). The other reason for this is that potentially, a client may want to have several output windows with different data. For example, you might want to have a relatively small window for the attack messages (5 lines or something), 10 lines for player communications (chat/tell/shout), and 10 lines for other interesting messages. In that way, you can easily carry on a conversation with other players without the messages getting lost in all the attack messages (or id messages or whatever). Likewise, more important messages don't get mixed in with all the attack messages. this can also be enhanced so the chat window may have an entry line which sends the appropriate say/shout/tell command to the server so that you don't need to bind commands to it. This can also be nice for quests where an npc tells you something - presuming that chat window has a scrollbar, you will more easily be able to scroll back to what you were told than you can currently. The server side of this is not hard, just a bit of work. Basic client support would not be hard either (basic support meaning it translate the NDI_ATTACK into being black, stat change into another color, etc). The addition of new windows is a bit harder. Basically, for the server it just means definining new tags for the type of message data and going through updating all the draw info commands to use the new tags. > -- > BSc. Pertti Karppinen |'Bridge Players | > Systems Designer, University of Jyvaskyla, Finland | Do | > http://www.iki.fi/~pjka/ | Office : +358 14 260 2088 | It | > HAM: OH6KTR QTH: KP22UF | Cellular: +358 40 564 0786 | on the Table' | > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From pjka at cc.jyu.fi Sun Feb 4 01:40:20 2001 From: pjka at cc.jyu.fi (Pertti Karppinen (OH6KTR)) Date: Thu Jan 13 17:59:54 2005 Subject: [CF-Devel] gcfclient without dmalloc segfaults In-Reply-To: <3A7C913E.52685568@scruz.net>; from mwedel@scruz.net on Sat, Feb 03, 2001 at 03:16:14PM -0800 References: <20010203210821.A5115@tukki.jyu.fi> <3A7C913E.52685568@scruz.net> Message-ID: <20010204094020.A26966@tukki.jyu.fi> On Sat, Feb 03, 2001 at 03:16:14PM -0800, Mark Wedel wrote: > I've noticed this problem with running with purify at times. The problem is > best I can tell the png.c file is correct now - the actual fault is happening > within the png library - I need to compile a debugged version of that and see > who is really at fault (ie, are we not passing an appropriately sized structure > to it, or is libpng broken in some obscure way) Heh .. that would be a first: crossfire working but a supporting library is broken. Looks like it might be the case here though. > > And 2nd note: > > We need a unique color for tell&say in gcfclient, as they trun white->black. > > Perhaps we need to add color to our selection? I vote for magenta, which > > displays with a lot of different background colors. (And is my favourite > > color along with pink) > > What really needs to be done is change how the server communicates to the > client the messages. Instead of hte server telling the client the color > (NDI_BLACK for example), this needs to be re-done so the server tell the client > the type of message it is (NDI_ATTACK, NDI_EXP_CHANGE, NDI_STAT_CHANGE, etc). > The client can then choose the appropriate color (and a good/clever client might > even have a color selector so the player can easily choose the appropriate > colors they want). Yes. No need for the server to decide the colours for user. And the clients would be easy to modify to work with this change. -- BSc. Pertti Karppinen |'Bridge Players | Systems Designer, University of Jyvaskyla, Finland | Do | http://www.iki.fi/~pjka/ | Office : +358 14 260 2088 | It | HAM: OH6KTR QTH: KP22UF | Cellular: +358 40 564 0786 | on the Table' | From joel at mamia.prninfo.com Sun Feb 4 08:29:30 2001 From: joel at mamia.prninfo.com (Joel South) Date: Thu Jan 13 17:59:54 2005 Subject: [CF-Devel] Going kind of Slow Message-ID: <200102041429.JAA06565@mamia.prninfo.com> The mailing list seems to be going kind of slow lately. From leaf at real-time.com Sun Feb 4 19:39:42 2001 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 17:59:54 2005 Subject: [CF-Devel] Going kind of Slow In-Reply-To: <200102041429.JAA06565@mamia.prninfo.com> Message-ID: Slow as in no traffic or slow as in sending a message and waiting for it to "post" on the list? On Sun, 4 Feb 2001, Joel South wrote: > > The mailing list seems to be going kind of slow lately. > From mwedel at scruz.net Mon Feb 5 01:06:11 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:54 2005 Subject: [CF-Devel] gcfclient without dmalloc segfaults References: <20010203210821.A5115@tukki.jyu.fi> <3A7C913E.52685568@scruz.net> <20010204094020.A26966@tukki.jyu.fi> Message-ID: <3A7E50E3.AABC9F@scruz.net> "Pertti Karppinen (OH6KTR)" wrote: > > On Sat, Feb 03, 2001 at 03:16:14PM -0800, Mark Wedel wrote: > > I've noticed this problem with running with purify at times. The problem is > > best I can tell the png.c file is correct now - the actual fault is happening > > within the png library - I need to compile a debugged version of that and see > > who is really at fault (ie, are we not passing an appropriately sized structure > > to it, or is libpng broken in some obscure way) > > Heh .. that would be a first: crossfire working but a supporting library is > broken. Looks like it might be the case here though. I would double check what version of libpng you have. I can't reproduce the problem on my system anymore (libpng 1.0.8 - 1). Heap checks out just fine. That didn't happen before. Under purify, the client on my sparc would crash with a non debugged libpng (1.0.6). However, when I compiled libpng 1.0.8 with debug information and ran it under purify, not problems happened. This debugged version was statically linked. I then compiled libpng 1.0.8 on my sparc, optimized, installed it, and once again, no problems (client still running under purify). So to me, this really points to me that some versions of libpng may be buggy. I do notice that version 1.0.9 png has recently been released - I haven't checked reliability of that release. From peterm at tesla.EECS.Berkeley.EDU Mon Feb 5 16:18:26 2001 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 17:59:54 2005 Subject: [CF-Devel] Improvement needed on artifact selection code? Message-ID: <200102052218.OAA28786@tesla.EECS.Berkeley.EDU> Hello, I recently added a bunch of rings oriented for fighters, which grant fighting stats at the expense of magic abilities. These rings are popular among the masses, and unfortunately, they're common. For some reason, a Ring of Thieves, for example, comes up more often than a Ring of Halvor. Thieves has a chance of 20 Halvor has a chance of 50 Therefore, you should see 2.5 rings of halvor for every ring of thieves. Instead, you see more rings of thieves. From Philipp.Currlin at t-online.de Mon Feb 5 17:25:42 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 17:59:54 2005 Subject: [CF-Devel] howto for map-making Message-ID: <3A7F3676.78250007@t-online.de> Hello I've just started writing a tutorial on how to make maps (with crossedit) If you have ideas, suggestions, know any tricks, have hints, etc. I would be glad if you would send them to me Phil From Philipp.Currlin at t-online.de Mon Feb 5 17:23:56 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 17:59:54 2005 Subject: [CF-Devel] Paralyzation code broken Message-ID: <3A7F360C.C278C923@t-online.de> Hi, In the past few days I noticed that I never had problems with paralyzation. Even Dread Knights and Titans didn't paralyze me though I only had res +20 on paralyzation. I then tried paralyzation on an two other players who had no protection to it and they didn't get paralyzed either. If someone could check the code please. Phil From leaf at real-time.com Mon Feb 5 18:54:00 2001 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 17:59:54 2005 Subject: [CF-Devel] howto for map-making In-Reply-To: <3A7F3676.78250007@t-online.de> Message-ID: Hi Phil, I started a FAQ for crossedit a while back. I will go back to it and re-apply source formating and add some HTML comments to the page in cause you want to cut & paste any of the content. http://crossfire.real-time.com/FAQs/Crossedit_FAQ/crossedit_faq.html As far as suggestions, include alot of screen shots if possible. From what I have read on the Crossfire web board (http://www.viksten.com/) people are not even sure where to start. i.e., What do they click on to open a new, blank map? After that, then what? - Rick Tanner leaf@real-time.com On Tue, 6 Feb 2001, Philipp Currlin wrote: > Hello > > > I've just started writing a tutorial on how to make maps (with > crossedit) > > If you have ideas, suggestions, know any tricks, have hints, etc. I > would be glad if you would send them to me > > > > Phil > From mwedel at scruz.net Mon Feb 5 21:57:20 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:54 2005 Subject: [CF-Devel] Improvement needed on artifact selection code? References: <200102052218.OAA28786@tesla.EECS.Berkeley.EDU> Message-ID: <3A7F7620.64BA5D31@scruz.net> Peter Mardahl wrote: > > Hello, > > I recently added a bunch of rings oriented for fighters, > which grant fighting stats at the expense of magic abilities. > > These rings are popular among the masses, and unfortunately, > they're common. > > For some reason, a Ring of Thieves, for example, comes up > more often than a Ring of Halvor. > > Thieves has a chance of 20 > Halvor has a chance of 50 > > Therefore, you should see 2.5 rings of halvor for every ring > of thieves. Instead, you see more rings of thieves. > > >From my vague recollections of the code, items up at the top > are favored in the artifact selection over items at the bottom. > > Is this true? Or is the observation just a result of chance? At least looking at the code, what you describe should be correct (See 2.5 rings of halvor for every ring of thieves). The selection of an artifact does not depending on the ordering. After load time, the chance values for all the objects of a type are summed up and stored. When it generates a random artifact, it generates a random number from 0 to that chance value, and traverses the list until the appropriate place is found (subtracts item chance from roll, if less than 0, use that artifact, otherwise continue with same roll) Now there may be some bug someplace - perhaps it isn't totalling the chance right or doing something else odd. But order in the artifact file should not make a difference. From mwedel at scruz.net Mon Feb 5 23:55:43 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:54 2005 Subject: [CF-Devel] Paralyzation code broken References: <3A7F360C.C278C923@t-online.de> Message-ID: <3A7F91DF.24485940@scruz.net> Philipp Currlin wrote: > > Hi, > > In the past few days I noticed that I never had problems with > paralyzation. Even Dread Knights and Titans didn't paralyze me though I > only had res +20 on paralyzation. > > I then tried paralyzation on an two other players who had no protection > to it and they didn't get paralyzed either. > > If someone could check the code please. Please, whenever anyone report a bug, include the version that you are running. In any case, I was able to reproduce the bug and fix it: MSW 2001/02/05: server/attack.c: Fix blind and paralyze - logic for reducing duration was broken, resulting in zero duration for most characters. It should now work properly, reducing according to the amount of protection. From peterm at tesla.EECS.Berkeley.EDU Tue Feb 6 02:58:09 2001 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 17:59:54 2005 Subject: [CF-Devel] Improvement needed on artifact selection code? In-Reply-To: Your message of "Mon, 05 Feb 2001 19:57:20 PST." <3A7F7620.64BA5D31@scruz.net> Message-ID: <200102060858.AAA07752@tesla.EECS.Berkeley.EDU> Well, I tried generating roughly 1000 rings at random, all artifacts. The numbers which showed up were all within expectation for a random distribution of picks, except: 1) Too many Rings of War showed up (not really significant since their numbers were low: I got six, but expected 3) 2) Too few rings of ruling showed up (1 instead of 3) However, neither 1) nor 2) is probably significant due to the small sample involved. PM > Peter Mardahl wrote: > > > > Hello, > > > > I recently added a bunch of rings oriented for fighters, > > which grant fighting stats at the expense of magic abilities. > > > > These rings are popular among the masses, and unfortunately, > > they're common. > > > > For some reason, a Ring of Thieves, for example, comes up > > more often than a Ring of Halvor. > > > > Thieves has a chance of 20 > > Halvor has a chance of 50 > > > > Therefore, you should see 2.5 rings of halvor for every ring > > of thieves. Instead, you see more rings of thieves. > > > > >From my vague recollections of the code, items up at the top > > are favored in the artifact selection over items at the bottom. > > > > Is this true? Or is the observation just a result of chance? > > At least looking at the code, what you describe should be correct (See 2.5 > rings of halvor for every ring of thieves). > > The selection of an artifact does not depending on the ordering. After load > time, the chance values for all the objects of a type are summed up and store >d. > When it generates a random artifact, it generates a random number from 0 to t >hat > chance value, and traverses the list until the appropriate place is found > (subtracts item chance from roll, if less than 0, use that artifact, otherwis >e > continue with same roll) > > Now there may be some bug someplace - perhaps it isn't totalling the chance > right or doing something else odd. But order in the artifact file should not > make a difference. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From peterm at tesla.EECS.Berkeley.EDU Tue Feb 6 04:15:06 2001 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 17:59:54 2005 Subject: [CF-Devel] Changes to the Demonology map Message-ID: <200102061015.CAA18599@tesla.EECS.Berkeley.EDU> Due to a suggestion by philc, I've done the following to the Demonology maps 1) The summoners can see invisible. 2) The undead guardians must be slain in order to ascend the center tower. 3) In order to get to the final treasure chamber, the player must have recently gone up and been marked in all four of the elemental master towers. PeterM From andi.vogl at gmx.net Tue Feb 6 07:00:52 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 17:59:54 2005 Subject: [CF-Devel] howto for map-making In-Reply-To: <3A7F3676.78250007@t-online.de> Message-ID: <000201c0903c$d7aab3e0$739ce23e@kyle> > Hello > > > I've just started writing a tutorial on how to make maps (with > crossedit) This is a great idea, we are in bad need for better tutorials. (We are also in need for a better map-editor, but that is another story ;) ) > If you have ideas, suggestions, know any tricks, have hints, etc. I > would be glad if you would send them to me I worked on large parts of the pupland maps. Think I know quite the tricks... =) Currently, I'm a bit stuffed working for some exams, but in about a week I would be glad to help. For a long time I've planned to write a tutorial on proper usage of all those freakin object-attributes. Maybe I finally get around doing this. =P Andreas V. From andi.vogl at gmx.net Tue Feb 6 07:13:58 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 17:59:55 2005 Subject: [CF-Devel] pocket realities broken Message-ID: <000001c0903e$ab6d1a00$739ce23e@kyle> Using current cvs, the pocket realities (in scorn perm. apartment) are always closed. I suspect that the generated exit-path is somehow wrong. Strange though, "normal" unique maps like the perm. appartments do work. Anyone knows how to fix this? Andreas V. From Philipp.Currlin at t-online.de Tue Feb 6 07:54:05 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 17:59:55 2005 Subject: [CF-Devel] howto for map-making References: <000201c0903c$d7aab3e0$739ce23e@kyle> Message-ID: <3A8001FD.E45F309F@t-online.de> Hi I've started with making a new map and showing the reader around while I explain and show on screen shots what i'm actually doing. I would just make a basic map, add a few monsters, maybe change the attributes of one monster, link to a new map, use levers, mouths and ears, etc.... For the second part of the tutorial I thought about explaining the different features of crossedit in detail and also make a list of the attributes. Phil From peterm at tesla.EECS.Berkeley.EDU Tue Feb 6 13:59:31 2001 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 17:59:55 2005 Subject: [CF-Devel] Using Gorokh as a priesthood--huge handicap Message-ID: <200102061959.LAA31465@tesla.EECS.Berkeley.EDU> I've been playing a low-level Gorokh player, and I have found it horribly debilitating. The lack of healing spells makes normally survivable stuff like a poisoning fatal instead of survivable by means of using minor healing. Also, it is much harder to do an emergency-repair job. The net result is that as a Gorokh priest I die about 3x as much as I would with another religion. I've also enjoyed no benefit to using the religion: without high-end artifacts such as the Ring of Elrond I'm not able to get the Wis quite high enough to get any of the spells by means of prayer. Getting to use "cause serious wounds" is not sufficient compensation for the lack of healing spells. PeterM From Philipp.Currlin at t-online.de Tue Feb 6 14:07:33 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 17:59:55 2005 Subject: [CF-Devel] servers going slow Message-ID: <3A805985.69DD4CF3@t-online.de> Hey I was playing on MichToen's server today and went down to the avatar of the firegod but as soon as he started to cast paralyzation and fire the server went so slow that i couldn't move for about 3 minutes and from then on only about 1 tile in 20 seconds. There were 4 other players on the server at the same time, but that didn't cause any problems before this bug first appeared. Now we can only seldom play for more than two hours without the server getting too slow. Sometimes it gets even slow when there is only one player on. I've been talking with Raistlin who is usually playing on Mids or on Voldsbooks and these servers seem to have the same problem. MichToen is running the CVS-Version from february 5 and Voldsbooks is using the version from january 25. Phil From peterm at tesla.EECS.Berkeley.EDU Tue Feb 6 14:08:25 2001 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 17:59:55 2005 Subject: [CF-Devel] Persistent problems with Word of Recall Message-ID: <200102062008.MAA32211@tesla.EECS.Berkeley.EDU> Hello, In the latest CVS, word of Recall won't work for me under these circumstances: 1) I use the savebed in my apartment 2) my char is "saved" somewhere else 3) my apartment isn't in the server memory Under these circumstances, when I try to use Word of Recall, I get: "force is closed." and go nowhere. What is happening is that my apartment is failing to be loaded. If, however, I "freshen" my apartment before casting word of recall by visiting my apartment, it works fine. PeterM From Philipp.Currlin at t-online.de Tue Feb 6 14:38:57 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 17:59:55 2005 Subject: [CF-Devel] word of recall not working Message-ID: <3A8060E1.1533BF51@t-online.de> On all servers updated in the last few days Word of Recall is not working anymore most of the time. Sometimes it does work but so far I couldn't find out when it's working and when it is not working. It does not seem to depend on the map or on what you are doing after speaking the prayer. When you speak the prayer you get the usual message: "You feel a force starting to build up inside you." But after some time, usually longer than it should be, you get: "The force is closed." This bug appears in a similar way when you die. The message there is: "The is closed." You loose your experience and stats as usual but you stay on the map as if you had an amulet of lifesaving. This once caused me to loose 58 levels and get my char back to level 10. I was trying to kill some elite dread knights and dread knights. I've done this before so I knew what i was doing. Well this time my connection got too slow with all the paralyzation (which didn't work anyway) and my char was just standing there and couldn't move anymore. I had to wait for the last EDK to kill himself, get a second char and kill the last DK with him. But that was too late :( Phil From Philipp.Currlin at t-online.de Tue Feb 6 16:17:15 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 17:59:55 2005 Subject: [CF-Devel] Persistent problems with Word of Recall References: <200102062008.MAA32211@tesla.EECS.Berkeley.EDU> Message-ID: <3A8077EB.4F22EFC6@t-online.de> Hi I've just tried this: left crossfire on the savebed in my appartement and came back right away. First test: Left the apartment, used WOR, got back to my appartement (still in scorn) Second: Lef t the apartment again, saved in scorn, used WOR, worked too Phil Peter Mardahl wrote: > Hello, > > In the latest CVS, word of Recall won't work for me under > these circumstances: > > 1) I use the savebed in my apartment > 2) my char is "saved" somewhere else > 3) my apartment isn't in the server memory > > Under these circumstances, when I try to use Word of Recall, > I get: "force is closed." and go nowhere. > > What is happening is that my apartment is failing to be loaded. > > If, however, I "freshen" my apartment before casting word of recall > by visiting my apartment, it works fine. > > PeterM > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From peterm at tesla.EECS.Berkeley.EDU Tue Feb 6 17:45:50 2001 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 17:59:55 2005 Subject: [CF-Devel] Persistent problems with Word of Recall Message-ID: <200102062345.PAA16800@tesla.EECS.Berkeley.EDU> ------- Forwarded Message > Hi > > I've just tried this: left crossfire on the savebed in my appartement > and came back right away. > First test: Left the apartment, used WOR, got back to my appartement > (still in scorn) > Second: Lef t the apartment again, saved in scorn, used WOR, worked too You did NOT try what I described: you failed condition #3. To do what I described, you'd have to: 1) Log out your client after you saved in scorn and wait a LONG time. 2) Save in scorn and the server suffers a crash. PeterM > > Phil > > > > Peter Mardahl wrote: > > > Hello, > > > > In the latest CVS, word of Recall won't work for me under > > these circumstances: > > > > 1) I use the savebed in my apartment > > 2) my char is "saved" somewhere else > > 3) my apartment isn't in the server memory > > > > Under these circumstances, when I try to use Word of Recall, > > I get: "force is closed." and go nowhere. > > > > What is happening is that my apartment is failing to be loaded. > > > > If, however, I "freshen" my apartment before casting word of recall > > by visiting my apartment, it works fine. > > > > 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 Wed Feb 7 01:09:08 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:55 2005 Subject: [CF-Devel] pocket realities broken References: <000001c0903e$ab6d1a00$739ce23e@kyle> Message-ID: <3A80F494.DB70CBB1@scruz.net> Andreas Vogl wrote: > > Using current cvs, the pocket realities (in scorn perm. apartment) > are always closed. I suspect that the generated exit-path is > somehow wrong. Strange though, "normal" unique maps like the > perm. appartments do work. > > Anyone knows how to fix this? Yeah, but its a real pain. The basic problem is that using relative pathnames (ie, just Apartments5) on per player unique maps do not work. I'm seriously considering just updating the map files, and not support relative map paths on unique maps. I'll poke some more at this tonight, but the more I poke into this, the bigger the can of worms. This can certainly be made to work, as it worked before, but I've already doubled the size of enter_unique_map, and there are still more changes. This seems pretty excessive to support a feature of otherwise limited use. From mwedel at scruz.net Wed Feb 7 01:55:13 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:55 2005 Subject: [CF-Devel] exit changes checked in. Message-ID: <3A80FF61.5A64D2AB@scruz.net> From my testing, this appears to fix the pocket realities as well as the word of recall to unique maps: MSW 2001/02/06: common/porting.c: relocate clean_path from this file to server/main.c server/main.c: relocate clean_path from porting.c. Add unclean_path. Modify enter_unique_exit so it supports relative maps on unique maps. Modify enter_exit so word of recall (or other forcelike fields), work when the return point is a swapped out unique map. From mwedel at scruz.net Wed Feb 7 01:57:01 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:55 2005 Subject: [CF-Devel] servers going slow References: <3A805985.69DD4CF3@t-online.de> Message-ID: <3A80FFCD.A295DAAD@scruz.net> What will really help when the servers are running slow is do a 'malloc command and grab the results and send it to me/the list. I can not readily reproduce the performance issue, but the output from the malloc will at least eliminate or narrow down what the problem may be. From Philipp.Currlin at t-online.de Wed Feb 7 13:48:03 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 17:59:55 2005 Subject: [CF-Devel] servers going slow References: <3A805985.69DD4CF3@t-online.de> <3A80FFCD.A295DAAD@scruz.net> Message-ID: <3A81A673.BE2A3E1D@t-online.de> Hi This is the first time the server is getting slow so I'm just sending the output of malloc now, because the server will reset in 15 minutes anyway and i won't have a chance to slow it down any further. Phil output of malloc: Sizeof: object=348 player=154924 map=4168 59673 used objects: 20766204 1627 free objects: 566196 7046 active objects: 0 1 players: 154924 71 maps allocated: 295928 52 maps in memory: 510492 2610 archetypes: 960480 3727 animations: 7454 202 spells: 12120 225 treasurelists 3600 1572 treasures 37728 272 artifacts 4352 281 artifacts strngs 2248 18 artifactlists 216 Total space allocated:23321942 Total space used: 22676554 From Philipp.Currlin at t-online.de Wed Feb 7 18:18:08 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 17:59:55 2005 Subject: [CF-Devel] bug in arena Message-ID: <3A81E5C0.CED6CC85@t-online.de> Hi again :) If someone pays for the arena, steps on the teleporter and leaves it again the next person to step on the other teleporter will get teleported to the next room while the first person stays on the teleporter (if he stepped on it again). The gates will both be closed and they can't be opened again leaving the people locked inside. Only way to get out: to kill himself or use word of recall, afaik Phil From leaf at real-time.com Wed Feb 7 20:44:39 2001 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 17:59:55 2005 Subject: [CF-Devel] Possible exploit in Scorn Potion shop Message-ID: I am not sure if this is really an exploit or not, or maybe even a bug. But, since you can't gain experience identifying things you purchase in other stores, here it is... In the lab area of the Scorn Potion shop you can buy alchemy ingredients. After the ingredients are in your inventory, you can use the skill alchemy to identify them and gain mental experience. You can also use the woodsman skill if you purchase water to gain mental experience. I am playing on v0.95.8-cvs from 02-Feb-01 - Rick Tanner leaf@real-time.com From andi.vogl at gmx.net Thu Feb 8 14:26:28 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 17:59:55 2005 Subject: [CF-Devel] bug in arena In-Reply-To: <3A81E5C0.CED6CC85@t-online.de> Message-ID: <000001c0920d$6ba6d660$f4a3e23e@kyle> > Hi again :) > > > If someone pays for the arena, steps on the teleporter and leaves it > again the next person to step on the other teleporter will get > teleported to the next room while the first person stays on the > teleporter (if he stepped on it again). The gates will both be closed > and they can't be opened again leaving the people locked inside. > > Only way to get out: to kill himself or use word of recall, afaik After the first person stepped on and off the teleporter, there is only a short period of time (like 10 seconds) where the second character could get trapped by stepping on the other teleporter. I created that map, and I saw this little "problem". I consider it harmless and tolerable. If people just don't do what they obviously are expected to, thus get trapped, and don't have WoR - their fault. Anyways, I might insert a magic_mouth when I have the time, telling like: "both step on the teleporters and stay there". If you want it happen right now, I welcome anyone doing this for me. Andreas V. From mwedel at scruz.net Fri Feb 9 01:33:57 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:55 2005 Subject: [CF-Devel] [Fwd: [Crossfire-cvs] CVS update: crossfire/server] Message-ID: <3A839D65.8EB0810F@scruz.net> As a note - I believe this change below should fix the performance problems. -------------- next part -------------- An embedded message was scrubbed... From: crossfire-cvs-admin@lists.sourceforge.net Subject: [Crossfire-cvs] CVS update: crossfire/server Date: Thu, 8 Feb 2001 23:30:37 -0800 Size: 5042 Url: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010208/14b51392/attachment.mht From Philipp.Currlin at t-online.de Fri Feb 9 09:26:46 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 17:59:55 2005 Subject: [CF-Devel] weird case of inflict disease Message-ID: <3A840C35.D3FFCC18@t-online.de> Hi I was playing CF when i suddenly got the message: "You feel ill." even though there were no monsters around. A few seconds later another player shouted: "You inflict Garet with disease cause flu." He did not have that disease and he did not cast that disease. I was somewhere in the temple getting a glowing crystal and the other player was in Brest in the castle. Phil From Philipp.Currlin at t-online.de Fri Feb 9 10:26:43 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 17:59:56 2005 Subject: [CF-Devel] way to crash of server Message-ID: <3A841A43.8607A656@t-online.de> Hi Someone crashed MT's server (CVS 2001-02-07) today by having two new chars kill each other in the HallOfSelection before choosing a class. Phil From michael.toennies at nord-com.net Fri Feb 9 13:13:39 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 17:59:56 2005 Subject: [CF-Devel] way to crash of server In-Reply-To: <3A841A43.8607A656@t-online.de> Message-ID: Hm This Hall of Selection brings me to some other older idea. Is it possible to create this map and perhaps other too as temp "personal" maps? Mean on char per map, like the appartments. In the case of the hall of Selection is this a good thing. These "temp personal" maps are memory only. There is no need to save them. And when i think about it, i saw more potential for them also in normal map design. Michael > -----Original Message----- > From: crossfire-devel-admin@lists.real-time.com > [mailto:crossfire-devel-admin@lists.real-time.com]On Behalf Of Philipp > Currlin > Sent: Friday, February 09, 2001 5:27 PM > To: crossfire-devel@lists.real-time.com > Subject: [CF-Devel] way to crash of server > > > Hi > > > > Someone crashed MT's server (CVS 2001-02-07) today by having two new > chars kill each other in the HallOfSelection before choosing a class. > > > > 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 Sat Feb 10 02:00:03 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 17:59:56 2005 Subject: [CF-Devel] howto for map-making In-Reply-To: <3A7F3676.78250007@t-online.de> Message-ID: On Tue, 6 Feb 2001, Philipp Currlin wrote: > Hello > > > I've just started writing a tutorial on how to make maps (with > crossedit) > > If you have ideas, suggestions, know any tricks, have hints, etc. I > would be glad if you would send them to me Certainly, a few tricks I have recently just learnt about, a) Use copy, it saves alot of time. * Make a perfect block of all the tiles you want, then select that square. * Select a completely blank square, and paste. b) Use png/xpm * run with -png of -xpm flags, pretty obvious but very important. c) When in doubt go searching * If you aren't sure about something, think back to a map that does something similar or the same, use the copy command. d) slow progression * Don't create a map that has monsters the second you walk in, or dragons behind the first door (dragon hangar is what you don't want) e) have fun! dnh =) > > 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 Sat Feb 10 03:03:21 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:56 2005 Subject: [CF-Devel] way to crash of server References: Message-ID: <3A8503D9.85F4A0E2@scruz.net> Michael Toennies wrote: > > Hm > This Hall of Selection brings me to some other older idea. > > Is it possible to create this map and perhaps other too as temp "personal" > maps? Mean on char per map, like the appartments. > > In the case of the hall of Selection is this a good thing. > > These "temp personal" maps are memory only. There is no need to > save them. > > And when i think about it, i saw more potential for them also in normal > map design. > > Michael I'll probably add some setting which basically says to just purge the map from memory and not swap them out. The hall of selection is a little odd in that a player is moved into it via the server code and not an exit. It should be pretty easy to modify that at least so it loads one per player. It would actually not be hard to do this for exits in general (basic code effect is to always call load original map and never ready map name). I'm unsure of the need and desire to do this. first, crossfire is a multi player game, so maps should generally be accessible by all players. If you get a proliferation of maps that are per player instance, that sort of removes the multiplayer feature. Second, depending on how such maps are done, I could see it being pretty easy for players to make a significant performance impact on the server (ie, hop on to a per player instance map, hop off, hop back in where a new instance is loaded, hop back off, etc). This can start creating fairly considerable load on the server. From tanner at real-time.com Sat Feb 10 03:41:57 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 17:59:56 2005 Subject: [CF-Devel] collect.pl Message-ID: <20010210034157.O29354@real-time.com> Can someone explain to me how collect.pl works? Running it like collect.pl my/path/to/arch gives me all sorts of warnings and errors(?) on files. Warning: /var/tmp/crossfire-0.95.8.arch/CHANGES might be a junk file Warning: /var/tmp/crossfire-0.95.8.arch/Naming.doc might be a junk file collect.pl: poison_fog duplicate fg color green/yellow face poisonc.111 collect.pl: poison_fog duplicate fg color green/yellow face poisonc.111 collect.pl: poisoncloud duplicate fg color yellow/green face poisonc.112 collect.pl: poisoncloud duplicate fg color yellow/green face poisonc.113 collect.pl: gnome_player duplicate magicmap color green/blue face gnome.111 collect.pl: gnome_player duplicate magicmap color green/blue face gnome.111 collect.pl: gnome_player duplicate magicmap color green/blue face gnome.112 collect.pl: gnome_player duplicate magicmap color green/blue face gnome.111 collect.pl: gnome_player duplicate magicmap color green/blue face gnome.112 -- 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 Feb 10 14:36:31 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 17:59:56 2005 Subject: [CF-Devel] new wall faces for png Message-ID: <000001c093a1$290e61c0$b521993e@kyle> I noticed on many maps that walls are used "incorrectly" in regard of perspective. That doesn't matter for xpms because they are so small that perspective is hardly noticed. But for the larger pngs it looks really ugly. So I've created some totally new kinds of wall faces. As an "example", I changed the zoo in scorn and the HallOfSelection to take advantage of these new images. I made snapshots so you can see the difference "before - afterwards": Right now the new pics are simply invisible in xpm mode, but I think they could be drawn in xpm pretty much alike. I'd like to change more maps to take advantage of this new "look". So, tell me what you think about it. Is it okay to do so? Does anyone have objections? Andreas V. From mwedel at scruz.net Sat Feb 10 17:00:23 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:56 2005 Subject: [CF-Devel] new wall faces for png References: <000001c093a1$290e61c0$b521993e@kyle> Message-ID: <3A85C807.6C0AA3F@scruz.net> I don't have nay big problems with it. It will mean the server will consume a little more memory, and the client will take a little more bandwidth (as the image data needs to be sent to them). A while back, I believe Bt had suggested making curves for other terrain types (forests, plains, etc) so things wouldn't be so blocky. I can't remember why I said it was a bad idea at the time - probably for the same reasons as above, but computers and bandwidth have changed quite a bit since that time. If someone wants to revisit that idea, it seems fine to me. Andreas Vogl wrote: > > I noticed on many maps that walls are used "incorrectly" > in regard of perspective. That doesn't matter for xpms because > they are so small that perspective is hardly noticed. But for > the larger pngs it looks really ugly. > > So I've created some totally new kinds of wall faces. > As an "example", I changed the zoo in scorn and the HallOfSelection > to take advantage of these new images. I made snapshots so > you can see the difference "before - afterwards": > > > Right now the new pics are simply invisible in xpm mode, but I > think they could be drawn in xpm pretty much alike. > I'd like to change more maps to take advantage of this new "look". > So, tell me what you think about it. Is it okay to do so? > Does anyone have objections? > > Andreas V. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From mwedel at scruz.net Sat Feb 10 17:12:44 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:56 2005 Subject: [CF-Devel] collect.pl References: <20010210034157.O29354@real-time.com> Message-ID: <3A85CAEC.A5319C2C@scruz.net> The first 2 warnings are just that - warnings. It just complains about files it finds that doesn't match againsts its known type of files. The warning about colors is a little more complicated. At one point, color values for archetype attributes, so multiple archetypes using the same face could specify different colors for it. Things have changed, so that colors are not attributes of the face, and not archetypes. However, for compatibility and ease of use, color for the faces can/is included in the .arc file. What the messages below say is that multiple .arc files are specifying the colors for the same faces. I believe in this case, these are more warnings, as the second arc file is specifying the same colors. If it was specifying different colors, I believe the messages would say such. The fix here is to just remove the color attributes from the second arc file. Bob Tanner wrote: > > Can someone explain to me how collect.pl works? > > Running it like collect.pl my/path/to/arch gives me all sorts of warnings and > errors(?) on files. > > Warning: /var/tmp/crossfire-0.95.8.arch/CHANGES might be a junk file > Warning: /var/tmp/crossfire-0.95.8.arch/Naming.doc might be a junk file > > collect.pl: poison_fog duplicate fg color green/yellow face poisonc.111 > collect.pl: poison_fog duplicate fg color green/yellow face poisonc.111 > collect.pl: poisoncloud duplicate fg color yellow/green face poisonc.112 > collect.pl: poisoncloud duplicate fg color yellow/green face poisonc.113 > collect.pl: gnome_player duplicate magicmap color green/blue face gnome.111 > collect.pl: gnome_player duplicate magicmap color green/blue face gnome.111 > collect.pl: gnome_player duplicate magicmap color green/blue face gnome.112 > collect.pl: gnome_player duplicate magicmap color green/blue face gnome.111 > collect.pl: gnome_player duplicate magicmap color green/blue face gnome.112 > > > -- > 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 andi.vogl at gmx.net Sat Feb 10 18:19:36 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 17:59:56 2005 Subject: [CF-Devel] map-making tutorial Message-ID: <000001c093c0$52a7b3a0$529ee23e@kyle> I started writing a crossfire map-making tutorial, focusing on detailed description of all those freaky object-attributes. Take a look at . It's not even half done though. Currently it covers 18 object-types, about 130 more to go... :P As you can imagine, I would greatly appreciate any support I can get. (I permanently need to look into the source, that is very time-consuming.) But I don't have problems doing it alone either. It's just likely to take me a few months then, since I don't feel like working on that page day and night :) Honestly, I don't even want to make any promise that I'm gonna finish it. But I think every single bit I write will help. Andreas V. From michael.toennies at nord-com.net Sat Feb 10 18:54:16 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 17:59:56 2005 Subject: [CF-Devel] RE: rogue like games gfx In-Reply-To: <5.0.0.25.0.20010210231624.00a4dcd0@m1.271.telia.com> Message-ID: > -----Original Message----- > From: M?rten Woxberg [mailto:maxmc@telia.com] > Sent: Saturday, February 10, 2001 11:20 PM > To: Michael Toennies > Subject: Re: rogue like games gfx > > > > >We have one problem: After changing the gfx tiles from 24x24x16 xpm tiles > >to 32x32 true color png files, we lake in good gfx. Because we have some > >powerful animation system also for multi tile monsters, we can > also put in > >animated monsters/gfx of any size. > > I've downloaded the DX client and ran around everywhere to see what > kind of tiles there is.. > I've made some small updates but It's going to take a while.. > even if Im only replacing images with what I allready have.. > > Although I have a problem... which colors are transparent > and which do something else.. > Im using Paintshop pro currently and it's not that nice to > the palette.. I'll try Gimp for windows tonight.. > > I hope the naming convension is the same on all servers.. > eg. I can replace the pictures in my cache with my pictures > and keep the name? > > I'll upload a zip this week to my site, with the updated graphics.. > it won't be more than 20 tiles or so.. but it's a start.. > > > /M?rten > http://come.to/trgp The Roguelike Graphics Page (Maintainer) > http://jihad.leminator.org Jihad Roguelike (Tile Artist) > > > From michael.toennies at nord-com.net Sun Feb 11 17:54:35 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 17:59:56 2005 Subject: [CF-Devel] FW: FW: rogue like games gfx (2nd) Message-ID: This is also a fine artist. As you can read, we have permission to use his tiles. Please be sure to add him to credits when you log in one of them. Also, we should contact him when we change them. I THINK when we cut of for example a little dragon of him and ask him "can you draw another animation to this?" he will do it. For people like him (also when he at this time had other work) we need a new and better map editor. When CF is 1.0 and more people join in, it will have much more ppl than the other graphical rogoue like games i saw. We should be prepared for it. A editor where you can make new maps AND create new arches / animations. Its easy to add for a java editor for example a little tool, where you can animate and/or cut down monsters to 32x32 tiles. But for all this people is like i said: They never will work for xpm and 24x24 anymore. All goes up to 32x32 and true color. One more: we don't need xpm anymore. Its wasted space, time and it makes the game more complex for people to join. Michael > -----Original Message----- > From: David [mailto:david_eg@mail.com] > Sent: Sunday, February 11, 2001 9:25 PM > To: Michael Toennies > Subject: Re: FW: rogue like games gfx > > > Hello, Michael Toennies > > As you may well know my 'FREE' Roguelike tiles are being used in > several games > as of now. I visited your site for Crossfire and believe that your game is > open source/freeware and that means that you can use my tiles to > your hearts > content. You can get my tiles at... > > http://w1.271.telia.com/~u27102957/index2.html > > Just follow the links to 'Graphics Library' and select David E. Gervais' > tiles. > > I'm currently working on a new set of Isometric tiles for a > Roguelike of my > own and do not have time to devote to doing any 'custom' tiles > for your game, > but you can feel free to use the ones I already made. > > FYI I'm basically redoing the 'terrain' and 'Feature' tiles, I'll > be using my > existing monsters along with all the other stuff. There are some > screenshots > at the above link showing my ISO game. > > Have fun and enjoy! > > P.S. If you do use any of my tiles be sure to mention my name in > the credits! > > David E. Gervais > ___________________________________________________ > One voice, One mind, Many thoughts, and always kind > From peterm at tesla.EECS.Berkeley.EDU Mon Feb 12 00:26:46 2001 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 17:59:56 2005 Subject: [CF-Devel] FW: FW: rogue like games gfx (2nd) In-Reply-To: Your message of "Mon, 12 Feb 2001 00:54:35 +0100." Message-ID: <200102120626.WAA20777@tesla.EECS.Berkeley.EDU> I agree that these tiles of his are very good. However, they aren't the proper perspective for crossfire's PNG set. If we're going to violate the perspective rule, I'd like to see a lot of the existing xpm images taken verbatim into the png set, so that we can keep the best of the xpm art. A lot of the xpm art is nearly as good as what this guy has produced. PeterM > This is also a fine artist. > > As you can read, we have permission to use his tiles. > Please be sure to add him to credits when you log in one of them. > Also, we should contact him when we change them. > > I THINK when we cut of for example a little dragon of him and ask him > "can you draw another animation to this?" he will do it. > > For people like him (also when he at this time had other work) > we need a new and better map editor. > > When CF is 1.0 and more people join in, it will have much more ppl than the > other graphical rogoue like games i saw. We should be prepared for it. > > A editor where you can make new maps AND create new arches / animations. > Its easy to add for a java editor for example a little tool, where you can > animate and/or cut down monsters to 32x32 tiles. > > But for all this people is like i said: They never will work for xpm and > 24x24 anymore. > All goes up to 32x32 and true color. > > One more: we don't need xpm anymore. Its wasted space, time and it makes the > game more complex > for people to join. > > Michael > > > > -----Original Message----- > > From: David [mailto:david_eg@mail.com] > > Sent: Sunday, February 11, 2001 9:25 PM > > To: Michael Toennies > > Subject: Re: FW: rogue like games gfx > > > > > > Hello, Michael Toennies > > > > As you may well know my 'FREE' Roguelike tiles are being used in > > several games > > as of now. I visited your site for Crossfire and believe that your game is > > open source/freeware and that means that you can use my tiles to > > your hearts > > content. You can get my tiles at... > > > > http://w1.271.telia.com/~u27102957/index2.html > > > > Just follow the links to 'Graphics Library' and select David E. Gervais' > > tiles. > > > > I'm currently working on a new set of Isometric tiles for a > > Roguelike of my > > own and do not have time to devote to doing any 'custom' tiles > > for your game, > > but you can feel free to use the ones I already made. > > > > FYI I'm basically redoing the 'terrain' and 'Feature' tiles, I'll > > be using my > > existing monsters along with all the other stuff. There are some > > screenshots > > at the above link showing my ISO game. > > > > Have fun and enjoy! > > > > P.S. If you do use any of my tiles be sure to mention my name in > > the credits! > > > > David E. Gervais > > ___________________________________________________ > > One voice, One mind, Many thoughts, and always kind > > > > _______________________________________________ > 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 Tue Feb 13 01:02:52 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 17:59:56 2005 Subject: [CF-Devel] 0.96.0 client Message-ID: <20010213010252.C25088@real-time.com> Mark, let me know when you are done committing, I'll roll a new 0.96.0 client. -- 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 Tue Feb 13 01:14:43 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 17:59:56 2005 Subject: [CF-Devel] 2nd request: PGP key for crossfire development team Message-ID: <20010213011443.A26843@real-time.com> This is my 2nd request for a PGP for the crossfire development team. I'd like a key so I can sign the client RPMs. If no one objects, I'll make a key using gpg, 2048bits and have it expire in 365 days. Any objections? -- 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 Tue Feb 13 01:14:05 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:58 2005 Subject: [CF-Devel] Crossfire 0.96.0 released. Message-ID: <3A88DEBD.BB01251A@scruz.net> Crossfire 0.96.0 has been released. Despite many changes from the last release, this release should be quite stable - its been tested fairly extensively. Unless serious bugs are detected, this will likely be the last release before 1.0. Main changes: New random map layouts added. Re-done player exit code - this should hopefully fix players appearing in the middle of oceans. Server will send image checksums to client when client is caching images - in this way, client knows to request new image or not (both client and server change) New spells PNG support added to editor. Partial Resistance code added. Protections now have numeric values, and add up. A complete list of changes is at the bottom of this message. NOTE TO MIRROR SITES: The primary site (ftp.scruz.net) has limited download bandwidth per day. If this poses a problem, you want a more reliable method, or you just want a backup method. please drop me a mail message - I have set up a secondary server off my ADSL link, but being that only has 128 kb upstream bandwidth and is also used for other interactive purposes, I don't want to make it available to all. Files released for this version: sums (bsd) filename 04869 1507 crossfire-0.96.0.arch.tar.bz2 65381 1796 crossfire-0.96.0.arch.tar.gz 63394 2645 crossfire-0.96.0.maps.tar.bz2 12882 3807 crossfire-0.96.0.maps.tar.gz 11913 2641 crossfire-0.96.0.tar.bz2 60544 2967 crossfire-0.96.0.tar.gz 27062 237 crossfire-client-0.96.0.tar.gz Sums (md5) 709ccf30ed6489dc3673b93be20b105b crossfire-0.96.0.arch.tar.bz2 290f8cb22336459b2ac9f42a440954e9 crossfire-0.96.0.arch.tar.gz b0b21296ba967e90388bce9b789a49ff crossfire-0.96.0.maps.tar.bz2 76c6574c7fb50d3fe27dfc659f4c1be3 crossfire-0.96.0.maps.tar.gz d29d939ccc7d0e02e14949e23f2109fb crossfire-0.96.0.tar.bz2 cf42d4c6f2ef2595424a14a110a8bcbb crossfire-0.96.0.tar.gz 2b6d9d9d6c355082a467805a301e7eb4 crossfire-client-0.96.0.tar.gz crossfire-client-0.96.0 is the client (X11) distribution - standard X11 and gtk interfaces are provided. crossfire-0.96.0.tar.{gz/bz2} contains the server code with prebuilt archetype and image files. crossfire-0.96.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-0.96.0-maps.tar.{gz/bz2} contains the maps. This is needed with the server distribution. No doc archive at this time - I don't believe anything in it should have changed much. 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.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 - it should be on the other ftp sites in a short time. Mark Wedel mwedel@scruz.net 01/28/2000 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Changes: Client: MSW 2001/02/02: Protocol: Update with new face1 command that includes checksum. client.c: add face1 protocol command. client.h: Update version_sc to 1026. commands.c: Move FaceCmd from gx11.c/x11.c to this file, since it now only does decoding of data and passes rendering off to appropriate file. Also add Face1Cmd function that deals with checksum. Both of these functions pass off the rendering to the same function. gx11.c: add keepcache variable, re-do facing loading/caching - if we have local version of face, generate checksum of it and compare to that against what server has. finish_face_command added to do this - called by the face functions in commands.c. Add -keepcache command line option which will have it not request images from server if checksum is different. Add usleep in metserver selection area to prevent client from hogging all the cpu time. item.c: Add support for ^ in items file to say only match at start of line. Useful for 'bolt' - doing substring also matched against firebolt. item_types, item_types.h: make bolt ^bolt, add Head and hauberk to matching criteria. proto.h: automatic regen. x11.c: As gx11.c above, plus: Use one font for all windows - reduces complexity. Add easy selection of font to use with -font command line option. xutil.c: As gx11.c for relevant functions that are located in this file and not x11.c End of MSW 2001/02/02 checkin. MSW 2001/01/31: client.c: Clear player inventory and look windows after disconnection from server. Prevents client crashes. gx11.c: various fixes - window placement no longer always centered on screen (very obnoxious if running xinerama), various prototypes fixed up, clear map data after clearing image data. player.c: Add suport for 'mapredraw' command. Not that this should ever really be needed, but the server supports it, so its nice to be able to use it. x11.c: Fixes prototype/casting problems when clearing pixmaps. Like gx11.c, clear map data. xutil.c: add better description to the unbind command. MSW 2001/1/13 (except as mentioned, all changes by MSW): Makefile.in: Create destination dirs, remove extra tab. Patch also by Dave. Protocol: typo fixed. config.h, config.h.in: Add HVAE_DMALLOC_H #ifdefs. Checks currently disable in configure.in, as with it, the sound won't like properly since it needs -ldmalloc, and I haven't bothered investing that much time into fixing the Makefile. gx11.c: Patches by Dave Peticolas - mostly code cleanup, but one new feature is support of wheel mice to move the scrollbars. png.c: No real code change, just adjustments in some ordering which I think makes the code appear a little simpler. x11.c: Minor code cleanups, some formatting changes, some to make better error messages. End of MSW 2000/1/13 checkin. MSW 2001/1/8: client.h: Change damage type to be 16 bits. MSW 2000/12/24: png.c: Fix a major memory corruption issue - the png function was re-allocing for a larger hunk of data, but did not update the pointer and was still using the pointer to the smaller hunk. Severity of this bug depended on luck - if the first png downloaded happened to have the full 4 bytes/pixel, it never needed to do a realloc so would work fine. Otherwise, a matter of luck what data got stomped over. Also, modified the main function in this file so that it you can compile against it and it now works with the new in memory data read. MSW 2000/12/19: Metaserver update. Most files updated. This change has the client connect the metaserver and lets the user choose which server to connect to. Also, if the client loses a connection (either because the player has quit playing or the server died), the client will no longer exit and instead go back to the server selection screen. A few unrelated changes (cfclient): when running cache, non downloaded images should look better. Also, client starts up with larger window in Png mode to take into account the extra space png images takes up in the game window. Changes by file: Makefile.in: Add metaserver.c file. cconfig.h: Add metaserver configuration information. client.c: Add meta_ variables, move resists_name to this file, no longer have DoClient exit if it gets an error on the socket (instead mark the fd as -1 and return), change main loop such that if connection to server has been lost, go through loop to establish a new connection. client.h: Add Metaserver_Select input state. Change resists_name from a static to extern. gx11.c: Remove some unused code, various code cleanups, and additions to support the metaserver connection process. init.c: Add reset_client_vars - call it between connections to servers. proto.h: rebuilt for new functions. x11.c: Update for metaserver connection status. If running Png mode, have windows created larger. xutil.c: When creating default images for cache, create 32x32 images for png mode, not 24x24 images. metaserver.c: New file for metaserver code. End MSW 2000/12/19 checkin. MSW 2000/12/10: png.c, gx11.c, x11.c, xutil.c: modified to use in memory loading of png's. This means that if not caching images, we don't need to write it out to a temp file. This should result in a minor performance gain, but also remove the need of using tmpnam. Also, modified gx11.c so that it uses same logic as the x11 client for extended command key ('). Before gx11.c client would use both ' and ", and there was no way to unbind the later - since one can always bind the command key, I found that a bit annoying. Updated to display resistance values in the message window. Except for armour, this is only displayed when running against serves with PR code. Change for both cfclient and gcfclient. Files affected: Protocol client.h commands.c gx11.c newclient.h player.c sounds soundsdef.h x11.c MSW 12-3-2000 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Server: MSW 2001/01/11: include/rproto.h: Rebuilt for new random map code. server/player.c: remove player insert in key_roll_stat - player is already inserted. server/swap.c: When swapping out map, see if it has already reached reset time, and if so, just delete it and not save it. In flush_old_maps, now have it check for maps that have no timeout set - this sometimes happens when players save/die on maps. MSW 2001/01/11: Other than various general cleanups, the main change this code does is that style maps (for random maps) get loaded special now - they objects they contain are not put on the active list, and they use a private map list so they do not appear in the output of the 'maps command. common/arch.c, common/treasure.c,server/login.c: Update calls to load_object common/loaderl.l,loader.c: Update lex_load to take an optional flags option. This is currently only used so that the loader can decide if it should call update_ob_speedto put objects on the active list or not. Calls to lex_load updated. load_object modified to take another option common.map.c: remove PROCESS_WHILE_LOADING and CHECK_ACTIVE_MAPS ifdefs. update calls to load_object. Remove some dead code. include/config.h: Remove CHECK_ACTIVE_MAPS and PROCESS_WHILE_LOADING flags. Those options did not work, and in all likelihood, this would be done via threading now days and not what code was there. include/libproto.h, sproto.h: updated or various function changes. include/map.h: Add MAP_STYLE flag. random_maps/exit.c: Call set_map_timeout after we load the final map so it will get swapped out. random_maps/standalone.c: Add dummy set_map_timeout function so it compiles. random_maps/style.c: Add load_style_map function which does the job of actually checking to see if a style map is in memory, and if not, loads it up. Updates the pointers so it appears on a map style map list and not the general map list. server/main.c: create set_map_timeout function that deals with setting the map timeouts. Fix bug so server doesn't crash if two players kill each other on hall of selection. server/monster.c remove dead code. socket/loop.c: If realloc fails, catch it and exit with meaningful error message. End of MSW 2001/02/11 checkin. MSW 2001/02/08: server/login.c:Fix that would prevent maps from getting swapped out properly - we would try to swap out a map the player is in the process of leaving - move swap out code until after we have moved the player to the new map. MSW 2001-02-08 MSW 2001/02/06: common/porting.c: relocate clean_path from this file to server/main.c server/main.c: relocate clean_path from porting.c. Add unclean_path. Modify enter_unique_exit so it supports relative maps on unique maps. Modify enter_exit so word of recall (or other forcelike fields), work when the return point is a swapped out unique map. MSW 2001/02/05: server/attack.c: Fix blind and paralyze - logic for reducing duration was broken, resulting in zero duration for most characters. It should now work properly, reducing according to the amount of protection. MSW 2001/02/02: common/item.c: Don't have armour item types get returned as magical if they have an armour value - that is to be expected. This eliminates the false positives that you otherwise get on armor when you cast detect magic. include/newserver/h: and checksum field to FaceInfo struct. Update version_sc to 1026. socket/init.c: calculate image checksums as we load the images. socket/request.c: If client is at least version_Sc 1026, use face1 protocol command that includes the checksum. MSW 2001/01/31: common/object.c: Fix that that spells cast on spaces with no floors get set properly after the spell expires. common/player.c: Use skill tools first (lockpicks, talismans, etc) before using native skills. In this way, an object with bonus automatically gets used. common/living.c: Fix so that negative con bonuses work properly - fixes bug where a higher con could result in lower total hp due to improper calculation. MSW 2001/01/30: Complete rewrite of the exit handling code. Hopefully as an effect, this will fix the player appearing in the middle of the oceans. I think the code should also work better in many other areas. Main enhancements is a 3x3 area for pets to follow player to new map, as well as golems now following players to the new maps. include/sproto.h, random_maps/rproto.h - rebuilt. random_maps/random_map.c: Change generate_random_map to take a structure with the random map paremeters. random_maps/reader.l, reader.c: Add set_random_map_variable function that reads the map parameters from a char buffer. Also, remove some leftover comments that were from the common/loader.l file. random_maps/rogue_layout.c: Change some functions to be static so make proto doesn't collect them. random_maps/standalone.c: Add opening of parms file into main function since it ws removed from the random_map.c file. server/apply.c: Don't display the message of random maps to the players as they enter them, as this message is random map parameters, and not a real message. server/login.c: #if 0 out using of the player loading element in the structure. this isn't used right now. server/main.c: Bulk of the changes. main changes are to break apart the old enter_exit function into smaller functions that more logically do the needed function (random maps, unique maps, and transferring the player to the new map). random map code now passes the parameters via structure instead of file in /tmp. Code is much more understandable now and hopefully bugfree. server/pets.c: minor changes/bugfixes. Search full SIZEOFFREE array, use real owner variable when print out messages. server/player.c: Remove usage of the loading variable in the player structure. End of MSW 2001/01/30 checking. MSW 2001/01/23: Various cleanups/fixes as detected by purify: common/anim.c: animation[0] was given a null pointer as the name, but bsearch/or comparison function will try to de-reference it. Give it a unique name. common/loader.l: msgbuf was being used initialized in the main loading function. loader.c also regenerated. common/object.c: find_free functions were not checking to see if the spaces they were examining were out of the map. Added checks to do so. server/apply.c: buf was being used uninitialized in the function. socket/init.c: input buffer needs to be initialized as we do a strncasecmp against the buffer which may not have any data in it. MSW 2001/01/18: server/skill_util.c: add change_skill_to_skill function to be used when we already know the skill object we want to use. This is more efficient than change_skill which takes a skill number and then searches the inventory for the object. remove extra esrv_send_item from do_skill_attack - don't need to send skills to player. do_skill_attack: remove call to hth_damage - that function does not take into account objects in the player inventory that increase damage, and since that is called each attack, it is not feasible to have it search the players inventory. Instead, we just rely on damage generated by fix_player - only think hth_damage did was adjust damage based on level difference. PeterM 2001/01/16 Added randomly-generated nethack-style maps to crossfire's random map generator. MSW 2001/01/15: Change blindness and paralyze so that duration is reduced based on protection the player has. file server/attack.c MSW 2001/01/15: Various fixes for friendly object code: common/button.c: Add missing call to remove_friendly_object common/friend.c: Pretty much completely re-written. add_friendly_object now checks to make sure the object being added isn't already on the list, remove_friendly_object will remove objects whose tags don't match, and added clean_friendly_list. common/object.c: No reason to use the function pointer to remove_friendly_object since that function is in the lib. common/time.c: Make DEBUG_TIME always on (no longer compile time option). other areas use the global var pticks, so if it was turned off, compile would break anyways. common/treasuer.c: No longer print debug messages on artifacts created. Cluttered log file making it hard to see more important errors. include/config.h: Remove DEBUG_TIME define. include/libproto.h: Rebuilt for clean_friendly_list function. server/main.c: rewrote do_specials to do things based on pticks variable. This allows various specials to be spread out across multiple ticks easier. Also, added clean_friendly_function to part of what this does. server/skills.c: add missing call to remove_friendly_object. Also, removed from #if 0 .. #else .. #endif code. End of MSW 2000/01/15 checkin. PeterM 2001/01/08: Wrathful Eye spell implemented. MSW 2000/12/26: Checkin of Jan's new god intervention code. I haven't played around with it much, but I haven't seen any really obvious problems. common/living.c: remove learn_prayer_chance common/treasure.c: Various changes to treasure generation - mostly to deal with starting equipment and putting it in the inventory. doc/crossfire.doc: Update docs on god intervention. include/define.h: GT_... flags removed. include/treasure.h: GT_... flags added. Addition flags added from what was in define.h before. lib/archetypes, lib/crossfire.png, lib/treasures: Updated with new archetypes and treasures. random_maps/standalone.c,server/rune.c,server/time.c: Calls to create_treasure updated server/apply.c: New functions for god intervention added, update calls to create_treasure, other god related changes. server/c_wiz.c: Calls to create_treasure updated, various functions to allow DM's to learn/unlearn spells added. server/commands.c: Various commands added to the wiz set of commands. See commen for c_wiz.c server/disease.c: Changes to reduce_symptoms server/gods.c: Numerous updates for god intervention code. server/player.c: Modifications for starting player equipment. server/skill_util.c: Display the god the character worships when they issue the skills command. server/skills.c: Minor cosmetic change made to message when praying on altar. server/spell_effect.c: Changes related to gods, cure spells, and generation of treasures & items. End of MSW 2000/12/26 checkin. MSW 2000/12/23: include/define.h: Add SIZEOFFREE1 and SIZEOFFREE2 values to use instead of arbitrary constants in the code. server/monster.c: change communicate function to use above values. Before it was stopping one short of the full 2 space array, so one particular space (-1, -2 relative to player) would not hear players speech. server/attack.c: Don't exit hit_player function if damage is reduced to 0 in magical attacks. This was preventing face of death and probably a lot of effect only spells from working. server/spell_util.c: modify check_cone_push to use move_object to blow the objects. Before, multisquare monsters were getting sliced into their individual components - move_object deals with multisquare objects properly. PeterM 2000/12/18: Re-add the conflict spell (various files) attack.c: fix a bug which could easily have led to seg fault, and did when I was testing under efence. MSW 2000/12/17: Various changes. Note that the scope of files in this checkin make it appear that a lot was changed, but in fact it was mostly just re-orginization - very little code has actually changed. include/autoconf.h.in: Add HAVE_LIBDES to file. include/config.h: Remove comments after defines for MAP_MIN/MAX timeouts. This just removes some warnings during compile. comments are now on lines by themselves. include/player.h: remove shootstrength for player structure. It was unused. server/Makefile.in: remove input.c file, add c_range.c file. server/c_chat.c: remove command_last, add command_shout and command_tell from input.c to this file. Also fix bug in command tell which would let players crash server at will. server/c_misc.c,server/c_object.c: Relocate many functions from input.c into these files. server/c_move.c, server/c_new.c: Add standard crossfire banner comment. server/c_range.c: New file - contains range related commands, including spell casting (relocated from input.c) server/c_wiz.c: move command_invisible from input.c into this file. server/commands.c: Remove unused commands (bell, last, strength) server/input.c: removed file. server/main.c: Change HAVE_DES_H to HAVE_LIBDES server/player.c: When choosing a race, draw it facing south for best presentation of image. server/spell_util.c: Remove dead code (#if 0 shootstrength related code) socket/loop.c: remove unused variables. NOTE: Due to the addition/removal of files, you will need to do 'config.status; make depend; make' from the top level directory for everything to be compiled properly. End of MSW 2000/12/17 checkin. PeterM: 2000/12/17: Various problems fixed in random_maps/*.c: endless loop removed, exit leading to blocked area of spiral fixed. PeterM: 2000/12/17: Stat max bug fixed. server/apply.c MSW 2000/12/16: server/player.c: If the player race archetype has a message, print that out. This allows a descriptive message about what the different races will get. The message is removed from the player once they decide on the race. common/living.c: Add some parens around some PR resistant checks - eliminates warnings from gcc. server/disease.c: have cure_disease remove all diseases a player is infected with. The code suggested it was attempting to do so, and the messages it printed out certainly suggested that the character was disease free. PeterM: 2000/12/14: Added spiral map layout PeterM: 2000/12/14: Restructuring of the random map code. Functionally, it should be identical. All global variables moved into the functions. MSW 2000/12/10: utils/metaserver.pl: Various improvements. Main one is that tcp connections to port 13326 of the metaserver will dump the information in a easily parsable format for the client or other applications. include/config.h: Set ARCHTABLE size to correct value. server/player.c: Have server send update item to client for players face while select class. Added esrv_new_player in Roll_Again, because without it, the client had yet to receive information on what tag the player was so could not make sense of the updated face. server/spell_effect.c: Balance issues for polymorph. Reduce maximum value for high valued objects, remove ability to polymorph generators, put maximum level on polymorphed monsters and give them saving throws against the effects. MSW 2000/12/5: server/player.c: Move location of where it sets the player has_hit variable until after we have confirmed that the player has actually attacked a monster and not that the space is blocked. Fixes various problems and make behaviour more predictable. common/button.c: Do not set path_attuned when loading connected objects from within the editor. This is normally done for random map code/glue logic. common/player.c: When trying to find a skill to use, use a native skill first before going off and returning a skill object like a talisman. MSW 2000/12/4: common/treasure.c: Make it so resistances from artifact files are absolute adjustments. Makefile.in configure configure.in: Fix check for libdes to see if des_crypt exists in libdes before setting HAVE_LIBDES crossedit/Makefile.in: Add Cnv/libCnv.a before LIBS - should fix linking error on irix systems. utils/metaserver.pl: modified so it ignores entries from hosts that report their name as put.your.hostname.here MSW 2000/12/3: crossedit/Attr.c: Add the new resist names to set of variables one can set. MSW 2000/12/3: Misc changes. Main one is adding PNG support to the editor. TODO: Remove outdated things to do (like partial resistance code) configure, configure.in, include/autoconf.h.in: Add check for libpng. include/global.h: Remove displaymodes - moved to crossedit/Defines.h crossedit/App.c, crossedit/App.h crossedit/CrEdit.c crossedit/CrFace.c crossedit/CrList.c crossedit/CrUtil.c crossedit/Edit.c crossedit/crossedit.c crossedit/xutil.c, crossedit/png.c (new file): Add support for png display in crossedit. crossedit/Makefile.in: Add png.c file. server/c_misc.c: Change who command to only display real players, and not players in process of connecting/unconnecting. Also, remove code to display old sockets, since those are not supported anymore. MSW 2000/12/3: Checking for partial resistance code. Various minor errors also fixed (compiler warnings, unused variables, Makefile.in changes, etc). PR code also includes support to send protections to the client. Files changed: common/Makefile.in common/button.c common/exp.c common/friend.c common/holy.c common/info.c common/init.c common/item.c common/living.c common/loader.c common/loader.l common/object.c common/player.c common/re-cmp.c common/readable.c common/treasure.c crossedit/App.c crossedit/crossedit.c crossedit/proto.h doc/crossfire.doc include/define.h include/global.h include/libproto.h include/newclient.h include/newserver.h include/object.h include/player.h include/sproto.h lib/Makefile.in lib/archetypes lib/artifacts lib/crossfire.png lib/crossfire.xbm lib/crossfire.xpm random_maps/rproto.h random_maps/special.c random_maps/style.c server/Makefile.in server/apply.c server/attack.c server/c_misc.c server/c_object.c server/commands.c server/disease.c server/gods.c server/input.c server/monster.c server/player.c server/resurrection.c server/rune.c server/spell_effect.c server/spell_util.c server/swap.c socket/metaserver.c socket/request.c Added Files: include/attack.h From tanner at real-time.com Tue Feb 13 01:27:06 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 17:59:58 2005 Subject: [CF-Devel] [mwedel@scruz.net: [CF Announce] Crossfire 0.96.0 released.] Message-ID: <20010213012706.C26843@real-time.com> Bug in announcement list. Forwarding this for Mark: --------------- Crossfire 0.96.0 has been released. Despite many changes from the last release, this release should be quite stable - its been tested fairly extensively. Unless serious bugs are detected, this will likely be the last release before 1.0. Main changes: New random map layouts added. Re-done player exit code - this should hopefully fix players appearing in the middle of oceans. Server will send image checksums to client when client is caching images - in this way, client knows to request new image or not (both client and server change) New spells PNG support added to editor. Partial Resistance code added. Protections now have numeric values, and add up. A complete list of changes is at the bottom of this message. NOTE TO MIRROR SITES: The primary site (ftp.scruz.net) has limited download bandwidth per day. If this poses a problem, you want a more reliable method, or you just want a backup method. please drop me a mail message - I have set up a secondary server off my ADSL link, but being that only has 128 kb upstream bandwidth and is also used for other interactive purposes, I don't want to make it available to all. Files released for this version: sums (bsd) filename 04869 1507 crossfire-0.96.0.arch.tar.bz2 65381 1796 crossfire-0.96.0.arch.tar.gz 63394 2645 crossfire-0.96.0.maps.tar.bz2 12882 3807 crossfire-0.96.0.maps.tar.gz 11913 2641 crossfire-0.96.0.tar.bz2 60544 2967 crossfire-0.96.0.tar.gz 27062 237 crossfire-client-0.96.0.tar.gz Sums (md5) 709ccf30ed6489dc3673b93be20b105b crossfire-0.96.0.arch.tar.bz2 290f8cb22336459b2ac9f42a440954e9 crossfire-0.96.0.arch.tar.gz b0b21296ba967e90388bce9b789a49ff crossfire-0.96.0.maps.tar.bz2 76c6574c7fb50d3fe27dfc659f4c1be3 crossfire-0.96.0.maps.tar.gz d29d939ccc7d0e02e14949e23f2109fb crossfire-0.96.0.tar.bz2 cf42d4c6f2ef2595424a14a110a8bcbb crossfire-0.96.0.tar.gz 2b6d9d9d6c355082a467805a301e7eb4 crossfire-client-0.96.0.tar.gz crossfire-client-0.96.0 is the client (X11) distribution - standard X11 and gtk interfaces are provided. crossfire-0.96.0.tar.{gz/bz2} contains the server code with prebuilt archetype and image files. crossfire-0.96.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-0.96.0-maps.tar.{gz/bz2} contains the maps. This is needed with the server distribution. No doc archive at this time - I don't believe anything in it should have changed much. 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.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 - it should be on the other ftp sites in a short time. Mark Wedel mwedel@scruz.net 01/28/2000 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Changes: Client: MSW 2001/02/02: Protocol: Update with new face1 command that includes checksum. client.c: add face1 protocol command. client.h: Update version_sc to 1026. commands.c: Move FaceCmd from gx11.c/x11.c to this file, since it now only does decoding of data and passes rendering off to appropriate file. Also add Face1Cmd function that deals with checksum. Both of these functions pass off the rendering to the same function. gx11.c: add keepcache variable, re-do facing loading/caching - if we have local version of face, generate checksum of it and compare to that against what server has. finish_face_command added to do this - called by the face functions in commands.c. Add -keepcache command line option which will have it not request images from server if checksum is different. Add usleep in metserver selection area to prevent client from hogging all the cpu time. item.c: Add support for ^ in items file to say only match at start of line. Useful for 'bolt' - doing substring also matched against firebolt. item_types, item_types.h: make bolt ^bolt, add Head and hauberk to matching criteria. proto.h: automatic regen. x11.c: As gx11.c above, plus: Use one font for all windows - reduces complexity. Add easy selection of font to use with -font command line option. xutil.c: As gx11.c for relevant functions that are located in this file and not x11.c End of MSW 2001/02/02 checkin. MSW 2001/01/31: client.c: Clear player inventory and look windows after disconnection from server. Prevents client crashes. gx11.c: various fixes - window placement no longer always centered on screen (very obnoxious if running xinerama), various prototypes fixed up, clear map data after clearing image data. player.c: Add suport for 'mapredraw' command. Not that this should ever really be needed, but the server supports it, so its nice to be able to use it. x11.c: Fixes prototype/casting problems when clearing pixmaps. Like gx11.c, clear map data. xutil.c: add better description to the unbind command. MSW 2001/1/13 (except as mentioned, all changes by MSW): Makefile.in: Create destination dirs, remove extra tab. Patch also by Dave. Protocol: typo fixed. config.h, config.h.in: Add HVAE_DMALLOC_H #ifdefs. Checks currently disable in configure.in, as with it, the sound won't like properly since it needs -ldmalloc, and I haven't bothered investing that much time into fixing the Makefile. gx11.c: Patches by Dave Peticolas - mostly code cleanup, but one new feature is support of wheel mice to move the scrollbars. png.c: No real code change, just adjustments in some ordering which I think makes the code appear a little simpler. x11.c: Minor code cleanups, some formatting changes, some to make better error messages. End of MSW 2000/1/13 checkin. MSW 2001/1/8: client.h: Change damage type to be 16 bits. MSW 2000/12/24: png.c: Fix a major memory corruption issue - the png function was re-allocing for a larger hunk of data, but did not update the pointer and was still using the pointer to the smaller hunk. Severity of this bug depended on luck - if the first png downloaded happened to have the full 4 bytes/pixel, it never needed to do a realloc so would work fine. Otherwise, a matter of luck what data got stomped over. Also, modified the main function in this file so that it you can compile against it and it now works with the new in memory data read. MSW 2000/12/19: Metaserver update. Most files updated. This change has the client connect the metaserver and lets the user choose which server to connect to. Also, if the client loses a connection (either because the player has quit playing or the server died), the client will no longer exit and instead go back to the server selection screen. A few unrelated changes (cfclient): when running cache, non downloaded images should look better. Also, client starts up with larger window in Png mode to take into account the extra space png images takes up in the game window. Changes by file: Makefile.in: Add metaserver.c file. cconfig.h: Add metaserver configuration information. client.c: Add meta_ variables, move resists_name to this file, no longer have DoClient exit if it gets an error on the socket (instead mark the fd as -1 and return), change main loop such that if connection to server has been lost, go through loop to establish a new connection. client.h: Add Metaserver_Select input state. Change resists_name from a static to extern. gx11.c: Remove some unused code, various code cleanups, and additions to support the metaserver connection process. init.c: Add reset_client_vars - call it between connections to servers. proto.h: rebuilt for new functions. x11.c: Update for metaserver connection status. If running Png mode, have windows created larger. xutil.c: When creating default images for cache, create 32x32 images for png mode, not 24x24 images. metaserver.c: New file for metaserver code. End MSW 2000/12/19 checkin. MSW 2000/12/10: png.c, gx11.c, x11.c, xutil.c: modified to use in memory loading of png's. This means that if not caching images, we don't need to write it out to a temp file. This should result in a minor performance gain, but also remove the need of using tmpnam. Also, modified gx11.c so that it uses same logic as the x11 client for extended command key ('). Before gx11.c client would use both ' and ", and there was no way to unbind the later - since one can always bind the command key, I found that a bit annoying. Updated to display resistance values in the message window. Except for armour, this is only displayed when running against serves with PR code. Change for both cfclient and gcfclient. Files affected: Protocol client.h commands.c gx11.c newclient.h player.c sounds soundsdef.h x11.c MSW 12-3-2000 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Server: MSW 2001/01/11: include/rproto.h: Rebuilt for new random map code. server/player.c: remove player insert in key_roll_stat - player is already inserted. server/swap.c: When swapping out map, see if it has already reached reset time, and if so, just delete it and not save it. In flush_old_maps, now have it check for maps that have no timeout set - this sometimes happens when players save/die on maps. MSW 2001/01/11: Other than various general cleanups, the main change this code does is that style maps (for random maps) get loaded special now - they objects they contain are not put on the active list, and they use a private map list so they do not appear in the output of the 'maps command. common/arch.c, common/treasure.c,server/login.c: Update calls to load_object common/loaderl.l,loader.c: Update lex_load to take an optional flags option. This is currently only used so that the loader can decide if it should call update_ob_speedto put objects on the active list or not. Calls to lex_load updated. load_object modified to take another option common.map.c: remove PROCESS_WHILE_LOADING and CHECK_ACTIVE_MAPS ifdefs. update calls to load_object. Remove some dead code. include/config.h: Remove CHECK_ACTIVE_MAPS and PROCESS_WHILE_LOADING flags. Those options did not work, and in all likelihood, this would be done via threading now days and not what code was there. include/libproto.h, sproto.h: updated or various function changes. include/map.h: Add MAP_STYLE flag. random_maps/exit.c: Call set_map_timeout after we load the final map so it will get swapped out. random_maps/standalone.c: Add dummy set_map_timeout function so it compiles. random_maps/style.c: Add load_style_map function which does the job of actually checking to see if a style map is in memory, and if not, loads it up. Updates the pointers so it appears on a map style map list and not the general map list. server/main.c: create set_map_timeout function that deals with setting the map timeouts. Fix bug so server doesn't crash if two players kill each other on hall of selection. server/monster.c remove dead code. socket/loop.c: If realloc fails, catch it and exit with meaningful error message. End of MSW 2001/02/11 checkin. MSW 2001/02/08: server/login.c:Fix that would prevent maps from getting swapped out properly - we would try to swap out a map the player is in the process of leaving - move swap out code until after we have moved the player to the new map. MSW 2001-02-08 MSW 2001/02/06: common/porting.c: relocate clean_path from this file to server/main.c server/main.c: relocate clean_path from porting.c. Add unclean_path. Modify enter_unique_exit so it supports relative maps on unique maps. Modify enter_exit so word of recall (or other forcelike fields), work when the return point is a swapped out unique map. MSW 2001/02/05: server/attack.c: Fix blind and paralyze - logic for reducing duration was broken, resulting in zero duration for most characters. It should now work properly, reducing according to the amount of protection. MSW 2001/02/02: common/item.c: Don't have armour item types get returned as magical if they have an armour value - that is to be expected. This eliminates the false positives that you otherwise get on armor when you cast detect magic. include/newserver/h: and checksum field to FaceInfo struct. Update version_sc to 1026. socket/init.c: calculate image checksums as we load the images. socket/request.c: If client is at least version_Sc 1026, use face1 protocol command that includes the checksum. MSW 2001/01/31: common/object.c: Fix that that spells cast on spaces with no floors get set properly after the spell expires. common/player.c: Use skill tools first (lockpicks, talismans, etc) before using native skills. In this way, an object with bonus automatically gets used. common/living.c: Fix so that negative con bonuses work properly - fixes bug where a higher con could result in lower total hp due to improper calculation. MSW 2001/01/30: Complete rewrite of the exit handling code. Hopefully as an effect, this will fix the player appearing in the middle of the oceans. I think the code should also work better in many other areas. Main enhancements is a 3x3 area for pets to follow player to new map, as well as golems now following players to the new maps. include/sproto.h, random_maps/rproto.h - rebuilt. random_maps/random_map.c: Change generate_random_map to take a structure with the random map paremeters. random_maps/reader.l, reader.c: Add set_random_map_variable function that reads the map parameters from a char buffer. Also, remove some leftover comments that were from the common/loader.l file. random_maps/rogue_layout.c: Change some functions to be static so make proto doesn't collect them. random_maps/standalone.c: Add opening of parms file into main function since it ws removed from the random_map.c file. server/apply.c: Don't display the message of random maps to the players as they enter them, as this message is random map parameters, and not a real message. server/login.c: #if 0 out using of the player loading element in the structure. this isn't used right now. server/main.c: Bulk of the changes. main changes are to break apart the old enter_exit function into smaller functions that more logically do the needed function (random maps, unique maps, and transferring the player to the new map). random map code now passes the parameters via structure instead of file in /tmp. Code is much more understandable now and hopefully bugfree. server/pets.c: minor changes/bugfixes. Search full SIZEOFFREE array, use real owner variable when print out messages. server/player.c: Remove usage of the loading variable in the player structure. End of MSW 2001/01/30 checking. MSW 2001/01/23: Various cleanups/fixes as detected by purify: common/anim.c: animation[0] was given a null pointer as the name, but bsearch/or comparison function will try to de-reference it. Give it a unique name. common/loader.l: msgbuf was being used initialized in the main loading function. loader.c also regenerated. common/object.c: find_free functions were not checking to see if the spaces they were examining were out of the map. Added checks to do so. server/apply.c: buf was being used uninitialized in the function. socket/init.c: input buffer needs to be initialized as we do a strncasecmp against the buffer which may not have any data in it. MSW 2001/01/18: server/skill_util.c: add change_skill_to_skill function to be used when we already know the skill object we want to use. This is more efficient than change_skill which takes a skill number and then searches the inventory for the object. remove extra esrv_send_item from do_skill_attack - don't need to send skills to player. do_skill_attack: remove call to hth_damage - that function does not take into account objects in the player inventory that increase damage, and since that is called each attack, it is not feasible to have it search the players inventory. Instead, we just rely on damage generated by fix_player - only think hth_damage did was adjust damage based on level difference. PeterM 2001/01/16 Added randomly-generated nethack-style maps to crossfire's random map generator. MSW 2001/01/15: Change blindness and paralyze so that duration is reduced based on protection the player has. file server/attack.c MSW 2001/01/15: Various fixes for friendly object code: common/button.c: Add missing call to remove_friendly_object common/friend.c: Pretty much completely re-written. add_friendly_object now checks to make sure the object being added isn't already on the list, remove_friendly_object will remove objects whose tags don't match, and added clean_friendly_list. common/object.c: No reason to use the function pointer to remove_friendly_object since that function is in the lib. common/time.c: Make DEBUG_TIME always on (no longer compile time option). other areas use the global var pticks, so if it was turned off, compile would break anyways. common/treasuer.c: No longer print debug messages on artifacts created. Cluttered log file making it hard to see more important errors. include/config.h: Remove DEBUG_TIME define. include/libproto.h: Rebuilt for clean_friendly_list function. server/main.c: rewrote do_specials to do things based on pticks variable. This allows various specials to be spread out across multiple ticks easier. Also, added clean_friendly_function to part of what this does. server/skills.c: add missing call to remove_friendly_object. Also, removed from #if 0 .. #else .. #endif code. End of MSW 2000/01/15 checkin. PeterM 2001/01/08: Wrathful Eye spell implemented. MSW 2000/12/26: Checkin of Jan's new god intervention code. I haven't played around with it much, but I haven't seen any really obvious problems. common/living.c: remove learn_prayer_chance common/treasure.c: Various changes to treasure generation - mostly to deal with starting equipment and putting it in the inventory. doc/crossfire.doc: Update docs on god intervention. include/define.h: GT_... flags removed. include/treasure.h: GT_... flags added. Addition flags added from what was in define.h before. lib/archetypes, lib/crossfire.png, lib/treasures: Updated with new archetypes and treasures. random_maps/standalone.c,server/rune.c,server/time.c: Calls to create_treasure updated server/apply.c: New functions for god intervention added, update calls to create_treasure, other god related changes. server/c_wiz.c: Calls to create_treasure updated, various functions to allow DM's to learn/unlearn spells added. server/commands.c: Various commands added to the wiz set of commands. See commen for c_wiz.c server/disease.c: Changes to reduce_symptoms server/gods.c: Numerous updates for god intervention code. server/player.c: Modifications for starting player equipment. server/skill_util.c: Display the god the character worships when they issue the skills command. server/skills.c: Minor cosmetic change made to message when praying on altar. server/spell_effect.c: Changes related to gods, cure spells, and generation of treasures & items. End of MSW 2000/12/26 checkin. MSW 2000/12/23: include/define.h: Add SIZEOFFREE1 and SIZEOFFREE2 values to use instead of arbitrary constants in the code. server/monster.c: change communicate function to use above values. Before it was stopping one short of the full 2 space array, so one particular space (-1, -2 relative to player) would not hear players speech. server/attack.c: Don't exit hit_player function if damage is reduced to 0 in magical attacks. This was preventing face of death and probably a lot of effect only spells from working. server/spell_util.c: modify check_cone_push to use move_object to blow the objects. Before, multisquare monsters were getting sliced into their individual components - move_object deals with multisquare objects properly. PeterM 2000/12/18: Re-add the conflict spell (various files) attack.c: fix a bug which could easily have led to seg fault, and did when I was testing under efence. MSW 2000/12/17: Various changes. Note that the scope of files in this checkin make it appear that a lot was changed, but in fact it was mostly just re-orginization - very little code has actually changed. include/autoconf.h.in: Add HAVE_LIBDES to file. include/config.h: Remove comments after defines for MAP_MIN/MAX timeouts. This just removes some warnings during compile. comments are now on lines by themselves. include/player.h: remove shootstrength for player structure. It was unused. server/Makefile.in: remove input.c file, add c_range.c file. server/c_chat.c: remove command_last, add command_shout and command_tell from input.c to this file. Also fix bug in command tell which would let players crash server at will. server/c_misc.c,server/c_object.c: Relocate many functions from input.c into these files. server/c_move.c, server/c_new.c: Add standard crossfire banner comment. server/c_range.c: New file - contains range related commands, including spell casting (relocated from input.c) server/c_wiz.c: move command_invisible from input.c into this file. server/commands.c: Remove unused commands (bell, last, strength) server/input.c: removed file. server/main.c: Change HAVE_DES_H to HAVE_LIBDES server/player.c: When choosing a race, draw it facing south for best presentation of image. server/spell_util.c: Remove dead code (#if 0 shootstrength related code) socket/loop.c: remove unused variables. NOTE: Due to the addition/removal of files, you will need to do 'config.status; make depend; make' from the top level directory for everything to be compiled properly. End of MSW 2000/12/17 checkin. PeterM: 2000/12/17: Various problems fixed in random_maps/*.c: endless loop removed, exit leading to blocked area of spiral fixed. PeterM: 2000/12/17: Stat max bug fixed. server/apply.c MSW 2000/12/16: server/player.c: If the player race archetype has a message, print that out. This allows a descriptive message about what the different races will get. The message is removed from the player once they decide on the race. common/living.c: Add some parens around some PR resistant checks - eliminates warnings from gcc. server/disease.c: have cure_disease remove all diseases a player is infected with. The code suggested it was attempting to do so, and the messages it printed out certainly suggested that the character was disease free. PeterM: 2000/12/14: Added spiral map layout PeterM: 2000/12/14: Restructuring of the random map code. Functionally, it should be identical. All global variables moved into the functions. MSW 2000/12/10: utils/metaserver.pl: Various improvements. Main one is that tcp connections to port 13326 of the metaserver will dump the information in a easily parsable format for the client or other applications. include/config.h: Set ARCHTABLE size to correct value. server/player.c: Have server send update item to client for players face while select class. Added esrv_new_player in Roll_Again, because without it, the client had yet to receive information on what tag the player was so could not make sense of the updated face. server/spell_effect.c: Balance issues for polymorph. Reduce maximum value for high valued objects, remove ability to polymorph generators, put maximum level on polymorphed monsters and give them saving throws against the effects. MSW 2000/12/5: server/player.c: Move location of where it sets the player has_hit variable until after we have confirmed that the player has actually attacked a monster and not that the space is blocked. Fixes various problems and make behaviour more predictable. common/button.c: Do not set path_attuned when loading connected objects from within the editor. This is normally done for random map code/glue logic. common/player.c: When trying to find a skill to use, use a native skill first before going off and returning a skill object like a talisman. MSW 2000/12/4: common/treasure.c: Make it so resistances from artifact files are absolute adjustments. Makefile.in configure configure.in: Fix check for libdes to see if des_crypt exists in libdes before setting HAVE_LIBDES crossedit/Makefile.in: Add Cnv/libCnv.a before LIBS - should fix linking error on irix systems. utils/metaserver.pl: modified so it ignores entries from hosts that report their name as put.your.hostname.here MSW 2000/12/3: crossedit/Attr.c: Add the new resist names to set of variables one can set. MSW 2000/12/3: Misc changes. Main one is adding PNG support to the editor. TODO: Remove outdated things to do (like partial resistance code) configure, configure.in, include/autoconf.h.in: Add check for libpng. include/global.h: Remove displaymodes - moved to crossedit/Defines.h crossedit/App.c, crossedit/App.h crossedit/CrEdit.c crossedit/CrFace.c crossedit/CrList.c crossedit/CrUtil.c crossedit/Edit.c crossedit/crossedit.c crossedit/xutil.c, crossedit/png.c (new file): Add support for png display in crossedit. crossedit/Makefile.in: Add png.c file. server/c_misc.c: Change who command to only display real players, and not players in process of connecting/unconnecting. Also, remove code to display old sockets, since those are not supported anymore. MSW 2000/12/3: Checking for partial resistance code. Various minor errors also fixed (compiler warnings, unused variables, Makefile.in changes, etc). PR code also includes support to send protections to the client. Files changed: common/Makefile.in common/button.c common/exp.c common/friend.c common/holy.c common/info.c common/init.c common/item.c common/living.c common/loader.c common/loader.l common/object.c common/player.c common/re-cmp.c common/readable.c common/treasure.c crossedit/App.c crossedit/crossedit.c crossedit/proto.h doc/crossfire.doc include/define.h include/global.h include/libproto.h include/newclient.h include/newserver.h include/object.h include/player.h include/sproto.h lib/Makefile.in lib/archetypes lib/artifacts lib/crossfire.png lib/crossfire.xbm lib/crossfire.xpm random_maps/rproto.h random_maps/special.c random_maps/style.c server/Makefile.in server/apply.c server/attack.c server/c_misc.c server/c_object.c server/commands.c server/disease.c server/gods.c server/input.c server/monster.c server/player.c server/resurrection.c server/rune.c server/spell_effect.c server/spell_util.c server/swap.c socket/metaserver.c socket/request.c Added Files: include/attack.h -- Bob Tanner I've just packed up a 0.96.0 release. The announcement message should be coming out soon. Unless there are significant problems, the release after this should be 1.0. Given that, a few notes: 1) Peter will be working on moving the current repository to sourceforge. Once he starts the move, the boltzmann.eecs.berkeley.edu repository will become read only. This is to ensure that no commits get lost. 2) IF you know of any bugs in the 0.96.0 release (even if they date back further), please send a message to the list. Best I know, the current snapshot is bug free. 3) The only code commits going forward should be for bug fixes and adjustments in balance. The point now is to make the version even more bug free. New features should not be getting checked in for 1.0 at this point. If in doubt, ask before you check in. Presuming nothing unexpected happens, I expect to roll a 1.0 release relatively quickly in comparison to past released (maybe in a month or so). I expect post 1.0 releases to go back to being development releases again (full of new features and bugs). Depending on various factors, we may go into bugfix mode for a release or to. I want to keep the ongoing future versions the main branch. If someone wants to take the task of making various updates to 1.0 to make it more stable/reliable/whatever, thats fine by me. From tanner at real-time.com Tue Feb 13 01:40:44 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 17:59:58 2005 Subject: [CF-Devel] Crossfire-client-0.96.0 Linux RPM released Message-ID: <20010213014044.E26843@real-time.com> A new version of client-linux-rpm has been released. You can download it from SourceForge by following this link: You requested to be notified when new versions of this file were released. If you don't wish to be notified in the future, please login to SourceForge and click this link: -- 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 Tue Feb 13 04:07:40 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 17:59:58 2005 Subject: [CF-Devel] Problems with 0.96.0 Message-ID: <20010213040740.I26843@real-time.com> Initialize new client/server data Loading image file /usr/games/crossfire/share/crossfire/crossfire.xbm read_client_images: Did not read desired amount of data, wanted 72, got 0 IMAGE 00000 72 /var/tmp/crossfire-0.95.8.arch/system/bug.111 Did collect not get run on the arch files? -- 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 Tue Feb 13 15:35:21 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 17:59:58 2005 Subject: [CF-Devel] FW: rogue like games gfx (3rd) Message-ID: Hi And another very great artist. This is the first contact, he aloow use to use his "common" tiles set. Remember, we need to contact him further to say : " we need a great demon, animated in x*x tiles, can you draw it?". (Peter, thats a hint for you :-) I am sure, one of the guys will draw it. Thats then the first exclusive one for cf, they will look for him, starting playing or saying "this demon look bad in this pther gfx, take this tiles... " You got the point? So please: CONTACT THE GUYS IF YOU WANT TILES FROM THEM! Michael > -----Original Message----- > From: Mitsuhiro Itakura [mailto:ita@gold.koma.jaeri.go.jp] > Sent: Tuesday, February 13, 2001 2:08 AM > To: michael.toennies@nord-com.net; ita@gold.koma.jaeri.go.jp > Subject: Re: rogue like games gfx > > > Hi, > >Crossfire is very massive at this time and we will bring out this year > >after some years of development the 1.0 version. > Great! I've been an addict of 0.9.* versions. > > >If you are an artist or if you know an artist or even if you > like rogue like > >games as mrpgs, > >give us a note. We look for always for people and we all play also other > >rogue like games. > > Feel free to use the following tileset: > http://rice.c.u-tokyo.ac.jp/~ita/game/nh/diy33.zip > > Please grance at the 3D-algorithm too: > http://www.geocities.co.jp/SiliconValley-SanJose/9606/nh/3d/ > > -- > M.Itakura > From michael.toennies at nord-com.net Tue Feb 13 16:05:51 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 17:59:58 2005 Subject: [CF-Devel] FW: rogue like games gfx (java) Message-ID: And then i have found this nice guy. I will give him some advice for Cf. Also, we have the java thing "flying in space" yet, right? > -----Original Message----- > From: Sebastien Bracquemont [mailto:dweeves@hotmail.com] > Sent: Monday, February 12, 2001 10:40 AM > To: michael.toennies@nord-com.net > Subject: Re: rogue like games gfx > > > Hi, i'm really interested in helping you in many ways. > > The project i had (RLGWeb) was too big to be done alone , so i > think i will > change a little bit and adapt my project to be an extension of yours by > giving up the server part. > > I propose you to start a "multi-gui" , high-end graphics , JAVA client > project for CrossFire. > > I think i will need more time that i had to follow my own project > , but real > results can be reached. > > The concept is to handle graphics independently. Indeed , 2D tile > graphics > with Point of View management , can 'easily' and why not dynamically be > mapped as isometric + fog (Diablo Like) or pseudo static 3D view > (Dungeon > Master/Eye of the Beholder like). > > Not only the graphic type , but even the client GUI can be > 'skinned' with a > little abstraction effort on the client. > > A note about the current graphics : they really look like "programmer's > graphics" for the tiles. Not very attractive. I think much better > could be > done (if not already) > > Some Questions : > - Is there any existing JAVA client for CF ? > - Are you interested by my ideas and has someone already > thought about it > ? > > Your project is great , and i think most of the work has been done on the > server. Let's have a really beautiful and powerful client !!! > > Sebastien > > PS: > A little information about me: > > - I'm french > - I'm a Sofware Engeneering Expert in a Telecommunication company > - I like roguelikes > - I'm a linux power user (not a guru yet) > - I'm a JAVA,C,C++,Assembly,PHP experienced programmer. > - I'm a development technologies explorer. > - I used to make some graphics before i began (a long time ago) > to program. > - I have only a little time to spend on my projects :(( (i've a > lot of work > and a very possessive girlfriend :)) ) > - I am full of ideas. > > Hope to have some news from you soon !!! > > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > From leaf at real-time.com Tue Feb 13 16:21:23 2001 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 17:59:58 2005 Subject: [CF-Devel] FW: rogue like games gfx (java) In-Reply-To: Message-ID: Yes, a Java client is available. More info is at: http://crossfire.real-time.com/Clients/Java_Crossclient/java_crossclient.html On Tue, 13 Feb 2001, Michael Toennies wrote: > And then i have found this nice guy. > I will give him some advice for Cf. > Also, we have the java thing "flying in space" yet, right? > > > > -----Original Message----- > > From: Sebastien Bracquemont [mailto:dweeves@hotmail.com] > > Sent: Monday, February 12, 2001 10:40 AM > > To: michael.toennies@nord-com.net > > Subject: Re: rogue like games gfx > > > > > > Hi, i'm really interested in helping you in many ways. > > > > The project i had (RLGWeb) was too big to be done alone , so i > > think i will > > change a little bit and adapt my project to be an extension of yours by > > giving up the server part. > > > > I propose you to start a "multi-gui" , high-end graphics , JAVA client > > project for CrossFire. > > > > I think i will need more time that i had to follow my own project > > , but real > > results can be reached. > > > > The concept is to handle graphics independently. Indeed , 2D tile > > graphics > > with Point of View management , can 'easily' and why not dynamically be > > mapped as isometric + fog (Diablo Like) or pseudo static 3D view > > (Dungeon > > Master/Eye of the Beholder like). > > > > Not only the graphic type , but even the client GUI can be > > 'skinned' with a > > little abstraction effort on the client. > > > > A note about the current graphics : they really look like "programmer's > > graphics" for the tiles. Not very attractive. I think much better > > could be > > done (if not already) > > > > Some Questions : > > - Is there any existing JAVA client for CF ? > > - Are you interested by my ideas and has someone already > > thought about it > > ? > > > > Your project is great , and i think most of the work has been done on the > > server. Let's have a really beautiful and powerful client !!! > > > > Sebastien > > > > PS: > > A little information about me: > > > > - I'm french > > - I'm a Sofware Engeneering Expert in a Telecommunication company > > - I like roguelikes > > - I'm a linux power user (not a guru yet) > > - I'm a JAVA,C,C++,Assembly,PHP experienced programmer. > > - I'm a development technologies explorer. > > - I used to make some graphics before i began (a long time ago) > > to program. > > - I have only a little time to spend on my projects :(( (i've a > > lot of work > > and a very possessive girlfriend :)) ) > > - I am full of ideas. > > > > Hope to have some news from you soon !!! > > > > > > > > > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com From michael.toennies at nord-com.net Tue Feb 13 18:25:57 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 17:59:58 2005 Subject: [CF-Devel] FW: Crossfire client testing Message-ID: Hi Mail i send to a people who answered to me > -----Original Message----- > From: Michael Toennies [mailto:michael.toennies@nord-com.net] > Sent: Wednesday, February 14, 2001 1:09 AM > To: bca@magellan.fpms.ac.be > Subject: RE: Crossfire client testing > > > Hi > Sorry for late answer, i was ill. > > Well, i don't will put in a script interpreter. > CF is not ready for this, and in dont like makro playing. > But i will include in future more "system commands" to the client > (the ?iamacommand things) where you can do some more fancy thing. > > The metaserver (where the server and connection data are stored) > is a obejct of work, there will come some changes. > > You should join this mailing list > > http://mailman.real-time.com/pipermail/crossfire-devel/ > > There are all the dev team people but also player who put in the ideas! > > Also try out IRC > IRC: irc.openprojects.net > channel: #crossfire > > There are all times 5-10 people online talking about servers, > playing and so on. > > Please, if you find a bug or a good idea for the user interface > of the client, > report it to me, i am lake in bug reports (i don't think there > are none, simply > no one tell me). > > cu > Michael > > > > > -----Original Message----- > > From: bca@magellan.fpms.ac.be [mailto:bca@magellan.fpms.ac.be] > > Sent: Saturday, January 20, 2001 11:42 PM > > To: Michael Toennies > > Subject: RE: Crossfire client testing > > > > > > Nearly perfect. > > I tested it for a week and the only problem was on the server side. > > Check only mouse middle button emulation, > > panes scrolling same to not work. > > To make it better, 2 tools could be useful: > > 1 a basic interpreter for setting some automatic behavior: Can be in > > a form of a perl interpreter(ActiveState is a free Perl port onto > > windows) a small script could avoid me to run into my own lightning > > > > 2 A config tool. Maybe by windows that can be accessed through a > > menu or somewhat like that. this could be useful to know at every > > time connections state and server state and permit to create > > profiles > > > > If you need help,I can try do do it. > > Sorry. I am a Java and Delphi programmer but I know also suffiently > > C/C++ to help you. > > Callebaut Beno?t > > E-mail :bca@magellan.fpms.ac.be > > E-mail FPMS :stu1997023@gaston.fpms.ac.be > > > > From michael.toennies at nord-com.net Tue Feb 13 18:27:58 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 17:59:58 2005 Subject: [CF-Devel] FW: rogue like games gfx (info) Message-ID: Hi Big mail i give out to artist who answered me. I explain the cf animation and tile set in simple words, so kick me if they not scope the whole reality. I do it for giving them a quick info... Well, it is some complex for a new people is alot. > -----Original Message----- > From: Michael Toennies [mailto:michael.toennies@nord-com.net] > Sent: Wednesday, February 14, 2001 1:25 AM > To: Sebastien Bracquemont [dweeves@hotmail.com] > Subject: FW: rogue like games gfx > > > > > > -----Original Message----- > > From: Michael Toennies [mailto:michael.toennies@nord-com.net] > > Sent: Wednesday, February 14, 2001 1:00 AM > > To: Jaakko Tapani Peltonen > > Cc: David [david_eg@mail.com]; Mitsuhiro Itakura > > [ita@gold.koma.jaeri.go.jp]; Hansjoerg Malthaner > > [hansjoerg.malthaner@danet.de]; M?rten Woxberg [maxmc@telia.com] > > Subject: RE: rogue like games gfx > > > > > > Ok > > First a thanks for all who answer me and give us tiles/permission > > to use tiles. > > > > I give you an overview how CF works and the gfx is included and > threaded. > > > > ** CF is a very very complex engine. They worked since 10 year on > > it, i think there are > > only a few programs outside with complexer map engines then cf. > > So, this will give you only > > a overview what can be done ** > > > > Our real problem is, that the maps and the gfx show only x% of > > the real potential of the engine. > > Thats, what we will change now. > > > > Plase read the part about the "Animation and Muli Tiles" and the > > following in all cases. > > > > About the CF tile system: > > ------------------------- > > > > It is very very flexible. It is multi tiled and animated. > > > > We use png pictures. We will use palettelized sprites and real > > alpha blending in the future, > > in fact my client can do it yet, but it is not yet in the server code. > > > > The single tile is 32x32 pixels. > > > > You can store the png in any format. 16 colors, 256 colors or > > true color - because the open pnglib > > every client/programm use can transform them in the right format. > > My client use 16bit HiColor > > yet. Thats only for speed, because some guys run the client on > > pc133. True color will give them no > > real better gfx yet but will drop speed. > > > > ** for rendered true color tiles with more then 256 colors please > > use RGB black (0,0,0) as default > > color key, for pngs <256 colors please use a 256 palette picture ** > > > > Remember: Because the png 16/256 palettes stores the pixel as > > true color pixel of course, > > we always have the color information as true color. So , we eat > > EVERY color information. > > > > ** Because the server SENDS the png to the client, the set can > > changed "on the fly" ** > > > > The server send every ppl who log in, the tile name and a > > checksum for all tiles, he can see on map. > > The server use a dirty map for it, so he knows which tile the > > user knows and he send it only one time. > > This will avoid lag. When the client don't have the tile in cache > > folder (from older logins or pre loaded > > from a library file) or he has an old tile, client requests the > > png from server who send it then to him. > > > > Map Editor and Random maps > > -------------------------- > > > > Maps are worked out with a map editor. CF use a very very complex > > real time engine for animate/control > > the maps. In fact, you can build crazy complex mashines, which > > levers, teleporters, moving bolders, > > creators, sensors .... and so on. > > > > There are maps out, which have so complex "engines" inside player > > can trigger to do some, dev team > > need weeks to find out how because the guy who created them is gone... > > > > WHAT WE REALLY NEED: > > Is gfx for multi tiles structures. So, big pyramids or some else. > > Or terrain with big mountains etc. > > > > ** in fact you can render a whole map and put it in ' at once' as > > one map ** > > > > Because you can put maps easy to a server with new tiles who get > > sended to client, you are free to > > draw ALL you want. > > > > btw: every gfx or tile is an object in cf. Every object can be > > given all object attributes. > > So, a simply floor tiles is the same object then the player - > > except he has not the right flags and > > the server/client handle it in different cases then. > > > > But perhaps you can have all times a event, who give a > > tile/object new flags and then he will be > > threaded then a new object... you got the point? > > > > We have also a random map generator like nethack or others included. > > In fact, in one of the next versions, we will put in the whole > > nethack quests. > > This will make nethack a kind of CF part ;) > > > > > > Animation and Multi Tiles > > ------------------------- > > > > This is easy. To every object (remember, that a simple floor tile > > is an object) you attach a gfx - > > here a png. > > > > Lets talk about floor.png as gfx. > > > > At first, you pre define a standard object which get attacked > > with a picture. For the ground it is > > the simplest object. > > > > Now you can extend this object. To animate, you put in a animate cmd. > > For this (and for multi tiles) you give the picture this names: > > > > floor.111.png > > > > This is the first tile of an animation. Every picture use this > > namings, even when there is no > > animation. This make it easy to extend a picture with more > > animation. Simply add the animation > > cmd the the object and put a > > > > floor.112.png > > > > in the pic lib. You also put in a speed value and then the client > > (or the server) plays the animation. > > > > first floor.111.png then floor.112.png... This can be extended to > > floor.119.png. > > > > This is only a animation STEP. You can add more STEPS to more > > complex animations. This removes the > > 10 frame animation limits. Steps are also used for complexer > > animation, fo example when you look > > in different direction with your player picture. Every step has > > then a single animation row... > > > > Also, you can create multi tiles objects! > > > > This goes from x=1 to 10 and y=1 to 10. So a 3x4 or a 2x6 or a > > 1x9 monster is possible!!!!!!!! > > > > Lets think about a 2x2 monster. It has 64x64 pixels and is has 4 tiles. > > > > Positions: > > > > AB > > CD > > > > This 4 pngs make this monster: > > > > monster.111.png = A Position > > monster.121.png = B "" > > monster.211.png = C "" > > monster.221.png = D "" > > > > As you can see, there are the first 2 numbers for: they define > > the position of a multi size object. > > this will make 320x320 monster possible... We HAVE big demons > > with 6x6 inside yet! > > > > (in later versions, we can change this to 2 chars. like > > monster_A.111111.png. This will make > > 99x99 tile object with 99 standard animations... but really... > > you don't want do draw often a > > 600x400 pixel monster with 20 animations :) If you do, we make > > the changes asap :)) ) > > > > Now, if you want look this monsters in a different direction (a > > different STEP): > > > > monster2.111.png > > monster2.121.png > > monster2.211.png > > monster2.221.png > > > > Now the trick: For every tile, you can still use normal frame > animation.! > > > > This for example will let the monster move the head from left > to right... > > This will be played from default tile animation system. > > > > monster2.121.png > > monster2.122.png > > monster2.123.png > > > > With this system, you can do very very complex situations and > animations. > > > > What that means for an artist? > > ------------------------------ > > > > Simply draw sets of animations with the full picture like you > > make it for comic movie. > > > > ** You don't need to cut them in 32x32 tiles!!! ** > > > > Now a guy who has access to a server or the CVS create the object > > with animation data for it. > > Also, the "cut off" to 32x32 will be done from him. > > > > ** You can give us every animation you can draw in normal > "movie style" ** > > > > > > Palettelized Sprites > > -------------------- > > > > For the 256 colors we will go to palettelized sprites - means we > > change the palette by client > > "on the fly". This will end up in the Diablo 2 monsters, where > > the special monsters have fancy > > colors, but use the same gfx data. Or in Age of Empire, the walls > > have a painting in player colors. > > There is a mask above them with a changed palette for every player. > > CF will do the same. The palettes will pre defined, so many > > pngs/monsters can use them. > > > > Example for a orc having the orc.png as tile: > > The server then will tell the client for a palettelized monster > > simply: "show tile 'orc.png' > > (and use the original palette of this png). For the chief orc, > > use same tile, but use palette 5. > > > > This will then show the orks "normal" because every palettelized > > png come with a default palette - > > even the one who in the png file. The chief or but will shown in > > different colors. > > > > The "palette 5" palette is nothing more then the png > > "palette_5.png". This png has no gfx data (it > > has, but it is only a 1,1 picture - the client/server ignore gfx > > data). The client safe it and then > > he rip of the palette when needed and attach it to other pngs. > > > > The big big plus of this is, that the information of the > > different color styles are in the monster > > data NOT in the gfx data. So you can crate a new city, getting > > the standard guard but attach in map > > editor a different palette to them, so they show up all with blue > > shields for example - different from > > other citys. Look for Diablo 2 and other games using it for > > getting more ideas. > > > > I talking about this, because i saw in many tile sets the same > > monsters in 4-6 different color styles. > > Using a set of pre definded palettes with different "ground" and > > "changing " colors will rip you off > > of all this same gfx. In fact, if you use so a set of pre defined > > palettes, you get automatically > > the different colors if you draw a new monster/gfx. > > > > Puh, that was alot. > > As you can see, CF is not one of this games "in development". > > In fact, we should had given out first 1.0 version 5 years ago. > > But the people had so many new ideas, we always go from 95.3 to 95.4... > > > > CF is more finished yet then some commerzial programs i know. > > BTW, iam a professionel game writer. > > > > cu > > Michael > > > > > -----Original Message----- > > > From: Jaakko Tapani Peltonen [mailto:jtpelto2@cc.hut.fi] > > > Sent: Tuesday, February 13, 2001 7:34 PM > > > To: Michael Toennies > > > Subject: Re: rogue like games gfx > > > > > > > > > On Fri, 9 Feb 2001, Michael Toennies wrote: > > > > > > Hello, > > > > > > I'm rather tied up with the different versions of NetHack - > Falcon's Eye > > > for now, but I'll look into the Crossfire when I have time. Judging by > > > the screenshots on the website, I believe I could make some > improvement > > > to the graphics, alghough it depends of course on how flexible the > > > graphics engine is. I'll send a concept screenshot of the > what the game > > > screen could look like, after I've had time to work on it. > > > > > > Jaakko Peltonen > > > > > > PS. I'm sorry about the late response. > > > > > > > > > From leaf at real-time.com Tue Feb 13 19:27:37 2001 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 17:59:59 2005 Subject: [CF-Devel] FW: rogue like games gfx (info) In-Reply-To: Message-ID: The screen shot section of the website is pretty sparse.. http://crossfire.real-time.com/Screen_Shots/screen_shots.html Anyone want to help add to this page? If so, please send me the graphics as attachments or a URL so I can download them that way. Thanks. - Rick Tanner leaf@real-time.com On Wed, 14 Feb 2001, Michael Toennies wrote: > From: Jaakko Tapani Peltonen [mailto:jtpelto2@cc.hut.fi] > Sent: Tuesday, February 13, 2001 7:34 PM > To: Michael Toennies > Subject: Re: rogue like games gfx > > > Hello, > > I'm rather tied up with the different versions of NetHack - > Falcon's Eye for now, but I'll look into the Crossfire when I have time. > Judging by the screenshots on the website, I believe I could make some > improvement to the graphics, alghough it depends of course on how > flexible the graphics engine is. I'll send a concept screenshot of the > what the game screen could look like, after I've had time to work on it. > > Jaakko Peltonen > > PS. I'm sorry about the late response. > From mwedel at scruz.net Tue Feb 13 21:59:47 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:59 2005 Subject: [CF-Devel] Problems with 0.96.0 References: <20010213040740.I26843@real-time.com> Message-ID: <3A8A02B3.C80136C7@scruz.net> Bob Tanner wrote: > > Initialize new client/server data > Loading image file /usr/games/crossfire/share/crossfire/crossfire.xbm > read_client_images: Did not read desired amount of data, wanted 72, got 0 > IMAGE 00000 72 /var/tmp/crossfire-0.95.8.arch/system/bug.111 I get no such problem. the xbm file actually has not been changed for quite a while. Couple idea: 1) Check the size of that file. Is it truncated? Perhaps the disk is full? 2) Perhaps during the compilation, it tried to run collect? This should not happen, but if you extracted the archive with the 'p' flag of tar, I think it could happen. Did you run a make install after the compilation? From mwedel at scruz.net Tue Feb 13 23:18:26 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:59 2005 Subject: [CF-Devel] FW: rogue like games gfx (java) References: Message-ID: <3A8A1522.FACB168D@scruz.net> Rick Tanner wrote: > > Yes, a Java client is available. > > More info is at: > > http://crossfire.real-time.com/Clients/Java_Crossclient/java_crossclient.html > But did the source for that ever get made publicly available? Granted, someone wanting to do a java client could ask Phil Brown for the source, but last I heard, the source still wasn't public, which is a shame. From mwedel at scruz.net Wed Feb 14 00:44:42 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:59 2005 Subject: [CF-Devel] FW: rogue like games gfx (3rd) References: Message-ID: <3A8A295A.2B018E56@scruz.net> As a note, I've montaged the images and put them up at: http://tavern.santa-clara.ca.us/cf/ Some of them look like they could be fairly direct replacement for objects currently in crossfire (after conversion to from bmp to png, and creation of a transperancy if necessary). My one main concern is that of consistency. Its great the MichT has talked to many artists and they are contributing images, but I think in some cases that stylistically, the artists (and thus their images) differe. While its pretty easy to say 'this battle axe looks the best out of all the choices', if the hand axe chosen is by someone different, and the sword by someone different still, I wonder how that will really look. Certainly, this is more important for objects within the same class (for example, mixing images of this guys potions (on the pxxx3.png image) with ours would probably reduce the overall image effect/quality. I also notice that this fellow images have shadowing, which would probably need to be removed/cleaned up. In summary - I think its great we are getting bunches of high quality images, but we need to make sure the image set (or at least images within a type) are consistent. Also, I really don't want to be the one responsible for image checkin/cleanup, but I do think we need an image czar to make sure the image set does remain consistent. This is a great thing for people who want to help out in a non programming manner. Any volunteers? From michael.toennies at nord-com.net Wed Feb 14 09:16:53 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 17:59:59 2005 Subject: [CF-Devel] FW: rogue like games gfx (3rd) In-Reply-To: <3A8A295A.2B018E56@scruz.net> Message-ID: Well, i think we need some "diplomacy" here. I look into the the projects the artist work for and most look very same - rogue like games like nethack with full or iso gfx. Most are really unfinished. One or two going in dev stronger, for that the artist works mainly. The set we got are "common sets", wrote for one of this games and then used by others. In fact, i think they got many requests for doing this and doing that, but then the project will never be great as expected. No one from the artist will yet go directly to CF and start drawing. I think i post some mail why not - and as you can see it goes like i wrote. But they do the first step: giving out was the have and give the stuff (CF) "a look". So, we must do the next step: Simply put many as possible gfx from then in a new png sets! Why? Because nothing is more exciting for an artist as to see his own work. ;) When it looks good, he will draw more because it looks good. If it looks bad, we will draw it new, so it will look good. We should not care at this point to a consistent set. Peter has wrote about it in IRC too. Because we must change alot and the png set is somewhat "assembled" from many sources, we should put in all what looks good. Ok, not the really crazy things, it should playable and showable, but we should not care yet about consistance or iso angel. This will come automatically with time. Our priority must be to involve so many artists as possible to work for CF. When they can do here valuable, useful (and used!) gfx, they will draw more and more. They will then remove itself the bad gfx. They are artists. It makes them depressive to see a bad png tile next to there favorite dragon. Ok, when we can assign one or two artists to the whole set and we know they will draw all in the same style, then style rules are a must - but we are not in this position. Remember, we talk about ~3000 tiles. If a artist produce 30 tiles every week he need about 2 years to finish the set! So, we need about 5-6 artist who draw a lot, to really make a resonable set in a time about 6-12 month. For this, we must give them a "playground". We can't avoid it. Ok, CF will look some time not as we think it should be, but we can all times say: "we growing up, it is in development". This is also a good thing!! It will give the people the feeling work is needed. If the set looks to "good", people will think its complete and will not think about doing now ones. ** We should think about some main style rules and we all should assign a few hours to the new gfx and the png set what we want have new and what we should put in - perhaps next days on IRC ** Michael > > As a note, I've montaged the images and put them up at: > http://tavern.santa-clara.ca.us/cf/ > > Some of them look like they could be fairly direct replacement > for objects > currently in crossfire (after conversion to from bmp to png, and > creation of a > transperancy if necessary). > > My one main concern is that of consistency. Its great the MichT > has talked to > many artists and they are contributing images, but I think in > some cases that > stylistically, the artists (and thus their images) differe. > While its pretty > easy to say 'this battle axe looks the best out of all the > choices', if the hand > axe chosen is by someone different, and the sword by someone > different still, I > wonder how that will really look. Certainly, this is more > important for objects > within the same class (for example, mixing images of this guys > potions (on the > pxxx3.png image) with ours would probably reduce the overall image > effect/quality. > > I also notice that this fellow images have shadowing, which > would probably need > to be removed/cleaned up. > > In summary - I think its great we are getting bunches of high > quality images, > but we need to make sure the image set (or at least images within > a type) are > consistent. > > Also, I really don't want to be the one responsible for image > checkin/cleanup, > but I do think we need an image czar to make sure the image set > does remain > consistent. This is a great thing for people who want to help > out in a non > programming manner. Any volunteers? > _______________________________________________ > 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 Wed Feb 14 19:16:19 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 17:59:59 2005 Subject: [CF-Devel] gcfclient and -image ? Message-ID: <20010214191619.G23134@real-time.com> Usage of gcfclient says -image is an option, but looking at the opts parsing code there is not a handler for -image. Is -image a future option? -- 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 leaf at real-time.com Wed Feb 14 19:55:21 2001 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 17:59:59 2005 Subject: [CF-Devel] Warrior Proving Tower Message-ID: With the latest CVS update I noticed that you can still enter the Warrior Proving Tower from it's old tower entrance in Scorn, but when you exit you end up in Dtabb. Looks like the Scorn map needs an update. - Rick Tanner leaf@real-time.com From andi.vogl at gmx.net Wed Feb 14 20:03:40 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 17:59:59 2005 Subject: [CF-Devel] mak maps Message-ID: <000001c096f3$85209be0$cc13993e@kyle> Just a note, I've checked in some mods to maps. Most are cosmetics for png outlook. But a few might be worth mentioning: Mak maps (the new warrior proving tower): I MOVED the mak maps (the tower) from scorn to dtabb (northeast edge). Reason: Such extremely high-level maps shouldn't be located in the starting town. Besides, dtabb has an urgent need for attractive maps. I also changed the formerly total insane artifacts (turban and bracers). (Please when checking in new map sets, take at least a quick look at the contained artifacts.) HouseOfHealing: Inserted nice altars for unlimited access to healing runes, for money. Removed "rod of restoration". Even though it costed about an ocean filled with platinums, it was just a source for exploits. Andreas V. From andi.vogl at gmx.net Wed Feb 14 21:30:54 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 17:59:59 2005 Subject: [CF-Devel] (old) bugs Message-ID: <000101c096ff$b5a218a0$cc13993e@kyle> Mark W. wrote: > IF you know of any bugs in the 0.96.0 release (even if they > date back further), please send a message to the list. Best I > know, the current snapshot is bug free. While reading this, a few bugs suddenly came to my mind: o Crossedit: In the main window of CE, there is this big scrollbar-list with all existing archetypes for picking. One can choose in the menu above, how many and what types of arches will appear in the list. When I select "all", there is some kind of overflow. Resulting in only a very small number of viewable arches (not even half of them!). That is TERRIBLE for map-making. I have to insert special objects in a pickmap, using an ascii-editor to access them in CE. Please fix this very old and very annoying bug. o cfclient: When I resize the window, client crashes. This bug existed since I first used cfclient. o CF server (attack code): I've noticed that multisquare monsters sometimes don't attack me with melee. They move next to me, cast spells at me, but no melee attack. Any idea why this could happen? When a monster with special resistances (special = not identical with archetype) has the "can_use_armour 1" and can_apply/will_apply set, this screws the monster's resistances. When applying an armour, the monster seems to revert to archetype's resistances (or maybe even none). The movement scripts don't work for multisquare monsters. The monsters seemingly are always treated one square, using the head (upper-left edge) of multi-squares. For monsters like 3x3 upwards, this leads to serious malfunction. Andreas V. From mwedel at scruz.net Wed Feb 14 21:48:19 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:59 2005 Subject: [CF-Devel] gcfclient and -image ? References: <20010214191619.G23134@real-time.com> Message-ID: <3A8B5183.7943BB37@scruz.net> -image may be a future option. I'll remove it from the option list until it actually gets implemented. Bob Tanner wrote: > > Usage of gcfclient says -image is an option, but looking at the opts parsing > code there is not a handler for -image. > > Is -image a future option? > > -- > 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 mwedel at scruz.net Wed Feb 14 22:17:16 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:59 2005 Subject: [CF-Devel] (old) bugs References: <000101c096ff$b5a218a0$cc13993e@kyle> Message-ID: <3A8B584C.8238045@scruz.net> Andreas Vogl wrote: > o Crossedit: In the main window of CE, there is this big scrollbar-list > with all existing archetypes for picking. One can choose in the menu > above, how many and what types of arches will appear in the list. > When I select "all", there is some kind of overflow. Resulting in > only a very small number of viewable arches (not even half of them!). > That is TERRIBLE for map-making. I have to insert special objects in a > pickmap, using an ascii-editor to access them in CE. Please fix this > very old and very annoying bug. Probably should be fixed. Unfortunately, I don't think anyone still active on the development is really all that familiar with crosseidt. > > o cfclient: When I resize the window, client crashes. This bug existed > since I first used cfclient. I do this all the time, and it never crashes. There is a bug in that if you resize the window while in metaserver selection mode, the window grows but it doesn't re-size the subwindows. But I haven't seen it crash. Perhaps more information on exactly how to do this might be useful. > > o CF server (attack code): I've noticed that multisquare monsters > sometimes don't attack me with melee. They move next to me, cast > spells at me, but no melee attack. Any idea why this could happen? Where is the monsters logical head located relative to you (logical head always being the upper left corner of the monster). I wonder if perhaps the code is thinking that the monster is not directly adjacent (of which the head is not), even though it is due to the rest of its body. > > When a monster with special resistances > (special = not identical with archetype) has the "can_use_armour 1" > and can_apply/will_apply set, this screws the monster's resistances. > When applying an armour, the monster seems to revert to archetype's > resistances (or maybe even none). This applies for more than just resistances - basically all attributes (str, dex, ...) The problem is difficult to fix. Basically, to fix this would require a second store of values as stored in the map file. This could perhaps be done via a dynamic archetype - if we notice some values being changed, we allocate another archetype, update the objects arch pointer to that, and set a flag so we know we have already done this (and to free that archetype when we free the object). The reason this happens is that when a creature applies something (note the both monsters and players use the same function), we go back to the archetype values to use for base and just add/subtract onto stuff. This is much more accurate, and in some ways the only way to go (since resistances are not strictly additive, I am not sure if you could accurately remove resistances without recalculating them all). > > The movement scripts don't work for multisquare monsters. The monsters > seemingly are always treated one square, using the head (upper-left edge) > of multi-squares. For monsters like 3x3 upwards, this leads to serious > malfunction. It should work. I've seen big monsters move around. Perhaps you can provide a better example? The logic should be recursive (ie, we check to see if the head can move in the desired direction, then try all the body parts, and are smart enough to check to see if the destination space is blocked by the monster or something else). As I think about it, however, this can probably be optimized a lot - if we know what direction the monster is moving, all we need to do is check the spaces that he would be moved into, not all the spaces. Ie, if a 3x3 monster is moving east, we just need to check the 3 spaces east of the monster, and not the 9 spaces one spot east of the head. From michael.toennies at nord-com.net Thu Feb 15 01:47:14 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 17:59:59 2005 Subject: [CF-Devel] New tiles for Crossfire ! Message-ID: Check this! http://w1.271.telia.com/~u27102957/index2.html [snip] Made some more convertions of my old tiles to Crossfire.. Be Ware.. these are PNG format tiles thus you probably need a new client (Im not sure about it but.. hm) Anyways.. >Download< them here! There's a total of 57 images in there.. some of them are new and probably needs some changes in the code for them to be used.. but I was told they where wanted.. From michael.toennies at nord-com.net Thu Feb 15 03:56:28 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 17:59:59 2005 Subject: [CF-Devel] New crossfire Tiles Message-ID: Here are some new Tiles. They are from a set i self cut down some. Well, to speed things up, i will going this way: I hold contact to the artist, look in the work and change and check the tiles (format, transparence, etc.). Then i give them to AV to check them in and for include in CF. This will free AV from unusable tiles - of course we still have work with them. In this set are some bigger structures... hill formations using 4 tiles - they look great! We will have to change the word map for it! Well, check this in and work over the world map will change the look in major way and will make them resonable for all people - and thats what we need! I will check in many as possible from this tiles fast as possible! Then we send him screenshots and tell him what we also need - you got the point? :) [snip] Hi Here are 58 semi-new tiles for use in Crossfire. These tiles are either done completely by me or they use some features of the tiles already present in the Game. This is my second release and I hope that the transparency works this time... most noticeably is the fountain.. so if the fountain isn't transparent where it should please feel free to contact me. This set contains 3 new tiles that wasn't present in the arch.tar.gz these are: hill.111.png, bighill.111.png, bighill.211.png, bighill.311.png, bighill.411.png, desert_1.111.png, desert_2.111.png, desert_3.111.png, desert_4.111.png, dsrt_hill.111.png, dsrt_oasis.111.png Bigg hill is a 2x2 hill in grass... hill is a 1x1 hill whereas the hills tile isnt done yet sadly.. so I guess you could rename hill.111.png to hills.111.png too... dsrt_hill and dsrt_oasis are just that.. a hill and an oasis in desert. desert_1 etc are variations on a desert theme.. so it wont get repetetive.. it goes along very well with desert.111.png too These tiles are free for use in non-profit products, I'd be very glad if you'd tell me in which projects you intend to use them too. New versions of this tileset will be avaiable on The Roguelike Graphics Page http://come.to/trgp/ Suggestions are welcome /M?rten E-mail: maxmc@telia.com Homepage: http://come.to/trgp/ From michael.toennies at nord-com.net Thu Feb 15 06:48:00 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 17:59:59 2005 Subject: [CF-Devel] Arch Files: my error / other error Message-ID: Hi Hm, i had given the artist an overview about the CF anim system - and is wasn't the truth! Sorry for it, i had a project with very similar naming, where the first 2 digit was for y and y. In CF we had this: image-file name.PDA.png (like orc.111.png) where P - part number D - direction (or any other instance coding in) A - animation phase numbering, PDA - 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F,G,...,Z (not case sensitive) - alphanumerics Part numbers (so, the first 2 numbers are not x and y position) Part numbers 3x3 1 2 3 4 5 6 7 8 9 2x2 1 2 3 4 3x2 1 2 3 4 5 6 2x3 1 2 3 4 5 6 codings: direction: 8 1 2 \ | / 7- 0 -3 / | \ 6 5 4 - same as in crossfire There are more complex for wall etc, but iam not sure, the arches really follow them - most i not needed i think. Well, this brings me to some Questions. 1.) Player Animations I never love thats our player chars only has 4 directions (1,3,5,7) but we ever walk in 8. Is it a big change to change them to 8 directions? In the code? 2.) Monsters I worked through the arches and i saw, that no monster is direction sensitive. Mean, we have monster looking left and right (dragons for example), but thats only animations like moving arms or so. Is it possible to add real directions to them? Or is it in the code? Means, when a monster go/attack to left, play left animations. If they walk to a different direction, only play animations with name.xPx . 3.) False included Arches Because there is no real monster direction in yet, there are some false included arches like the raas. The raas is include as raas.131.png and raas.171.png what means that in the old animation the raas looks left and right. In the new ones the raas lift arms. So, following our namings it must be raas.111.png and raas.112.png instead. Michael Michael From andi.vogl at gmx.net Thu Feb 15 06:55:50 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 17:59:59 2005 Subject: [CF-Devel] Warrior Proving Tower In-Reply-To: Message-ID: <000001c0974e$a0ddaf20$6796e23e@kyle> Rick Tanner wrote: > With the latest CVS update I noticed that you can still enter > the Warrior Proving Tower from it's old tower entrance in Scorn, > but when you exit you end up in Dtabb. > > Looks like the Scorn map needs an update. I am absolutely 100% sure that I updated scorn map and removed the exit path there. I even checked CVS right now: No mak-exit in scorn. So, I really have no idea why this happened to you. I guess your map update was incomplete for some reason. Andreas V. From michael.toennies at nord-com.net Thu Feb 15 06:34:01 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 17:59:59 2005 Subject: [CF-Devel] BIG error in arches - what a joke Message-ID: Hi As i telled some weeks ago the GreatDemon arch is broken. But peter say it is not... Well i saw him on my dxclient broken... Now i know why and its real a joke. As i look in the arches i saw this: GreatDemon.a11.png GreatDemon.A11.png HAHA. Yes, under unix these are 2 different files. Under windows (and mac and much more OS) they are NOT different! Windows file system is NOT case sensitive!! -------------------------------------------- We must remove ASAP all case sensitive names from CF! For a first quick look i found only the GreatDemon.. this must be changed to great_demon and the a11/A11 must be removed. Really, if i think how long this bug was in the arches and no one see it... :) Michael From andi.vogl at gmx.net Thu Feb 15 20:46:16 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 17:59:59 2005 Subject: [CF-Devel] new graphics Message-ID: <000001c097c2$a3f584c0$e29de23e@kyle> I just wanted to ask: Shall I start inserting the new graphics from Mitsuhiro and Marten into PNG set on cvs? Note that these pics will make our set a bit more inconsistent. Mainly because the new ones look so much more "professional" than the ones we currently have. There's also this little problem with prespective-"violation". But I think that is rather harmless: Most roguelikes seem to use a mix of different perspectives for walls/monsters, and we also did this in the xpm set. For example, replacing the remaining scaled-up monsters can hardly be a mistake... Making instant use of the new tiles might also make the artists happy. Showing them that we really care about their work. Overall I believe using the new stuff would be an improvement to the set. What do you think? Andreas V. PS.: Here again the sites where you can look at the new images: From mwedel at scruz.net Thu Feb 15 23:58:13 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:59:59 2005 Subject: [CF-Devel] new graphics References: <000001c097c2$a3f584c0$e29de23e@kyle> Message-ID: <3A8CC175.1C9A91B0@scruz.net> Andreas Vogl wrote: > > I just wanted to ask: Shall I start inserting the new graphics > from Mitsuhiro and Marten into PNG set on cvs? > Note that these pics will make our set a bit more inconsistent. > Mainly because the new ones look so much more "professional" than > the ones we currently have. Unless we do a wholesale checkin of a complete new image set, that will pretty much happen no matter what. And the png set is already inconsistent, so adding a few more won't hurt - as long as it is on the way to consistency. > There's also this little problem with prespective-"violation". > But I think that is rather harmless: Most roguelikes seem to use > a mix of different perspectives for walls/monsters, and we also > did this in the xpm set. For example, replacing the remaining > scaled-up monsters can hardly be a mistake... True. But we should aim for one perspective - especially if artists are going to draw new images for us - getting them all the same perspective is a good thing. I also think that if we don't get a consistency, we may have an issue of one artist re-doing another artists work because of the perspective difference, and that is just a waste of effort. > > Making instant use of the new tiles might also make the artists > happy. Showing them that we really care about their work. > Overall I believe using the new stuff would be an improvement > to the set. I agree. But at the same time, we do need to look at the end goal. If artists are giving us images with the wrong perspectively, we may want to gently say that the perspective is wrong, and the current perspective is X. While its nice for the artists to see the immediate results, if we end up getting rid of images they did or even say 'nope - sorry - don't like that image', you may very well alienate that particular artist. From mwedel at scruz.net Fri Feb 16 00:10:56 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:00 2005 Subject: [CF-Devel] BIG error in arches - what a joke References: Message-ID: <3A8CC470.CB142854@scruz.net> Michael Toennies wrote: > > Hi > > As i telled some weeks ago the GreatDemon arch is broken. > > But peter say it is not... Well i saw him on my dxclient broken... > > Now i know why and its real a joke. > > As i look in the arches i saw this: > > GreatDemon.a11.png > GreatDemon.A11.png Note that there are 42 animations for the great demon. So after the letters and number, there are still more than 6 animations that need to be covered. > > HAHA. > > Yes, under unix these are 2 different files. no problem there. > > Under windows (and mac and much more OS) they are NOT different! no problem there unless you plan to unpack the arch archive on a windows system and then collect it. > > Windows file system is NOT case sensitive!! > -------------------------------------------- > > We must remove ASAP all case sensitive names from CF! > > For a first quick look i found only the GreatDemon.. > this must be changed to great_demon and the a11/A11 must be removed. The reason no one sees it is because the only place you will notice it is if the client is caching images, runs on an OS that has case insenstive names, and the client is written such that it knows this fact and does renaming on its own. The problem really is what alternate characters can reasonably be used for the 6 (in this case) other images. Things like / and \ are out, as are probably :, <, >, [, ], *, |, $, !, ... In this case, we might be able to find 6 more (I thinkg _, {, }, =, -, % can probably be used OK). Of course, if someone ever makes as 7x7 objects (49 images), finding 13 non alphanumeric characters may be difficult. This is purely a client bug. A simple fix for the client can be to take that letter, convert it to hex, and save (and load) the filename that way. From dnh at hawthorn.csse.monash.edu.au Fri Feb 16 00:35:25 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:00 2005 Subject: [CF-Devel] Graphic perspective Message-ID: I think an important thing to note is monsters tend to be either front view (such as xpm set) or ISO (such as newer png (png made specifically for png set)). It would make alot of sense to maintain two sets, one for ISO view graphics, and one for front view. This would also allow use to completely remove the old xpm/xbm sets. dnh From michael.toennies at nord-com.net Fri Feb 16 02:51:41 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:00 2005 Subject: [CF-Devel] new tiles Message-ID: Hi I convert some monster from the new tiles. They are here http://mids.student.utwente.nl/~michtoen/demotiles/ Put them in the cache folder (or the gfx from the dxclient) and go to the newbie tower or better the mansion in scorn... The real looks nice! Michael From andi.vogl at gmx.net Fri Feb 16 07:57:05 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:00 2005 Subject: [CF-Devel] new graphics In-Reply-To: <3A8CC175.1C9A91B0@scruz.net> Message-ID: <000001c09820$5a0c39e0$72a5e23e@kyle> Mark W. wrote: > [...] we should aim for one perspective - especially if artists > are going to draw new images for us - getting them all the same > perspective is a good thing. [...] > > [...] we do need to look at the end goal. > If artists are giving us images with the wrong perspectively, we may > want to gently say that the perspective is wrong, and the current > perspective is X. While its nice for the artists to see the immediate > results, if we end up getting rid of images they did or even say 'nope - > sorry - don't like that image', you may very well alienate that particular > artist. So what do you propose to do? I see two valid options: 1) Insert new graphics into current png set. Eventually trying not to replace existing art that is good (and in the "correct" tilted style). Advantage here: We can start right away. 2) Start a second png set, to use all the new stuff. Of course we must remove xpm and xbm then. But most of the good xpm art is in the png set already, due to PeterM's recent effort. I believe that several people wanted to have a png set with front-view monsters (replacing xpm) anyways. Long before we got these new tiles. However, there must be a few tweaks in the client/server code and install scripts to support the new configuration of tile sets. If we choose to go this way, it would be nice to pull it off rather quick, so that the artists don't get bored. ;) Andreas V. From andi.vogl at gmx.net Fri Feb 16 18:02:35 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:00 2005 Subject: [CF-Devel] screenshots Message-ID: <000001c09874$f2f45120$069ee23e@kyle> Here are some screenshots how the game would look like if the new art would get inserted: . Just to demonstrate what we're talking about ;) We should decide what to do with it now. Andreas V. From andi.vogl at gmx.net Fri Feb 16 18:09:58 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:00 2005 Subject: [CF-Devel] (old) bugs In-Reply-To: <3A8B584C.8238045@scruz.net> Message-ID: <000101c09875$f9cf93a0$069ee23e@kyle> Uups, I accidentally sent this mail only to Mark, not to cf-devel. Here it is for everybody now: --------- Looks like I provided a bit too sparse info in some cases... But here we go: > [...] > > > o cfclient: When I resize the window, client crashes. This bug existed > > since I first used cfclient. > > I do this all the time, and it never crashes. There is a bug in that if > you resize the window while in metaserver selection mode, the window grows > but it doesn't re-size the subwindows. But I haven't seen it crash. > Perhaps more information on exactly how to do this might be useful. I suspect it might be a system-dependant bug then. I do nothing special, just install the client and run it. It crashes *always* when I resize it, at any time of play. I use SuSE linux 7.0. > > o CF server (attack code): I've noticed that multisquare monsters > > sometimes don't attack me with melee. They move next to me, cast > > spells at me, but no melee attack. Any idea why this could happen? > > Where is the monsters logical head located relative to you (logical head > always being the upper left corner of the monster). I wonder if perhaps > the code is thinking that the monster is not directly adjacent (of which > the head is not), even though it is due to the rest of its body. This bug doesn't seem to depend on my relative position to the monster's head. I noticed it very clearly when testing "Lorkas", the multi-square angel (and final boss) in Warrior Proving Tower. Sometimes he attacked melee, sometimes not. But he always casted spells and moved around. I'd love to tell you a "reason" for this to happen, but I can't yet. > [...] > > The movement scripts don't work for multisquare monsters. The monsters > seemingly are always treated one square, using the head (upper-left edge) > of multi-squares. For monsters like 3x3 upwards, this leads to serious > malfunction. > > It should work. I've seen big monsters move around. Perhaps you can > provide a better example? Sorry, you completely misunderstood my point (my fault). I referred to the attack-movement here. Not "monster relative to walls", but "monster relative to player". For example: When I set a certain attack_movement number (think that number was 1), the monster tries to maintain a distance of two squares to the player. But the distance is counted only from the monster's head. Thus, when I approach a 3x3 monster from above (north) - fine it will step away from me. But when I approach it from below (south) - it doesn't step away because head is in 3 squares distance north since monster *is* 3x3. Monster stands close to me, I can easily attack with melee, thus attack-movement algo has completely failed it's purpose. Andreas V. From peterm at tesla.EECS.Berkeley.EDU Fri Feb 16 19:04:11 2001 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:00 2005 Subject: [CF-Devel] screenshots In-Reply-To: Your message of "Sat, 17 Feb 2001 01:02:35 +0100." <000001c09874$f2f45120$069ee23e@kyle> Message-ID: <200102170104.RAA26806@tesla.EECS.Berkeley.EDU> > Here are some screenshots how the game would look like if > the new art would get inserted: > . > > Just to demonstrate what we're talking about ;) > We should decide what to do with it now. I agree with your comment on the page that it doesn't seem to really matter. I think you should put in the new tiles. PeterM > > Andreas V. > _______________________________________________ > 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 Fri Feb 16 19:12:57 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:00 2005 Subject: [CF-Devel] bug in unique exit code Message-ID: <000001c0987e$c52dfac0$059fe23e@kyle> The permanent apartment in nuernberg (pupland) is not accessible since the new exit code got checked in. It appears "closed" because the exit path is somehow misinterpreted. The correct name of this apartment map is "/maps/pup_land/ nurnberg/apartment/main". The link to this map is on "/maps/pup_land/nurnberg/city" - nuernberg city. All other perm. apartments work fine. As far as I know, nuernberg is the only case where the apartment map is in a subdirectory relative to the map it is linked to. This must be the reason for the bug. It seemingly can't cope with fact that there is a subdirectory. I hope this is easy to fix..? =p Some poor guys have valuable stuff in this apartment, heh... Andreas V. From dnh at hawthorn.csse.monash.edu.au Fri Feb 16 21:14:12 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:00 2005 Subject: [CF-Devel] new graphics In-Reply-To: <000001c09820$5a0c39e0$72a5e23e@kyle> Message-ID: > So what do you propose to do? I see two valid options: > > 1) Insert new graphics into current png set. Eventually trying not > to replace existing art that is good (and in the "correct" tilted style). > Advantage here: We can start right away. > > 2) Start a second png set, to use all the new stuff. Of course we must > remove xpm and xbm then. But most of the good xpm art is in the png set > already, due to PeterM's recent effort. > I believe that several people wanted to have a png set with front-view > monsters (replacing xpm) anyways. Long before we got these new tiles. > However, there must be a few tweaks in the client/server code and > install scripts to support the new configuration of tile sets. > If we choose to go this way, it would be nice to pull it off rather > quick, so that the artists don't get bored. ;) This is defn my prefered choice. We can start on the second set straight away also. Basically it will be exactly the same as png except monsters will be front view instead of ISO. (Building etc will be the same). I would suggest that if someone were to take this on they could create the whole new png set in two days or less. I would say version 1.0 would support only png 32 x 32. njh (my brother) has finished and released a new tiler specifically designed for png in linux; http://www.csse.monash.edu.au/~njh/programming/tile-widget-0.0.0.tar.bz2 Hopefull we can get a client that uses this very soon and this can probably also be used for a new crossedit if someone was interested. dnh From dnh at hawthorn.csse.monash.edu.au Sat Feb 17 00:02:58 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:00 2005 Subject: [CF-Devel] Jeweler? Message-ID: Hmm I always thought appraisment was the jeweler skill scroll.. it appears either a) I am mistaken in which case what is the correct scroll, or b) it has been broken (which might also have something to do with the fact that jewels are currently pre-identified.. has someone fiddled with this stuff? dnh From mwedel at scruz.net Sat Feb 17 02:22:02 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:00 2005 Subject: [CF-Devel] Jeweler? References: Message-ID: <3A8E34AA.7738277B@scruz.net> dnh wrote: > > Hmm I always thought appraisment was the jeweler skill scroll.. it appears > either a) I am mistaken in which case what is the correct scroll, or b) it > has been broken (which might also have something to do with the fact that > jewels are currently pre-identified.. has someone fiddled with this stuff? Sort of. appraisement is the right skill. The problem is this bit of code: #if 0 /* Bit verbose, but keep it here until next time I need it... */ { char identified = QUERY_FLAG(op, FLAG_IDENTIFIED); SET_FLAG(op, FLAG_IDENTIFIED); LOG(llevDebug, "Generated artifact %s %s [%s]\n", op->name, op->title, describe_item(op)); if (!identified) CLEAR_FLAG(op, FLAG_IDENTIFIED); } #endif Now at first glance, you would think that the above code should not change the identified status of objects. But in fact, it clears it because a char value is not large enough to hold the QUERY_FLAG request. So this code basically cleared the identified value for all objects. Random artifacts normally inherit the identified value of the object they are derived from. The gem types are by default identified. So either changing the gem archetypes to not be identified or changing the code so that all random artifacts are not identified is probably the needed fix. From dnh at hawthorn.csse.monash.edu.au Sat Feb 17 06:03:49 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:00 2005 Subject: [CF-Devel] Hmm more skill scroll problems.. Message-ID: Leadership and Performing give backwards skills? I learnt singing from leadership.. I thought that would be given from Performing. Also, I got oratory from performing.. =) dnh From michael.toennies at nord-com.net Sat Feb 17 13:02:36 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:00 2005 Subject: [CF-Devel] New Crossfire DirectX Client 0.99 BETA 5 Message-ID: Hi A new Client Version of the CFDX Client: 0.99 BETA 5. - include face checksums - add spelllist file for spell select panel - removed ALT+F4 (causes client exit() when pressing ALT for running and invoke F4 for shortcut item) - + many little cosmetic changes I made a download page now http://mids.student.utwente.nl/~michtoen/crossfire/ I riped of MiDS homepage and some stuff from AV for it, so kick me. ;) Always, the client is here on old position http://mids.student.utwente.nl/~michtoen/cfdxclient/newestversion Michael From dnh at hawthorn.csse.monash.edu.au Sat Feb 17 23:57:24 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:00 2005 Subject: [CF-Devel] Skill scrolls... AGAIN? Message-ID: I am not 100% but I am fairly sure alchemisty scrolls have vanished dnh From michael.toennies at nord-com.net Sun Feb 18 04:13:44 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:01 2005 Subject: [CF-Devel] Server bug in items cmd Message-ID: Hi When you plays raffle, the 3rd level with the trolls, get all items and drop them and step then on the pile, the connection dies. I got this 2 logs from it. Look at the 2nd one: After the item1cmds i start getting itemcmds!! The server stops normal after the big item1cmd sending cmds. The server logs for this here must be on crossfire.csua.berkeley.edu. Btw, the first number in front of the cmd is system time in ms (GetTime() ). [snip] 73724294 ::GetCommand:face1 -> len:14 73724294 ::GetCommand:face1 -> len:13 73724294 ::GetCommand:map -> len:79 73724295 ::GetCommand:map -> len:13 73724498 ::GetCommand:map -> len:13 73724498 ::GetCommand:map -> len:13 73725201 ::GetCommand:drawinfo -> len:12 73725201 ::GetCommand:drawinfo -> len:15 73725201 ::GetCommand:drawinfo -> len:32 73725203 ::GetCommand:player -> len:21 73725203 ::GetCommand:delinv -> len:7 73725203 ::GetCommand:face1 -> len:17 73725204 ::GetCommand:face1 -> len:19 73725204 ::GetCommand:face1 -> len:16 73725204 ::GetCommand:face1 -> len:14 73725205 ::GetCommand:face1 -> len:20 73725205 ::GetCommand:item1 -> len:250 73725205 ::GetCommand:stats -> len:68 73725206 ::GetCommand:face1 -> len:17 73725206 ::GetCommand:face1 -> len:17 73725206 ::GetCommand:face1 -> len:18 73725207 ::GetCommand:face1 -> len:20 73725207 ::GetCommand:face1 -> len:17 73725207 ::GetCommand:face1 -> len:18 73725208 ::GetCommand:face1 -> len:17 73725208 ::GetCommand:face1 -> len:15 73725208 ::GetCommand:face1 -> len:14 73725209 ::GetCommand:face1 -> len:16 73725209 ::GetCommand:face1 -> len:17 73725209 ::GetCommand:map -> len:225 73725210 ::GetCommand:delinv -> len:1 73725210 ::GetCommand:face1 -> len:14 73725210 ::GetCommand:face1 -> len:15 73725211 ::GetCommand:face1 -> len:14 73725211 ::GetCommand:face1 -> len:15 SEND: SEND: ncom ***** START ******** Item1Cmd: length 250 bytes DATA: tag:2637365 name:long sword flags:2 weight:15000 face:3070 nlen:22 DATA: tag:2637364 name:chain mail flags:3 weight:60000 face:738 nlen:22 DATA: tag:2637363 name:shield flags:3 weight:15000 face:2752 nlen:14 DATA: tag:2637362 name:sack flags:0 weight:100 face:2668 nlen:10 DATA: tag:2637361 name:food flags:0 weight:6500 face:1473 nlen:10 DATA: tag:2637360 name:silver coin flags:0 weight:10 face:2784 nlen:24 ***** END ******** 73726750 ::GetCommand:item1 -> len:9948 ***** START ******** Item1Cmd: length 9948 bytes DATA: tag:2564324 name:gold coin flags:0 weight:15 face:1600 nlen:20 DATA: tag:2564323 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564322 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564321 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564320 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564319 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564318 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564317 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564316 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564315 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564314 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564313 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564312 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564311 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564310 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564309 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564308 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564307 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564306 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564305 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564304 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564303 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564302 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564301 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564300 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564299 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564298 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564297 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564296 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564295 name:hill giant's heart flags:0 weight:11999 face:1710 nlen:38 DATA: tag:2564294 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564293 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564292 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564291 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564290 name:hill giant's heart flags:0 weight:11999 face:1710 nlen:38 DATA: tag:2564289 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564288 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564287 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564286 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564285 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564284 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564283 name:large club flags:0 weight:120000 face:371 nlen:22 DATA: tag:2564282 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564281 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564280 name:large club flags:0 weight:120000 face:371 nlen:22 DATA: tag:2564279 name:large club flags:0 weight:240000 face:371 nlen:22 DATA: tag:2564278 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564277 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564276 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564275 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564274 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564273 name:hill giant's heart flags:0 weight:11999 face:1710 nlen:38 DATA: tag:2564272 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564271 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564270 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564269 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564268 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564267 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564266 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564265 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564264 name:hill giant's heart flags:0 weight:11999 face:1710 nlen:38 DATA: tag:2564263 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564262 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564261 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564260 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564259 name:hill giant's heart flags:0 weight:11999 face:1710 nlen:38 DATA: tag:2564258 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564257 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564256 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564255 name:hill giant's heart flags:0 weight:11999 face:1710 nlen:38 DATA: tag:2564254 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564253 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564252 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564251 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564250 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564249 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564248 name:hill giant's heart flags:0 weight:11999 face:1710 nlen:38 DATA: tag:2564247 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564246 name:hill giant's heart flags:0 weight:11999 face:1710 nlen:38 DATA: tag:2564245 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564244 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564243 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564242 name:large club flags:0 weight:120000 face:371 nlen:22 DATA: tag:2564241 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564240 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564239 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564238 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564237 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564236 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564235 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564234 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564233 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564232 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564231 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564230 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564229 name:large club flags:0 weight:240000 face:371 nlen:22 DATA: tag:2564228 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564227 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564226 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564225 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564224 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564223 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564222 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564221 name:large club flags:0 weight:120000 face:371 nlen:22 DATA: tag:2564220 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564219 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564218 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564217 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564216 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564215 name:large club flags:0 weight:120000 face:371 nlen:22 DATA: tag:2564214 name:large club flags:0 weight:120000 face:371 nlen:22 DATA: tag:2564213 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564212 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564211 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564210 name:hill giant's heart flags:0 weight:11999 face:1710 nlen:38 DATA: tag:2564209 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564208 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564207 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564206 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564205 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564204 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564203 name:large club flags:0 weight:120000 face:371 nlen:22 DATA: tag:2564202 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564201 name:large club flags:0 weight:120000 face:371 nlen:22 DATA: tag:2564200 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564199 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564198 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564197 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564196 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564195 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564194 name:large club flags:0 weight:120000 face:371 nlen:22 DATA: tag:2564193 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564192 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564191 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564190 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564189 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564188 name:large club flags:0 weight:120000 face:371 nlen:22 DATA: tag:2564187 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564186 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564185 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564184 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564183 name:large club flags:0 weight:120000 face:371 nlen:22 DATA: tag:2564182 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564181 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564180 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564179 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564178 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564177 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564176 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564175 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564174 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564173 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564172 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564171 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564170 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564169 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564168 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564167 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564166 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564165 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564164 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564163 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564162 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564161 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564160 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564159 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 ***** END ********SEND: SEND: ncom SEND: SEND: ncom SEND: SEND: ncom SEND: SEND: ncom SEND: [snip] 74568881 ::GetCommand:item1 -> len:9948 ***** START ******** Item1Cmd: length 9948 bytes DATA: tag:2564324 name:gold coin flags:0 weight:15 face:1600 nlen:20 DATA: tag:2564323 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564322 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564321 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564320 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564319 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564318 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564317 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564316 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564315 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564314 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564313 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564312 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564311 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564310 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564309 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564308 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564307 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564306 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564305 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564304 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564303 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564302 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564301 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564300 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564299 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564298 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564297 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564296 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564295 name:hill giant's heart flags:0 weight:11999 face:1710 nlen:38 DATA: tag:2564294 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564293 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564292 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564291 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564290 name:hill giant's heart flags:0 weight:11999 face:1710 nlen:38 DATA: tag:2564289 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564288 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564287 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564286 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564285 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564284 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564283 name:large club flags:0 weight:120000 face:371 nlen:22 DATA: tag:2564282 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564281 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564280 name:large club flags:0 weight:120000 face:371 nlen:22 DATA: tag:2564279 name:large club flags:0 weight:240000 face:371 nlen:22 DATA: tag:2564278 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564277 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564276 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564275 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564274 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564273 name:hill giant's heart flags:0 weight:11999 face:1710 nlen:38 DATA: tag:2564272 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564271 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564270 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564269 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564268 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564267 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564266 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564265 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564264 name:hill giant's heart flags:0 weight:11999 face:1710 nlen:38 DATA: tag:2564263 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564262 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564261 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564260 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564259 name:hill giant's heart flags:0 weight:11999 face:1710 nlen:38 DATA: tag:2564258 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564257 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564256 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564255 name:hill giant's heart flags:0 weight:11999 face:1710 nlen:38 DATA: tag:2564254 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564253 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564252 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564251 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564250 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564249 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564248 name:hill giant's heart flags:0 weight:11999 face:1710 nlen:38 DATA: tag:2564247 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564246 name:hill giant's heart flags:0 weight:11999 face:1710 nlen:38 DATA: tag:2564245 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564244 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564243 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564242 name:large club flags:0 weight:120000 face:371 nlen:22 DATA: tag:2564241 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564240 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564239 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564238 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564237 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564236 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564235 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564234 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564233 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564232 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564231 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564230 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564229 name:large club flags:0 weight:240000 face:371 nlen:22 DATA: tag:2564228 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564227 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564226 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564225 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564224 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564223 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564222 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564221 name:large club flags:0 weight:120000 face:371 nlen:22 DATA: tag:2564220 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564219 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564218 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564217 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564216 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564215 name:large club flags:0 weight:120000 face:371 nlen:22 DATA: tag:2564214 name:large club flags:0 weight:120000 face:371 nlen:22 DATA: tag:2564213 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564212 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564211 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564210 name:hill giant's heart flags:0 weight:11999 face:1710 nlen:38 DATA: tag:2564209 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564208 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564207 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564206 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564205 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564204 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564203 name:large club flags:0 weight:120000 face:371 nlen:22 DATA: tag:2564202 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564201 name:large club flags:0 weight:120000 face:371 nlen:22 DATA: tag:2564200 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564199 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564198 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564197 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564196 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564195 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564194 name:large club flags:0 weight:120000 face:371 nlen:22 DATA: tag:2564193 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564192 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564191 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564190 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564189 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564188 name:large club flags:0 weight:120000 face:371 nlen:22 DATA: tag:2564187 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564186 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564185 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564184 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564183 name:large club flags:0 weight:120000 face:371 nlen:22 DATA: tag:2564182 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564181 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564180 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564179 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564178 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564177 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564176 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564175 name:hill giant's foot flags:0 weight:15000 face:1474 nlen:36 DATA: tag:2564174 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564173 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564172 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564171 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564170 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564169 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564168 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564167 name:hill giant's hand flags:0 weight:8999 face:1699 nlen:36 DATA: tag:2564166 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564165 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 DATA: tag:2564164 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564163 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564162 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564161 name:hill giant's head flags:0 weight:45000 face:1704 nlen:36 DATA: tag:2564160 name:hill giant's corpse flags:0 weight:300000 face:863 nlen:40 DATA: tag:2564159 name:hill giant's liver flags:0 weight:11999 face:2023 nlen:38 ***** END ******** 74570197 ::GetCommand:item -> len:9960 ItemCmd: Overread buffer: 10044 > 9960 74571515 ::GetCommand:item -> len:9968 ItemCmd: Overread buffer: 10048 > 9968 74572827 ::GetCommand:item -> len:9984 ItemCmd: Overread buffer: 10000 > 9984 From michael.toennies at nord-com.net Sun Feb 18 08:16:45 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:01 2005 Subject: [CF-Devel] The truth about ISO gfx - or why you all are wrong Message-ID: Hi I love this title - kick me for it. Ok, i have read alot about iso gfx and iso style here and i try to explain why things are different as some expect. So, i make this mail and some demo gfx to SHOW you why things are different as we do it in CF and why the CF png iso style is nonsense. 1. What is ISO gfx? ISO gfx is NOT a 3D gfx. It is not drawn 3D perspective. ISO style gfx is a eye trick. A way to fool yours eyes. You THINK you see a natural perspective gfx - in real its a big fake. It uses gfx tricks to fool you and tricks to make drawing gfx simple. I will show you the interesting tricks. 2. Diablo and Age of Empire Diablo and Age of Empire use both rectangle gfx turned for 90?. This is only a way to attach in a easy way the tiles - i will show you later why we don't need it. Diablo 2 use not real ISO tile gfx. It uses "ISO parts", big rendered parts which gets connected to a big picture. But int the core it is the same as Age of Empire. Age of Empires is one of the most sofisticated ISO bitmap tile engine which is on market. It has a map editor and i will show you the examples with it. 3. What ISO style bitmaps use? a.) *nearly* FLAT BITMAP Objects! b.) On all positions of a map objects of same *size* c.) background gfx who fool the eye to think you see a perpective d.) hidden "eye lines" in all object to fool your eyes to the perspective. This brings me to the first big point: The artist who native draw the CF png set don't know what iso style gfx are and how it works! ** We have NOT iso gfx in the png set - we have a bad frozen 3D gfx in it !!** Let me show you first picture (gfx from age of empire! microsoft copyright, so beware) This is simple grass with a few fighters. http://mids.student.utwente.nl/~michtoen/isodemo/demo1.png As you can see, the 2 figures going the the right - THEY ARE *nearly* FLAT!! The guy above is also flat, but the gfx has a animation on it, which turn the figure looking left to right. but the figure IS FLAT. The figure is drawn 'inside' as a object which look like propotions - thats all. All figures are drawn flat from front!! But as you can see, the pictures *without* any objects look real good - look NOT flat. why? Well, i will show you. But first the funny part: Look this ... http://mids.student.utwente.nl/~michtoen/isodemo/demo2.png Grin. Thats our ninja png .... Now look at it. THATS WHY OUR PNG pictures are NOT iso style gfx... Its a broken 3D gfx... Why artist don't use this? Why want the use the flat one? Because iso works with it! Because you can show more details! Because only this fools the eyes. Now i include the pngs all people from you called "flat"... http://mids.student.utwente.nl/~michtoen/isodemo/demo3.png Hello? What is flat here? You see it? Welcome to ISO style gfx. Our flat little suckers mutate to real 3d like iso orcs... Ok. WHY? 4. Hidden perspective lines The *trick* are hidden in the grass... There are structures and *perspective* lines in it, which let your eye see the "iso perspective*. I had drawn lines in this picture to show you where they are... * i had drawn the lines *more* turned to the perspektive, than the real lines in the grass structures are, so you will see difference easily ** http://mids.student.utwente.nl/~michtoen/isodemo/demo4.png Thats all? thats real all? Yes. Thats the whole trick. The point is - The background must look as ONE perpective object. When this is not the case - things start looking strange. A nice demo picture. All objects are ok here, but vertical line, sitting in the middle breaks the eye perpective... not much, but it look good as when you put your hand on it and shows at the left one part. http://mids.student.utwente.nl/~michtoen/isodemo/demo5.png This "hidden" perspective lines works also, when you had nearly vertical structures. At this demo picture, all things are slighty turned or not 100% vertical... result... See for yourself. http://mids.student.utwente.nl/~michtoen/isodemo/demo6.png Give the background a look. See you, how the hidden structures in the grass give you the 3D perspektive look? But in real, the non vertical structures gives you the iso look. This 90? thing. So without. LOOK AT THE BACKGROUND. There is the perspective, NOT in the figure. http://mids.student.utwente.nl/~michtoen/isodemo/demo7.png Here with ... http://mids.student.utwente.nl/~michtoen/isodemo/demo8.png 5. So whats the point? a.) Our problem are the png iso gfx. DELETE THEM. b.) We need this kind of background structures. c.) We don't need 90? tiles like in AoE or Diablo. The structures can also in rectangle tile included. Look at demo7.png... its a rectangle. You can cut this in 32x32 tiles. What you need is a collection of parts where the hidden lines go on. d.) Its only a task of map making 6.) Are there more tricks Some. Most is to had "in the whole picture" the hidden lines. Because the lines are 90? its easy to draw when tiles are 90? too - but Diablo 2 for example use big rendered parts. Inside there are not 90? tiles... Its just more native to do it, but we don't must. 7.) How we can do it In fact for us is easier to draw rectangles... Simply draw the lines in bigger pictures and cut them out. ** Then use for maps bigger structures ** Don't include like we had done in old maps vertical lines of same tiles... This destroys the iso perspective. Look at the grass structures of the demo pictures, that gives you imagination how this bigger structures works. Its easy! You don't need much tiles. Plus some masks we can easily include because we have multi tile maps... 8.) Use background / object layers. We had some gfx- trees for example who had included backgrounds. This must removed also, because you start getting trouble with the background structures. But thats always a sign of good map editors to have logical layers. Its something we had included in CF long time - Simply we don't use it in our tile set. This must be changed. 9.) For fun: true high levels. If you ever think how the fancy high levels in AoE or other games works: here. The trick is, when you got a tile between 2 high levels - make this tile *longer* or shorter* Means, when all tiles 32x32. Make in a high levels first step 32x32, next step (thats goind down) 28x32 and the bottom tile (where you see much room) 36x32... This goes with masks. Now, when a object move in this, you had a speed x. 32/x are the pixels you move every turn. For the 28x32 tile is it 28/x ... means you can move faster (or slower when calc it different). Because you now have also a real *on the map existing* pixel difference, you see in AoE the figures really going high or down in the map... Because the tile SIZE is different... But thats only for fun, we want do this in CF before version 4.0 or so :) http://mids.student.utwente.nl/~michtoen/isodemo/levels 10.) Whats now? Ok, lets talk about. I hope i had cleared the things for you. Our problem is the background and the maps, meaning the use of background gfx in the maps. Also, when we dont include rectangle houses/dungeons , we got it. Its simple to add a 90? dungeons, with 90? walls... in fact, we can do it with the set we have. Michael From mwedel at scruz.net Sun Feb 18 13:32:22 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:01 2005 Subject: [CF-Devel] Server bug in items cmd References: Message-ID: <3A902346.B4014A34@scruz.net> Found the bug. Unfortunatel, the CVS server is down so I can't check it in right now. Michael Toennies wrote: > > Hi > > When you plays raffle, the 3rd level with the trolls, get all items and drop > them and step then on > the pile, the connection dies. > I got this 2 logs from it. > > Look at the 2nd one: After the item1cmds i start getting itemcmds!! > The server stops normal after the big item1cmd sending cmds. > > The server logs for this here must be on crossfire.csua.berkeley.edu. > > Btw, the first number in front of the cmd is system time in ms (GetTime() ). > > [snip] > 73724294 ::GetCommand:face1 -> len:14 > 73724294 ::GetCommand:face1 -> len:13 > 73724294 ::GetCommand:map -> len:79 > 73724295 ::GetCommand:map -> len:13 > 73724498 ::GetCommand:map -> len:13 > 73724498 ::GetCommand:map -> len:13 > 73725201 ::GetCommand:drawinfo -> len:12 > 73725201 ::GetCommand:drawinfo -> len:15 > 73725201 ::GetCommand:drawinfo -> len:32 > 73725203 ::GetCommand:player -> len:21 > 73725203 ::GetCommand:delinv -> len:7 > 73725203 ::GetCommand:face1 -> len:17 > 73725204 ::GetCommand:face1 -> len:19 > 73725204 ::GetCommand:face1 -> len:16 > 73725204 ::GetCommand:face1 -> len:14 > 73725205 ::GetCommand:face1 -> len:20 > 73725205 ::GetCommand:item1 -> len:250 > 73725205 ::GetCommand:stats -> len:68 > 73725206 ::GetCommand:face1 -> len:17 > 73725206 ::GetCommand:face1 -> len:17 > 73725206 ::GetCommand:face1 -> len:18 > 73725207 ::GetCommand:face1 -> len:20 > 73725207 ::GetCommand:face1 -> len:17 > 73725207 ::GetCommand:face1 -> len:18 > 73725208 ::GetCommand:face1 -> len:17 > 73725208 ::GetCommand:face1 -> len:15 > 73725208 ::GetCommand:face1 -> len:14 > 73725209 ::GetCommand:face1 -> len:16 > 73725209 ::GetCommand:face1 -> len:17 > 73725209 ::GetCommand:map -> len:225 > 73725210 ::GetCommand:delinv -> len:1 > 73725210 ::GetCommand:face1 -> len:14 > 73725210 ::GetCommand:face1 -> len:15 > 73725211 ::GetCommand:face1 -> len:14 > 73725211 ::GetCommand:face1 -> len:15 > SEND: > SEND: ncom > ***** START ******** > Item1Cmd: length 250 bytes > DATA: tag:2637365 name:long sword flags:2 weight:15000 face:3070 nlen:22 > DATA: tag:2637364 name:chain mail flags:3 weight:60000 face:738 nlen:22 > DATA: tag:2637363 name:shield flags:3 weight:15000 face:2752 nlen:14 > DATA: tag:2637362 name:sack flags:0 weight:100 face:2668 nlen:10 > DATA: tag:2637361 name:food flags:0 weight:6500 face:1473 nlen:10 > DATA: tag:2637360 name:silver coin flags:0 weight:10 face:2784 nlen:24 > ***** END ******** > 73726750 ::GetCommand:item1 -> len:9948 > ***** START ******** > Item1Cmd: length 9948 bytes > DATA: tag:2564324 name:gold coin flags:0 weight:15 face:1600 nlen:20 > DATA: tag:2564323 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564322 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564321 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564320 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564319 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564318 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564317 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564316 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564315 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564314 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564313 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564312 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564311 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564310 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564309 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564308 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564307 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564306 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564305 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564304 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564303 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564302 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564301 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564300 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564299 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564298 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564297 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564296 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564295 name:hill giant's heart flags:0 weight:11999 face:1710 > nlen:38 > DATA: tag:2564294 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564293 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564292 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564291 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564290 name:hill giant's heart flags:0 weight:11999 face:1710 > nlen:38 > DATA: tag:2564289 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564288 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564287 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564286 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564285 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564284 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564283 name:large club flags:0 weight:120000 face:371 nlen:22 > DATA: tag:2564282 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564281 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564280 name:large club flags:0 weight:120000 face:371 nlen:22 > DATA: tag:2564279 name:large club flags:0 weight:240000 face:371 nlen:22 > DATA: tag:2564278 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564277 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564276 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564275 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564274 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564273 name:hill giant's heart flags:0 weight:11999 face:1710 > nlen:38 > DATA: tag:2564272 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564271 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564270 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564269 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564268 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564267 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564266 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564265 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564264 name:hill giant's heart flags:0 weight:11999 face:1710 > nlen:38 > DATA: tag:2564263 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564262 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564261 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564260 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564259 name:hill giant's heart flags:0 weight:11999 face:1710 > nlen:38 > DATA: tag:2564258 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564257 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564256 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564255 name:hill giant's heart flags:0 weight:11999 face:1710 > nlen:38 > DATA: tag:2564254 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564253 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564252 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564251 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564250 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564249 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564248 name:hill giant's heart flags:0 weight:11999 face:1710 > nlen:38 > DATA: tag:2564247 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564246 name:hill giant's heart flags:0 weight:11999 face:1710 > nlen:38 > DATA: tag:2564245 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564244 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564243 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564242 name:large club flags:0 weight:120000 face:371 nlen:22 > DATA: tag:2564241 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564240 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564239 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564238 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564237 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564236 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564235 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564234 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564233 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564232 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564231 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564230 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564229 name:large club flags:0 weight:240000 face:371 nlen:22 > DATA: tag:2564228 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564227 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564226 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564225 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564224 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564223 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564222 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564221 name:large club flags:0 weight:120000 face:371 nlen:22 > DATA: tag:2564220 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564219 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564218 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564217 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564216 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564215 name:large club flags:0 weight:120000 face:371 nlen:22 > DATA: tag:2564214 name:large club flags:0 weight:120000 face:371 nlen:22 > DATA: tag:2564213 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564212 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564211 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564210 name:hill giant's heart flags:0 weight:11999 face:1710 > nlen:38 > DATA: tag:2564209 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564208 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564207 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564206 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564205 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564204 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564203 name:large club flags:0 weight:120000 face:371 nlen:22 > DATA: tag:2564202 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564201 name:large club flags:0 weight:120000 face:371 nlen:22 > DATA: tag:2564200 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564199 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564198 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564197 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564196 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564195 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564194 name:large club flags:0 weight:120000 face:371 nlen:22 > DATA: tag:2564193 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564192 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564191 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564190 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564189 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564188 name:large club flags:0 weight:120000 face:371 nlen:22 > DATA: tag:2564187 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564186 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564185 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564184 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564183 name:large club flags:0 weight:120000 face:371 nlen:22 > DATA: tag:2564182 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564181 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564180 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564179 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564178 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564177 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564176 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564175 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564174 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564173 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564172 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564171 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564170 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564169 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564168 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564167 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564166 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564165 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564164 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564163 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564162 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564161 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564160 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564159 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > ***** END ********SEND: > SEND: ncom > SEND: > SEND: ncom > SEND: > SEND: ncom > SEND: > SEND: ncom > SEND: > > [snip] > 74568881 ::GetCommand:item1 -> len:9948 > ***** START ******** > Item1Cmd: length 9948 bytes > DATA: tag:2564324 name:gold coin flags:0 weight:15 face:1600 nlen:20 > DATA: tag:2564323 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564322 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564321 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564320 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564319 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564318 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564317 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564316 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564315 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564314 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564313 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564312 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564311 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564310 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564309 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564308 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564307 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564306 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564305 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564304 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564303 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564302 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564301 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564300 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564299 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564298 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564297 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564296 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564295 name:hill giant's heart flags:0 weight:11999 face:1710 > nlen:38 > DATA: tag:2564294 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564293 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564292 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564291 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564290 name:hill giant's heart flags:0 weight:11999 face:1710 > nlen:38 > DATA: tag:2564289 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564288 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564287 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564286 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564285 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564284 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564283 name:large club flags:0 weight:120000 face:371 nlen:22 > DATA: tag:2564282 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564281 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564280 name:large club flags:0 weight:120000 face:371 nlen:22 > DATA: tag:2564279 name:large club flags:0 weight:240000 face:371 nlen:22 > DATA: tag:2564278 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564277 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564276 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564275 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564274 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564273 name:hill giant's heart flags:0 weight:11999 face:1710 > nlen:38 > DATA: tag:2564272 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564271 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564270 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564269 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564268 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564267 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564266 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564265 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564264 name:hill giant's heart flags:0 weight:11999 face:1710 > nlen:38 > DATA: tag:2564263 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564262 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564261 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564260 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564259 name:hill giant's heart flags:0 weight:11999 face:1710 > nlen:38 > DATA: tag:2564258 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564257 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564256 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564255 name:hill giant's heart flags:0 weight:11999 face:1710 > nlen:38 > DATA: tag:2564254 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564253 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564252 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564251 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564250 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564249 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564248 name:hill giant's heart flags:0 weight:11999 face:1710 > nlen:38 > DATA: tag:2564247 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564246 name:hill giant's heart flags:0 weight:11999 face:1710 > nlen:38 > DATA: tag:2564245 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564244 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564243 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564242 name:large club flags:0 weight:120000 face:371 nlen:22 > DATA: tag:2564241 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564240 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564239 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564238 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564237 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564236 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564235 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564234 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564233 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564232 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564231 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564230 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564229 name:large club flags:0 weight:240000 face:371 nlen:22 > DATA: tag:2564228 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564227 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564226 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564225 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564224 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564223 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564222 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564221 name:large club flags:0 weight:120000 face:371 nlen:22 > DATA: tag:2564220 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564219 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564218 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564217 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564216 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564215 name:large club flags:0 weight:120000 face:371 nlen:22 > DATA: tag:2564214 name:large club flags:0 weight:120000 face:371 nlen:22 > DATA: tag:2564213 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564212 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564211 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564210 name:hill giant's heart flags:0 weight:11999 face:1710 > nlen:38 > DATA: tag:2564209 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564208 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564207 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564206 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564205 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564204 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564203 name:large club flags:0 weight:120000 face:371 nlen:22 > DATA: tag:2564202 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564201 name:large club flags:0 weight:120000 face:371 nlen:22 > DATA: tag:2564200 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564199 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564198 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564197 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564196 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564195 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564194 name:large club flags:0 weight:120000 face:371 nlen:22 > DATA: tag:2564193 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564192 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564191 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564190 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564189 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564188 name:large club flags:0 weight:120000 face:371 nlen:22 > DATA: tag:2564187 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564186 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564185 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564184 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564183 name:large club flags:0 weight:120000 face:371 nlen:22 > DATA: tag:2564182 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564181 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564180 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564179 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564178 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564177 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564176 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564175 name:hill giant's foot flags:0 weight:15000 face:1474 > nlen:36 > DATA: tag:2564174 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564173 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564172 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564171 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564170 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564169 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564168 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564167 name:hill giant's hand flags:0 weight:8999 face:1699 > nlen:36 > DATA: tag:2564166 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564165 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > DATA: tag:2564164 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564163 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564162 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564161 name:hill giant's head flags:0 weight:45000 face:1704 > nlen:36 > DATA: tag:2564160 name:hill giant's corpse flags:0 weight:300000 face:863 > nlen:40 > DATA: tag:2564159 name:hill giant's liver flags:0 weight:11999 face:2023 > nlen:38 > ***** END ******** > 74570197 ::GetCommand:item -> len:9960 > ItemCmd: Overread buffer: 10044 > 9960 > 74571515 ::GetCommand:item -> len:9968 > ItemCmd: Overread buffer: 10048 > 9968 > 74572827 ::GetCommand:item -> len:9984 > ItemCmd: Overread buffer: 10000 > 9984 > > _______________________________________________ > 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 Sun Feb 18 16:50:42 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:01 2005 Subject: [CF-Devel] The truth about ISO gfx - or why you all are wrong In-Reply-To: Message-ID: > Diablo and Age of Empire use both rectangle gfx turned for 90?. > This is only a way to attach in a easy way the tiles - i will show you > later why we don't need it. > Puh, of course its 45 deegree and not 90 deegree. From peterm at tesla.EECS.Berkeley.EDU Sun Feb 18 23:24:11 2001 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:01 2005 Subject: [CF-Devel] Thoughts on partial protections Message-ID: <200102190524.VAA28176@tesla.EECS.Berkeley.EDU> In general, I think the partial protection code which Mark has done has been very beneficial. 1) I use protection spells now. I never used them before. 2) Monsters can have (and have been given) greater protection vs. area effect spells instead of either useless 50% protection or total immunity. 3) Items are ever so much more interesting to mix-and-match for the desired protections profile. I can't think of any downside to the partial protections. PeterM From dnh at hawthorn.csse.monash.edu.au Mon Feb 19 01:19:05 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:01 2005 Subject: [CF-Devel] Thoughts on partial protections In-Reply-To: <200102190524.VAA28176@tesla.EECS.Berkeley.EDU> Message-ID: On Sun, 18 Feb 2001, Peter Mardahl wrote: > > In general, I think the partial protection code which Mark has done > has been very beneficial. i completely agree. > 1) I use protection spells now. I never used them before. Very very useful, as are holy possession and scrolls of protection. > 2) Monsters can have (and have been given) greater protection vs. > area effect spells instead of either useless 50% protection or > total immunity. Yup, I have noticed much balancing in regards to multitile monsters are large area spells. I think perhaps someone should revise the cyclops and its resistance to holy power/god power, mostrai carves them up. > 3) Items are ever so much more interesting to mix-and-match for > the desired protections profile. Indeed, I tend to carry 2 copies of each of the elemental rings (ice, fire, storm) plus various swords and shields =). I think it has added a whole new flavour that is both challenging and exciting. Of course I have noted it has become slightly easy in general as you can alot more prepareing before hand with spells and armour and not have to worry so much about potions running out.. (which was instant death). > I can't think of any downside to the partial protections. Slightly easier in some cases.. demons fall like flies I just wield a demon slayer two rings of fire and starting running down greater demons... dnh > PeterM From mwedel at scruz.net Mon Feb 19 01:39:01 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:02 2005 Subject: [CF-Devel] [Fwd: Crossfire bugs and suggestions] Message-ID: <3A90CD95.1CF17A3D@scruz.net> Forwarding along this message sent only to me. please update the reply line as necessary. -------------- next part -------------- An embedded message was scrubbed... From: "Christian Wolfgang Hujer" Subject: Crossfire bugs and suggestions Date: Mon, 19 Feb 2001 00:47:42 +0100 Size: 10802 Url: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010218/47c9e1a1/attachment.mht From pjka at cc.jyu.fi Mon Feb 19 03:07:14 2001 From: pjka at cc.jyu.fi (Pertti Karppinen (OH6KTR)) Date: Thu Jan 13 18:00:02 2005 Subject: [CF-Devel] Thoughts on partial protections In-Reply-To: <200102190524.VAA28176@tesla.EECS.Berkeley.EDU>; from peterm@tesla.EECS.Berkeley.EDU on Sun, Feb 18, 2001 at 09:24:11PM -0800 References: <200102190524.VAA28176@tesla.EECS.Berkeley.EDU> Message-ID: <20010219110714.A1824@tukki.jyu.fi> On Sun, Feb 18, 2001 at 09:24:11PM -0800, Peter Mardahl wrote: > > In general, I think the partial protection code which Mark has done > has been very beneficial. > > 1) I use protection spells now. I never used them before. > 2) Monsters can have (and have been given) greater protection vs. > area effect spells instead of either useless 50% protection or > total immunity. > 3) Items are ever so much more interesting to mix-and-match for > the desired protections profile. > > I can't think of any downside to the partial protections. I can. With about 100 HP, I quaf down a potion of both cold and fire resistance, after making earth walls around me but one direction, pull the lever and have just enough time to cast word of recall to get out a live from /pup_land/kurte/eureca_road1. 20 chinese dragon vs. 90% cold resistance is worth shit. And as people in their great wisdom made spells non cumulative, You cannot boost Your hp's with con spells. And potions are so rare, it takes ages to get You con up to it's max. -- BSc. Pertti Karppinen |'Bridge Players | Systems Designer, University of Jyvaskyla, Finland | Do | http://www.iki.fi/~pjka/ | Office : +358 14 260 2088 | It | HAM: OH6KTR QTH: KP22UF | Cellular: +358 40 564 0786 | on the Table' | From pjka at cc.jyu.fi Mon Feb 19 03:31:26 2001 From: pjka at cc.jyu.fi (Pertti Karppinen (OH6KTR)) Date: Thu Jan 13 18:00:02 2005 Subject: [CF-Devel] Why do people hate wizards? Message-ID: <20010219113126.B1824@tukki.jyu.fi> I was just wondering, why do people hate wizards so much, that it has been unplayable? (Waiting for the cries and flames to calm down.) Yes unplayable. Most of You know what the 'ultimate' wizard stuff is: Wizard's hat, midnight robe and Staff of magi. Now to get those items, one has to kill, (from the end outwards): 2 Jessy's (Oppie&Fonz): 10000HP only, immune: physical, fire, cold, confusion, acid, drain, ghosthit, poison, slow, paralyze and turn_undead. 90% prot magic, vulnerable electricity and fear. 4 demon lords: 5000 hp only, immune fire and fear, 90% resistance godpower and holyword, 95% cold, 80% magic. 4 Dragon lords: one 5000 hp only, rest 3500 hp only, immune: fire, electricity, cold, acid, drain, poison, slow, paralyze and fear, 30% resistance physical and confusion. 8 demilich and a lich. 10 electric, 10 red and 10 chinise dragons. A wizard that can do all those kills, needs those items as much as a fish needs a bicycle. I mean, I have 18million points lvl 28(?), I have str 12. With str spell I can get a whooping str 17. I have yet to find my first str potion. Back, when wizards were still playable, one could, with enough spellpoints, get str near 30 and with immunity potions one could kill those jessys and dragonmen with a big weapon. Now this is no longer possible. Well ,perhaps I have played this game enough allready, perhaps it's time to find some other game, that let's me play wizard again. Angband/tk looks quite good actually. -- BSc. Pertti Karppinen |'Bridge Players | Systems Designer, University of Jyvaskyla, Finland | Do | http://www.iki.fi/~pjka/ | Office : +358 14 260 2088 | It | HAM: OH6KTR QTH: KP22UF | Cellular: +358 40 564 0786 | on the Table' | From mwedel at scruz.net Mon Feb 19 03:58:56 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:02 2005 Subject: [CF-Devel] [Fwd: Crossfire bugs and suggestions] References: <3A90CD95.1CF17A3D@scruz.net> Message-ID: <3A90EE60.B373B5CA@scruz.net> Mark Wedel wrote: > 1. Server crash on map reset > Sometimes the server crashes when actively resetting the map as dungeon > master. I could not find out, under what circumstances this happens. I > always tried with a newly instanciated server, and sometimes it crashes, > sometimes it doesn't. > It crashes with SIGSEGV (although I'm not a Linux/C/Intel-Crack, I think > this is a segmentation fault resulting from a pointer error). This is not very high on my priority list. One thing which may be a contributing factor is if a player is on the map you are resetting? The code to deal with that is highly suspect from my quick look over. > > 2. Client crash on 2nd window resize or on window unhide > When I resize the client window, it crashes very often (about 95% of resize > tries). > It also crashes when I first put another window in front of the client and > after that the client window back to front (or the other window to the > back). > Again it's a SIGSEGV. Another person has reported this, yet it works OK on my system. So there is something out there, and I think te other user was also using Suse. So it might be a bug there, or it could be with options the client is run with - don't know. > > 3. Bug in permanent death code? > I once compiled the server (the previous version) with permanent death code. > When a character died and was reincarnated again, he lost all his skills. He > even cannot search for traps or fight. > I think this is the result of randomly looting items without checking wether > the items are skills or spells. > Is this a bug or a feature? I would call that a bug. I don't play with permadeath, but I did notice that object looting could remove invisible objects, which is probably wrong - I've put a check in so that invisible objects will not be removed from the players inventory. > > 4. Map /city/misc/HallOfQuests > I achieved the highest rank, I think it is prince of scorn. After that I > could start all the quests from the beginning again. Is this meant to be? Actually, you can restart the quest from the beginning at any time. At best, this is a minor bug, as in most cases, the objects probably have limited in multiple instances (ie, 3 dragonshields doesn't do you much good unless you give the extras to friends) > > 5. I think, some NPCs should currently not be oratable. > I orated the king of scorn and he followed me, of course he died... :( Probably so. This is actually easy to fix - looking at the code, any creature with a message is non oratable. > > 6. Crossedit crashes when closing info window > This bug is not so important to me since I don't use crossedit to create > maps, I write my own perl scripts or Java programs to do that. (I will > release them as soon as they are okay to be used by others. If you want to > have a look at them, just drop me a line.) Any map tools you contribute to the probject would be useful. Fact is, crossedit is not all the heavily maintained - I don't think many of the current developers know it that well, and most new developers probably don't have the Xt toolkit high on their list of things to learn. > > Suggestions > > 1. Race amulets and rings > amulets and rings should be a race. Pouch should be a container for rings > and amulets. The race gold and jewels should go in a container called purse. > This can be done very quick: > 1st add "race amulets and rings" to all rings and amulets in > share/archetypes. > 2nd copy the pouch archetype to pouch2 > 3rd give pouch the name purse > If you want to, I can send you modified archetypes and treasure files for > this. This falls into one of those things that it would be convenient for it to be done, but should it really be the servers responsibility. My personal thought is that races for containers should only be used to restrict what can be placed into that container. That is only really needed in the sense of the container shape or volume may be odd sized (Realistically, there is no reason you could not fill your quiver with coins or put rings on your keyring). So in reality, the client should deal with the sorting of objects into different containers (hopefully made easily selectable by a nice selection tool). So you could say that food type items should go into the luggage, and your gems into large pouch, with your coins in the small pouch, etc. And really, from a protocol standpoing, this should be easy to do - the client can tell the server to move items. Now to facilitate this, we probably want to make moving items from inventory to storage containers and vice versa free actions. The way this would basically work would be character picks up item (either manually or via the automatical pick up modes). Client sees new item for inventory, and sees if it matches against any container sort roles the player sets up. IF not, it does nothing further. IF so, it sends a message to the server to put it into container X. The only reason the server needs to know is because many containers reduce the weight. Realistically, a client could make any number of number of virtual containers, which are really just convenient ways for the player to arrange their inventory. > 3. In client > a) A command history similar to a shell. Not sure I would want to go to that effort, but a 'repeat last command' would be easy enough to do - potentially useful I suppose for a spell casting that failed, but something you don't cast often enough such that you bind it to a key. > b) A window history with a scroll bar for the text window Look at the man page. The -scrollines does what you want unless you are describing something different. > > 4. NoWeapon-fields > I prefer to play a sorcerer (wizard before class code). > No spells is really unfair. A barbarian can run and slash and hack > everywhere. And it is quite easy to get a strength of 30 for a barbarian. > But a sorcerer might have a strength of 15 or 18. So what about > NoWeapon-fields where one must rely on magic or prayers? My personal thought is that unholy ground and non magical areas are used too often to try and make things tougher. I really don't like that. IF you don't want players to use magic on the monster, easy enough to give it resist_magic 100. Now there are cases where those fields are needed (such to protect treasure rooms). But really, I would rather see less use of such spaces to make things difficult. Also, as a note, spell casters can always resort back to brute force without a tremendous amount of difficulty (put on that armor, use that weapon, and adjust some other items, and away you go). The reverse is less true - a fighter who does not have spells to cast really doesn't have anything else to resort to. And from discussions, it generally seems that fighters are already the less powerful classes anyway,so I don't see a big reason to make them even less powerful. > > 5. Partial "No" fields > NoSpells and Unholy ground should not be absolute. For a level 107 sorcerer > it should be possible to cast spells on several nospells areas. For a level > 107 priest it should be possible to use prayers on several unholy grounds. > So what about a "Partial no code"? Nospells ground might influence the > amount of spellpoints required for casting. And it might require a certain > level for casting. See comment above about use of these fields. But also, just how the server deals with these fields means it isn't an easy fix to do this (ie, adding some level field to those objects) - casting prohibition is stored in bitmask of flags on a per space basis on the map, so to go to the above, you would now need to find (or store) the power of resistance, and update all the code that currently checks for prohibition to the new system. > > 6. New spellpoint calculation > A power 30 level 5 sorcerer has already something between 150 and 250 > spellpoints. > A power 30 level 107 sorcerer has just >750 spellpoints. > I think the relation is wrong. > Same applies to grace. First, a character at level 5 to get 30 pow is pretty unusual. I think realistically through normal play, the amount of grace/sp/hp per level would probably follow a reasonable line. A level 1 player with 30 grace and 30 wis would look even more out of wack. I won't explain the formula here, but I haven't seen any real problems with this. But for sp/hp/grace, the stat bonus at low levels is really important, and at higher levels, doesn't really make much difference. So the real key is to get the high stats right away. > > 7. Spells should cost less > Although a sorcerer has many possibilities, it is not just harder, but much > much harder, to play a sorcerer than a fighter. > I think the game is a bit unbalanced regarding this. A fighter needs a break > for hp regeneration only. Mages and priests also need to regenerate sp / > grace. See note above about spell casters tending to be considered the more powerful classes. Priests can regenerate grace very quickly by praying. I'm not sure if meditation is generally available, but I believe it gives a similar effect for sp. > > 8. Protection and immunity spells > I think there should not just be prayers, but also spells to protect (not > just armour). Perhaps they should be a bit more "expensive" than the > corresponding prayers. Matter of balance. If the useful priests spells are also available for mages, it diminishes the usefulness of the priest. You can always pick up the scrolls to give you the protections. > 10. Special alchemy spell > I think the alchemist should not only have the skill, but also the spell > alchemy as a starting equipment. It should be a special form of the alchemy > spell which is castable from level 1, not 3. Realistically, getting level 3 is 15 minutes of work. But more relevant, is a first level alchemist likely to have either the ingrediants or recipes to do anything useful? My guess is no unless the character has been created for use by an experienced adventuring party because no one there wants to alchemy anything. > > 11. Rethink "Denied"-Code > When casting a denied spell, the spell has no effect (ok) but still costs > its spellpoints. Is this meant to be? > Perhaps this code should be changed to a "partial attuned/denied"-code. It should just prevent you from casting the spell. But looking at the code, I notice that it will cost a random amount of sp (1 to full cost). I have no idea what it should do that - if you can't cast it, you can't cast it, and I agree that it shouldn't cost you anything. > > 12. Special kind of spellbook > What about a new kind of spellbook, that doesn't vanish when learning a new > spell? It could be much much more expensive... Usefulness of this is for a party to share or to keep retrying if you have a low chance to memorize? Reasonable idea I suppose. Just curious as to what purpose this is there for. > > 13. Change comment on "heavy rod of restoration" from the HouseOfHealing > In some document it is said that noone can afford to buy a "heavy rod of > restoration". This is untrue: Kill dragons regularly, collect *all* uncursed > items, if you cannot carry them, alchemy them to gold, then buy diamonds, > saphires... of flawless beauty and collect them. It is possible to buy a > heavy rod of restoration. And high level characters anyway don't know what > to do with their treasure. I think in two weeks I can afford mine. I think someone removed that recently. > > 14. More quests on spells > Perhaps also some lower spells should be only available by solving quests? > My candidates for this are: > - alchemy (simple shop quest only, no need to kill something, perhaps > retreive it from Leonardo Da Vinci...) > - destruction > - restoration There's pluses and minuses to this. On the plus side, you can restrict access to certain spells - or at least means you can't get it on the shop. On the downside, going through some dungeon for the 5'th time (player wise) to get the useful spell can prove annoying. This may not be so bad if the spellbook is available in multiple dungeons, so at least the player can get some variety. > > 15. It is possible to "create" money > Take some silver, cast alchemy on it, and the gold will be worth more than > the silver coins. > I know cheating with this is impossible because there is a chance that > alchemy will fail and destroy the silver... Looking at the code, it would appear that if it works on silver, it should also work with gold, platinum, and gems. I'll have to look at that further. > > 16. Alchemy > I think the result of invoking alchemy should be independent of wether the > item(s) is/are identified or not. agree. > > 17. Alchemy (again) > It should be possible to create rings and better potions using alchemy and > the appropriate ingredients. > 3 potions of strength, a ring of adornment, 10 large gold nuggets and 2 > ogre's arms might create a ring (Str+1). > For a ring (Str+2) the square amount of items should be required: > 9 potions of strength, a ring (Str+1), 100 large gold nuggets and 4 ogre's > arms might create a ring (Str+1). > For a ring (Str+3) the square amount of items again should be required: > 81 potions of strength, a ring (Str+2), 10000 large gold nuggets and 16 > ogre's arms might create a ring (Str+1). > Perhaps a new spell would be required for this. > Or the improvement scrolls. > And diamonds of flawless beauty. > The value of the item resulting from alchemy should be more valuable than > the sum of it's ingredients' values, otherwise this would not be logical. > There also should be the possibility for players to create artifacts > themselves. > I cannot see a reason why a level 100 character should not be able to create > artifacts when collecting the neccessary amount of special items. Adding recipes can be done. Allowing characters to create artifacts is still probably a bad idea. Note that crossfire is not a human adjudicated game. While a GM would not have a problem with high level characters creating all sorts of stuff, its quite a bit different because teh GM can control many aspects (for example, make sure that some ingrediants are in very limited supply or virtually impossible to get, and if the party wants even more, that becomes harder.) It doesn't really work that way in crossfire. If a player can do a map and get 1 of item X, he can do it again later and get another, and another, and so on. So given that, could then realistically create as many objects as he may want. I don't think thats a good idea in general. > > 18. Alchemy (again) > It should be possible to create ... "of Holding" for a player himself. > Ogre arms or potions of strength could be required. > "of Holding" items then should be more seldom and valuable, since a potion > of strength is quite expensive... See above. > > 19. Players / Characters > It is possible for a player, not to choose a class. It is a very poor > starting character, then, but I like the idea. The hall of selection map will have a way for someone not to choose a class (this was mostly added to prevent players who accidentally get warped back there from having 2 classes). Realistically, tuning classes that players take at the start is very difficult. Trying to balance not having a class (which basically means no skills, so you can't do anything), and adjusting the balance on that, and the balance of abandoning one class and picking up another, and so on, would be a real nightmare. Really, all classes get you as I recall is starting equipment, your skills, and some minor adjustment to stats. I can't remember if there are any private skills (ie, you need to be that class to have it) or not. If not, then you can basically be any class you want to be simply by learning the right skills and wearing the right equipment. As for changing faces - that could be added. Problem is that a list of legitimate faces would be needed - ie, youcan't change yourselfto look like a sword, but could choose to look like a woman for example. Easiest way to do this would probably be something similar to the hall of selection but for faces only - ie, a dressing room/house, which has spaces that change the appearance. > 20. Unique artifacts > What about artifacts that are really unique? Which only one character could > have? This gets discussed periodically, and the old discussions are probably still on the archive. The basic answer is 'no. Reasons are: 1) non trivial to deal with the object (or player possesing it) getting destroyed. 2) What to do if other players want it (ie, do they have to kill the person that owns it? Suppose the two players are in physically opposite sides of the world, so are seldom on line at the same time, and even if they are, they still need to meet) 3) If used as the reward of the quest, could get very frustrated players who solve the quest only to find out the reward isn't there. That may be realistic, but crossfire is not about realism. From tanner at real-time.com Mon Feb 19 12:15:06 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:00:02 2005 Subject: [CF-Devel] Boltzmann CVS access ? Message-ID: <20010219121506.A4072@real-time.com> I have been unable to update or commit to boltzmann for the last 4 days. I can ping and traceroute to the machine just fine. Our network utilization is high, but I do not think that should effect cvs. Any problems on boltzmann? -- 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 tesla.EECS.Berkeley.EDU Mon Feb 19 13:49:35 2001 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:02 2005 Subject: [CF-Devel] Why do people hate wizards? In-Reply-To: Your message of "Mon, 19 Feb 2001 11:31:26 +0200." <20010219113126.B1824@tukki.jyu.fi> Message-ID: <200102191949.LAA28599@tesla.EECS.Berkeley.EDU> > 2 Jessy's (Oppie&Fonz): 10000HP only, immune: physical, fire, cold, > confusion, acid, drain, ghosthit, poison, slow, paralyze and turn_undead. > 90% prot magic, vulnerable electricity and fear. Ball lightning OR Divine shock OR Directors and comet OR Directors and cause wounds. Create earth wall with the directors. > 4 demon lords: 5000 hp only, immune fire and fear, 90% resistance godpower > and holyword, 95% cold, 80% magic. Ball lightning OR Divine shock OR Directors and comet. Also, required is a potion of fire resistance and healing. > 4 Dragon lords: one 5000 hp only, rest 3500 hp only, immune: fire, > electricity, cold, acid, drain, poison, slow, paralyze and fear, > 30% resistance physical and confusion. Divine shock OR Directors and comet OR Directors and cause wounds. Create earth wall. > 8 demilich and a lich. Directors and holy orb OR potion of cold resistance and holy word for a frontal assault. And it's a super-lich not just a lich. > 10 electric, 10 red and 10 chinise dragons. for the 10 chinese: potion of cold resistance. Burning hands. They die FAST. For the 10 red: director and large snowstorm. create earth wall as a shield. For the 10 electric: simplest yet! Just fire large fireball at them from beyond the range of the lightning. > A wizard that can do all those kills, needs those items as much as a fish > needs a bicycle. I did all this at about magic level 20. I had a str of about 19, because I'd taken the time to look around in chests and random maps to find sufficient potions of str to max myself out. I was wearing a girdle of dam I'd got in the quests. I was wearing a Ring of Elrond I found in a shop and bought with my accumulated wealth. I also found an Amulet of Free Action while I was killing angels in the Temple of Darkness to get my power crystal. I did this on metalforge.real-time.com, using my gorokh-priest (who cannot cast healing spells). Now, what *I* am having trouble with is the FireTemple. The damned second-to-last greater demon wouldn't die to ANYTHING I did to it. :( In retrospect, I should have just sealed him off with earthwalls and bypassed him. > Back, when wizards were still playable, one could, with enough spellpoints, > get str near 30 and with immunity potions one could kill those jessys and > dragonmen with a big weapon. Now this is no longer possible. Well, I killed them. I just used divine shock instead. I could also have done it with build director, create earthwall, and spells like cause many wounds or comet or meteor storm. In fact, compared to the old way I used to play a wizard, the only changes are that I need to use the potions of cold resistance/fire resistance instead of just holy-wording the demon lords with my valriel-priest, and I have the new option of using Divine Shock. To me, what you say sounds like you really want to be playing your wizard like a fighter--when the going gets tough, whip out that sword. I say that when suitable preparations are made, you can solve that quest without resorting to the sword at all, as a wizard. I have done it. Recently. On metalforge. Furthermore, if you turn over enough rocks, you can find the potions you need. Also, the random fountains in the random maps sometimes give stat points. I'm afraid I must dismiss your claim that wizards are "unplayable." They are playable. I've solved that map. However, how hard are they compared to playing a fighter? It might be a good idea to turn down the magic resistance of various monsters a bit. Who has played BOTH a wizard-only player AND a fighter-only player? What say you? Are fighter-only players lots easier? I pretty much only use wizards, so I cannot compare. The last time I started a troll-barbarian, I quickly turned him into a semi-decent spellcaster. PeterM > Well ,perhaps I have played this game enough allready, perhaps it's time to > find some other game, that let's me play wizard again. > Angband/tk looks quite good actually. > -- > BSc. Pertti Karppinen |'Bridge Players | > Systems Designer, University of Jyvaskyla, Finland | Do | > http://www.iki.fi/~pjka/ | Office : +358 14 260 2088 | It | > HAM: OH6KTR QTH: KP22UF | Cellular: +358 40 564 0786 | on the Table' | > _______________________________________________ > 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 Feb 19 14:33:51 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:02 2005 Subject: [CF-Devel] [Fwd: Crossfire bugs and suggestions] References: <000401c09a6c$3ffc03c0$0b00a8c0@laptop3> Message-ID: <3A91832F.E82033B9@scruz.net> webmaster wrote: > Well, I don't think so, but everyone has his own point of view. And that's > the > general point of view, it's okay. > > My arguments: > If I'm a warrior and I kill a dragon, all items survive and I collect them. > Lot's of treasure. > If I'm a mage and I kill a dragon, often only very very few items survive. > I'd have to kill the dragon with missiles, bullets or destruction to get all > items. > If it is a group of mages, the picture changes, of course: Imagine 5-10 > mages invoking destruction like wild! The counter is that mages can kill from a distance, so in many cases it is much safer than the fighter (which you need to be right next to the monster). Whether or not either one is more powerful, I would really like to see the prohibition of spellcasting removed from quests except where it does protect treasure chambers or the like. IT should not be used to make things more difficult. > > By the way, I've seen there is a spell "regenerate spellpoints". Is it > possible to be learned (quest, praying or whatever), or is it only available > to the DM? (I don't want to hear the complete answer, just "already possible > in a quest" or "DM") I believe this is not generally available. IT wouldn't make a lot of sense would it - use some relatively small amount of sp to get many more back. Potions (at least code wise) are basically treated as spells contained in a bottle. The magic power potion basically uses that spell to do its job. > > I really agree to nospells being used to often. > Perhaps dimension door should be modified to be at higher level, cost more > sp and be a quest spell? > If I'm a mage at level 100, I don't see a reason why I should be unable to > dimension door through the border gate in publand. OTOH, if your level 100, chances are you might already have the information you need. I'm not sure how often dimension door is really used. (low level characters with 30 stats really high sp) > That's the typical "second character" of a bored level 110 player, who > equips his "child" with tons of artifacts and potions, including an amulet > of the Magi, two rings of Elrond, a Midnight robe, a wizard hat, a staff of > the Magi and a talisman of Wizardry... > > By the way: I like being attuned to Missiles as a low level mage: magic > missile and magic bullet cost no spellpoints ;) I'm not sure how much this is really a bug. A low level figter equipped with relevant artifacts probably would not have a damage rating much lower than that of the high level dude. The simple fact is, items and stats are very important to the power of the character. > > Matter of balance. If the useful priests spells are also > > available for mages, > > it diminishes the usefulness of the priest. You can always pick > > up the scrolls > > to give you the protections. > Perhaps it's just my style of play. You know what I do with scrolls? > I sell them! ;) > But, you're right, if I'm on a shopping trip, I'd perhaps better use my sp > inscribing some scrolls of destruction. > You need to cast a huge lot of destruction to kill red dragon... destruction is generally not an especially useful spell (IMO). If you want to kill that red dragon, ice storms or snowballs are much more effective. I don't know if there is anyone out there that uses destruction really often. > > > 12. Special kind of spellbook > > > What about a new kind of spellbook, that doesn't vanish when > > learning a new > > > spell? It could be much much more expensive... > > > > Usefulness of this is for a party to share or to keep retrying > > if you have a > > low chance to memorize? Reasonable idea I suppose. Just curious > > as to what > > purpose this is there for. > I did not think about "keeping trying" for low int characters. > A character trying to learn a spell from such a book and once failing > should only be able to retry if he either gains a mental level or more > intelligence. But I see, it is currently impossible to integrate such > a feature in crossfire. It is similar to the identification. If player X > identifies an item and drops it, and half an hour later player Y picks > it up, it's still identified... So what did you think of? a party sharing a spellbook? You are right - in fact, there is actually no tracking when a player learns a spell. At least with items, we can record that someone tried to id it. The problem more on items is that there are quite a few skills that can operate on items (magic, curse, id). Recording who did what could be pretty difficult. You could record the level of the last person to attempt to id it, and only if the new person is higher level coudl they attempt it. However, if you have several people in a party with id type skills, that then means you need to order it right (lowest level people try first). > > > 17. Alchemy (again) (able to make artifacts) > If for real artifacts enough rare items are required, this would be no > problem, I think, > but I agree, it is difficult to find a good balance. This really only works if the rare items are randomly generated treasure. At high levels, I would think most players would know where they can go to get the body parts they need. if you need to start with a long sword +4 for example, and you can't make it, that could make generation more difficult as those just don't pop up all over the place. But if it gets too hard, then no one will use it. Right now, I'm not sure how many people use alchemy. From tanner at real-time.com Mon Feb 19 14:49:13 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:00:02 2005 Subject: [CF-Devel] Stress(?) testing: 3 days 7 players approximately 20hrs each day Message-ID: <20010219144913.H15317@real-time.com> Background: Real Time takes crossfire to Con of the North (http://www.conofthenorth.org) each year. We do this because it's fun :-) and to expose crossfire to more people. Praise: This year as all years crossfire was a popular game. We ran 7 clients, approximately 20 hours a day over a 3 day period. The png maps where a big hit, although slower then the xbm. The hard core people still used the xbm for the speed. The gtk client was received with much praise. Especially the keybinding area and the curse/magical highlighting. We ran all linux, so the dxclient was not used, but many people expressed interest in it and took a flyer on where to download it. Problems: Stability. The server crashed very often. We are running 0.96.0, this was a big turn off for the players. Crashed whenever a new player would log in. Crashed whenever a new player would "Roll Again" more then 3 times. Crashed whenever you where in the Tower of Demonology and you get to those teleporters where 3 say "Down" to get out. 1 says you must say something. If you say down on the teleport it crashed. I saved 30+ core dumps when I'll investigate and see if I can solve them myself. Just a wrap up of the 0.96.0 release. Rick, any other places it always crashed? Those are all I have in my notes. -- 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 Feb 19 14:52:49 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:00:02 2005 Subject: [CF-Devel] More boltzmann.eecs.berkeley.edu problems Message-ID: <20010219145249.J15317@real-time.com> % cvs update -d -P Warning: the RSA host key for 'boltzmann.eecs.berkeley.edu' differs from the key for the IP address '169.229.34.28' tanner@boltzmann.eecs.berkeley.edu's password: Connection to boltzmann.eecs.berkeley.edu closed by remote host. cvs [update aborted]: received broken pipe signal -- 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 Mon Feb 19 15:47:49 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:02 2005 Subject: [CF-Devel] Why do people hate wizards? Message-ID: > However, how hard are they compared to playing a fighter? It might > be a good idea to turn down the magic resistance of various monsters > a bit. I agree the magic resistances in general should be turned down, now that wizards can't cast all the important phys stats up to 30 it has actually made them difficult. > Who has played BOTH a wizard-only player AND a fighter-only player? > What say you? Are fighter-only players lots easier? > I pretty much only use wizards, so I cannot compare. The last time > I started a troll-barbarian, I quickly turned him into a semi-decent > spellcaster. Warriors are easier, you can line up all the items of the right resistance and kill just about anything.. for Jessys you just get max of fire or ice then drink 90 of the other resistance potion. With a demon slayer demonlords, greater demons and jessys tend to fall like flies (I kill oppie or fonz in under a second). Warriors of course don't get the protection spells which makes life slightly harder, but you will tend to see warriors with a fair bit of magic and wisdom just to get those spells. There are quite alot of maps that get pretty close to undoable by wizards fire temple is a good example... greater demons take alot of pumping, infact I found the best thing to kill them with was bombs... =|. Warriors have been very much improved by PR, perhaps we should think alittle more about wizards (although in todays system, it doesn't really make alot of difference about whether your a wizard or a warrior.. only intial stats, items and skills.. most important part is race..). my 2 cents. dnh From dnh at hawthorn.csse.monash.edu.au Mon Feb 19 16:47:53 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:02 2005 Subject: [CF-Devel] Perm apartments in nurmburg + kurte Message-ID: Firstly it would appear that the perm apartments in nurmburg are currently broken, at least on MiDS server they are. Secondly, at the end of the room full of questions you get a scroll which doesn't seem to have any use at all, and it doesn't seem to explain what to do with it except burn it. Raistlin informs me you need to goto the apartment, is there someway AV you could make it alittle more clear.. currently it teleports you back to a pentagram at which you can't go to the north teleporter and the southern one just sends you back to the start of the eureca road. Either could you give me a hint, or change the maps please? =) dnh From mwedel at scruz.net Mon Feb 19 16:52:34 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:02 2005 Subject: [CF-Devel] Perm apartments in nurmburg + kurte References: Message-ID: <3A91A3B2.C05FDA05@scruz.net> dnh wrote: > > Firstly it would appear that the perm apartments in nurmburg are > currently broken, at least on MiDS server they are. I've fixed this, but have been unable to check it in due to CVS problems. From leaf at real-time.com Mon Feb 19 17:05:48 2001 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:00:02 2005 Subject: [CF-Devel] Warrior Proving Tower In-Reply-To: <000001c0974e$a0ddaf20$6796e23e@kyle> Message-ID: Fixed. It was a local problem only... On Thu, 15 Feb 2001, Andreas Vogl wrote: > Rick Tanner wrote: > > > With the latest CVS update I noticed that you can still enter > > the Warrior Proving Tower from it's old tower entrance in Scorn, > > but when you exit you end up in Dtabb. > > > > Looks like the Scorn map needs an update. > > I am absolutely 100% sure that I updated scorn map and removed > the exit path there. I even checked CVS right now: No mak-exit in scorn. > > So, I really have no idea why this happened to you. I guess > your map update was incomplete for some reason. > > > Andreas V. From leaf at real-time.com Mon Feb 19 17:22:45 2001 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:00:02 2005 Subject: [CF-Devel] Why do people hate wizards? In-Reply-To: <20010219113126.B1824@tukki.jyu.fi> Message-ID: On Mon, 19 Feb 2001, Pertti Karppinen (OH6KTR) wrote: > I was just wondering, why do people hate wizards so much, that it has been > unplayable? > (Waiting for the cries and flames to calm down.) > Yes unplayable. > Most of You know what the 'ultimate' wizard stuff is: Wizard's hat, midnight > robe and Staff of magi. On a somewhat related topic to this, I agree the 'ultimate' items for a wizard are the ones listed, plus a couple of other items.... ;) Perhaps new equipment to compliment the wizard class is required. Playing a warrior, you look around for some sort of armor that is +1, +2, +3, etc. and you replace what you have on only when you find something with a higher plus or better Armour value - until you get the dragon scales to make Dragon Armour. You run around with that until you get something like Power Dragon Mail or Mithril Armour (the +1str, +1con kind..) and then after that you try to obtain WDSM. However, as a wizard - what does that character have to choose from when they startat level 1 all the way until they are powerful enough to get the Midnight Robe, Wizard hat, etc.? Well, this is up for debate, but the point I am trying to make here is there isn't much for a wizard to choose from in the early and mid levels of the game. Sure, they have rings of magic and ancient magic, but what about 'armour'? There are gauntlets of Strength and gauntlets of Dexterity for the warrior classes, but what does a wizard have? There are no gloves or gaunlets (that I know of..) that improve spell casting or sp regeneration. Same goes for foot wear or belts. Anyone agree or disagree on this? Have their own thoughts to add? - Rick Tanner leaf@real-time.com From andi.vogl at gmx.net Mon Feb 19 20:59:26 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:03 2005 Subject: [CF-Devel] Perm apartments in nurmburg + kurte In-Reply-To: Message-ID: <000001c09ae9$2391f780$6b96e23e@kyle> > Firstly it would appear that the perm apartments in nurmburg are > currently broken, at least on MiDS server they are. I hope Mark will soon be able to check in the fix. I find it strange thet Mark has problems connecting to boltzmann, since I don't have any. > Secondly, at the end of the room full of questions you get a scroll which > doesn't seem to have any use at all, and it doesn't seem to explain what > to do with it except burn it. Raistlin informs me you need to goto the > apartment, is there someway AV you could make it alittle more clear.. > currently it teleports you back to a pentagram at which you can't go to > the north teleporter and the southern one just sends you back to the start > of the eureca road. > > Either could you give me a hint, or change the maps please? =) In this "pentagram room" in Kurte's place, there is one teleporter to the north and one to the south. When you walk on the northern one it it says: "This teleporter accepts only scolars of Kurte." So you go south instead and do all the stuff that leads you to the scroll. When you enter the last room it says "You have passed the test, you are now a scolar of Kurte" (-> you get a mark there). Then you get teleported back to the pentagram room, where you are now able to proceed through the north teleporter, finally meeting Kurte... Well, rule #1 when playing on pupland maps: You must always take some time to investigate. It's not a set of maps where you run through knocking down everything on sight. I spent quite a lot of work to make it all a bit more logic and fair. But when I put in large explanations for every step you have to take, the main purpose of the maps would fail. Andreas V. From andi.vogl at gmx.net Mon Feb 19 21:30:19 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:03 2005 Subject: [CF-Devel] [Fwd: Crossfire bugs ...] In-Reply-To: <3A90EE60.B373B5CA@scruz.net> Message-ID: <000101c09aed$74d7cbc0$6b96e23e@kyle> Mark Wedel wrote: > > 2. Client crash on 2nd window resize or on window unhide > > When I resize the client window, it crashes very often (about 95% of > > resize tries). > > It also crashes when I first put another window in front of the client and > > after that the client window back to front (or the other window to the > > back). > > Again it's a SIGSEGV. > > Another person has reported this, yet it works OK on my system. So there is > something out there, and I think te other user was also using Suse. So it > might be a bug there, or it could be with options the client is run with - > don't know. That other person was me. I strongly suspect the bug is OS-related. I had this bug on every version of SuSE linux I ever had installed on my local PC. I believe the worst part about this bug is the "bad impression" you get from the client. > > 6. Crossedit crashes when closing info window > > This bug is not so important to me since I don't use crossedit to create > > maps, I write my own perl scripts or Java programs to do that. (I will > > release them as soon as they are okay to be used by others. If you want to > > have a look at them, just drop me a line.) > > Any map tools you contribute to the probject would be useful. Fact is, > crossedit is not all the heavily maintained - I don't think many of the > current developers know it that well, and most new developers probably don't > have the Xt toolkit high on their list of things to learn. This bug is really bad and severe. It seems to be OS-related as well. I have checked this one with debugger and found out that the core dump happens in one of the Xaw graphic library routines (SuSE linux 7.0). Together with the broken pick-arch scrollbar in the main window, crossedit is currently in a state close to "unusable", for my system. And it's not like SuSE systems would be rare... =/ Best I could manage was disabling the buttons on the info windows. Once opened, I must leave them open till I quit CE. Sorry, I know it doesn't help much to complain - Just in hope that I might inspire somebody to write a new editor. =] Andreas V. From pjka at cc.jyu.fi Tue Feb 20 02:17:25 2001 From: pjka at cc.jyu.fi (Pertti Karppinen (OH6KTR)) Date: Thu Jan 13 18:00:03 2005 Subject: [CF-Devel] Why do people hate wizards? In-Reply-To: <200102191949.LAA28599@tesla.EECS.Berkeley.EDU>; from peterm@tesla.EECS.Berkeley.EDU on Mon, Feb 19, 2001 at 11:49:35AM -0800 References: <20010219113126.B1824@tukki.jyu.fi> <200102191949.LAA28599@tesla.EECS.Berkeley.EDU> Message-ID: <20010220101725.A17136@tukki.jyu.fi> On Mon, Feb 19, 2001 at 11:49:35AM -0800, Peter Mardahl wrote: > > 2 Jessy's (Oppie&Fonz): 10000HP only, immune: physical, fire, cold, > > confusion, acid, drain, ghosthit, poison, slow, paralyze and turn_undead. > > 90% prot magic, vulnerable electricity and fear. > > Ball lightning OR Divine shock OR Directors and comet OR Directors and > cause wounds. Create earth wall with the directors. Ok and Ball lightning is such an easy spell to get, you had it on You? > > I did this on metalforge.real-time.com, using my gorokh-priest > (who cannot cast healing spells). Divine Shock is what You used I bet. It is way too powerful spell, and not available for Mostrai's followers now is it? Try to kill those monsters with 20 level magic and power, let's say 28, and directors and comets. You need one BIG pile of magic power potions to do that. And Your directors probably would need to be renewed a couple of times. How about the Cyclops in the 2nd floor in the sister's maps. I bumbed it with lightning and I tried comets and I tried bombs. Nothing, nada, zip ... not a scratch. > Now, what *I* am having trouble with is the FireTemple. The > damned second-to-last greater demon wouldn't die to ANYTHING > I did to it. :( It isn't supposed to. > > Well, I killed them. I just used divine shock instead. I could OK. tryi it withou divine shock, and see how 'easy' it with directors and various wizard spells. Divine shock is god given spell, not available for other gods, or am I mistaken. > also have done it with build director, create earthwall, and spells > like cause many wounds or comet or meteor storm. Hah! "I also could fly, if I only had wings" > To me, what you say sounds like you really want to be playing your > wizard like a fighter--when the going gets tough, whip out that sword. > I say that when suitable preparations are made, > you can solve that quest without resorting to the sword at all, > as a wizard. I have done it. Recently. On metalforge. Yup with DIVINE SHOCK. Not as a normal wizard. > Furthermore, if you turn over enough rocks, you can find the potions > you need. Also, the random fountains in the random maps sometimes > give stat points. Yup, I've turned every rock in the game on our local server, been playing for about a month now, and I have yet to find one potion of strength. I haven't found even one spellbook of build director either, evevn after visiting THE book shop three times. > I'm afraid I must dismiss your claim that wizards are "unplayable." > They are playable. I've solved that map. Again with DIVINE SHOCK, which is way too powerful a spell to begin with. But I'm just a beginner wizard player, so I bow before gurus. > Who has played BOTH a wizard-only player AND a fighter-only player? > What say you? Are fighter-only players lots easier? > I pretty much only use wizards, so I cannot compare. The last time > I started a troll-barbarian, I quickly turned him into a semi-decent > spellcaster. See dnh's reply. -- BSc. Pertti Karppinen |'Bridge Players | Systems Designer, University of Jyvaskyla, Finland | Do | http://www.iki.fi/~pjka/ | Office : +358 14 260 2088 | It | HAM: OH6KTR QTH: KP22UF | Cellular: +358 40 564 0786 | on the Table' | From elsbernd at dfki.uni-kl.de Tue Feb 20 06:36:37 2001 From: elsbernd at dfki.uni-kl.de (Klaus Elsbernd) Date: Thu Jan 13 18:00:03 2005 Subject: [CF-Devel] Bug in install-script of crossclient Message-ID: <200102201240.f1KCeoH02454@gate-2000.kl.dfki.de> Hello I found a bug in the install-script utils/install-sh on Solaris 8 with version crossfire-client-0.96.0 make install calls utils//install-sh -c gcfclient cfclient cfsndserv /tools/games/bin wich only copies gcfclient to /tools/games/bin cfclient and cfsndserv won't be updated. here is a trace 0 root@gate-2000: sh -x utils//install-sh -c gcfclient cfclient cfsndserv /tools/games/bin doit= mvprog=mv cpprog=cp chmodprog=chmod chownprog=chown chgrpprog=chgrp stripprog=strip rmprog=rm mkdirprog=mkdir transformbasename= transform_arg= instcmd=mv chmodcmd=chmod 0755 chowncmd= chgrpcmd= stripcmd= rmcmd=rm -f mvcmd=mv src= dst= dir_arg= + [ x-c != x ] instcmd=cp + shift + continue + [ xgcfclient != x ] + [ x = x ] src=gcfclient + shift + continue + [ xcfclient != x ] + [ xgcfclient = x ] + : dst=cfclient + shift + continue + [ xcfsndserv != x ] + [ xgcfclient = x ] + : dst=cfsndserv + shift + continue + [ x/tools/games/bin != x ] + [ xgcfclient = x ] + : dst=/tools/games/bin + shift + continue + [ x != x ] + [ xgcfclient = x ] + true + [ x != x ] + [ -f gcfclient -o -d gcfclient ] + true + [ x/tools/games/bin = x ] + true + [ -d /tools/games/bin ] + basename gcfclient dst=/tools/games/bin/gcfclient + sed -e s,[^/]*$,,;s,/$,,;s,^$,., + echo /tools/games/bin/gcfclient dstdir=/tools/games/bin + [ ! -d /tools/games/bin ] + [ x != x ] + [ x = x ] + basename /tools/games/bin/gcfclient dstfile=gcfclient + [ xgcfclient = x ] + true dsttmp=/tools/games/bin/#inst.2409# + cp gcfclient /tools/games/bin/#inst.2409# + trap rm -f /tools/games/bin/#inst.2409# 0 + [ x != x ] + true + [ x != x ] + true + [ x != x ] + true + [ xchmod 0755 != x ] + chmod 0755 /tools/games/bin/#inst.2409# + rm -f -f /tools/games/bin/gcfclient + mv /tools/games/bin/#inst.2409# /tools/games/bin/gcfclient + exit 0 + rm -f /tools/games/bin/#inst.2409# The script seems to handle only one source-file. I would suggest to write a for-command in the makefile arround the files to be installed. 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 andi.vogl at gmx.net Tue Feb 20 07:09:01 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:03 2005 Subject: [CF-Devel] Perm apartments in nurmburg + kurte In-Reply-To: Message-ID: <000001c09b3e$4bc5b660$5115993e@kyle> > > [...] in Kurte's place, [...] When you enter the last room > > it says "You have passed the test, you are now a scolar of Kurte" > > (-> you get a mark there). > > a mark? What mark? a scroll? I picked up the scroll that explained > about 5 pentagrams. the actual map name was something like Eurecaroad3... > I went into the teleporter and then went to the north teleporter. it > then told me I had to be a scholar of kurte and yet I thought I > already was. A mark is what you get when moving onto a marker. It's like the knight/barone.. titles you get in scorn's hero quest. You should get the "scolar of kurte" mark when moving over the opened gate into the last room on Eurecaroad3, the room with scroll and teleporter. I checked it and figured out that there seemingly is a small possibility not to get marked when running too fast over the marker. This might have happened to you. I will increase the marker's speed, maybe insert a second (identical) marker beneath the scroll, just in case. And make the teleporter in that room only work when you already got the mark. Note that a player cannot get marked twice by the same mark (-> same slaying), so this should work fine. Andreas V. From dnh at hawthorn.csse.monash.edu.au Tue Feb 20 07:45:29 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:03 2005 Subject: [CF-Devel] End of Eureca road (Re:) Message-ID: Yes I just looked at the map via crossedit I believe I did run over that tile and only ran back to grab the scroll. Simply giving some instruction to stand in a place to recieve a blessing etc would prob be suffecient.. or placing the marker over the teleporter.. and making the teleporter only work after the marker has added scholar. dnh From peterm at tesla.EECS.Berkeley.EDU Tue Feb 20 15:47:44 2001 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:03 2005 Subject: [CF-Devel] CVS server fixed--BUT DO NOT COMMIT. Message-ID: <200102202147.NAA29738@tesla.EECS.Berkeley.EDU> Dear All, The CVS server is fixed. The problem was a loose ethernet cable, of all things. It took me about 1/2 hour in front of the machine to figure that out. however, WE ARE MOVING TO SOURCEFORGE. You may cvs update and cvs checkout, but NO cvs commits. Anything committed after Monday, 2/19/2001 will be DISCARDED. Reserve your new stuff for sourceforge. Please bear with me for a week or so while the repository gets moved. PeterM From andi.vogl at gmx.net Tue Feb 20 19:35:10 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:03 2005 Subject: [CF-Devel] bug in magic ear/npc conversation code Message-ID: <000001c09ba6$88f66760$f3a7e23e@kyle> When there is an "@match " in a magic ear/npc, the player must speak to trigger the magic ear, or get an answer from the npc. There is a bug: The last letter (/character) spoken does NOT get compared with the @match-string. Example: When a magic ear contains "@match yes", I already get a match for speaking "ye". For "@match no", speaking a single 'n' is already sufficient. E.g. when I say "certainly", I would get a match for "@match no", since there is an 'n' in "certaiNly". A match for single characters is impossible: "@match x" gets triggered by anything I say. Should be rather simple to fix *if* one is familiar with these parts of the code. Andreas V. From mwedel at scruz.net Tue Feb 20 22:56:00 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:03 2005 Subject: [CF-Devel] bug in magic ear/npc conversation code References: <000001c09ba6$88f66760$f3a7e23e@kyle> Message-ID: <3A934A60.1637B311@scruz.net> Andreas Vogl wrote: > > When there is an "@match " in a magic ear/npc, > the player must speak to trigger the magic ear, > or get an answer from the npc. > > There is a bug: The last letter (/character) spoken does > NOT get compared with the @match-string. > Example: When a magic ear contains "@match yes", I already > get a match for speaking "ye". > For "@match no", speaking a single 'n' is already sufficient. > E.g. when I say "certainly", I would get a match for "@match no", > since there is an 'n' in "certaiNly". > A match for single characters is impossible: "@match x" gets > triggered by anything I say. > > Should be rather simple to fix *if* one is familiar with these > parts of the code. The bug is actually in the regular expression code (re-cmp.c file). And in fact, its not that the last character is getting discarded - the current matching method seems to basically be if any letter if the what the player says matches against the first letter of, we get a match. So saying 'ah' matches against 'hi'. I've in fact tested that out. I've made a minor change, and it doesn't match quite so much. ITs still not 100% accurate - 'ye' will mach against "yes" for example, but just "y" or "e" will not. But the match of certainly against no should not happen, as it does have to match against the start of the line. I'm not sure how much time should be spent fixing it - we've discussed better npc communication many times. and I'm not really sure how much regex's are needed/used for the current conversation. I think post 1.0, we'll seriously look at what we want npc talk to be like. From mwedel at scruz.net Tue Feb 20 23:19:59 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:03 2005 Subject: [CF-Devel] Bug in install-script of crossclient References: <200102201240.f1KCeoH02454@gate-2000.kl.dfki.de> Message-ID: <3A934FFF.8820206E@scruz.net> I've updated the Makefile.in. I'll commit it after the move to sourceforge. Klaus Elsbernd wrote: > > Hello > I found a bug in the install-script > utils/install-sh > on Solaris 8 with version crossfire-client-0.96.0 > make install > calls > utils//install-sh -c gcfclient cfclient cfsndserv /tools/games/bin > wich only copies gcfclient to /tools/games/bin > cfclient and cfsndserv won't be updated. > > here is a trace > 0 root@gate-2000: sh -x utils//install-sh -c gcfclient cfclient cfsndserv > /tools/games/bin > doit= > mvprog=mv > cpprog=cp > chmodprog=chmod > chownprog=chown > chgrpprog=chgrp > stripprog=strip > rmprog=rm > mkdirprog=mkdir > transformbasename= > transform_arg= > instcmd=mv > chmodcmd=chmod 0755 > chowncmd= > chgrpcmd= > stripcmd= > rmcmd=rm -f > mvcmd=mv > src= > dst= > dir_arg= > + [ x-c != x ] > instcmd=cp > + shift > + continue > + [ xgcfclient != x ] > + [ x = x ] > src=gcfclient > + shift > + continue > + [ xcfclient != x ] > + [ xgcfclient = x ] > + : > dst=cfclient > + shift > + continue > + [ xcfsndserv != x ] > + [ xgcfclient = x ] > + : > dst=cfsndserv > + shift > + continue > + [ x/tools/games/bin != x ] > + [ xgcfclient = x ] > + : > dst=/tools/games/bin > + shift > + continue > + [ x != x ] > + [ xgcfclient = x ] > + true > + [ x != x ] > + [ -f gcfclient -o -d gcfclient ] > + true > + [ x/tools/games/bin = x ] > + true > + [ -d /tools/games/bin ] > + basename gcfclient > dst=/tools/games/bin/gcfclient > + sed -e s,[^/]*$,,;s,/$,,;s,^$,., > + echo /tools/games/bin/gcfclient > dstdir=/tools/games/bin > + [ ! -d /tools/games/bin ] > + [ x != x ] > + [ x = x ] > + basename /tools/games/bin/gcfclient > dstfile=gcfclient > + [ xgcfclient = x ] > + true > dsttmp=/tools/games/bin/#inst.2409# > + cp gcfclient /tools/games/bin/#inst.2409# > + trap rm -f /tools/games/bin/#inst.2409# 0 > + [ x != x ] > + true > + [ x != x ] > + true > + [ x != x ] > + true > + [ xchmod 0755 != x ] > + chmod 0755 /tools/games/bin/#inst.2409# > + rm -f -f /tools/games/bin/gcfclient > + mv /tools/games/bin/#inst.2409# /tools/games/bin/gcfclient > + exit 0 > + rm -f /tools/games/bin/#inst.2409# > > The script seems to handle only one source-file. I would suggest to > write a for-command in the makefile arround the files to be installed. > > 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 From mwedel at scruz.net Tue Feb 20 23:59:36 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:03 2005 Subject: [CF-Devel] Skill scrolls... AGAIN? References: Message-ID: <3A935948.6D38B98F@scruz.net> dnh wrote: > > I am not 100% but I am fairly sure alchemisty scrolls have vanished They are still in the treasure lists. I notice that skill scrolls don't show up very often, so it becomes pretty hard to know if one has disappeared. i've been keeping an eye out for skill scrolls, and I know I haven't seen some at all, despite looking a lot at the shops. The rarity of some items in shops is a problem (or maybe not depending on your point of view). What I can see happening is a mad rush to magic shops as they reset on active servers as player look for the specific items they want. The original reason I added the identification tables was before then the only way to identify stuff was via the spell (or scroll), and if playing with a few people, the shops would very quickly get cleared out of any id scrolls around because they were so useful. I think it would be much cooler to have guilds where you can learn the skills. Pass a test (if deemed necessary), pay some money, and get the skill. This can easily be done by the various invisible object inserters (or creator). The advantage of object inserters is the character does not then need to read the scroll. REally, that grunt fighter should really be able to learn punching without much difficulty, but with the current literacy methods, its actually pretty unlikely he'll learn it from a scroll. From mwedel at scruz.net Wed Feb 21 00:31:24 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:03 2005 Subject: [CF-Devel] (old) bugs References: <000101c09754$0caa2c60$6796e23e@kyle> Message-ID: <3A9360BC.7D990DEA@scruz.net> Andreas Vogl wrote: > > > o CF server (attack code): I've noticed that multisquare monsters > > > sometimes don't attack me with melee. They move next to me, cast > > > spells at me, but no melee attack. Any idea why this could happen? > > > > Where is the monsters logical head located relative to you (logical head > > always being the upper left corner of the monster). I wonder if perhaps > > the code is thinking that the monster is not directly adjacent (of which > > the head is not), even though it is due to the rest of its body. > > This bug doesn't seem to depend on my relative position to the monster's > head. I noticed it very clearly when testing "Lorkas", the multi-square > angel (and final boss) in Warrior Proving Tower. > Sometimes he attacked melee, sometimes not. But he always casted spells and > moved around. > I'd love to tell you a "reason" for this to happen, but I can't yet. I did notice some suspect code in the move monster area. The logic is basically: 1) Go through all the parts of the monster, seeing if it wants to use any of its range type attacks from that part. 2) find the part nearest the enemy, and apply the special movement rules. IF the monster does not have any special movement rules, it would use the direction value from the last part of the monster, which I would think should work, but result in some odd things. Think of this case: PMMM MMM MML P is the Player, M is the monster, with L being the last space processed. In this case, the monster may very well want to move northwest (which I'm not sure if it would attack the player or not). I did add a call in so that we calculate the direction from the closest monster part, and I think that should make it more intelligent. > > Sorry, you completely misunderstood my point (my fault). > I referred to the attack-movement here. Not "monster relative to walls", > but "monster relative to player". > > For example: When I set a certain attack_movement number (think that number > was 1), the monster tries to maintain a distance of two squares to the > player. > But the distance is counted only from the monster's head. Thus, when I > approach a 3x3 monster from above (north) - fine it will step away from me. > But when I approach it from below (south) - it doesn't step away because > head is in 3 squares distance north since monster *is* 3x3. Monster stands > close > to me, I can easily attack with melee, thus attack-movement algo has > completely > failed it's purpose. Yes - it was being calculated from the head, and not the nearest part. that was easy to change. I do notice that even with that change, once the player has closed to be right next to the monster, the monster will not move away at that point and instead attack. But if its a few spaces away, it will try to keep that distance. This is probably an intelligent approach - most players move faster than the monsters, so if the monster tried to move away, chances are the player would pound it while it does so. From bugs at real-time.com Wed Feb 21 17:08:17 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:00:03 2005 Subject: [CF-Devel] [Bug 334] Changed - Crossfire 95.8 doesn't redraw screens correctly from peripheral effects of field spells Message-ID: <200102212308.f1LN8HA31413@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=334 *** shadow/334 Mon Feb 12 02:11:53 2001 --- shadow/334.tmp.31409 Wed Feb 21 17:08:17 2001 *************** *** 1,19 **** ! Bug#: 334 ! Product: Crossfire ! Version: 0.95.6 ! Platform: SGI ! OS/Version: IRIX ! Status: NEW ! Resolution: ! Severity: normal ! Priority: P2 ! Component: GTK client ! AssignedTo: crossfire-devel@lists.real-time.com ! ReportedBy: karlg@chemwatch.net ! URL: ! Cc: ! Summary: Crossfire 95.8 doesn't redraw screens correctly from peripheral effects of field spells ! 95.8 with the current gtk client. When you cast burning-hands/confusion/ice-storm or similar spells, the landscape is frequently not being redrawn, leaving residual spell-shapes all over the place. --- 1,27 ---- ! +============================================================================+ ! | Crossfire 95.8 doesn't redraw screens correctly from peripheral effects of | ! +----------------------------------------------------------------------------+ ! | Bug #: 334 Product: Crossfire | ! | Status: RESOLVED Version: 0.95.6 | ! | Resolution: FIXED Platform: SGI | ! | Severity: normal OS/Version: IRIX | ! | Priority: P2 Component: GTK client | ! +----------------------------------------------------------------------------+ ! | Assigned To: crossfire-devel@lists.real-time.com | ! | Reported By: karlg@chemwatch.net | ! | CC list: Cc: | ! +----------------------------------------------------------------------------+ ! | URL: | ! +============================================================================+ ! | DESCRIPTION | 95.8 with the current gtk client. When you cast burning-hands/confusion/ice-storm or similar spells, the landscape is frequently not being redrawn, leaving residual spell-shapes all over the place. + + ------- Additional Comments From leaf@real-time.com 2001-02-21 17:08 ------- + + This is now fixed in cvs. + Mark Wedel + Wed, 31 Jan 2001 22:31:09 -0800 + + http://mailman.real-time.com/pipermail/crossfire-devel/2001-February/001143.html \ No newline at end of file From tanner at real-time.com Thu Feb 22 02:00:15 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:00:03 2005 Subject: [CF-Devel] Little confused on arch.c:first_arch_pass() Message-ID: <20010222020015.F9510@real-time.com> First, I'd like to make a suggestion. If a function has the side effect of loading/altering/etc a static data struct it should be documented in that function somewhere. I believe a case in point is arch.c:first_arch_pass(). The comments says: /* * Reads/parses the archetype-file, and copies into a linked list * of archetype-structures. */ Yet the prototype is void, so it looks like it must load the archtype linked list into a static variable somewhere. Once first_arch_pass() is called, what is the name of the linked list it creates? -- 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 Thu Feb 22 02:59:09 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:00:03 2005 Subject: [CF-Devel] Parsing archetype file Message-ID: <20010222025909.A20992@real-time.com> I just want to parse the archetype file and get the archetype array from it. I happily read the code and saw I could use the first_arch_pass function. But it looks like that the animation stuff needs to be loaded first. Does the bmaps need to be loaded before the aninmation stuff? I'd like to make a standalone util to be able to dump the archetypes in customized formats. Looking at the code, the approach to dumping archetype is tied to DM mode and keystrokes. Is this the easiest way for doing object dumps? Add a function called bobs_dump_arch() and do things that way? -- 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 Thu Feb 22 07:37:48 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:03 2005 Subject: [CF-Devel] New client feature Message-ID: Hi I add map masking to the dx client. It a client side only effect. http://mids.student.utwente.nl/~michtoen/cf_old.png and with masking http://mids.student.utwente.nl/~michtoen/cf_new.png Michael From leaf at real-time.com Thu Feb 22 12:20:37 2001 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:00:03 2005 Subject: [CF-Devel] Character Creation and Crossedit Bugs Message-ID: Please cc your reply to Lerman Benjamin ( quisar@quisar.ambre.net ) since he is not subscribed to the mailing list right now. Thanks. - Rick Tanner leaf@real-time.com ---------- Forwarded message ---------- Date: Thu, 22 Feb 2001 04:07:44 -0600 Name: Lerman Benjamin Email Address: quisar@quisar.ambre.net Comment or Suggestion: I experimented few problems with crossfire and crossedit First crossfire : The server does crashed from time to time when someone creates a new character : Here's what is on the output when crossfire is using -d option : Trying to load map /opt/local/crossfire-0.96.0/share/crossfire/maps/HallOfSelection. load_original_map: /HallOfSelection (0) enter_map: supplied coordinates are not within the map! (/HallOfSelection: -1, 5) SIGSEGV received. Emergency saves disabled, no save attempted Cleaning up... Saving map /HallOfSelection Player on map that is being saved Player on map that is being saved zsh: abort (core dumped) crossfire -d Now with crossedit : The way this program is handling paths is buggy. First you cannot go out of the ${PREFIX}/share/crossedit/maps/ hierarchie, which is absurd because I might want to create or edit a map that is not yet a standard one. Second, when I try to save a map, crossedit forgot the path and try to save it in the root of the filesystem (/name_of_the_map) which it can't (that's a chance...) I'm obliged to choose save as.. and type the all path if I don't want to loose everything I did. Thanks. PS: Sorry for my not so good english, I'm french. -- Benjamin `Quisar' Lerman From mwedel at scruz.net Thu Feb 22 22:00:34 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:04 2005 Subject: [CF-Devel] Little confused on arch.c:first_arch_pass() References: <20010222020015.F9510@real-time.com> Message-ID: <3A95E062.D553579@scruz.net> Bob Tanner wrote: > > First, I'd like to make a suggestion. If a function has the side effect of > loading/altering/etc a static data struct it should be documented in that > function somewhere. As I think about this quickly, its a reasonable idea, but lots of functions modify/change something that was not passed to them. But generally speaking, the comments with the source are not all that great. > > I believe a case in point is arch.c:first_arch_pass(). The comments says: > > /* > * Reads/parses the archetype-file, and copies into a linked list > * of archetype-structures. > */ > > Yet the prototype is void, so it looks like it must load the archtype linked > list into a static variable somewhere. > > Once first_arch_pass() is called, what is the name of the linked list it > creates? first_archetype From mwedel at scruz.net Thu Feb 22 22:06:54 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:04 2005 Subject: [CF-Devel] Parsing archetype file References: <20010222025909.A20992@real-time.com> Message-ID: <3A95E1DE.D5144437@scruz.net> Bob Tanner wrote: > > I just want to parse the archetype file and get the archetype array from it. I > happily read the code and saw I could use the first_arch_pass function. > > But it looks like that the animation stuff needs to be loaded first. Does the > bmaps need to be loaded before the aninmation stuff? There is a fairly specific order in which the things need to be loaded. > > I'd like to make a standalone util to be able to dump the archetypes in > customized formats. Looking at the code, the approach to dumping archetype is > tied to DM mode and keystrokes. Unfortunately, the library is not all that independent of the rest of the code, and there are some dependancies (depending on the needs, you could avoid this - if you wrote your own standalone utility, you could just have things like find_face or whatever just return some value, if you don't actually care about the faces) > > Is this the easiest way for doing object dumps? > > Add a function called bobs_dump_arch() and do things that way? Yeah - look at server/init.c and the dump_ functions there. Thats probably the easiest way to do it - add a new dump flag. Now it requires that the server be used to get that data, but that isn't a very big deal. From mwedel at scruz.net Thu Feb 22 23:21:31 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:04 2005 Subject: [CF-Devel] CVS repository moved. Message-ID: <3A95F35B.8FB8AE6@scruz.net> The cvs repository is now installed on sourceforge. If you do not have any changes in your checked out tree, the easiest thing to do is just do a new checkout. See http://sourceforge.net/cvs/?group_id=13833 for information on setup. If you want to reparent your tree, do the following: 1) Create a /tmp/Root file with the new repository information. The contents of mine looks like: :ext:mwedel@cvs.crossfire.sourceforge.net:/cvsroot/crossfire Everything but the login name (mwedel) should be the same for anyone else. 2) Update all the Root entries in your cvs tree. To do that, run find . -name Root -exec cp /tmp/Root {} \; This is best run from the the relevant directory (arch, crossfire, maps, client). IF you have all those and nothing checked out in a common directory, you could run it from there. 3) Update the repository information. Use the perl script I provide - its useage is update_rp - if run from the parent dir, it would be arch, crossfire, maps, client, as above. If withing the arch, ... dirs, then just use . if you have a CVSROOT environment variable set, also remember to update that. -------------- next part -------------- #!/usr/bin/perl use File::Find; find(\&wanted, "$ARGV[0]"); sub wanted { if ($_ eq "Repository") { $file=$_; open(IN,"<$file"); $contents = ; close(IN); $contents =~ s#/home/cvs/CVS/##; open(IN,">$file"); print IN $contents; close(IN); } } From mwedel at scruz.net Fri Feb 23 00:52:56 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:04 2005 Subject: [CF-Devel] checkins. Message-ID: <3A9608C8.3CB929F6@scruz.net> I've made checkins to both the client and server. The mail notification was not set up on the sourceforge cvs repository - I believe it should be now. I enclose a copy of the changes here to remind people to update. client: Makefile.in: Modify so that it installs the target (cfclient, gcfclient, cfsndserv) one at a time so it works with the install script. item.c: add insert_item_before_item function. Modify the sorting function so it first sorts by type, then by locked/unlocked status, and then by alphabetical order (not including the number prefix). item_types, item_types.h: More updates of missing objects or ones that need more specific matching rules. x11.c: Remove a lot of duplicate code that was in place for metaserver support - instead, just add checks to the existing X event handling code to know not to do some things if we're in metaserver selection mode. This fixes a bug in that resize events would not be handled if in metaserver selection mode. MSW 2001/02/22 server: MSW 2001/02/22: TODO: Add some items, remove some others, remove outline of future versions, since it was out of date. common/loader.l,loader.c: Declare msgbuf a static outside the lex_load function. lex_load was otherwise clearing it each time it was called, which resulted in empty messages for the random artifacts (since the call lex_load one line at a time). Instead, we just zero this at start of load_object. Original reason of this change was due to purify errors - as I look at the code, it appears even before these changes that it was clearing the buffer properly. common/map.c: removing pending field from map objects. common/re-cmp.c: Comment out some code which was resulting in too many false compares. include/config.h: increase default for MAX_OBJECTS. 6000 is a bit small on current systems. include/map.h: Remove pending field from map structure. random_maps/treasure.c: Increase size of doorlist. Fixes crash, in that if a random map could place 8 doors around the treasure, the list was not terminated, so the problem would eventually try to read/dereference random memory after the array. server/c_misc.c: Remove pending field from maps, so remove functions and other places that referred to it (like the maps command) server/c_wiz.c: fix up wiz map reset command. Not really tested, but old code had some definate problems just from visual inspection. server/main.c: Further fix for unique exits - relative paths to unique maps from non unique maps should now work. server/monster.c: Various fixes - one is that should get more reliable distance values for multipart monsters. Second, modify dist_att to calculate from closest part of monster, and not the head of the monster. server/pets.c: Remove code dealing with pending objects. server/player.c: Don't remove invisible objects in players inventory when playing with permadeath mode. server/spell_util.c: If you try to cast denied spell, it no longer costs any spellpoints. socket/item.c: Fix bug where it was using 'item' protocol command instead of 'item1' End of MSW 2001/02/22 checkin. From dnh at hawthorn.csse.monash.edu.au Fri Feb 23 01:51:47 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:04 2005 Subject: [CF-Devel] Character Creation and Crossedit Bugs In-Reply-To: Message-ID: > Name: > Lerman Benjamin > > Email Address: > quisar@quisar.ambre.net > > Comment or Suggestion: > I experimented few problems with crossfire and crossedit > > First crossfire : > > The server does crashed from time to time when someone creates a new character : Yes, this has been raised already. I am not sure if anyone is working on fixing it just yet. =( > Now with crossedit : > > The way this program is handling paths is buggy. First you cannot go out of the ${PREFIX}/share/crossedit/maps/ hierarchie, which is absurd because I might want to create or edit a map that is not yet a standard one. Yes I find this very annoying. Unfortunetly no one is currently working on crossedit. > Second, when I try to save a map, crossedit forgot the path and try to save it in the root of the filesystem (/name_of_the_map) which it can't (that's a chance...) I'm obliged to choose save as.. and type the all path if I don't want to loose everything I did. > > Thanks. > > PS: Sorry for my not so good english, I'm french. No Problem at all. dnh > -- > Benjamin `Quisar' Lerman > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From quisar at quisar.ambre.net Fri Feb 23 05:27:19 2001 From: quisar at quisar.ambre.net (Benjamin `Quisar' Lerman) Date: Thu Jan 13 18:00:04 2005 Subject: [CF-Devel] Character Creation and Crossedit Bugs In-Reply-To: ; from dnh@hawthorn.csse.monash.edu.au on Fri, Feb 23, 2001 at 06:51:47PM +1100 References: Message-ID: <20010223122719.A20509@hell.ambre.net> > > The server does crashed from time to time when someone creates a new character : > > Yes, this has been raised already. I am not sure if anyone is working on > fixing it just yet. =( I try to see what might be wrong. The big problems is that I didn't figure out how to make this thing predictable. I finally get a core file which was usable (after removing the catching of SIGSEV signals...) and I found that : hell:~ $ gdb ~quisar/download/crossfire/crossfire-test/server/crossfire core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-suse-linux"... Core was generated by `/home/quisar/download/crossfire/crossfire-test/server/crossfire -d'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libm.so.6...done. Reading symbols from /lib/libcrypt.so.1...done. Reading symbols from /lib/libnsl.so.1...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. Reading symbols from /lib/libnss_files.so.2...done. Reading symbols from /lib/libnss_dns.so.2...done. Reading symbols from /lib/libresolv.so.2...done. #0 0x80b6a6c in draw_client_map (pl=0x87c0b98) at request.c:896 896 esrv_map_setbelow(&pl->contr->socket,ax,ay, (gdb) backtrace #0 0x80b6a6c in draw_client_map (pl=0x87c0b98) at request.c:896 #1 0x80afc5d in draw (pl=0x87c0b98) at info.c:219 #2 0x80b3dfb in doeric_server () at loop.c:572 #3 0x8064103 in main (argc=2, argv=0xbffff634) at main.c:967 (gdb) print face $1 = (New_Face *) 0x3e8 (gdb) print face->number Cannot access memory at address 0x3e8. OOOps The value for face is wrong. 0x3e8 is way out of the addressing space of this program. face is taken from pl->map, but we can see a little up in the file : /* IF player is just joining the game, he isn't here yet, so the map * can get swapped out. If so, don't try to send them a map. All * will * be OK once they really log in. */ if (pl->map->in_memory!=MAP_IN_MEMORY) return; So maybe the initalisation of pl->map is incorrect or incomplete. So I add the patch : ------------------------------------------------------------------- --- ../crossfire-0.96.0/server/player.c Tue Feb 13 07:59:59 2001 +++ server/player.c Fri Feb 23 12:02:15 2001 @@ -666,7 +666,9 @@ /* So that enter_exit will put us at startx/starty */ op->x= -1; - +#if 1 + op->map->in_memory = ! MAP_IN_MEMORY; +#endif enter_exit(op,NULL); SET_ANIMATION(op, 2); /* So player faces south */ ------------------------------------------------------------------- and the server didn't crashed anymore since. The problem is that, because I don't know how to force the bug to show, I might be totally wrong. So if someone is more aware than me (it is not difficult...) how the initalisation of a new player is done and can confirm or deny that the probleme might be this one... -- Benjamin `Quisar' Lerman quisar@quisar.ambre.net http://www.ambre.net/quisar "Si les yeux pouvaient tuer et enfanter, les rues seraient pleines de cadavres et de femmes grosses." Valery From pjka at cc.jyu.fi Fri Feb 23 06:44:49 2001 From: pjka at cc.jyu.fi (Pertti Karppinen (OH6KTR)) Date: Thu Jan 13 18:00:04 2005 Subject: [CF-Devel] checkins. In-Reply-To: <3A9608C8.3CB929F6@scruz.net>; from mwedel@scruz.net on Thu, Feb 22, 2001 at 10:52:56PM -0800 References: <3A9608C8.3CB929F6@scruz.net> Message-ID: <20010223144449.B15683@tukki.jyu.fi> On Thu, Feb 22, 2001 at 10:52:56PM -0800, Mark Wedel wrote: > > I've made checkins to both the client and server. The mail notification was > not set up on the sourceforge cvs repository - I believe it should be now. I > enclose a copy of the changes here to remind people to update. The current server code in cvs is broken. When logging in everything works, till server tries to clear out a map from memory. Then it prints free_all_objects: Link error, bailing out. and dies shortly thereafter. -- BSc. Pertti Karppinen |'Bridge Players | Systems Designer, University of Jyvaskyla, Finland | Do | http://www.iki.fi/~pjka/ | Office : +358 14 260 2088 | It | HAM: OH6KTR QTH: KP22UF | Cellular: +358 40 564 0786 | on the Table' | From mwedel at scruz.net Fri Feb 23 21:26:15 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:04 2005 Subject: [CF-Devel] Character Creation and Crossedit Bugs References: Message-ID: <3A9729D7.15615688@scruz.net> dnh wrote: > > > > The way this program is handling paths is buggy. First you cannot go out of the ${PREFIX}/share/crossedit/maps/ hierarchie, which is absurd because I might want to create or edit a map that is not yet a standard one. > > Yes I find this very annoying. Unfortunetly no one is currently working on > crossedit. there is an easy fix for this - make a symlink from the map directories to wherever you want (/ for example), which will then allow crossedit to traverse the entire fs. From mwedel at scruz.net Fri Feb 23 23:48:11 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:04 2005 Subject: [CF-Devel] Crossfire debugging tips. Message-ID: <3A974B1B.ADA1E4FC@scruz.net> Give me access to a crossfire core file, and I'll investigate. Note that access typically means login to the system that the core was generated on. Given that, here are tips to make debugging for either myself or others more useful: 1) By default, configure/autoconf use -g -O2 as compiler flags if it finds gcc. the -O2 makes debugging more difficult, as variables can get optimized out, execution is not necessarily in the same order, and so on. To get around this, I set my environment flags to "-ggdb" before running configure. You can in fact add that to your .cshrc/.profile, but then all programs will get that. 2) Keep the core file with the tree that made it. If you have a core file from a few days ago and are about to do a cvs update and recompile, copy the current compilation and put the core file with that. Trying to debug programs in which the core file does not match the executable is virtually impossible. 3) Keep the log file that crossfire generates with the core file. The crossloop scripts already do this. Not always, but many times the log file may say why the program is exiting (this is typically if link lists are corrupted or it gets internally caugt errors, vs something like memory scrambling and bad pointer derefs). 4) Make sure you don't strip the binaries as you install them. By default, the installation does not do this, but you can just make sure that your executable (installdir/bin/crossfire) matches soucedir/server/crossfire). doing a size check is sufficient. 5) Send me a stack trace. To do this: gdb executable core_file (ie, gdb /usr/games/bin/crossfire core), and then from within gdb do a 'where'. If you don't have gdb, install it as one can't do debug work without it. Also include the version of crossfire (including latest cvs update). This information will at least let me quickly see where the crash happened, and will let me know if its a duplicate, and may even provide enough information to fix the problem. I really want to get all these bugs squashed. Note that I can not promise I will always look at all cores - if some really widespread bug comes out such that there are core files all over the place, I'll just look at a few and once I figure out the problem, go from there. From tanner at real-time.com Sat Feb 24 02:52:40 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:00:04 2005 Subject: [CF-Devel] SF CVS SUX Message-ID: <20010224025240.A20132@real-time.com> I have to say that cvs access to SF has just sucked the last 2 days. I get partial updates and the connection just drops. Commits sit for mintues before actually going through. Anyone else? -- 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 Sat Feb 24 03:03:12 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:00:04 2005 Subject: [CF-Devel] SF CVS SUX In-Reply-To: <20010224025240.A20132@real-time.com>; from tanner@real-time.com on Sat, Feb 24, 2001 at 02:52:40AM -0600 References: <20010224025240.A20132@real-time.com> Message-ID: <20010224030312.B20132@real-time.com> Quoting Bob Tanner (tanner@real-time.com): > I have to say that cvs access to SF has just sucked the last 2 days. I get > partial updates and the connection just drops. Commits sit for mintues before > actually going through. > > Anyone else? > Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE protocol error: invalid directory syntax in server/ cvs commit: saving log message in /tmp/cvsV6iDOd -- 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 Feb 24 05:17:28 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:04 2005 Subject: [CF-Devel] SF CVS SUX In-Reply-To: <20010224030312.B20132@real-time.com> Message-ID: <000001c09e53$614bb6c0$3921993e@kyle> Bob Tanner wrote: > Quoting Bob Tanner (tanner@real-time.com): > > I have to say that cvs access to SF has just sucked the last 2 days. > > I get partial updates and the connection just drops. Commits sit for > > mintues before actually going through. > > > > Anyone else? > > > > Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE > Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE > Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE > protocol error: invalid directory syntax in server/ > cvs commit: saving log message in /tmp/cvsV6iDOd I have done several commits/checkouts to SF yesterday and I didn't encounter any problems. Actually, I was surprised how good the connection was. I really am not an expert, but these protocol errors don't look like the "the connection just drops". More like there is a system/network related problem... Andreas V. From meeg at mamia.prninfo.com Sat Feb 24 04:39:21 2001 From: meeg at mamia.prninfo.com (Meegwun South) Date: Thu Jan 13 18:00:04 2005 Subject: [CF-Devel] Magic In-Reply-To: <200102240135.UAA26587@mamia.prninfo.com> from "Meegwun South" at Feb 23, 2001 08:35:48 PM Message-ID: <200102241039.FAA27541@mamia.prninfo.com> > > > > > Hello > > > Here's a little magic idea > > You can use any kind of ball > large fireball + the middle button on the large keypad = fireballs go into all directions kinda like burning hands.Here's another idea flame bomb it looks > like a fireborn it makes a larger fire than large fireball. > > Meegwun Southall > From joel at mamia.prninfo.com Sat Feb 24 04:40:23 2001 From: joel at mamia.prninfo.com (Joel South) Date: Thu Jan 13 18:00:04 2005 Subject: [CF-Devel] karate moves Message-ID: <200102241040.FAA27551@mamia.prninfo.com> Hello > > I know people haven't given karate moves many replies,but if anyone plans > on doing karate moves. I have an idea. > lunge punch+front kick+down block. The player would attack by > running into monsters,such as karate already works. By would use the moves > in succesion;punch,kick,block,punch,kick,block,ect. The player could change > the setting. > Then there would be the special moves. Example:Perform energy bolt. > These would work much like spells. But costing hp instead of mana.(Because > of the extreme physical and mental effort.) > > I hope someone gives the idea some thought. > > Bye (: > From mwedel at scruz.net Sun Feb 25 01:47:47 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:04 2005 Subject: [CF-Devel] SF CVS SUX References: <000001c09e53$614bb6c0$3921993e@kyle> Message-ID: <3A98B8A3.FD45DF7D@scruz.net> Andreas Vogl wrote: > > Bob Tanner wrote: > > > Quoting Bob Tanner (tanner@real-time.com): > > > I have to say that cvs access to SF has just sucked the last 2 days. > > > I get partial updates and the connection just drops. Commits sit for > > > mintues before actually going through. > > > > > > Anyone else? > > > > > > > Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE > > Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE > > Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE > > protocol error: invalid directory syntax in server/ > > cvs commit: saving log message in /tmp/cvsV6iDOd > > I have done several commits/checkouts to SF yesterday and I didn't encounter > any problems. Actually, I was surprised how good the connection was. I haven't had any problems either. OTOH, there could be issues of it being down/broken at certain times. It is pretty likely that the CVS on sourceforge will not be be as good as it was on boltzmann - thats simply due to the dedication of Peter, and the fact that I believe that machine wasn't being used for a lot else, where as the sourceforge machine is being used by many projects. It'll probably take some time to tell if moving to sourceforge was a good idea (it had to move someplace, but not necessarily sourceforge). From mwedel at scruz.net Sun Feb 25 23:12:38 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:04 2005 Subject: [CF-Devel] sourceforge anonymous checkout now working. Message-ID: <3A99E5C6.15341E22@scruz.net> They actually do have people working on the weekends. Thats nice. In short summary: You can not check out via cvs without having a developer account. See the directions at http://sourceforge.net/cvs/?group_id=13833. Note that is read only access. If you want to check in changes, you will still need a developer account. From mwedel at scruz.net Mon Feb 26 01:19:09 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:04 2005 Subject: [CF-Devel] checkins. References: <3A9608C8.3CB929F6@scruz.net> <20010223144449.B15683@tukki.jyu.fi> Message-ID: <3A9A036D.A2FD1DB7@scruz.net> I've just checked in some changes which I believe fix this. At least the previous crashes (which I was able to reproduce) no longer happen. "Pertti Karppinen (OH6KTR)" wrote: > > On Thu, Feb 22, 2001 at 10:52:56PM -0800, Mark Wedel wrote: > > > > I've made checkins to both the client and server. The mail notification was > > not set up on the sourceforge cvs repository - I believe it should be now. I > > enclose a copy of the changes here to remind people to update. > > The current server code in cvs is broken. > When logging in everything works, till server tries to clear out a map from > memory. Then it prints > free_all_objects: Link error, bailing out. > and dies shortly thereafter. > -- > BSc. Pertti Karppinen |'Bridge Players | > Systems Designer, University of Jyvaskyla, Finland | Do | > http://www.iki.fi/~pjka/ | Office : +358 14 260 2088 | It | > HAM: OH6KTR QTH: KP22UF | Cellular: +358 40 564 0786 | on the Table' | > _______________________________________________ > 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 Mon Feb 26 10:01:59 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:04 2005 Subject: [CF-Devel] current server-code is still totally broken! In-Reply-To: <3A9A036D.A2FD1DB7@scruz.net> Message-ID: <000001c0a00d$77da7b40$11a5e23e@kyle> Mark W. wrote: > I've just checked in some changes which I believe fix this. > At least the previous crashes (which I was able to reproduce) > no longer happen. Well, the server doesn't crash, but about 20 seconds after I log on with a player, my connection is killed. This happens *always*, so I actually wonder how Mark could "overlook" it? =) (Of course this happened with the server from latest CVS). The problem happens on the "/HallOfSelection" map. When a player logs on to the server, a player object is created on that map, for some weird reason (I suspect this is a kinda copy of my own player). I can even see that "ghost player" standing on the pentagram while typing in my user password! (I am NOT creating a new character, and I play local - alone!). Well, the game works fine but only till the moment where it tries to save (and swap out) the HallOfSelection. In that second, the server realizes that some mess is going on and kills all objects that he doesn't like. My real player-object gets removed in this proccess, thus brutely killing my connection. Here is my server log: [...] LOGIN: Player named red_blaze from ip 127.0.0.1 Saving map /HallOfSelection Player on map that is being saved Player on map that is being saved Object squizez another object: arch warrior name red_blaze race human slaying demon face warrior.151 animation warrior [... ...] end arch flagstone name flagstone face flagstone.111 x 14 y 22 no_pick 1 is_floor 1 end free_all_objects: Link error, bailing out. make_path_tofile /usr/games/crossfire/var/crossfire/players/(null)/(null).pl...Was not dir... LOGOUT: Player named (null) from ip 127.0.0.1 /* <-- "logout"? ha ha =) */ Trying to free freed object. arch warrior face warrior.151 animation warrior is_animated 0 Str 23 [... ...] end Waiting for connections... /* <-- note that the server did not die! */ From peterm at tesla.EECS.Berkeley.EDU Mon Feb 26 11:26:34 2001 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:05 2005 Subject: [CF-Devel] I'm disabling the CVS repository on Boltzmann Message-ID: <200102261726.JAA07835@tesla.EECS.Berkeley.EDU> Hello, Since the CVS on sourceforge seems to be working, I'm going to disable the CVS repository on boltzmann. PeterM From peterm at tesla.EECS.Berkeley.EDU Mon Feb 26 11:43:59 2001 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:05 2005 Subject: [CF-Devel] Release-of-the-day crossfire snapshots also disabled Message-ID: <200102261743.JAA07901@tesla.EECS.Berkeley.EDU> Hello, Since sourceforge allows anonymous CVS access, I'm disabling the "release of the day" snapshots formerly available on langmuir.eecs.berkeley.edu. PeterM From bca at magellan.fpms.ac.be Mon Feb 26 06:56:17 2001 From: bca at magellan.fpms.ac.be (bca@magellan.fpms.ac.be) Date: Thu Jan 13 18:00:05 2005 Subject: [CF-Devel] Characters:wizards vs fighter vs special characters Message-ID: <3A9A6081.12214.E0A545@localhost> All that had been said is true for Wizard and fighter. But me I use Wraith,Quezalcoalt or Fireborn race. It is very interesting to play. You begin with characters having some greater advantages in some points and bad points for others. I will take the example of a Fireborn. It has a low strenght,a glowing crystal(500sp max I think), spell point regeneration bonuses,no melee weapon,no armour. It is very interesting to play it as a wizard. I think that event as a monk it should be better. I tried it with Valriel and Goroth. The second one is better for a fireborn because the bad points of it are cthe same and thus not cumulated. But thre is also some bad points. No armour means no special protections or bonuses along with them. No weapons means also no magic weapons.And sometime for a spellcaster it could be easier with a good bow. Other problems found are inconsistencies when starting equipment. A magical hat or an armour or a weapon you can't use. Even the limitation to 500HP for the glowing Crystal is somewhat a problem because I love to play using a lot of casting ;using a sort of torment of spell. I know that is may be a stupid manner to play but it works. Hence using petmonsters(they are handled very stupidly, casting spells on you sometimes) is useful. And for a fireborn ti is too easy to kill wyverns in the dragon quest. I do it at level 5 .Others rooms are too hard to me because ice spell or lighning kill me fast and melee too. In the fire room a red dragon is now free to attacks you directly when you enter in the room. Before it wasn't the case: The red dragon could enter in the entry area of the room. May be think to balance XP gain for such races, items and maps. For them some level otherwise easy for other classes are to hard for a fireborn. For items ,a thing could be a customizable ring with special gems like in Diablo (whitout needing alchemy for low players) or a ring of ring permitting you to wear more thn two rings. Providing special items more regularly which are specially designed for a fireborn or a wraith or a Quezalcoalt could be great like a burning ring of armour +50 that you can't put if you are not immune to fire. Some maps should be created for these kinds of players like a map with a lot of lava and some path of earth who could be a lot easier for a fireborn with levitate and fire immunity than for a classical warrior. Callebaut Beno?t E-mail :bca@magellan.fpms.ac.be E-mail FPMS :stu1997023@gaston.fpms.ac.be From peterm at tesla.EECS.Berkeley.EDU Mon Feb 26 13:00:33 2001 From: peterm at tesla.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:05 2005 Subject: [CF-Devel] Class/Race page on crossfire.real-time.com: some comments Message-ID: <200102261900.LAA07681@tesla.EECS.Berkeley.EDU> Hello, I'm pleased to see the class/race page. It is very useful and largely accurate, but I have these clarifications: 1) Pow("POW") .... affects max mana and max grace both. 2) "You can raise your primary stats by drinking potions up to your class natural limit". Should be "race" natural limit. 3) NET +/- in the tables. Some comment that "Cha" isn't figured into the net +/- should be added: it is confusing otherwise. Regards, PeterM (P.S., is there any chance of getting these and other such web pages into the crossfire CVS?) From leaf at real-time.com Mon Feb 26 15:53:50 2001 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:00:05 2005 Subject: [CF-Devel] Class/Race page on crossfire.real-time.com: some comments In-Reply-To: <200102261900.LAA07681@tesla.EECS.Berkeley.EDU> Message-ID: On Mon, 26 Feb 2001, Peter Mardahl wrote: > > I'm pleased to see the class/race page. It is very useful and largely > accurate, but I have these clarifications: Are there other areas that need to be corrected? Or is this all that you have noticed so far? > > 1) Pow("POW") .... affects max mana and max grace both. > Corrected in both areas: http://crossfire.real-time.com/CF_Handbook/Chapter2/characters.html#2.1.2 http://crossfire.real-time.com/Website_Index/Player_Stats/player_stats.html > > 2) "You can raise your primary stats by drinking potions up to your class > natural limit". > > Should be "race" natural limit. Had it correct in the Handbook, but not on the player stats page. It has been corrected now. > > 3) NET +/- in the tables. Some comment that "Cha" isn't figured into > the net +/- should be added: it is confusing otherwise. > Done. > > (P.S., is there any chance of getting these and other such web pages > into the crossfire CVS?) > What is all involved with getting this done? - Rick Tanner leaf@real-time.com From mwedel at scruz.net Mon Feb 26 21:54:33 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:05 2005 Subject: [CF-Devel] current server-code is still totally broken! References: <000001c0a00d$77da7b40$11a5e23e@kyle> Message-ID: <3A9B24F9.363846E6@scruz.net> Actually, the checkin didn't happen last night - turns out I had a sticky tag on one of the files. I've cleared the tag and just checked it in now. So now it should all work properly (fingers crossed) From dnh at hawthorn.csse.monash.edu.au Tue Feb 27 21:05:58 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:05 2005 Subject: [CF-Devel] Armour encumberance to speed. Message-ID: This morning I had a thought about how we currently handle the speed limits that are imposed via armour. The discussion formed because Philc was annoyed that only +1 AC was added from getting to 30 Dex (instead of 29) where as 30 Pow has a massive difference along with Con. I pointed out that Dex is mostly used only for speed and that is it mostly useless beyond a certain amount because armour has set max speeds attached (exceptive speed bonus (boots of speed etc)). I suggest that instead of making an upper limit to top speed we impose a ratio. It will be based roughly on standard dex stats (about 20) for each item, but instead of stopping when you reach (1.73 for example with PDM) it keeps going. So at say Dex of 30 a player may be able to move at 2.8 (completely arbitrary). This has a few draw backs though, firstly it will make the player more powerful and already we are starting to make things just alittle too easy for warriors as I am sure roWer will point out. Secondly it may make some items suddenly unbalanced (unavoidable really with a change such as this) but I feel many items still need alot of basic revision (powermail for example I feel is slightly to powerful compared to the wizards counterpart, midnight robe. Regardless I think this should be added to CVS and such issues then be looked at, if we spend five years discussing every minor change, things which may in the future add a great amount of fun may be ruled out simply because they are; a) to hard to do b) create a large long term amount of work c) don't _feel_ right to some people (for example I think removing .xpms still isn't 100% agreed on not because .png isn't better but because it just doesn't seem right to remove all the xpms). I can probably make this armour change but I just felt important to make that point. I understand most if not _ALL_ crossfire-dev people are quite busy living their lives (I know I am), but we aren't up to version 1 yet =). dnh From mwedel at scruz.net Wed Feb 28 01:59:56 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:05 2005 Subject: [CF-Devel] Armour encumberance to speed. References: Message-ID: <3A9CAFFC.B8863C5A@scruz.net> dnh wrote: > > This morning I had a thought about how we currently handle the speed > limits that are imposed via armour. > > The discussion formed because Philc was annoyed that only +1 AC was added > from getting to 30 Dex (instead of 29) where as 30 Pow has a massive > difference along with Con. I pointed out that Dex is mostly used only for > speed and that is it mostly useless beyond a certain amount because armour > has set max speeds attached (exceptive speed bonus (boots of speed etc)). The bonuses for pow and con could of course be toned down. One reason the bonuses for those appear really huge is because its a cumulative total (the con bonus applies to about 12 levels, were the dex is not adjusted in that way). In reality, at high levels, dex bonus to ac may be pretty meaningless or very important. Ac is used for determination if a monster hits (via physical) attack or not. At high levels, AC is probably meaningless - most creatures don't use physical, and those that do will probably hit you even if your AC is 10 points better. Or its very imporant - too hit chance are rolled on a d20 basically, so if the monster needs a 5 and you get 10 ac points, it now needs a 15, greatly reducing the chances you can be hit. At low levels, this means if your AC is good enough, you will basically never get hit. > > I suggest that instead of making an upper limit to top speed we impose a > ratio. It will be based roughly on standard dex stats (about 20) for each > item, but instead of stopping when you reach (1.73 for example with PDM) > it keeps going. So at say Dex of 30 a player may be able to move at 2.8 > (completely arbitrary). It wouldn't be hard to do something like you get some portion of your speed that is above the max dictated by armor. But note that the speed bonus gained via high dex (25+) is really a lot. Also, it has been suggested at least once that max values for stats get removed - if that is done, then I would expect a much more linear system. > > This has a few draw backs though, firstly it will make the player more > powerful and already we are starting to make things just alittle too easy > for warriors as I am sure roWer will point out. Secondly it may make some > items suddenly unbalanced (unavoidable really with a change such as this) > but I feel many items still need alot of basic revision (powermail for > example I feel is slightly to powerful compared to the wizards > counterpart, midnight robe. It strikes me that only real reason to do this is because not enough is gained from that really high dex. The real question is of course, is this really a problem? You get even less from that high charisma. My bigger problem is that I think such a change will have very wide spread benefits. Even at low levels, this could make a difference. This could result in a complete re-arrangement of what the good armours are. > > Regardless I think this should be added to CVS and such issues then be > looked at, if we spend five years discussing every minor change, things > which may in the future add a great amount of fun may be ruled out simply > because they are; > > a) to hard to do > b) create a large long term amount of work > c) don't _feel_ right to some people (for example I think removing .xpms > still isn't 100% agreed on not because .png isn't better but because it > just doesn't seem right to remove all the xpms). This should not be checked in until after the 1.0 release. this is not the time to be checking in things that will potentially have significant effects on balance. Unrelated to this, I'll quickly go over the points above: A & B: Someone has to do the work. I typically have no problem taking on something that is hard to do, but realistically, the current set of developers have a finite amount of time, and can't do everything that someone suggests. Also, none of the developers (to best of my knowledge) is getting paid for working on crossfire, so what stuff gets done is stuff that interests the developers. As for point B, if people agree ahead of time to do that work, I don't think that is a problem. Some stuff in the past few months seemed to fall into this area. The problem I have with this is if someone does some amount of stuff and then expects others to pick up/make all the rest of the changes. I don't think that is fair to the others unless they have agreed to pick up that work. As for point C, I think that is just a problem with group efforts. Its very easy to do something is everyone agrees. Its even pretty easy if 90% agree. But what happens when its 60/40? Now right now, the number of developers is small, but if this number grows reasonably large, then some smaller decision making group may be necessary. The danger is alienating users and developers (as a devils advocate point of view, think about joining a project and saying you want to do this and that and the other thing, and the people in charge keep saying no - you'll probably say this is a waste of time and move to something else). But really, that does need to happen - I've rejected patches from people simply because I did not consider them good patches (ie, quick and not really maintainable approach taken, which means that down the road, someone else will end up having to fix it up). > > I can probably make this armour change but I just felt important to make > that point. I understand most if not _ALL_ crossfire-dev people are quite > busy living their lives (I know I am), but we aren't up to version 1 yet We should be at version 1.0 soon. I'll probably roll another release (0.97) simply because 96 had enough bugs that I want get something out there again. And we'll probably need to make some form of roadmap for the 2.0 release and what things go in there so two people don't do conflicting changes (simple example would be adjusting stat bonuses and someone else doing a linear stat system) From pjka at cc.jyu.fi Wed Feb 28 06:33:30 2001 From: pjka at cc.jyu.fi (Pertti Karppinen (OH6KTR)) Date: Thu Jan 13 18:00:05 2005 Subject: [CF-Devel] xpm removal??? In-Reply-To: ; from dnh@hawthorn.csse.monash.edu.au on Wed, Feb 28, 2001 at 02:05:58PM +1100 References: Message-ID: <20010228143330.A9749@tukki.jyu.fi> On Wed, Feb 28, 2001 at 02:05:58PM +1100, dnh wrote: > c) don't _feel_ right to some people (for example I think removing .xpms > still isn't 100% agreed on not because .png isn't better but because it > just doesn't seem right to remove all the xpms). Why do peole want to remove xpm's? The main reason I ever started playing crossfire was the amazingly good looking graphics, namely the xpm ones. I'm used to them and they are still better looking than the png ones. I like pictures that are easy to see, and xpm's are easy to see. Also there are no gamma correction problems across different systems. (eg. On an sgi box, web pages look very different than on winblows systems, because of the default gamma correction.) If someone is going to point that "we cannot maintain 3 separate sets of graphics", then I think the development is taking the wrong route. It basically means that lot of monsters are added to the game. There are alot of monsters allready, we don't urgently need any new ones. What we need are maps. And maps. And perhaps some more maps. If someone absolutely has to make a new monster, she/he should take the trouble of making the picture available in all supported formats, using automated transformation if nothing else. If the picture is sufficiently bad someone will make a better one someday. RoWeR P.S. We could use some more maps for crossfire. P.P.S. We could use a new map editor for crossfire. -- BSc. Pertti Karppinen |'Bridge Players | Systems Designer, University of Jyvaskyla, Finland | Do | http://www.iki.fi/~pjka/ | Office : +358 14 260 2088 | It | HAM: OH6KTR QTH: KP22UF | Cellular: +358 40 564 0786 | on the Table' | From andi.vogl at gmx.net Wed Feb 28 20:49:51 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:05 2005 Subject: [CF-Devel] xpm removal??? In-Reply-To: <20010228143330.A9749@tukki.jyu.fi> Message-ID: <000001c0a1fa$4bd4b120$bfa1e23e@kyle> Pertti Karppinen wrote: > > Why do peole want to remove xpm's? > [...] > If someone is going to point that "we cannot maintain 3 separate sets of > graphics", then I think the development is taking the wrong route. It > basically means that lot of monsters are added to the game. There are alot > of monsters allready, we don't urgently need any new ones. What we need are > maps. And maps. And perhaps some more maps. If someone absolutely has to > make a new monster, she/he should take the trouble of making the picture > available in all supported formats, using automated transformation if > nothing else. If the picture is sufficiently bad someone will make a better > one someday. Did you ever create maps for yourself? Well, I did - And I can tell you that when working on a set of maps, you quickly come to a point where you desperately want to insert a new monster. Placing the millionst enhanced dragon called "very old dragon" or "fiery dragon" or "ancient dragon" or "mega dragon"... that becomes very tiresome after a while. Not only for the map-maker but also for the players. You want to have unique monsters/NPCs? Then you'll need unique images as well. And what about weapons? *Every* map-maker dreams about inserting new weapons... Using an old image? NO, NEVER! Now if you're working on a multisquare monster with animation and you have to draw every pic three times (and that means half a day of extra work), only because some people don't get a consensus... To say it mildly: That doesn't make you happy. And doing the picture exta-aweful (like using convert/resize), saying "oh someday someone will make it look better", that isn't a good solution. I'm not saying we must remove xpm ASAP, nobody said that. Especially not now that future of CF art is kinda.. "uncertain", and developers have so many different preferences. What I do want is that, at least, xbm gets removed (the bitamps for running CF on gameboys) and that we finally *decide* heading for ONE set. We don't have to remove all others, but there should be one set that is the "main set". And some future day, when it is far better than all others, it should remain the only one. I don't really care if this is png or xpm, iso, front-view or top-down, 24x24, 32x32 or maybe something completely new. As long as it looks good and it is ONE set. Andreas Vogl From mwedel at scruz.net Wed Feb 28 22:55:37 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:05 2005 Subject: [CF-Devel] xpm removal??? References: <000001c0a1fa$4bd4b120$bfa1e23e@kyle> Message-ID: <3A9DD649.ED09281@scruz.net> Hmm.. I think this discussion is a good example of darths point C. In any case, the reasons I see for removing everything but the PNG set: 1) Smaller distribution (only one image file in the lib directory instead of three, and this applies for the arch set also) 2) Less code (only need to support one format). This isn't that big a deal in the server, as that code doesn't actually care about the format, but is more an issue with the editor and clients. 3) Easier for people to make new archetypes and images, as only one image is needed. The main argument against it is that people still like the XPM set. I'm not sure I agree with AV's that difficulty in making images results in fewer maps. I would generally hope that every map maker doesn't feel the need to put special objects with special images on each mapset. I don't think this is a good idea for the following reasons: 1) Even if there is still only one image set, creating a new arch and image is still a bit of work. 2) There is no convenient way to just add a few new images/archetyps to the server - basically, you need the arch distribution, and have to do a collect, which makes the maps a bit more of a pain to install. 3) I think this could get overdone - if too many maps have new special unique images/objects, that uniqueness starts to wear off. But I do have a few points: Best I know, for both XPM's and PNG's, no gamma correction is done for them in the client. PNG supports this, but I don't believe the client is using it (at least not the code I wrote). Peter is/was working on making another PNG set that was basically in the same style/a converted but not rescaled version of the XPM set. This is a lot better, in that if someone does make a new image, they still only need to make one - this alternate PNG set can just borrow from that. And in fact, there does not even need to be server support for this - you could very well have an 'alternate image set' that you download, unpack into your .crossfire/images directory, and run the client with the right options (-cache -keepcache) and it will use these other images. If that set is missing images, it would still get the appropriate one from the server. Now for a bit of history: Way back in the early 90's, I added the XPM support to crossfire. The initial xpm set was just the converted bitmaps (2 color). Over time, the transparencies were added, additional colors used, and overall the set evolved into the nice set we have today. Now I certainly hope it won't take as long for that to happen to the PNG set. And in fact what really moved the XPM set along was when a few people would systematically go through and fix the images, and I think that is sort of happening now with the PNG set. Also, the PNG set thankfully has a good starting point (xpm set). I will note that over that time, issues of different images for the same thing arose - the losers can currently be found the arch/dev/xpm_pref directory. Fortunately, now days with the client doing the images, such alternate image sets are much easier to handle. Whats the end result of all this? I don't know. I will predict that the xpm and xbm set will probably go away sometime before 2.0. The question is really if the server will have an alternate png set that can be used that roughly equates to the current xpm set or whether that alternate support will just be handled by people who want it downloading it and unpacking it in their cache directory as I describe above. From dnh at hawthorn.csse.monash.edu.au Wed Feb 28 23:46:43 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:05 2005 Subject: [CF-Devel] xpm removal??? In-Reply-To: <3A9DD649.ED09281@scruz.net> Message-ID: On Wed, 28 Feb 2001, Mark Wedel wrote: > > Hmm.. I think this discussion is a good example of darths point C. why yes, I do believe it is (to quote David Eddings). > In any case, the reasons I see for removing everything but the PNG set: > > 1) Smaller distribution (only one image file in the lib directory instead of > three, and this applies for the arch set also) I don't see this as a big problem, in todays market 1 gig games are not uncommon. Also most players choose only one set anyway.. if caching is on that still only constitutes 1 set. > 2) Less code (only need to support one format). This isn't that big a deal in > the server, as that code doesn't actually care about the format, but is more an > issue with the editor and clients. This is certainly a BIG point. With the current system you need 3 sets of libraries to get all the features and at least two for it to compile properly (AFAIK). With only PNG supported this would be reduced to defn only one. > 3) Easier for people to make new archetypes and images, as only one image is > needed. This is the killer, I generally stopped making images after the 'Skree'. To create one fairly poor 2 x 2 monster took more work than I could really be bothered doing constantly (especially considering it isn't even very good). > The main argument against it is that people still like the XPM set. > > I'm not sure I agree with AV's that difficulty in making images results in > fewer maps. I would generally hope that every map maker doesn't feel the need > to put special objects with special images on each mapset. I don't think this > is a good idea for the following reasons: I agree with AV. Map makers love to make unique maps that is a major part of _creating_ something. For example Peterm only makes a mapset when he has something new to add. I know I wouldn't want to create a whole set of maps and find that most of my plot, or monsters or even items were repeated else where. To make a new monsters is something to be very proud of, and something to make alot of extra interest in a map. I loved the first time I found a sandy not because it was worth alot of points, or because it looked cool, but because it WAS the first time I had found one (or three). I still haven't found a postman =). > 1) Even if there is still only one image set, creating a new arch and image is > still a bit of work. Most mapmakers are willing to put in that work to make something to be proud of. > 2) There is no convenient way to just add a few new images/archetyps to the > server - basically, you need the arch distribution, and have to do a collect, > which makes the maps a bit more of a pain to install. Again, most mapmakers are more interested in a good map than in a abit of work. > 3) I think this could get overdone - if too many maps have new special unique > images/objects, that uniqueness starts to wear off. IMHO I don't think we CAN over do the amount of monsters items etc. If everything is properly balanced the sheer massiveness alone of the game would certainly be a key point to many players. It is very exciting to have a world that really is a world. Different cultures for different regions.. etc etc.. adds alot of flare to a game that may otherwise be boring (not that crossfire is boring). > But I do have a few points: > > Best I know, for both XPM's and PNG's, no gamma correction is done for them in > the client. PNG supports this, but I don't believe the client is using it (at > least not the code I wrote). PNG does support it (PNG supports just about everything =). I think Mich would probably be very interested in doing just that, currently though there is no one working on a linux client AFAIK. > Peter is/was working on making another PNG set that was basically in the same > style/a converted but not rescaled version of the XPM set. This is a lot > better, in that if someone does make a new image, they still only need to make > one - this alternate PNG set can just borrow from that. And in fact, there does > not even need to be server support for this - you could very well have an > 'alternate image set' that you download, unpack into your .crossfire/images > directory, and run the client with the right options (-cache -keepcache) and it > will use these other images. If that set is missing images, it would still get > the appropriate one from the server. Peterms set was widely considered better than the scaled versions of the xpms in PNG. > Now for a bit of history: > Way back in the early 90's, I added the XPM support to crossfire. The initial > xpm set was just the converted bitmaps (2 color). Over time, the transparencies > were added, additional colors used, and overall the set evolved into the nice > set we have today. Now I certainly hope it won't take as long for that to > happen to the PNG set. And in fact what really moved the XPM set along was when > a few people would systematically go through and fix the images, and I think > that is sort of happening now with the PNG set. Also, the PNG set thankfully > has a good starting point (xpm set). > > I will note that over that time, issues of different images for the same thing > arose - the losers can currently be found the arch/dev/xpm_pref directory. > Fortunately, now days with the client doing the images, such alternate image > sets are much easier to handle. > > Whats the end result of all this? I don't know. I will predict that the xpm > and xbm set will probably go away sometime before 2.0. The question is really > if the server will have an alternate png set that can be used that roughly > equates to the current xpm set or whether that alternate support will just be > handled by people who want it downloading it and unpacking it in their cache > directory as I describe above. Yes, I would like to see two sets of PNG (or more as we get bigger). Currently I see a need for front view and the more 3D appearing view of the current PNG set. Over time this may change (10 years is along time though) but I think we shouldn't look to far ahead it may cause alot more problems than it fixes. I would say that that perfect stability of the server is a more pressing issue than the PNG set graphics right now. I would still absolutely love to see some work done in it though. I think Mark has made some very important points here so i thought it valueable to add my thoughts. I think EVERYONE should say what they think now.. or forever hold their peace. dnh > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From biggy at biggiesjoint.every1.net Thu Feb 1 00:50:04 2001 From: biggy at biggiesjoint.every1.net (biggy.) Date: Thu Jan 13 18:03:52 2005 Subject: [CF List] problems with crossfire Message-ID: <20010201065004.683F72742@sitemail.everyone.net> we are using the cfclient, it says cfclient -server localhost Could not open ~/.crossfire /keys, trying to load global bindings Warning: could not convert seysym F28 into keycode, ignoring Warning: could not convert seysym F34 into keycode, ignoring Warning: could not convert seysym F30 into keycode, ignoring Warning: could not convert seysym F32 into keycode, ignoring Warning: could not convert seysym F27 into keycode, ignoring Warning: could not convert seysym F29 into keycode, ignoring Warning: could not convert seysym F31 into keycode, ignoring Warning: could not convert seysym F33 into keycode, ignoring Warning: could not convert seysym F35 into keycode, ignoring Can't connect to server: Connection refused and we have suse 7.0, when i first start it in that way, i can see a quick flash of the program switching on and off. --- Peter Mardahl > wrote: > >You mean the client? >If you're using gcfclient you could do >gcfclient -server localhost > > >> Until recently i had an older version of crossfire where i could actually pla >>y without logging onto the internet, bu with the newest version it always trie >>s to make me go onto the net, is there a way i could play without logging onto >> the internet? >> >> _____________________________________________________________ >> Get your free email at: http://biggiesjoint.mail.everyone.net! >> _______________________________________________ >> 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 _____________________________________________________________ Get your free email at: http://biggiesjoint.mail.everyone.net! From anyname at jan.anorak.org.uk Thu Feb 1 02:03:56 2001 From: anyname at jan.anorak.org.uk (Jan) Date: Thu Jan 13 18:03:53 2005 Subject: [CF List] A stupid question, pehaps Message-ID: <3A79186C.DF37F16A@jan.anorak.org.uk> but here we go (I'm quite new to this game): I'm running crossfire and the gcfclient on Linux and I can't seem to fire my arrows etc. At first I discovered that none of my keys were bound - I fixed that. Now I have a new and worse problem: When I issue the 'fire' command, I shoot whatever I have readied, like eg. all of my arrows, and then it goes on forever with 'you don't have any arrows'. Plus I seem to lose the ability to move around. What have I done wrong? The version is what I downloaded yesterday, my OS is Linux, kernel 2.2, the desktop is downloaded recently (< 1 month) from helix. /jan From tanner at real-time.com Tue Feb 13 01:27:06 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:53 2005 Subject: [CF List] [mwedel@scruz.net: [CF Announce] Crossfire 0.96.0 released.] Message-ID: <20010213012706.C26843@real-time.com> Bug in announcement list. Forwarding this for Mark: --------------- Crossfire 0.96.0 has been released. Despite many changes from the last release, this release should be quite stable - its been tested fairly extensively. Unless serious bugs are detected, this will likely be the last release before 1.0. Main changes: New random map layouts added. Re-done player exit code - this should hopefully fix players appearing in the middle of oceans. Server will send image checksums to client when client is caching images - in this way, client knows to request new image or not (both client and server change) New spells PNG support added to editor. Partial Resistance code added. Protections now have numeric values, and add up. A complete list of changes is at the bottom of this message. NOTE TO MIRROR SITES: The primary site (ftp.scruz.net) has limited download bandwidth per day. If this poses a problem, you want a more reliable method, or you just want a backup method. please drop me a mail message - I have set up a secondary server off my ADSL link, but being that only has 128 kb upstream bandwidth and is also used for other interactive purposes, I don't want to make it available to all. Files released for this version: sums (bsd) filename 04869 1507 crossfire-0.96.0.arch.tar.bz2 65381 1796 crossfire-0.96.0.arch.tar.gz 63394 2645 crossfire-0.96.0.maps.tar.bz2 12882 3807 crossfire-0.96.0.maps.tar.gz 11913 2641 crossfire-0.96.0.tar.bz2 60544 2967 crossfire-0.96.0.tar.gz 27062 237 crossfire-client-0.96.0.tar.gz Sums (md5) 709ccf30ed6489dc3673b93be20b105b crossfire-0.96.0.arch.tar.bz2 290f8cb22336459b2ac9f42a440954e9 crossfire-0.96.0.arch.tar.gz b0b21296ba967e90388bce9b789a49ff crossfire-0.96.0.maps.tar.bz2 76c6574c7fb50d3fe27dfc659f4c1be3 crossfire-0.96.0.maps.tar.gz d29d939ccc7d0e02e14949e23f2109fb crossfire-0.96.0.tar.bz2 cf42d4c6f2ef2595424a14a110a8bcbb crossfire-0.96.0.tar.gz 2b6d9d9d6c355082a467805a301e7eb4 crossfire-client-0.96.0.tar.gz crossfire-client-0.96.0 is the client (X11) distribution - standard X11 and gtk interfaces are provided. crossfire-0.96.0.tar.{gz/bz2} contains the server code with prebuilt archetype and image files. crossfire-0.96.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-0.96.0-maps.tar.{gz/bz2} contains the maps. This is needed with the server distribution. No doc archive at this time - I don't believe anything in it should have changed much. 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.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 - it should be on the other ftp sites in a short time. Mark Wedel mwedel@scruz.net 01/28/2000 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Changes: Client: MSW 2001/02/02: Protocol: Update with new face1 command that includes checksum. client.c: add face1 protocol command. client.h: Update version_sc to 1026. commands.c: Move FaceCmd from gx11.c/x11.c to this file, since it now only does decoding of data and passes rendering off to appropriate file. Also add Face1Cmd function that deals with checksum. Both of these functions pass off the rendering to the same function. gx11.c: add keepcache variable, re-do facing loading/caching - if we have local version of face, generate checksum of it and compare to that against what server has. finish_face_command added to do this - called by the face functions in commands.c. Add -keepcache command line option which will have it not request images from server if checksum is different. Add usleep in metserver selection area to prevent client from hogging all the cpu time. item.c: Add support for ^ in items file to say only match at start of line. Useful for 'bolt' - doing substring also matched against firebolt. item_types, item_types.h: make bolt ^bolt, add Head and hauberk to matching criteria. proto.h: automatic regen. x11.c: As gx11.c above, plus: Use one font for all windows - reduces complexity. Add easy selection of font to use with -font command line option. xutil.c: As gx11.c for relevant functions that are located in this file and not x11.c End of MSW 2001/02/02 checkin. MSW 2001/01/31: client.c: Clear player inventory and look windows after disconnection from server. Prevents client crashes. gx11.c: various fixes - window placement no longer always centered on screen (very obnoxious if running xinerama), various prototypes fixed up, clear map data after clearing image data. player.c: Add suport for 'mapredraw' command. Not that this should ever really be needed, but the server supports it, so its nice to be able to use it. x11.c: Fixes prototype/casting problems when clearing pixmaps. Like gx11.c, clear map data. xutil.c: add better description to the unbind command. MSW 2001/1/13 (except as mentioned, all changes by MSW): Makefile.in: Create destination dirs, remove extra tab. Patch also by Dave. Protocol: typo fixed. config.h, config.h.in: Add HVAE_DMALLOC_H #ifdefs. Checks currently disable in configure.in, as with it, the sound won't like properly since it needs -ldmalloc, and I haven't bothered investing that much time into fixing the Makefile. gx11.c: Patches by Dave Peticolas - mostly code cleanup, but one new feature is support of wheel mice to move the scrollbars. png.c: No real code change, just adjustments in some ordering which I think makes the code appear a little simpler. x11.c: Minor code cleanups, some formatting changes, some to make better error messages. End of MSW 2000/1/13 checkin. MSW 2001/1/8: client.h: Change damage type to be 16 bits. MSW 2000/12/24: png.c: Fix a major memory corruption issue - the png function was re-allocing for a larger hunk of data, but did not update the pointer and was still using the pointer to the smaller hunk. Severity of this bug depended on luck - if the first png downloaded happened to have the full 4 bytes/pixel, it never needed to do a realloc so would work fine. Otherwise, a matter of luck what data got stomped over. Also, modified the main function in this file so that it you can compile against it and it now works with the new in memory data read. MSW 2000/12/19: Metaserver update. Most files updated. This change has the client connect the metaserver and lets the user choose which server to connect to. Also, if the client loses a connection (either because the player has quit playing or the server died), the client will no longer exit and instead go back to the server selection screen. A few unrelated changes (cfclient): when running cache, non downloaded images should look better. Also, client starts up with larger window in Png mode to take into account the extra space png images takes up in the game window. Changes by file: Makefile.in: Add metaserver.c file. cconfig.h: Add metaserver configuration information. client.c: Add meta_ variables, move resists_name to this file, no longer have DoClient exit if it gets an error on the socket (instead mark the fd as -1 and return), change main loop such that if connection to server has been lost, go through loop to establish a new connection. client.h: Add Metaserver_Select input state. Change resists_name from a static to extern. gx11.c: Remove some unused code, various code cleanups, and additions to support the metaserver connection process. init.c: Add reset_client_vars - call it between connections to servers. proto.h: rebuilt for new functions. x11.c: Update for metaserver connection status. If running Png mode, have windows created larger. xutil.c: When creating default images for cache, create 32x32 images for png mode, not 24x24 images. metaserver.c: New file for metaserver code. End MSW 2000/12/19 checkin. MSW 2000/12/10: png.c, gx11.c, x11.c, xutil.c: modified to use in memory loading of png's. This means that if not caching images, we don't need to write it out to a temp file. This should result in a minor performance gain, but also remove the need of using tmpnam. Also, modified gx11.c so that it uses same logic as the x11 client for extended command key ('). Before gx11.c client would use both ' and ", and there was no way to unbind the later - since one can always bind the command key, I found that a bit annoying. Updated to display resistance values in the message window. Except for armour, this is only displayed when running against serves with PR code. Change for both cfclient and gcfclient. Files affected: Protocol client.h commands.c gx11.c newclient.h player.c sounds soundsdef.h x11.c MSW 12-3-2000 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Server: MSW 2001/01/11: include/rproto.h: Rebuilt for new random map code. server/player.c: remove player insert in key_roll_stat - player is already inserted. server/swap.c: When swapping out map, see if it has already reached reset time, and if so, just delete it and not save it. In flush_old_maps, now have it check for maps that have no timeout set - this sometimes happens when players save/die on maps. MSW 2001/01/11: Other than various general cleanups, the main change this code does is that style maps (for random maps) get loaded special now - they objects they contain are not put on the active list, and they use a private map list so they do not appear in the output of the 'maps command. common/arch.c, common/treasure.c,server/login.c: Update calls to load_object common/loaderl.l,loader.c: Update lex_load to take an optional flags option. This is currently only used so that the loader can decide if it should call update_ob_speedto put objects on the active list or not. Calls to lex_load updated. load_object modified to take another option common.map.c: remove PROCESS_WHILE_LOADING and CHECK_ACTIVE_MAPS ifdefs. update calls to load_object. Remove some dead code. include/config.h: Remove CHECK_ACTIVE_MAPS and PROCESS_WHILE_LOADING flags. Those options did not work, and in all likelihood, this would be done via threading now days and not what code was there. include/libproto.h, sproto.h: updated or various function changes. include/map.h: Add MAP_STYLE flag. random_maps/exit.c: Call set_map_timeout after we load the final map so it will get swapped out. random_maps/standalone.c: Add dummy set_map_timeout function so it compiles. random_maps/style.c: Add load_style_map function which does the job of actually checking to see if a style map is in memory, and if not, loads it up. Updates the pointers so it appears on a map style map list and not the general map list. server/main.c: create set_map_timeout function that deals with setting the map timeouts. Fix bug so server doesn't crash if two players kill each other on hall of selection. server/monster.c remove dead code. socket/loop.c: If realloc fails, catch it and exit with meaningful error message. End of MSW 2001/02/11 checkin. MSW 2001/02/08: server/login.c:Fix that would prevent maps from getting swapped out properly - we would try to swap out a map the player is in the process of leaving - move swap out code until after we have moved the player to the new map. MSW 2001-02-08 MSW 2001/02/06: common/porting.c: relocate clean_path from this file to server/main.c server/main.c: relocate clean_path from porting.c. Add unclean_path. Modify enter_unique_exit so it supports relative maps on unique maps. Modify enter_exit so word of recall (or other forcelike fields), work when the return point is a swapped out unique map. MSW 2001/02/05: server/attack.c: Fix blind and paralyze - logic for reducing duration was broken, resulting in zero duration for most characters. It should now work properly, reducing according to the amount of protection. MSW 2001/02/02: common/item.c: Don't have armour item types get returned as magical if they have an armour value - that is to be expected. This eliminates the false positives that you otherwise get on armor when you cast detect magic. include/newserver/h: and checksum field to FaceInfo struct. Update version_sc to 1026. socket/init.c: calculate image checksums as we load the images. socket/request.c: If client is at least version_Sc 1026, use face1 protocol command that includes the checksum. MSW 2001/01/31: common/object.c: Fix that that spells cast on spaces with no floors get set properly after the spell expires. common/player.c: Use skill tools first (lockpicks, talismans, etc) before using native skills. In this way, an object with bonus automatically gets used. common/living.c: Fix so that negative con bonuses work properly - fixes bug where a higher con could result in lower total hp due to improper calculation. MSW 2001/01/30: Complete rewrite of the exit handling code. Hopefully as an effect, this will fix the player appearing in the middle of the oceans. I think the code should also work better in many other areas. Main enhancements is a 3x3 area for pets to follow player to new map, as well as golems now following players to the new maps. include/sproto.h, random_maps/rproto.h - rebuilt. random_maps/random_map.c: Change generate_random_map to take a structure with the random map paremeters. random_maps/reader.l, reader.c: Add set_random_map_variable function that reads the map parameters from a char buffer. Also, remove some leftover comments that were from the common/loader.l file. random_maps/rogue_layout.c: Change some functions to be static so make proto doesn't collect them. random_maps/standalone.c: Add opening of parms file into main function since it ws removed from the random_map.c file. server/apply.c: Don't display the message of random maps to the players as they enter them, as this message is random map parameters, and not a real message. server/login.c: #if 0 out using of the player loading element in the structure. this isn't used right now. server/main.c: Bulk of the changes. main changes are to break apart the old enter_exit function into smaller functions that more logically do the needed function (random maps, unique maps, and transferring the player to the new map). random map code now passes the parameters via structure instead of file in /tmp. Code is much more understandable now and hopefully bugfree. server/pets.c: minor changes/bugfixes. Search full SIZEOFFREE array, use real owner variable when print out messages. server/player.c: Remove usage of the loading variable in the player structure. End of MSW 2001/01/30 checking. MSW 2001/01/23: Various cleanups/fixes as detected by purify: common/anim.c: animation[0] was given a null pointer as the name, but bsearch/or comparison function will try to de-reference it. Give it a unique name. common/loader.l: msgbuf was being used initialized in the main loading function. loader.c also regenerated. common/object.c: find_free functions were not checking to see if the spaces they were examining were out of the map. Added checks to do so. server/apply.c: buf was being used uninitialized in the function. socket/init.c: input buffer needs to be initialized as we do a strncasecmp against the buffer which may not have any data in it. MSW 2001/01/18: server/skill_util.c: add change_skill_to_skill function to be used when we already know the skill object we want to use. This is more efficient than change_skill which takes a skill number and then searches the inventory for the object. remove extra esrv_send_item from do_skill_attack - don't need to send skills to player. do_skill_attack: remove call to hth_damage - that function does not take into account objects in the player inventory that increase damage, and since that is called each attack, it is not feasible to have it search the players inventory. Instead, we just rely on damage generated by fix_player - only think hth_damage did was adjust damage based on level difference. PeterM 2001/01/16 Added randomly-generated nethack-style maps to crossfire's random map generator. MSW 2001/01/15: Change blindness and paralyze so that duration is reduced based on protection the player has. file server/attack.c MSW 2001/01/15: Various fixes for friendly object code: common/button.c: Add missing call to remove_friendly_object common/friend.c: Pretty much completely re-written. add_friendly_object now checks to make sure the object being added isn't already on the list, remove_friendly_object will remove objects whose tags don't match, and added clean_friendly_list. common/object.c: No reason to use the function pointer to remove_friendly_object since that function is in the lib. common/time.c: Make DEBUG_TIME always on (no longer compile time option). other areas use the global var pticks, so if it was turned off, compile would break anyways. common/treasuer.c: No longer print debug messages on artifacts created. Cluttered log file making it hard to see more important errors. include/config.h: Remove DEBUG_TIME define. include/libproto.h: Rebuilt for clean_friendly_list function. server/main.c: rewrote do_specials to do things based on pticks variable. This allows various specials to be spread out across multiple ticks easier. Also, added clean_friendly_function to part of what this does. server/skills.c: add missing call to remove_friendly_object. Also, removed from #if 0 .. #else .. #endif code. End of MSW 2000/01/15 checkin. PeterM 2001/01/08: Wrathful Eye spell implemented. MSW 2000/12/26: Checkin of Jan's new god intervention code. I haven't played around with it much, but I haven't seen any really obvious problems. common/living.c: remove learn_prayer_chance common/treasure.c: Various changes to treasure generation - mostly to deal with starting equipment and putting it in the inventory. doc/crossfire.doc: Update docs on god intervention. include/define.h: GT_... flags removed. include/treasure.h: GT_... flags added. Addition flags added from what was in define.h before. lib/archetypes, lib/crossfire.png, lib/treasures: Updated with new archetypes and treasures. random_maps/standalone.c,server/rune.c,server/time.c: Calls to create_treasure updated server/apply.c: New functions for god intervention added, update calls to create_treasure, other god related changes. server/c_wiz.c: Calls to create_treasure updated, various functions to allow DM's to learn/unlearn spells added. server/commands.c: Various commands added to the wiz set of commands. See commen for c_wiz.c server/disease.c: Changes to reduce_symptoms server/gods.c: Numerous updates for god intervention code. server/player.c: Modifications for starting player equipment. server/skill_util.c: Display the god the character worships when they issue the skills command. server/skills.c: Minor cosmetic change made to message when praying on altar. server/spell_effect.c: Changes related to gods, cure spells, and generation of treasures & items. End of MSW 2000/12/26 checkin. MSW 2000/12/23: include/define.h: Add SIZEOFFREE1 and SIZEOFFREE2 values to use instead of arbitrary constants in the code. server/monster.c: change communicate function to use above values. Before it was stopping one short of the full 2 space array, so one particular space (-1, -2 relative to player) would not hear players speech. server/attack.c: Don't exit hit_player function if damage is reduced to 0 in magical attacks. This was preventing face of death and probably a lot of effect only spells from working. server/spell_util.c: modify check_cone_push to use move_object to blow the objects. Before, multisquare monsters were getting sliced into their individual components - move_object deals with multisquare objects properly. PeterM 2000/12/18: Re-add the conflict spell (various files) attack.c: fix a bug which could easily have led to seg fault, and did when I was testing under efence. MSW 2000/12/17: Various changes. Note that the scope of files in this checkin make it appear that a lot was changed, but in fact it was mostly just re-orginization - very little code has actually changed. include/autoconf.h.in: Add HAVE_LIBDES to file. include/config.h: Remove comments after defines for MAP_MIN/MAX timeouts. This just removes some warnings during compile. comments are now on lines by themselves. include/player.h: remove shootstrength for player structure. It was unused. server/Makefile.in: remove input.c file, add c_range.c file. server/c_chat.c: remove command_last, add command_shout and command_tell from input.c to this file. Also fix bug in command tell which would let players crash server at will. server/c_misc.c,server/c_object.c: Relocate many functions from input.c into these files. server/c_move.c, server/c_new.c: Add standard crossfire banner comment. server/c_range.c: New file - contains range related commands, including spell casting (relocated from input.c) server/c_wiz.c: move command_invisible from input.c into this file. server/commands.c: Remove unused commands (bell, last, strength) server/input.c: removed file. server/main.c: Change HAVE_DES_H to HAVE_LIBDES server/player.c: When choosing a race, draw it facing south for best presentation of image. server/spell_util.c: Remove dead code (#if 0 shootstrength related code) socket/loop.c: remove unused variables. NOTE: Due to the addition/removal of files, you will need to do 'config.status; make depend; make' from the top level directory for everything to be compiled properly. End of MSW 2000/12/17 checkin. PeterM: 2000/12/17: Various problems fixed in random_maps/*.c: endless loop removed, exit leading to blocked area of spiral fixed. PeterM: 2000/12/17: Stat max bug fixed. server/apply.c MSW 2000/12/16: server/player.c: If the player race archetype has a message, print that out. This allows a descriptive message about what the different races will get. The message is removed from the player once they decide on the race. common/living.c: Add some parens around some PR resistant checks - eliminates warnings from gcc. server/disease.c: have cure_disease remove all diseases a player is infected with. The code suggested it was attempting to do so, and the messages it printed out certainly suggested that the character was disease free. PeterM: 2000/12/14: Added spiral map layout PeterM: 2000/12/14: Restructuring of the random map code. Functionally, it should be identical. All global variables moved into the functions. MSW 2000/12/10: utils/metaserver.pl: Various improvements. Main one is that tcp connections to port 13326 of the metaserver will dump the information in a easily parsable format for the client or other applications. include/config.h: Set ARCHTABLE size to correct value. server/player.c: Have server send update item to client for players face while select class. Added esrv_new_player in Roll_Again, because without it, the client had yet to receive information on what tag the player was so could not make sense of the updated face. server/spell_effect.c: Balance issues for polymorph. Reduce maximum value for high valued objects, remove ability to polymorph generators, put maximum level on polymorphed monsters and give them saving throws against the effects. MSW 2000/12/5: server/player.c: Move location of where it sets the player has_hit variable until after we have confirmed that the player has actually attacked a monster and not that the space is blocked. Fixes various problems and make behaviour more predictable. common/button.c: Do not set path_attuned when loading connected objects from within the editor. This is normally done for random map code/glue logic. common/player.c: When trying to find a skill to use, use a native skill first before going off and returning a skill object like a talisman. MSW 2000/12/4: common/treasure.c: Make it so resistances from artifact files are absolute adjustments. Makefile.in configure configure.in: Fix check for libdes to see if des_crypt exists in libdes before setting HAVE_LIBDES crossedit/Makefile.in: Add Cnv/libCnv.a before LIBS - should fix linking error on irix systems. utils/metaserver.pl: modified so it ignores entries from hosts that report their name as put.your.hostname.here MSW 2000/12/3: crossedit/Attr.c: Add the new resist names to set of variables one can set. MSW 2000/12/3: Misc changes. Main one is adding PNG support to the editor. TODO: Remove outdated things to do (like partial resistance code) configure, configure.in, include/autoconf.h.in: Add check for libpng. include/global.h: Remove displaymodes - moved to crossedit/Defines.h crossedit/App.c, crossedit/App.h crossedit/CrEdit.c crossedit/CrFace.c crossedit/CrList.c crossedit/CrUtil.c crossedit/Edit.c crossedit/crossedit.c crossedit/xutil.c, crossedit/png.c (new file): Add support for png display in crossedit. crossedit/Makefile.in: Add png.c file. server/c_misc.c: Change who command to only display real players, and not players in process of connecting/unconnecting. Also, remove code to display old sockets, since those are not supported anymore. MSW 2000/12/3: Checking for partial resistance code. Various minor errors also fixed (compiler warnings, unused variables, Makefile.in changes, etc). PR code also includes support to send protections to the client. Files changed: common/Makefile.in common/button.c common/exp.c common/friend.c common/holy.c common/info.c common/init.c common/item.c common/living.c common/loader.c common/loader.l common/object.c common/player.c common/re-cmp.c common/readable.c common/treasure.c crossedit/App.c crossedit/crossedit.c crossedit/proto.h doc/crossfire.doc include/define.h include/global.h include/libproto.h include/newclient.h include/newserver.h include/object.h include/player.h include/sproto.h lib/Makefile.in lib/archetypes lib/artifacts lib/crossfire.png lib/crossfire.xbm lib/crossfire.xpm random_maps/rproto.h random_maps/special.c random_maps/style.c server/Makefile.in server/apply.c server/attack.c server/c_misc.c server/c_object.c server/commands.c server/disease.c server/gods.c server/input.c server/monster.c server/player.c server/resurrection.c server/rune.c server/spell_effect.c server/spell_util.c server/swap.c socket/metaserver.c socket/request.c Added Files: include/attack.h -- Bob Tanner A new version of client-linux-rpm has been released. You can download it from SourceForge by following this link: You requested to be notified when new versions of this file were released. If you don't wish to be notified in the future, please login to SourceForge and click this link: -- 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 csnyder at techieguy.com Fri Feb 23 10:21:07 2001 From: csnyder at techieguy.com (Chris Snyder) Date: Thu Jan 13 18:03:53 2005 Subject: [CF List] Game not saving Message-ID: <20010223162107.27804.cpmta@c004.sfo.cp.net> Ok I am having a problem with Crossfire not saving. I get errors when the program tries to autosave, and the bed or reality does not work either. I am using Storm Linux (DEB files were included with the distribution), and I am using the GTK client. Is there a config that I need to change in order to get this to work correctly? Please let me know. Chris _______________________________________________________ Are you a Techie? Get Your Free Tech Email Address Now! Many to choose from! Visit http://www.TechEmail.com From andi.vogl at gmx.net Fri Feb 23 11:24:07 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:03:53 2005 Subject: [CF List] Game not saving In-Reply-To: <20010223162107.27804.cpmta@c004.sfo.cp.net> Message-ID: <000001c09dbd$6e5025e0$12a6e23e@kyle> Chris Snyder wrote: > Ok I am having a problem with Crossfire not saving. I get errors > when the program tries to autosave, and the bed or reality does not > work either. I am using Storm Linux (DEB files were included with > the distribution), and I am using the GTK client. Is there a config > that I need to change in order to get this to work correctly? Please > let me know. This looks very much like a write-protection problem to me. Are you sure that you have read/write access to all crossfire directories? Let's assume you installed the game to "/usr/games/crossfire/", then the player files are stored in "/usr/games/crossfire/var/crossfire/players". Make sure to have write premission there. Andreas V. From csnyder at techieguy.com Fri Feb 23 17:28:44 2001 From: csnyder at techieguy.com (Chris Snyder) Date: Thu Jan 13 18:03:53 2005 Subject: [CF List] Game not saving Message-ID: <20010223232844.7323.cpmta@c004.sfo.cp.net> > This looks very much like a write-protection problem to me. > Are you sure that you have read/write access to all crossfire directories? > > Let's assume you installed the game to "/usr/games/crossfire/", > then the player files are stored in > "/usr/games/crossfire/var/crossfire/players". Make sure to have > write premission there. > > > Andreas V. Thank you for your help so far. It appears that I have access to all the directories needed. I found the player directory under "/var/lib/games/crossfire/players" it even seems to have made a file for my character. When I go to save (either autosave, or at a bed of reality) I get "Can't open file for save SAVE FAILED!" I have the following deb packages installed "crossfire-server", "crossfire-edit" (both version 0.95.4-2), "crossfire-client", "crossfire-maps", "crossfire-client-gtk", and "crossfire-client-x11" (those 4 are version 0.95.4-1). The save failure occurs in either client (gtk or x11). Attached is a file that list all the files/directories that were installed for the server, client, and client-gtk. Any ideas. Thank you. _______________________________________________________ Are you a Techie? Get Your Free Tech Email Address Now! Many to choose from! Visit http://www.TechEmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: cs-client Type: application/octet-stream Size: 526 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010223/4b0f769d/cs-client.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: cs-client-gtk Type: application/octet-stream Size: 173 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010223/4b0f769d/cs-client-gtk.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: cs-server Type: application/octet-stream Size: 2535 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010223/4b0f769d/cs-server.obj From andi.vogl at gmx.net Fri Feb 23 20:19:28 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:03:53 2005 Subject: [CF List] Game not saving In-Reply-To: <20010223232844.7323.cpmta@c004.sfo.cp.net> Message-ID: <000101c09e08$3876a340$12a6e23e@kyle> > > This looks very much like a write-protection problem to me. > > Are you sure that you have read/write access to all crossfire directories? > > > > Let's assume you installed the game to "/usr/games/crossfire/", > > then the player files are stored in > > "/usr/games/crossfire/var/crossfire/players". Make sure to have > > write premission there. > > It appears that I have access to all the directories needed. > I found the player directory under "/var/lib/games/crossfire/players" > it even seems to have made a file for my character. When I go to save > (either autosave, or at a bed of reality) I get "Can't open file for > save SAVE FAILED!" I have the following deb packages installed > "crossfire-server", "crossfire-edit" (both version 0.95.4-2), > "crossfire-client", "crossfire-maps", "crossfire-client-gtk", and > "crossfire-client-x11" (those 4 are version 0.95.4-1). The save > failure occurs in either client (gtk or x11). Attached is a file > that list all the files/directories that were installed for the > server, client, and client-gtk. Any ideas. Looking at the code, there clearly is only one case in that the message "Can't open file for save SAVE FAILED!" gets displayed. That is: the fopen command to open a new player file fails. This again, can mean two things: Either you don't have the write permission, or the path is wrong and certain directories don't exist. So, please try and run crossfire as super-user (su), and/or do a recursive chmod 777 through your whole crossfire directory tree. And eventually try installing crossfire in "/usr/games/" (the default path) instead of "var/lib/games/" just in case, if all else fails. (Though I'm not sure about the paths in version 0.95.4 at all). Besides, I strongly recommend that you don't use those far outdated packages from debian but get the latest version 0.96.0 from . I don't know about eventual bugs in old server versions, and I don't want to learn about them, if already fixed in todays version. :-] (If you have difficulties with the installation process, join IRC irc.openprojects.net, channel #crossfire - most likely you'll get helped there.) Your player directory should appear in "/[...]/crossfire/var/crossfire/player/" with version 0.96.0. Andreas V.