From crossfire-devel at archives.real-time.com Mon Aug 2 09:24:08 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:53 2005 Subject: [CF-Devel] Posted here because SF lists block me (Mlab maps release 7) Message-ID: Added: 2 houses in scorn Addressed: Zelots house no longer has free treasure Tavern pass can be decerned by poking around. Changes: /mlab NOT /scorn/mlab rand maps that go places, more stuff in the city of clouds https://cat2.ath.cx/cat2/media.html dev server: cat2.ath.cx _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Aug 2 10:46:39 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:53 2005 Subject: =?iso-8859-1?Q?Re:=20[CF-Devel]=20Posted=20here=20because=20SF=20lists=20block=20me=20(Mla=b=20maps=20release?= Message-ID: > Added: 2 houses in scorn > > Addressed: Zelots house no longer has free treasure > > Tavern pass can be decerned by poking around. > > Changes: /mlab NOT /scorn/mlab > > rand maps that go places, more stuff in the city of clouds > Why not /scorn/mlab? - the policy we have with the bigworld mapset is to place maps in the 'city' or 'quest type' folder where they are easily found- I think that's a good idea. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Aug 2 14:19:18 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:53 2005 Subject: [CF-Devel] Posted here because SF lists block me (Mlaï20maps release Message-ID: /mlab because mlab is bigger then scorn now and where ever I had to put in a definite path (end maps for rand maps, perm apartments in CityDeClouds) I put /mlab/something because that's the dir I use. Mlab has the tavern and 40 something story tower (not random, all hand done btw, I use rand maps as bridges in some maps elsewhere in mlab to make traversing it uncertain and long), the City on the clouds (CityDeClouds), the cloud world, then there is the other places including a new town and great wilderness's, dwarvish gold mine, a chaotic emerald mine taken over by a witch who has opened a portal to another relm (which you can explore 1 level of... I might expand that later...) A working courthouse and jail (levers in the town send you to court, then levers there make your sentance, only accessable by DM now... but later will be useable by players who gain magisterium status in the town, jail isnt finished yet (dosn't have death penalty or life in prison yet). There is also the mazes of menace and the valley of Gehennom (death valley esque)... so you can play nethack w/o going to a guild... but it is a tough journy. And also ice caves are present. If the cvs guy does put it in scorn lots of stuff wont work. If he uses a script to change the paths he's wasting his time and is probably breaking my maps. You can play them on cat2.ath.cx btw. ---- Original Message ---- From: Todd Mitchell Date: Mon 8/2/04 11:55 To: crossfire-devel@lists.real-time.com Subject: Re: [CF-Devel] Posted here because SF lists block me (Mlaï20maps release > Added: 2 houses in scorn >=20 > Addressed: Zelots house no longer has free treasure >=20 > Tavern pass can be decerned by poking around. >=20 > Changes: /mlab NOT /scorn/mlab >=20 > rand maps that go places, more stuff in the city of clouds >=20 Why not /scorn/mlab? - the policy we have with the bigworld mapset is to pl= ace maps in the 'city' or 'quest type' folder where they are easily found- = I think that's a good idea. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Aug 2 16:43:59 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:54 2005 Subject: =?ISO-8859-1?Q?Re=3A_=5BCF-Devel=5D_Posted_here_because_SF_li?= =?ISO-8859-1?Q?sts_block_me_=28Mla=EF20maps_release?= In-Reply-To: References: Message-ID: When was the last time the mlab mapset was synchronized with CVS? What version of CVS (or date) are you currently working off of? How much will your map changes conflict with what's currently in CVS? How much will the current maps in CVS conflict with what you have developed? IMO, things are going to have to be coordinated very soon before merging mlab maps with the official distribution becomes more time, work and effort then anyone wants to take on. Example: 1.) Where is this courthouse located? 1.1) Does an existing map need to be moved? 1.1.1) If so, where to? (see question 2) 1.1.2) It not, does this existing map get removed or retired? 1.1.2.1) If so, why? 1.1.2.2) If not removed or retired, then what happens to it? 2.) How does the world map need to be modified for this new courthouse? 2.1) What other buildings are affected by this? 2.1.1) How are they affected? 2.1.1.1) Start over with question 1.1 Well, I'm not the greatest when it comes to designing "charts" like this, but I think you get the idea. Work in tandem, otherwise the work load to put everything together will be immense. =/ On Mon, 2 Aug 2004, mikeeusa@caethaver2.ath.cx wrote: > > /mlab because mlab is bigger then scorn now and where ever I had to put > in a definite path (end maps for rand maps, perm apartments in > CityDeClouds) I put /mlab/something because that's the dir I use. Mlab > has the tavern and 40 something story tower (not random, all hand done > btw, I use rand maps as bridges in some maps elsewhere in mlab to make > traversing it uncertain and long), the City on the clouds > (CityDeClouds), the cloud world, then there is the other places > including a new town and great wilderness's, dwarvish gold mine, a > chaotic emerald mine taken over by a witch who has opened a portal to > another relm (which you can explore 1 level of... I might expand that > later...) A working courthouse and jail (levers in the town send you to > court, then levers there make your sentance, only accessable by DM > now... but later will be useable by players who gain magisterium > status in the town, jail isnt finished yet (dosn't have death penalty > or life in prison yet). There is also the mazes of menace and the valley > of Gehennom (death valley esque)... so you can play nethack w/o going > to a guild... but it is a tough journy. And also ice caves are present. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Aug 2 17:52:23 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:54 2005 Subject: [CF-Devel] Posted here because SF li?= =?ISO-8859-1?Q?sts block me (Mlaï20maps release Message-ID: I'm using the current CVS version (well it's about 5 days old) The courthouse etc is not in scorn or bigworld tile, since most of mlab takes place in a dream (once you go up the tower there is a bed... you have to fall asleep in it to go to the CityDeClouds... all an illluuusssiiooonn) it's in mlab, you'll see if you find the mountain to climb down. The only changes to scorn are to change the exits to /mlab/bla also I did add to the tavern map (tavern, zealot's house, rundownhouse) the two houses to the east of that four tile complex in scorn (now a 6 tile complex) I put in the mlab/bigworld/world the western scorn bigworld tile as motified and a mask-map of it (just has the motified building-exits in their proper place and nothing more). The last time mlab was checked in was a year or so ago (maby more?...) ... it still works fine though (except it has to be /mlab ) as I didnt screw with the rest of the world so much. ---- Original Message ---- From: Rick Tanner Date: Mon 8/2/04 17:40 To: crossfire-devel@lists.real-time.com Subject: Re: [CF-Devel] Posted here because SF li?= =?ISO-8859-1?Q?sts block me (Mlaï20maps release When was the last time the mlab mapset was synchronized with CVS? What version of CVS (or date) are you currently working off of? How much will your map changes conflict with what's currently in CVS? How much will the current maps in CVS conflict with what you have developed? IMO, things are going to have to be coordinated very soon before merging mlab maps with the official distribution becomes more time, work and effort then anyone wants to take on. Example: 1.) Where is this courthouse located? 1.1) Does an existing map need to be moved? 1.1.1) If so, where to? (see question 2) 1.1.2) It not, does this existing map get removed or retired? 1.1.2.1) If so, why? 1.1.2.2) If not removed or retired, then what happens to it? 2.) How does the world map need to be modified for this new courthouse? 2.1) What other buildings are affected by this? 2.1.1) How are they affected? 2.1.1.1) Start over with question 1.1 Well, I'm not the greatest when it comes to designing "charts" like this, but I think you get the idea. Work in tandem, otherwise the work load to put everything together will be immense. =/ On Mon, 2 Aug 2004, mikeeusa@caethaver2.ath.cx wrote: > > /mlab because mlab is bigger then scorn now and where ever I had to put > in a definite path (end maps for rand maps, perm apartments in > CityDeClouds) I put /mlab/something because that's the dir I use. Mlab > has the tavern and 40 something story tower (not random, all hand done > btw, I use rand maps as bridges in some maps elsewhere in mlab to make > traversing it uncertain and long), the City on the clouds > (CityDeClouds), the cloud world, then there is the other places > including a new town and great wilderness's, dwarvish gold mine, a > chaotic emerald mine taken over by a witch who has opened a portal to > another relm (which you can explore 1 level of... I might expand that > later...) A working courthouse and jail (levers in the town send you to > court, then levers there make your sentance, only accessable by DM > now... but later will be useable by players who gain magisterium > status in the town, jail isnt finished yet (dosn't have death penalty > or life in prison yet). There is also the mazes of menace and the valley > of Gehennom (death valley esque)... so you can play nethack w/o going > to a guild... but it is a tough journy. And also ice caves are present. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Aug 2 19:00:11 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:54 2005 Subject: [CF-Devel] Re: [ crossfire-Patches-983864 ] Add python plugin events for kick and muzzle (no_shout) dm c In-Reply-To: References: Message-ID: Pardon the "newbie" question, but where would one find this log file on the server? For instance, some one with shell access to the server can check the ban_file for players that have been banned (and their IP, character name, date and by which DM) - where does one look for the kick and muzzle details? On Mon, 2 Aug 2004, SourceForge.net wrote: > Patches item #983864, was opened at 2004-07-02 01:02 > Message generated for change (Settings changed) made by temitchell > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=313833&aid=983864&group_id=13833 > > Category: Server > Group: None > >Status: Closed > >Resolution: Fixed > Priority: 5 > Submitted By: Todd Mitchell (temitchell) > Assigned to: Nobody/Anonymous (nobody) > Summary: Add python plugin events for kick and muzzle (no_shout) dm c > > Initial Comment: > Adds python plugin events for kick and muzzle > (no_shout) dm commands. This allows for two new global > events which will launch scripts (primarily for logging). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Aug 2 19:59:53 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:54 2005 Subject: [CF-Devel] Re: [ crossfire-Patches-983864 ] Add python plugin events for kick and muzzle (no_shout) dm c Message-ID: <1091494487.11638.16.camel@oberon.kameria> Well at the moment thre is no log file for this- this just allows the events to be logged. I wanted to put in the server code in advance of the changes to the python scritps. I am working on updating the CFLog.py script (so it will use the crossfirelog shelve file for now) to incorporate these events and then will add some scripts to the chicken oracle to pull the information out again. I envision somehting like this: say seen Polo The Great Chicken Oracle says: I have seen 'Polo' 23 times. I saw them last coming from IP: 111.222.333.444 on Mon, 02 Aug 2004 16:40:04 CEST say muzzle Polo The Great Chicken Oracle says: Polo is muzzled say lastkick Polo The Great Chicken Oracle says: Polo was last kicked out on Mon, 02 Aug 2004 16:49:01 CEST say kickcount The Great Chicken Oracle says: Polo has been kicked 2 times say muzzlecount The Great Chicken Oracle says: Polo has been muzzled 983 times say lastmuzzle The Great Chicken Oracle says: Polo was last muzzled on Mon, 13 May 2004 11:30:01 CEST _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Aug 3 09:11:53 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:54 2005 Subject: [CF-Devel] clients Message-ID: <20040803141149.GD23344@laranja.org> Well. Last night I felt like playing some crossfire and I remembered why I haven't been doing that a lot recently. The existing clients (xt and gtk) are all but unplayable in 800x600 :-( I do get to play eventually, by splitting windows and stacking them in a very hackish way, but I don't think that's an acceptable solution in the long term. On first thought it may seem that 800x600 is not a modern resolution; but please remember that in portable-land, only the most expensive laptops support more than that. If at all possible, we should have a client that runs in 640x480! I know I'm guilty of having started and not finished a client. I was writing a client for PicoGUI, and when it was approaching a state where I could actually play the game, PicoGUI itself was abandoned :-/ so I kind of lost enthusiasm. As a side note, is anyone working in porting the gtk client to gtk2? There are probably three or four binaries linked to gtk1 in my system, counting with gcfclient; in a few months it won't be reasonable to expect new installations to even have gtk1. What became of the sdl client? It seems like, with a smart skin, it could be made to work in 800x600. []s, |alo +---- -- Those who trade freedom for security lose both and deserve neither. -- http://www.laranja.org/ mailto:lalo@laranja.org pgp key: http://garfield.laranja.org/~lalo/gpgkey-signed.asc GNU: never give up freedom http://www.gnu.org/ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Aug 3 21:27:32 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:54 2005 Subject: [CF-Devel] Ghosting problem, weather thoughts In-Reply-To: References: Message-ID: <20040804122732.7e092728.won_fang@yahoo.com.au> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Aug 3 16:13:38 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:54 2005 Subject: [CF-Devel] clients In-Reply-To: <20040803141149.GD23344@laranja.org> References: <20040803141149.GD23344@laranja.org> Message-ID: <41100002.8050607@sonic.net> Lalo Martins wrote: > The existing clients (xt and gtk) are all but unplayable in > 800x600 :-( I do get to play eventually, by splitting windows > and stacking them in a very hackish way, but I don't think > that's an acceptable solution in the long term. Note that there are also options for the client to scale down the size of the images - this can help a bit also - especially for the inventory and look window, where the spacing is really determined by the size of the images. > > On first thought it may seem that 800x600 is not a modern > resolution; but please remember that in portable-land, only the > most expensive laptops support more than that. If at all > possible, we should have a client that runs in 640x480! all relative I suppose - it seems that basically any new laptop will have at least 1024x768, with higher resolution being available. The problem gets into the target - a client that runs/looks nice on 800x600 may not look or be all that efficient on higher resolution systems. > As a side note, is anyone working in porting the gtk client to > gtk2? There are probably three or four binaries linked to gtk1 > in my system, counting with gcfclient; in a few months it won't > be reasonable to expect new installations to even have gtk1. I'm working on it slowly. My main motivation was to have a client that completely used glade2 for the gui design elements, so that down the road, it will be much easier to add new menus and whatever else. Progess is whenever I have time to do so, which basically means when I'm not busy with something else. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Aug 3 16:24:24 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:54 2005 Subject: =?ISO-8859-1?Q?Re=3A_=5BCF-Devel=5D_Posted_here_because_?= =?ISO-8859-1?Q?SF_lists_block_me_=28Mla=EF20maps_release?= In-Reply-To: References: Message-ID: <41100288.1000008@sonic.net> mikeeusa@caethaver2.ath.cx wrote: > If the cvs guy does put it in scorn lots of stuff wont work. If he uses a script to > > change the paths he's wasting his time and is probably breaking my maps. In this particular case (/mlab), it may be reasonable for it to be seperate, as it is a big enough entity to in a sense be its own city. But I want to be clear, that the rationale of 'I use /xyz because I want to' is not an acceptable policy overall - the just eventually leads to a bunch of such maps in the directory, and makes it difficult to maintain what is where. As said, since /mlab is probably OK in this case since it is a large entity, so long as what is there is all part of the same thing. If for example there are maps that are located in other main cities, or are on the world continent, they should be placed in the appropriate directory and not in /mlab. The issue of the connecting maps is always odd. For example, I think there are maps that connect scorn to wolfsburg - do those sit in wolfsburg or scorn for example? The answer is really that either is OK. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Aug 3 16:35:47 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:54 2005 Subject: [CF-Devel] Ghosting problem, weather thoughts In-Reply-To: <20040804122732.7e092728.won_fang@yahoo.com.au> References: <20040804122732.7e092728.won_fang@yahoo.com.au> Message-ID: <41100533.5070306@sonic.net> David Seikel wrote: > On Sat, 31 Jul 2004 09:40:15 -0400 mikeeusa@caethaver2.ath.cx wrote: > > I had big plans for the weather code. One of the major plans was to move the > weather code to a separate server, to help with the resource usage (just run > it on a different box). That is about half way completed. Just a note - I never really saw that much a point in that - it seems that if you are short of resources on the main box, it is probably easier to add resources on that first box that have another box in play. But it also all depends on what is considered the minimum requirements. It could very well be a case that a 128 MB p2-300 isn't considered appropriate. My only real main objection to it being a seperate process is that surely adds complexity - you still have all the complexity is the weather program to do the generations, but you have added complexity that it needs to communicate those changes to/from the server, keep synchronized, etc - and it then depends on how that is done and where the resources are really spent on the server (eg, loading/saving maps is probably a nontrivial operation, so if the server still has to do those, and now update those maps, communicate that data back and forth, I'm really not sure how much work is now getting offloaded) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Aug 3 16:39:57 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:54 2005 Subject: [CF-Devel] More patches and things to consider In-Reply-To: <1091264528.d638ea3cyann.chachkoff@myrealbox.com> References: <1091264528.d638ea3cyann.chachkoff@myrealbox.com> Message-ID: <4110062D.9070009@sonic.net> Yann Chachkoff wrote: > > The solution was to provide wrappers to those functions from the server > context itself (I admit it, it is not the most elegant solution - I'd have > scrapped the whole common/server split away myself, but I'm not the only one > to decide such drastical changes). There was a discussion to actually re-arrange the source code. The real issue is that for the most part, the current system works, and to re-arrange it is quite a bit of work without a lot of immediate gain. At one point, the split made more sense - the Xt editor linked in the common library. and in fact, the standalone random map generator does also, but not being able to generate that probably isn't that big a deal. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Aug 3 17:10:17 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:54 2005 Subject: [CF-Devel] Weather level 5 (Re: Weather needs smoothing) In-Reply-To: <1091255719.d644639cyann.chachkoff@myrealbox.com> References: <1091255719.d644639cyann.chachkoff@myrealbox.com> Message-ID: <41100D49.2090003@sonic.net> a lot of good ideas, but some of my own thoughts. In addition to be able to better tell the client about some effects, it'd also be nice if the server knew which information was weather related with no real meaning (say the puddles on the ground) vs data with real meaning. I say this in that a lot of the data falls into that later category, and it is probably something that individual players should decide if they want to see it or not. Some thoughts on the previous ideas: 1) Each space could have an actual temperature. High or low temperatures could effectively cause fire or cold damage (taking into account the players resistances, or maybe have each point of resistance act as it shifting the temperature in the players favor?) Anyways, the point being, deserts could have a temp of 120 F, and arctic reasons temps at -10 F, and do damage as appropriate - shouldn't be that hard to do, because I believe the weather code currently figures out the temperature of each space. In terms of lifecycles - the best way to handle this is to add a field like 'expires_at' to the object structure, and have it represent the tick (or other global time) it happens. This is different from the current object scheme where it only ages if it is currently in memory. Thus, when a map is loaded, the expires_at field can be examined, and it can quickly be determined that the object should now be dead. Likewise, maps in memory could periodically be examined to clean them up. And it wouldn't be hard to have a flag or something which says 'when this object expires, create other_arch in its place' - thus you could mimic growth - the sapling expires, but creates a small tree in its place, after a while it expires, creates a large tree, etc. As far as the crash in wolfsburg, a stack trace could be handy. And there is no guarantee of course that the code is bug free. dmalloc or purify (free demo available for linux) can be useful in finding memory leaks. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Aug 3 17:15:01 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:54 2005 Subject: [CF-Devel] python setquantity() In-Reply-To: <200407230844.44739.yann.chachkoff@myrealbox.com> References: <1090374210.2891.5.camel@oberon.kameria> <200407230844.44739.yann.chachkoff@myrealbox.com> Message-ID: <41100E65.7060204@sonic.net> Yann Chachkoff wrote: > Le mercredi 21 Juillet 2004 03:43, Todd Mitchell a ?crit : > I have to admit that I don't remember anymore why I put an arbitrary limit - > probably that was just a workaround for an obscure bug involving large > quantities of a single object. There are probably other arbitrary limits in the ocde. > > The clean way to correct it is to: > > - Include system header (you can do it in the plugin.h specific > plugin header. Since it is theorically part of the ANSI-C definition, it > should exist on Win32 as well); > > - Test value against INT_MAX, which holds the maximum acceptable value for the > integer type. Only useful if the value in question is a long (64 bit value). Otherwise, you've already overflowed the value you are testing against, which probably doesn't get you the results you want. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Aug 4 11:15:50 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:54 2005 Subject: =?ISO-8859-1?Q?Re=3A_=5BCF-Devel=5D_Posted_here_because_?= =?ISO-8859-1?Q?SF_lists_block_me_=28Mla=EF20maps_release?= In-Reply-To: <41100288.1000008@sonic.net> References: <41100288.1000008@sonic.net> Message-ID: <41110BB6.1050605@sympatico.ca> > In this particular case (/mlab), it may be reasonable for it to be > seperate, as it is a big enough entity to in a sense be its own city. > > But I want to be clear, that the rationale of 'I use /xyz because I > want to' is not an acceptable policy overall - the just eventually leads > to a bunch of such maps in the directory, and makes it difficult to > maintain what is where. > > As said, since /mlab is probably OK in this case since it is a large > entity, so long as what is there is all part of the same thing. If for > example there are maps that are located in other main cities, or are on > the world continent, they should be placed in the appropriate directory > and not in /mlab. > Currently the mlab maps in question are in /scorn/mlab if they are to be moved out of the Scorn folder it should be either to their own city folder or to the quest folder. Now I would say that if the city in the clouds is called 'mlab' then /mlab would be reasonable but /cloudcity or some such would be better if mlab is merely a personal tag. If they are a quest then /quests/mlab would be reasonable - just as mlab was reasonable (if not entirely desirable) if they were in Scorn. Using meaningful area names whenever possibe is something that I am more and more in support of the more maps I work on. I am sure the DMs would agree. Now I have been of the opinion that these maps should probably be moved a little ways outside scorn city walls anyway because they take up a lot of realestate in an already crowded city. It also would make the dialogue of the NPCs a little more relevant if this area was a suburb of Scorn (the disenfranchised living outside the city walls) and not on mainstreet. An little inn and suburb with a few houses just a little outside the city would be nice and would encourage some movement outside the city walls which would also be nice. In this case moving the maps to their own folder would be sensible as well. Again I don't mind meeting halfway on these things but I really think there were improvements made to the map layout with the bigworld maps that make it easier to locate things (from inside the game as well as in the editor) which we should try to stick with or even improve upon. I also think that with a bit of coordination the maps are better than if each area is a little self contained system. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Aug 4 13:18:18 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:55 2005 Subject: [CF-Devel] clients In-Reply-To: <41100002.8050607@sonic.net> References: <20040803141149.GD23344@laranja.org> <41100002.8050607@sonic.net> Message-ID: <200408042018.34276.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well the size is mainly determined not by pictures but because this game has LOTS of messages and , well we need to put them somewhere. (Stats, fight message, chat message, inventory, ground, etc). By the way, the resolution of my PDA is 480x480, that's not enough to play. Just one more useless message i post to mailing list :p Le mardi 03 Ao?t 2004 23:13, Mark Wedel a ?crit : Lalo Martins wrote: > The existing clients (xt and gtk) are all but unplayable in > 800x600 :-( I do get to play eventually, by splitting windows > and stacking them in a very hackish way, but I don't think > that's an acceptable solution in the long term. Note that there are also options for the client to scale down the size of the images - this can help a bit also - especially for the inventory and look window, where the spacing is really determined by the size of the images. > On first thought it may seem that 800x600 is not a modern > resolution; but please remember that in portable-land, only the > most expensive laptops support more than that. If at all > possible, we should have a client that runs in 640x480! all relative I suppose - it seems that basically any new laptop will have at least 1024x768, with higher resolution being available. The problem gets into the target - a client that runs/looks nice on 800x600 may not look or be all that efficient on higher resolution systems. > As a side note, is anyone working in porting the gtk client to > gtk2? There are probably three or four binaries linked to gtk1 > in my system, counting with gcfclient; in a few months it won't > be reasonable to expect new installations to even have gtk1. I'm working on it slowly. My main motivation was to have a client that completely used glade2 for the gui design elements, so that down the road, it will be much easier to add new menus and whatever else. Progess is whenever I have time to do so, which basically means when I'm not busy with something else. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel - -- - -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBESh2HHGOa1Q2wXwRAuWZAJsH0PHLc3h8TDVF2gdAzgrCHYJVEQCg4LYI 9tCKx7TzCJsdfi7q5Lm53FA= =XBBI -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu Aug 5 17:09:43 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:55 2005 Subject: [CF-Devel] Weather level 5 (Re: Weather needs smoothing) In-Reply-To: Message-ID: As the person who wrote the weather.. just a few comments.. On 30-Jul-2004 Todd Mitchell wrote: > Level 5 weather is not just weather but erosion/climate as well I think - it > is > a lot to process on the maps beacuse it would change ground arches such as > swamp to desert as well as do 'weather'. There are still a few places > (mostly > cities) where there are no elevation of the landscape as well which may or > may > not be a problem for the code. In the least it will result in very active > weather as it will be a big hole in the elevation map. Level 4 and 5 never fully worked. There were too many elevation holes on the maps, and I never got the feathering routines worked out. It's insanely difficult to essentially backport a weather system into a game that was never designed for multiple-layered tiles. You end up with all kinds of artifacts because of the 3-layer limit, and therefore I had to do alot of silly hacking to make it work better. As for the rain blobs.. I didn't draw them.. not my fault. :) > Weather is still > somewhat experimental (and anything above level 3 I had problems with in the > past) I believe so there could be leaks or whatnot as well I suppose. There > may be problems with the feathering code as well but I would have to check > the > archives to remember that. Basically.. level 3 worked decently last time I tried, which was quite awhile ago.. so other changes may have broken it over time. Level 4 and 5 never really got off the ground, and really just shouldn't be used. They are essentially unfinished. As for the complaints regarding the layout of the equator, it is fairly easy to move the equator. You should be able to simply move it to a map edge without much work. The equator was originally designed for a much larger bigworld map, but Mark scaled the bigworld down after I had allready tuned the equasions.. and I never got around to re-fiddling them. There are probably some misconceptions about the gulfstream, and the other aspects. The code is relatively simple.. it simply has two truly random factors, and then everything else is derrived. You start with a random pressure. Pressure affects windspeed. Windspeed affects effecitve temperature (windchill) and basically moves humidity around from the shores. However, just pressure alone does not properly move humidity enough from the coasts, therefore the gulfstream was added to push humidity inland. Temperature is based on distance from equator, season, and time of day. Without the gulf stream, the map stagnates and the entire world becomes a desert bordered by swampland. Once you have temperature, windspeed, pressure and humidity, you simply combine those four numbers on a basic chart, to determine the weather. High temp, low pressure, high humidity, high wind == hurricane. I don't think getting level 5 working will ever really be possible. It basically means you have to toss out the entire map, and randomly generate one. People weren't thrilled with the idea, and in order to make it really work, I think you will have to change a number of basics in the game. In addition, elevation was trashed on most of the maps.. You can make it grow trees.. thats pretty easy.. but by letting it do that, that means whole forests are going to change position. This will screw up the placement of map entrances. I think to make level 5 work, you need to make a commitment to a fully dynamically generated bigworld, and I think most people do not want that. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Aug 6 02:08:51 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:55 2005 Subject: [CF-Devel] Weather level 5 (Re: Weather needs smoothing) In-Reply-To: Message-ID: On 06-Aug-2004 mikeeusa@caethaver2.ath.cx wrote: > only 2 problems are snow as weather dosn't smooth for some reason and the > equator is_ > in the middle. How would I set the equator to the bottom of the bigworld? Hrmm.. it's been awhile.. Oh.. here we are.. You basically want to write a new version of weather.c:polar_distance() Basically it determines how far a given x,y is from the equator. You would simply change it to return something based only on the y value, rather than the stuff it does now to calculate the diagonal equator. Change that one function, and you have a new equator. > Feathering_ > sounds like a good solution to the elevation hole problem. Another thing that > could_ > be done is a script that parses the worldmaps (perl yay) and if it finds say > a_ > mountain tile with no elevation if it is a highmountain it makes it > elevation_ > 10000-12000 or so etc and do this with hills too and posibly grass etc._ I had some perl scripts that would backpatch the elevation from an old copy of the map that still had it. However if you've added a new mountain, you will basically have to manually edit it, or do something like you suggest with the script basing it off the terrain. The feathering doesn't work at all. You would have to fix that routine, and that is not a simple task. It is currently commented out from weather_effect(). --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Aug 6 22:26:17 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:55 2005 Subject: [CF-Devel] clients In-Reply-To: <200408042018.34276.tchize@myrealbox.com> References: <20040803141149.GD23344@laranja.org> <41100002.8050607@sonic.net> <200408042018.34276.tchize@myrealbox.com> Message-ID: <41144BD9.8060009@sonic.net> tchize wrote: > Well the size is mainly determined not by pictures but because this game has > LOTS of messages and , well we need to put them somewhere. (Stats, fight > message, chat message, inventory, ground, etc). One of the things I was doing for the gtk2 client was using more tabs to select the data. Eg, for the messages, have a few tabs - one contains everything, one contains only the important messages, I think maybe one for chat type messages. In this way, in the middle of the battle, you could see all the messages, and afterward, go to the other tabs to see messages you might have missed. However, the basic design of the gtk2 was for a 1024x768 resolution (that was the layout size) - might be resizable smaller, but that wasn't my design goal. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Aug 7 05:24:08 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:55 2005 Subject: [CF-Devel] clean code? Message-ID: <200408071224.25805.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wandering in the code today, i was wondering. Am i the only one to feel ashamed by those 'goto' in the code? When i learned programming 12 years ago, i was learned never to use them because you endup with spaghetti programs. - -- tchize tchize@myrealbox.com Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html A government that is big enough to give you all you want is big enough to take it all away. Barry Goldwater -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBFK3PHHGOa1Q2wXwRApi9AJwMij2i+hzS3n64Q3KQnciKUdwAYACeL4MM 3SyQ81uv/f4aaxR0ri9y44U= =mHkw -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Aug 7 05:44:33 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:55 2005 Subject: [CF-Devel] clean code? In-Reply-To: <200408071224.25805.tchize@myrealbox.com> References: <200408071224.25805.tchize@myrealbox.com> Message-ID: <4114B291.6050102@laposte.net> tchize a ?crit : > Wandering in the code today, i was wondering. Am i the only one to feel > ashamed by those 'goto' in the code? When i learned programming 12 years ago, > i was learned never to use them because you endup with spaghetti programs. Well, somehow function calls & such are really gotos.... But yes, if we could avoid'em, i too think that'd be better. Though maybe we could first clean the code of other weird stuff, fix broken things, and so on :) Ryo _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Aug 7 06:27:43 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:55 2005 Subject: [CF-Devel] clean code? In-Reply-To: <4114B291.6050102@laposte.net> References: <200408071224.25805.tchize@myrealbox.com> <4114B291.6050102@laposte.net> Message-ID: <200408071328.07355.d.delbecq@laposte.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 mm cleanup weird stuff? like using carefully a snprintf and 2 lines later using strcat? Well am already cleaning (and it take a huge amount of time) string manipulation in server code (to prevent buffer overflows :) ) Le samedi 07 Ao?t 2004 12:44, Nicolas Weeger a ?crit : tchize a ?crit : > Wandering in the code today, i was wondering. Am i the only one to feel > ashamed by those 'goto' in the code? When i learned programming 12 years > ago, i was learned never to use them because you endup with spaghetti > programs. Well, somehow function calls & such are really gotos.... But yes, if we could avoid'em, i too think that'd be better. Though maybe we could first clean the code of other weird stuff, fix broken things, and so on :) Ryo _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel - -- - -- David Delbecq d.delbecq@laposte.net Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBFLy1HHGOa1Q2wXwRAo+DAJ0WS60DoH05DuYC/ddIOp9J1NPvVwCgtclx NBg8cNS05pYiBzUXLnxoFbM= =Y22L -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Aug 10 20:20:12 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:55 2005 Subject: [CF-Devel] Ghosting problem, weather thoughts In-Reply-To: <41100533.5070306@sonic.net> References: <20040804122732.7e092728.won_fang@yahoo.com.au> <41100533.5070306@sonic.net> Message-ID: <20040811112012.15199ab6.won_fang@yahoo.com.au> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Aug 10 20:25:20 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:55 2005 Subject: [CF-Devel] Weather level 5 (Re: Weather needs smoothing) In-Reply-To: <41100D49.2090003@sonic.net> References: <1091255719.d644639cyann.chachkoff@myrealbox.com> <41100D49.2090003@sonic.net> Message-ID: <20040811112520.2da104df.won_fang@yahoo.com.au> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Aug 10 20:37:22 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:55 2005 Subject: [CF-Devel] Weather level 5 (Re: Weather needs smoothing) In-Reply-To: References: Message-ID: <20040811113722.10355f5f.won_fang@yahoo.com.au> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Aug 11 00:18:17 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:56 2005 Subject: [CF-Devel] Weather level 5 (Re: Weather needs smoothing) In-Reply-To: <20040811113722.10355f5f.won_fang@yahoo.com.au> Message-ID: On 11-Aug-2004 David Seikel wrote: > While I was adding the visualisation code, I noticed that the humidity still > tended to hug the coasts, which is why I added spin_globe(). Both gulf > stream > and spin_globe() make the weather interesting and realistic, either or > neither > results in boring, unrealistic weather. Yeah.. I have to admit that idea helped alot. I hadn't thought of that originally, but it worked really well. Good idea. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Aug 13 13:41:07 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:56 2005 Subject: [CF-Devel] Alchemy exploit Message-ID: <20040813184107.GA3015@idefix2.dvlp.in-medias-res.com> Hello, I'd like to come back to alternate recipes for alchemy and related skills. I think they can be (and currently on metalforge are) abused to make money. (I found 1 million(!) potions of sunfire sold to a shop.) The common precondition for any valid recipe should be that at least one ingredient is hard to get. This precondition is not valid for many alternate recipes: after writing a small perl script, I recognized that alternate recipes are *very* common, even when using only common ingredients (for example coins or food). Without much effort, I found a recipe that made items with a selling price of 40.000pp while using only 400pp of coins as ingredients. To prevent this particular abuse, I'd like to propose the following fix (see attached diff): do not allow *alternate* recipes with a result value higher than that of the ingredients. I limited the check for increased value to alternate recipes only because there are some normal recipes that also match. But this should not be a problem because you have to get the uncommon items first. -------------- next part -------------- Index: server/alchemy.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/alchemy.c,v retrieving revision 1.20 diff -u -w -r1.20 alchemy.c --- server/alchemy.c 13 Sep 2003 05:02:07 -0000 1.20 +++ server/alchemy.c 13 Aug 2004 17:32:39 -0000 @@ -60,6 +60,9 @@ }; +static int is_defined_recipe(const recipe *rp, const object *cauldron, object *caster); + + /* cauldron_sound() - returns a random selection from cauldron_effect[] */ char * cauldron_sound ( void ) { @@ -136,6 +139,11 @@ ; if (rp) { /* if we found a recipe */ + uint64 value_ingredients; + uint64 value_item; + object *tmp; + int attempt_shadow_alchemy; + ave_chance = fl->total_chance/(float)fl->number; /* the caster gets an increase in ability based on thier skill lvl */ if (rp->skill != NULL) { @@ -155,6 +163,13 @@ return; } + /* determine value of ingredients */ + value_ingredients = 0; + for(tmp = cauldron->inv; tmp != NULL; tmp = tmp->below) + value_ingredients += query_cost(tmp, NULL, F_TRUE); + + attempt_shadow_alchemy = !is_defined_recipe(rp, cauldron, caster); + /* create the object **FIRST**, then decide whether to keep it. */ if ((item=attempt_recipe(caster, cauldron, ability, rp, formula/rp->index)) != NULL) { /* compute base chance of recipe success */ @@ -168,8 +183,14 @@ success_chance, ability, rp->diff, item->level); #endif + value_item = query_cost(item, NULL, F_TRUE); + new_draw_info_format(NDI_UNIQUE, 0, caster, "result value=%llu", value_item); + if(attempt_shadow_alchemy && value_item > value_ingredients) +#ifdef ALCHEMY_DEBUG + LOG(llevDebug, "Forcing failure for shadow alchemy recipe.\n"); +#endif /* roll the dice */ - if ((float)(random_roll(0, 101, caster, PREFER_LOW)) <= 100.0 * success_chance) { + else if ((float)(random_roll(0, 101, caster, PREFER_LOW)) <= 100.0 * success_chance) { change_exp(caster, rp->exp, rp->skill, SK_EXP_NONE); return; } @@ -640,4 +661,84 @@ return danger; } +/* is_defined_recipe() - determines if ingredients in a container match the + * proper ingredients for a recipe. + * + * rp is the recipe to check + * cauldron is the container that holds the ingredients + * returns 1 if the ingredients match the recipe, 0 if not + * + * This functions tries to find each defined ingredient in the container. It is + * the defined recipe iff + * - the number of ingredients of the recipe and in the container is equal + * - all ingredients of the recipe are found in the container + * - the number of batches is the same for all ingredients + */ +static int is_defined_recipe(const recipe *rp, const object *cauldron, object *caster) +{ + unsigned long batches_in_cauldron; + const linked_char *ingredient; + int number; + const object *ob; + + /* check for matching number of ingredients */ + number = 0; + for(ingredient = rp->ingred; ingredient != NULL; ingredient = ingredient->next) + number++; + for(ob = cauldron->inv; ob != NULL; ob = ob->below) + number--; + if(number != 0) + return 0; + /* check for matching ingredients */ + batches_in_cauldron = 0; + for(ingredient = rp->ingred; ingredient != NULL; ingredient = ingredient->next) { + unsigned long nrof; + const char *name; + int ok; + + /* determine and remove nrof from name */ + name = ingredient->name; + nrof = 0; + while(isdigit(*name)) { + nrof = 10*nrof+(*name-'0'); + name++; + } + if(nrof == 0) + nrof = 1; + while(*name == ' ') + name++; + + /* find the current ingredient in the cauldron */ + ok = 0; + for(ob = cauldron->inv; ob != NULL; ob = ob->below) { + char name_ob[MAX_BUF]; + const char *name2; + + if(ob->title == NULL) + name2 = ob->name; + else { + snprintf(name_ob, sizeof(name_ob), "%s %s", ob->name, ob->title); + name2 = name_ob; + } + + if(strcmp(name2, name) == 0) { + if(ob->nrof%nrof == 0) { + unsigned long batches; + + batches = ob->nrof/nrof; + if(batches_in_cauldron == 0) { + batches_in_cauldron = batches; + ok = 1; + } else if(batches_in_cauldron == batches) + ok = 1; + } + break; + } + } + if(!ok) + return(0); + } + + return(1); +} -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Aug 14 09:52:03 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:56 2005 Subject: [CF-Devel] New spell proposal: cold meteor swarm Message-ID: <411E2713.5070407@laposte.net> Hello. Evocation doesn't have (as far as i know) powerful spells. So i'm wondering about doing a cold version of comet & meteor swarm. Pretty easy to do, everything is already in place. I'd just add 'slow' attacktype to cold, though, since bad cold should slow players ;p What do you think of that? Ryo _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Aug 15 12:14:31 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:56 2005 Subject: [CF-Devel] New DM commands Message-ID: <411F99F7.5060102@laposte.net> Hello. I just commited some DM functions that should ease item manipulation. DM now have an 'item' stack, that contains dumped & such items. Any item dumped with 'dump ' gets pushed on stack, and can be used on commands, with '$stack_index', or omitting the argument (defaults to stack top). So you can do: * dumpbelow * patch weight 1500 => patches just dumped item, which is now on stack top. You can also do 'dump $2' to dump 3rd item on stack (0 based). New command list: * stack_push * stack_pop * stack_list * diff diff basically calls 'get_ob_diff' with specified items, and dumps difference. Makes it easier to spot why items won't merge :) Note: diff left right calls get_ob_diff( right, left ) This is not a mistake, but to ease manipulation - basically, you'll probably want to do: * push correct_item * push weird_item_not_merging * diff <-- displays values for right item, thus the correct ones * patch => thus you need to compare this way. Weird prolly, oh well :) I changed remove, free, patch, create, dump, dumpbelow to use those stack functions. No help is yet written, though. Warning: i tested this code, and it works. But i haven't heavily tested it, so maybe i'm missing some obvious default. (for instance, you can possibly enter 'dump $-5' and it'll work/crash) Also, there may be parasitic messages now & then, with remove for instance. Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Aug 15 23:47:28 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:56 2005 Subject: [CF-Devel] New spell proposal: cold meteor swarm In-Reply-To: <411E2713.5070407@laposte.net> References: <411E2713.5070407@laposte.net> Message-ID: <41203C60.6020404@sonic.net> Nicolas Weeger wrote: > Hello. > > Evocation doesn't have (as far as i know) powerful spells. > So i'm wondering about doing a cold version of comet & meteor swarm. > Pretty easy to do, everything is already in place. > I'd just add 'slow' attacktype to cold, though, since bad cold should > slow players ;p > > What do you think of that? I don't see any problem with that - certainly, there is room for expansion of spells for some of the other disciplines (summoning) also. I certainly knew that when things were split apart that everyting wouldn't be perfectly balanced. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Aug 16 00:05:15 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:56 2005 Subject: [CF-Devel] Alchemy exploit In-Reply-To: <20040813184107.GA3015@idefix2.dvlp.in-medias-res.com> References: <20040813184107.GA3015@idefix2.dvlp.in-medias-res.com> Message-ID: <4120408B.1040506@sonic.net> Andreas Kirschbaum wrote: > Hello, > > I'd like to come back to alternate recipes for alchemy and related > skills. I think they can be (and currently on metalforge are) abused to > make money. (I found 1 million(!) potions of sunfire sold to a shop.) > > The common precondition for any valid recipe should be that at least one > ingredient is hard to get. This precondition is not valid for many > alternate recipes: after writing a small perl script, I recognized that > alternate recipes are *very* common, even when using only common > ingredients (for example coins or food). Without much effort, I found a > recipe that made items with a selling price of 40.000pp while using only > 400pp of coins as ingredients. > > To prevent this particular abuse, I'd like to propose the following fix > (see attached diff): do not allow *alternate* recipes with a result > value higher than that of the ingredients. > > I limited the check for increased value to alternate recipes only > because there are some normal recipes that also match. But this should > not be a problem because you have to get the uncommon items first. the patch looks good, with only a few minor nits: 1) It seems there is a debug new_draw_info_format left in that prints the results of value of the item - presumably that needs to be removed. 2) The block: @@ -168,8 +183,14 @@ success_chance, ability, rp->diff, item->level); #endif + value_item = query_cost(item, NULL, F_TRUE); + new_draw_info_format(NDI_UNIQUE, 0, caster, "result value=%llu", value_item); + if(attempt_shadow_alchemy && value_item > value_ingredients) +#ifdef ALCHEMY_DEBUG + LOG(llevDebug, "Forcing failure for shadow alchemy recipe.\n"); +#endif /* roll the dice */ - if ((float)(random_roll(0, 101, caster, PREFER_LOW)) <= 100.0 * success_chance) { + else if ((float)(random_roll(0, 101, caster, PREFER_LOW)) <= 100.0 * success_chance) { change_exp(caster, rp->exp, rp->skill, SK_EXP_NONE); return; } @@ -640,4 +661,84 @@ I'm not sure if it will actually compile of ALCHEMY_DEBUG is not defined, as there is then just an empty if () else statement. This can pretty easily be solved by just putting {} in the right places, as an empty block should be OK. Wonder if it might also be good to put some message as to why it failed. 3) use of any 'long' or 'unsigned long' variables is discouraged, as past experience has shown that there is no guarantee if these will be 64 or 32 bit values. Instead use the uint32 or uint64 types, depending on what you need (maybe this has been clarified in more recent versions of the C standard). But in any case, use of the uint/sint types is still preferred - I note that object.h defines nrof as a uint32. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Aug 16 03:02:52 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:56 2005 Subject: [CF-Devel] Handbook & spoilers guide Message-ID: <41206A2C.2010502@laposte.net> Hello. Website isn't uptodate on a few things, so Leaf & I are wondering how to update it. It seems the 'doc' folder contains scripts to extract much information from the archetypes & such files, but they seem quite old. Has anyone tried'em lately? If they don't work, anyone feeling like updating'em? ^_- (note that they probably work under Windows so i could try & fix'em myself, but before i reinvent the wheel, who knows, maybe someone tested'em already :) Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Aug 16 11:06:23 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:56 2005 Subject: [CF-Devel] New spell proposal: cold meteor swarm In-Reply-To: <41203C60.6020404@sonic.net> References: <411E2713.5070407@laposte.net> <41203C60.6020404@sonic.net> Message-ID: <4120DB7F.8000907@sympatico.ca> >> Evocation doesn't have (as far as i know) powerful spells. >> So i'm wondering about doing a cold version of comet & meteor swarm. >> Pretty easy to do, everything is already in place. >> I'd just add 'slow' attacktype to cold, though, since bad cold should >> slow players ;p >> >> What do you think of that? > It is easy to make alternate versions of spells by changing the attacktype but we should try to make these balance 'fixes' a but more interesting - how would a high level evoker dish out a bunch of cold damage for example? Compare that to how a high level summoner would do the same. Points are awarded for overall coolness of the method(pun intended). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Aug 16 13:26:30 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:56 2005 Subject: [CF-Devel] New spell proposal: cold meteor swarm In-Reply-To: <4120DB7F.8000907@sympatico.ca> Message-ID: On 16-Aug-2004 todd mitchell wrote: > how would a high level evoker dish out a bunch of cold > damage for example? Avalanche! Comet? --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Aug 16 14:15:23 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:56 2005 Subject: [CF-Devel] Fix for diseases on tiled maps crashing the server Message-ID: <20040816191522.GA30130@idefix2.dvlp.in-medias-res.com> The attached patches fixes a bug with diseases cast on tiled maps. (This bug did crash the server on metalforge some days ago.) Basically, the bug is that the loop variables (x and y) in check_infection() are modified by get_map_flags(), resulting in an infinite loop. My fix uses some temp variables for the result values, leaving the loop variables unchanged. I checked all other calls of get_map_flags() for similar problems. (I did not actually tested these other fixes.) But I have some concerns with the change to magic_wall() in server/spell_effect.c: it does not feel right to me that the existing code used the leftover value from the previous loop for "m". Therefore I added "m=tmp->map" because "x" and "y" use the coordinates from "tmp" as well. -------------- next part -------------- Index: server/disease.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/disease.c,v retrieving revision 1.27 diff -w -c -5 -r1.27 disease.c *** server/disease.c 13 Sep 2003 05:02:09 -0000 1.27 --- server/disease.c 16 Aug 2004 19:00:45 -0000 *************** *** 230,242 **** } /* searches around for more victims to infect */ int check_infection(object *disease) { int x,y,range, mflags; ! mapstruct *map; object *tmp; ! sint16 i,j; range = abs(disease->magic); if(disease->env) { x = disease->env->x; y = disease->env->y; --- 230,242 ---- } /* searches around for more victims to infect */ int check_infection(object *disease) { int x,y,range, mflags; ! mapstruct *map, *map2; object *tmp; ! sint16 i, j, i2, j2; range = abs(disease->magic); if(disease->env) { x = disease->env->x; y = disease->env->y; *************** *** 249,261 **** } if(map == NULL) return 0; for(i=x-range;iabove) { infect_object(tmp,disease,0); } } } } --- 249,261 ---- } if(map == NULL) return 0; for(i=x-range;iabove) { infect_object(tmp,disease,0); } } } } Index: server/move.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/move.c,v retrieving revision 1.32 diff -w -c -5 -r1.32 move.c *** server/move.c 16 Apr 2004 06:23:43 -0000 1.32 --- server/move.c 16 Aug 2004 19:00:45 -0000 *************** *** 289,312 **** int try_fit (object *op, mapstruct *m, int x, int y) { object *tmp, *more; sint16 tx, ty; int mflags; if (op->head) op = op->head; for (more = op; more ; more = more->more) { tx = x + more->x - op->x; ty = y + more->y - op->y; ! mflags = get_map_flags(m, &m, tx, ty, &tx, &ty); if (mflags & P_OUT_OF_MAP) return 1; ! for (tmp = get_map_ob (m, tx, ty); tmp; tmp=tmp->above) { if (tmp->head == op || tmp == op) continue; if ((QUERY_FLAG(tmp,FLAG_ALIVE) && tmp->type!=DOOR)) return 1; --- 289,313 ---- int try_fit (object *op, mapstruct *m, int x, int y) { object *tmp, *more; sint16 tx, ty; int mflags; + mapstruct *m2; if (op->head) op = op->head; for (more = op; more ; more = more->more) { tx = x + more->x - op->x; ty = y + more->y - op->y; ! mflags = get_map_flags(m, &m2, tx, ty, &tx, &ty); if (mflags & P_OUT_OF_MAP) return 1; ! for (tmp = get_map_ob (m2, tx, ty); tmp; tmp=tmp->above) { if (tmp->head == op || tmp == op) continue; if ((QUERY_FLAG(tmp,FLAG_ALIVE) && tmp->type!=DOOR)) return 1; Index: server/spell_effect.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/spell_effect.c,v retrieving revision 1.121 diff -w -c -5 -r1.121 spell_effect.c *** server/spell_effect.c 16 Jun 2004 07:09:45 -0000 1.121 --- server/spell_effect.c 16 Aug 2004 19:00:45 -0000 *************** *** 1178,1187 **** --- 1178,1188 ---- dir2 = (dir<4)?(dir+2):dir-2; x = tmp->x+i*freearr_x[dir2]; y = tmp->y+i*freearr_y[dir2]; + m = tmp->map; if(!(get_map_flags(m, &m, x, y, &x, &y) & (P_OUT_OF_MAP | P_BLOCKED)) && !posblocked) { tmp2 = get_object(); copy_object(tmp,tmp2); tmp2->x = x; -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Aug 17 14:15:24 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:56 2005 Subject: [CF-Devel] Music and integrated control panels Message-ID: <4122594C.4030801@telemuse.net> Greetings, developers. I have been observing the activity, and I think it is appropriate voice some of my ideas. I think CrossFire should have some sort of background music, kinda like how Diablo II has. Really, Crossfire needs some "adventurous" or some type of music to immerse the user fully into the game. A look at the extremely successful Blizzard games, they all immerse you fully into the "world" of the game. If Someone created some sort of music that "fits" in with CF, wouldn't that be more appealing to existing and potential players? Another matter I'd like to bring to light is a question of: why is the UI so garbled? I find it very unappealing, only the fun of the game outweighs it. Perhaps developement can start for a "skinnable" or an intergrated gui? Although most of the developement focuses on extending actual gameplay, I think many would agree if the client's GUI's were rethought out. Ben _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Aug 18 02:16:16 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:56 2005 Subject: [CF-Devel] Fix for diseases on tiled maps crashing the server In-Reply-To: <20040816191522.GA30130@idefix2.dvlp.in-medias-res.com> References: <20040816191522.GA30130@idefix2.dvlp.in-medias-res.com> Message-ID: <41230240.90107@sonic.net> Andreas Kirschbaum wrote: > The attached patches fixes a bug with diseases cast on tiled maps. (This > bug did crash the server on metalforge some days ago.) > > Basically, the bug is that the loop variables (x and y) in > check_infection() are modified by get_map_flags(), resulting in an > infinite loop. My fix uses some temp variables for the result values, > leaving the loop variables unchanged. That looks good. > > I checked all other calls of get_map_flags() for similar problems. (I > did not actually tested these other fixes.) Looks like other ones could have similar problems. > > But I have some concerns with the change to magic_wall() in > server/spell_effect.c: it does not feel right to me that the existing > code used the leftover value from the previous loop for "m". Therefore I > added "m=tmp->map" because "x" and "y" use the coordinates from "tmp" as > well. Yes - I think that fix is valid also. I'm not sure how often a problem would show up - you'd have to cast the spell near the seam of one of the tiled maps, and without the map being set right, what would probably happen is a wall showing up someplace odd, but probably far enough from the player they wouldn't immediately see it. At least in that case, it is unlikely to actually cause a crash/infinite loop. So it looks fine to apply the patch. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Aug 18 02:22:42 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:56 2005 Subject: [CF-Devel] Handbook & spoilers guide In-Reply-To: <41206A2C.2010502@laposte.net> References: <41206A2C.2010502@laposte.net> Message-ID: <412303C2.8090903@sonic.net> Nicolas Weeger wrote: > Hello. > > Website isn't uptodate on a few things, so Leaf & I are wondering how to > update it. > It seems the 'doc' folder contains scripts to extract much information > from the archetypes & such files, but they seem quite old. > Has anyone tried'em lately? Yep - tried the html spoiler and playbook just now, seem to work fine. I remember I did some work on them not too long back to make sure they still work. I think the postscript ones are perhaps less well supported. Is there anything in particular that is otherwise missing? I believe it is only the spoiler and playbook which are generated automatically - everything else is just a basic text file. Note that you require all the right bits to make the documents - for the html ones, I think it is only really the netpbm package. For the postscript ones, you need latex, but it's more a pain because you have to update a global tex configuration file someplace to increase the memory limit (or maybe they changed it so that you can pass in a value now - can't remember). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Aug 18 02:32:26 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:56 2005 Subject: [CF-Devel] clean code? In-Reply-To: <200408071328.07355.d.delbecq@laposte.net> References: <200408071224.25805.tchize@myrealbox.com> <4114B291.6050102@laposte.net> <200408071328.07355.d.delbecq@laposte.net> Message-ID: <4123060A.5010105@sonic.net> David Delbecq wrote: > mm cleanup weird stuff? like using carefully a snprintf and 2 lines later > using strcat? Well am already cleaning (and it take a huge amount of time) > string manipulation in server code (to prevent buffer overflows :) ) > > Le samedi 07 Ao?t 2004 12:44, Nicolas Weeger a ?crit : > tchize a ?crit : > >>>Wandering in the code today, i was wondering. Am i the only one to feel >>>ashamed by those 'goto' in the code? When i learned programming 12 years >>>ago, i was learned never to use them because you endup with spaghetti >>>programs. > > > Well, somehow function calls & such are really gotos.... > But yes, if we could avoid'em, i too think that'd be better. > Though maybe we could first clean the code of other weird stuff, fix > broken things, and so on :) Well, taking a quick look at the code, it seems a lot are in the apply() function, and taking a quick look, I can't see any reason those can't be breaks. Of course, that basically is the same thing as a goto. Some number of goto's are in computer generated code (Eg, the stuff from the .l files) so that's not a big deal. But I see a good number in other places. It'd be nice to clean those up, but probably not as big a deal - they make the code a little mess, but probably don't make it more reliable. There is a memory corruption leak out there someplace. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Aug 18 02:36:10 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:57 2005 Subject: =?ISO-8859-1?Q?Re=3A_=5BCF-Devel=5D_Posted_here_because_?= =?ISO-8859-1?Q?SF_lists_block_me_=28Mla=EF20maps_release?= In-Reply-To: <41110BB6.1050605@sympatico.ca> References: <41100288.1000008@sonic.net> <41110BB6.1050605@sympatico.ca> Message-ID: <412306EA.5080303@sonic.net> todd mitchell wrote: > > Currently the mlab maps in question are in /scorn/mlab if they are to be > moved out of the Scorn folder it should be either to their own city > folder or to the quest folder. Now I would say that if the city in the > clouds is called 'mlab' then /mlab would be reasonable but /cloudcity or > some such would be better if mlab is merely a personal tag. If they are > a quest then /quests/mlab would be reasonable - just as mlab was > reasonable (if not entirely desirable) if they were in Scorn. Using > meaningful area names whenever possibe is something that I am more and > more in support of the more maps I work on. I am sure the DMs would agree. Yep - I'll agree on that. > Again I don't mind meeting halfway on these things but I really think > there were improvements made to the map layout with the bigworld maps > that make it easier to locate things (from inside the game as well as in > the editor) which we should try to stick with or even improve upon. I > also think that with a bit of coordination the maps are better than if > each area is a little self contained system. True - basically right now you find out a bunch of stuff about scorn in scorn, a bunch of stuff in navar city in navar city, etc. So you basically do one city, find out a bunch of info about that, then go to the next city, etc. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu Aug 19 02:19:58 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:57 2005 Subject: [CF-Devel] Alchemy exploit In-Reply-To: <4120408B.1040506@sonic.net> References: <20040813184107.GA3015@idefix2.dvlp.in-medias-res.com> <4120408B.1040506@sonic.net> Message-ID: <20040819071958.GA19908@idefix2.dvlp.in-medias-res.com> > 1) It seems there is a debug new_draw_info_format left in that prints the > results of value of the item - presumably that needs to be removed. Yes, I missed that one. > 2) The block: [...] > I'm not sure if it will actually compile of ALCHEMY_DEBUG is not defined, > as there is then just an empty if () else statement. This can pretty easily > be solved by just putting {} in the right places, as an empty block should > be OK. Wonder if it might also be good to put some message as to why it > failed. I fixed that and included the old and new prices in the debug message. > 3) use of any 'long' or 'unsigned long' variables is discouraged, as past > experience has shown that there is no guarantee if these will be 64 or 32 > bit values. Instead use the uint32 or uint64 types, depending on what you > need (maybe this has been clarified in more recent versions of the C > standard). But in any case, use of the uint/sint types is still preferred - > I note that object.h defines nrof as a uint32. I changed the variables to uint32 type. But now I need a type cast in the call to LOG(): LOG(..., "...%lu...", (unsigned long)value_item, ...) because "%lu" wants an unsigned long. Unfortunately, I found another problem with my patch: after doing alchemy, the resulting item is not identified and (always?) cursed. Therefore query_cost() returns a value much less than a player would actually get for that item. So I need a means to pretend the item to be identified and not be cursed to calculate the price for it. I could imagine two alternatives for doing that: a) temporarily change the item flags, call query_cost() and restore the flags. b) add a new flag F_SELL_IDENTIFIED to query_cost() and modify the price calculations accordingly. My preference would be second alternative because temporarily modifying objects does not make the code easier to understand. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Aug 20 01:16:43 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:57 2005 Subject: [CF-Devel] Alchemy exploit In-Reply-To: <20040819071958.GA19908@idefix2.dvlp.in-medias-res.com> References: <20040813184107.GA3015@idefix2.dvlp.in-medias-res.com> <4120408B.1040506@sonic.net> <20040819071958.GA19908@idefix2.dvlp.in-medias-res.com> Message-ID: <4125974B.6020409@sonic.net> Andreas Kirschbaum wrote: > >>3) use of any 'long' or 'unsigned long' variables is discouraged, as past >>experience has shown that there is no guarantee if these will be 64 or 32 >>bit values. Instead use the uint32 or uint64 types, depending on what you >>need (maybe this has been clarified in more recent versions of the C >>standard). But in any case, use of the uint/sint types is still preferred - >>I note that object.h defines nrof as a uint32. > > > I changed the variables to uint32 type. But now I need a type cast in > the call to LOG(): LOG(..., "...%lu...", (unsigned long)value_item, ...) > because "%lu" wants an unsigned long. That's sort of an odd approach to take. I'd think the easier fix is to just use the right format (%d) instead of doing casts. > > > Unfortunately, I found another problem with my patch: after doing > alchemy, the resulting item is not identified and (always?) cursed. > Therefore query_cost() returns a value much less than a player would > actually get for that item. > > So I need a means to pretend the item to be identified and not be cursed > to calculate the price for it. I could imagine two alternatives for > doing that: > > a) temporarily change the item flags, call query_cost() and restore the > flags. > > b) add a new flag F_SELL_IDENTIFIED to query_cost() and modify the price > calculations accordingly. > > My preference would be second alternative because temporarily modifying > objects does not make the code easier to understand. Actually, something like an F_IDENTIFIED that is another flag that can be orred with the other ones makes more sense, like the F_NO_BARGAIN is. Thus you could do something like query_cost(..., F_BUY | F_IDENTIFIED) or the like, so that two different parameters don't need to be defined for the behaviour. However, I do recall that other places in the code do play around with the FLAG_IDENTIFIED value - perhaps a little confusing, but presuming it is adequately commented, not so much so. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Aug 21 01:55:20 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:57 2005 Subject: [CF-Devel] Music and integrated control panels In-Reply-To: <4122594C.4030801@telemuse.net> References: <4122594C.4030801@telemuse.net> Message-ID: <4126F1D8.1040308@laposte.net> > Greetings, developers. > I have been observing the activity, and I think it is appropriate voice > some of my ideas. Hello. > I think CrossFire should have some sort of background music, kinda like You'll notice there is currently almost no sound, either. It needs to be kind of rewritten - started to, didn't yet finish... > Another matter I'd like to bring to light is a question of: why is the Gros & Tchize have been working on a SDL client, but not sure of its status right now. And yes, some people just don't like GTK client ;p > Ben Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Aug 22 11:01:00 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:57 2005 Subject: [CF-Devel] Alchemy exploit In-Reply-To: <4125974B.6020409@sonic.net> References: <20040813184107.GA3015@idefix2.dvlp.in-medias-res.com> <4120408B.1040506@sonic.net> <20040819071958.GA19908@idefix2.dvlp.in-medias-res.com> <4125974B.6020409@sonic.net> Message-ID: <20040822160100.GA32120@idefix2.dvlp.in-medias-res.com> Mark Wedel wrote: > That's sort of an odd approach to take. I'd think the easier fix is to > just use the right format (%d) instead of doing casts. OK, I will do that. (But I noticed that the assumption in global.h that an "unsigned int" (uint32) can hold at least 32 bits is not valid according to the C standard.) > Actually, something like an F_IDENTIFIED that is another flag that can > be orred with the other ones makes more sense, like the F_NO_BARGAIN > is. Because I could not invent a flag name for "identified and not cursed", I simply defined two independent flags: F_IDENTIFIED (pretend FLAG_IDENTIFIED to be set) and F_NOT_CURSED (pretend FLAG_CURSED and FLAG_DAMNED to be unset). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Aug 24 01:46:24 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:58 2005 Subject: [CF-Devel] Alchemy exploit In-Reply-To: <20040822160100.GA32120@idefix2.dvlp.in-medias-res.com> References: <20040813184107.GA3015@idefix2.dvlp.in-medias-res.com> <4120408B.1040506@sonic.net> <20040819071958.GA19908@idefix2.dvlp.in-medias-res.com> <4125974B.6020409@sonic.net> <20040822160100.GA32120@idefix2.dvlp.in-medias-res.com> Message-ID: <412AE440.2010700@sonic.net> Andreas Kirschbaum wrote: > Mark Wedel wrote: > >>That's sort of an odd approach to take. I'd think the easier fix is to >>just use the right format (%d) instead of doing casts. > > > OK, I will do that. (But I noticed that the assumption in global.h that > an "unsigned int" (uint32) can hold at least 32 bits is not valid > according to the C standard.) True - but the main point being that if different systems/OS's/whatever require different typedefs, that could be coded in and only one place needs to be updated - this is certainly much better than having 'unsigned ints' or whatever sprinkled all through the code. > > > >>Actually, something like an F_IDENTIFIED that is another flag that can >>be orred with the other ones makes more sense, like the F_NO_BARGAIN >>is. > > > Because I could not invent a flag name for "identified and not cursed", > I simply defined two independent flags: F_IDENTIFIED (pretend > FLAG_IDENTIFIED to be set) and F_NOT_CURSED (pretend FLAG_CURSED and > FLAG_DAMNED to be unset). Well, that is fine - multiple flags is easier/better than having a flag like (FLAG_WANT_TO_SELL) which means many things, because you could get a case where someone wants the second case you mention and not the first, or vice versa, etc. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Aug 24 14:30:09 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:58 2005 Subject: [CF-Devel] Music and integrated control panels In-Reply-To: <4122594C.4030801@telemuse.net> References: <4122594C.4030801@telemuse.net> Message-ID: <200408242130.26823.david.Delbecq@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le mardi 17 Ao?t 2004 21:15, Ben Jolitz a ?crit : >Greetings, developers. >I have been observing the activity, and I think it is appropriate voice >some of my ideas. constructive ideas are always a good thing, but there are regulary lots of ideas and not so much time to implement them ;) >I think CrossFire should have some sort of background music, kinda like >how Diablo II has. Really, Crossfire needs some "adventurous" or some type >of music to immerse the user fully into the game. A look at the >extremely successful >Blizzard games, they all immerse you fully into the "world" of the game. >If Someone created >some sort of music that "fits" in with CF, wouldn't that be more >appealing to existing and >potential players? Code for music isn't that difficult (yes a bit anyway, or Ryo won't have enough challenge on it ;) Like always in crossfire, the most difficult par is having artists at hand. There are quite a few drawers sharing their talents to this game, but as far as i know, we have no music artist to build a nice background music and give this music free under GPL. >Another matter I'd like to bring to light is a question of: why is the >UI so garbled? I find it >very unappealing, only the fun of the game outweighs it. Perhaps >developement can start >for a "skinnable" or an intergrated gui? Although most of the >developement focuses on extending >actual gameplay, I think many would agree if the client's GUI's were >rethought out. This idea is in the air since more than a year, however, building such client and getting in mind some player still use outdated slow computer is not easy and brings some challenges to gros. Beta client, first build on sdl lib now is in process of convertion to opengl rendering, so it will use the acceleration of now cheap 3D video cards. By cheap i mean in the range of a riva TNT2 or such, now a few years old. No need for a Geforce 15 Ultra GX FX with per atom subaquatic rendering able to do 25000x16000 pixels at 50 tera texels per second and needing 2 coolers the size of an airbus engine. No basically, the Opengl will be used for alpha rendering, texture streching and perhaps some basic effects. I know gros has still some issue with png loading before the commit of initial release (Well technically, a code *always* has issue), but he could tell better then me (if you are not in a hurry). Last but not least, this client has been though with skinnability in mind since the early beginning. It will be commited with 1024x768 basic skin. You can get some pictures of the skin here: http://users.skynet.be/tchize/crossfire/skin/interface_full.png http://users.skynet.be/tchize/crossfire/skin/chat_preview.png please note it will even include a potion belt ;) >Ben _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel - -- - -- David Delbecq david.delbecq@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBK5dKHHGOa1Q2wXwRArR7AKC+52yk/8vRKbY+0QxaDVCjS6VVrACgjF0a 4n2SSgZClY5n0TpoujRqvOk= =0uDO -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Aug 24 15:12:46 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:58 2005 Subject: [CF-Devel] Alchemy exploit In-Reply-To: <412AE440.2010700@sonic.net> References: <20040813184107.GA3015@idefix2.dvlp.in-medias-res.com> <4120408B.1040506@sonic.net> <20040819071958.GA19908@idefix2.dvlp.in-medias-res.com> <4125974B.6020409@sonic.net> <20040822160100.GA32120@idefix2.dvlp.in-medias-res.com> <412AE440.2010700@sonic.net> Message-ID: <20040824201246.GA11007@idefix2.dvlp.in-medias-res.com> Committed to CVS. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Aug 25 11:53:41 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:58 2005 Subject: [CF-Devel] Music and integrated control panels In-Reply-To: <200408242130.26823.david.Delbecq@myrealbox.com> References: <4122594C.4030801@telemuse.net> <200408242130.26823.david.Delbecq@myrealbox.com> Message-ID: <200408251853.49143.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Damn! Once again i messed my mail accounts to post the reply :p Sorry for additinal work moderator :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBLMQaHHGOa1Q2wXwRAplQAKCYW+RzRyyRVSfb0ctG0zSS1KdolQCff2db Ep9NYu18vWix/F6YHC57rhE= =5pka -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Aug 25 13:03:06 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:58 2005 Subject: [CF-Devel] Improvements to 'tell' and 'reply' commands Message-ID: <20040825180306.GA12970@idefix2.dvlp.in-medias-res.com> Here are two small improvements to the commands 'tell' and 'reply': The patch tell.diff enables you to talk to players with ambiguous names: Currently you can't talk to (for example) 'abc' if both 'abc' and 'abcII' are currently logged in. This patch prefers exact matches over prefix/case-folded matches. The patch reply.diff allows you to reply to players that logged out but did not yet drop the connection. (The current situation is somewhat inconsistent: 'talk' does work but 'reply' does not work.) -------------- next part -------------- Index: server/player.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/player.c,v retrieving revision 1.151 diff -w -c -5 -r1.151 player.c *** server/player.c 13 Jun 2004 17:30:38 -0000 1.151 --- server/player.c 25 Aug 2004 17:47:53 -0000 *************** *** 59,68 **** --- 59,71 ---- for ( pl = first_player; pl != NULL; pl = pl->next ) { if ( strlen( pl->ob->name ) < namelen ) continue; + if ( !strcmp( pl->ob->name, plname) ) + return pl; + if ( !strncasecmp( pl->ob->name, plname, namelen ) ) { if ( found ) return NULL; -------------- next part -------------- Index: server/player.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/player.c,v retrieving revision 1.151 diff -w -c -5 -r1.151 player.c *** server/player.c 13 Jun 2004 17:30:38 -0000 1.151 --- server/player.c 25 Aug 2004 17:47:53 -0000 *************** *** 43,53 **** player *find_player(char *plname) { player *pl; for(pl=first_player;pl!=NULL;pl=pl->next) { ! if(pl->ob != NULL && !QUERY_FLAG(pl->ob,FLAG_REMOVED) && !strcmp(query_name(pl->ob),plname)) return pl; }; return NULL; } --- 43,53 ---- player *find_player(char *plname) { player *pl; for(pl=first_player;pl!=NULL;pl=pl->next) { ! if(pl->ob != NULL && !strcmp(query_name(pl->ob),plname)) return pl; }; return NULL; } -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Aug 27 17:23:17 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:58 2005 Subject: [CF-Devel] Windows regular snapshot releases Message-ID: <412FB455.9060003@laposte.net> Hello. Unless someone objects really loudly & with good arguments, I plan on doing regular Windows client/server releases :) Named snapshot-, or something like that. The rationale is that, under Windows, it's harder to compile than other platforms like linux - need the tools, and such, and not everyone knows how to do it (it's harder'an 'cvs update && make clean && make && make install ;p gtk for one is a real pain) And of course it isn't nice to wait some months between official releases... Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Aug 28 15:30:16 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:58 2005 Subject: [CF-Devel] Scroll issues Message-ID: <4130EB58.7010706@laposte.net> Hello. I've been playing with inscription, and there are a few bugs with scrolls use ;) If you write a scroll of glyph/pentagram, you can't use it, when applying you get a 'write what spell?' Dimension door scrolls are useless too, it'll say 'in which direction?' and not move you. I'd guess it's related to player's orientation not being used when applying scrolls. Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Aug 29 13:29:42 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:59 2005 Subject: [CF-Devel] Traps not working reliable Message-ID: <20040829182942.GA23666@idefix2.dvlp.in-medias-res.com> I noticed that some traps (in chests and doors) do not work reliable anymore. Sometimes you set off a trap, but nothing happens. My investigations resulted in: - There is a bug in trap_adjust() in server/rune.c. The code basically does "level = MAX(1, rndm(...))" to ensure "level >= 1". This does not work because MAX() is a macro and evaluates its arguments multiple times. The result may be a trap (RUNE) with level zero: a rune that does not detonate. - It seem me that there are three ways to puts spells into runes: 1) put an item (spell) into inventory 2) use spell name in 'slaying' field 3) use archetype name in 'other_arch' field For traps, 1) can't be used because inventory items can't be used in archetypes. 2) The 'slaying' field (or the obsolete spell number in the 'sp' field) is converted to an inventory item by check_loaded_object() in loader.l. However, this conversion is not done by create_all_treasures()/create_one_treasure() in treasure.c. spring_trap() in server/rune.c does not use the 'slaying' field, only inventory items or the 'other_arch' field. Therefore runes using the slaying field do not work when created by a treasure list. 3) The other_arch field does work. But I'm not sure if that is the preferred way: doc/Developers/runes, server/rune.c, and CFJavaEditor specify to use the 'slaying' field but do not mention the 'other_arch' field. After fixing the bug in rune.c and changing most runes in the archetypes file according to 3), I got all kinds of traps working again. I summarized some attributes of the runes in runes-old.txt/runes-new.txt, because the diff of the archetypes file is not very clear. Besides that, I re-enabled the 'maxhp' field for runes to cast more than one spell. Now it works for all types of spells, not just for summoning spells. -------------- next part -------------- Index: lib/archetypes =================================================================== RCS file: /cvsroot/crossfire/crossfire/lib/archetypes,v retrieving revision 1.151 diff -c -5 -r1.151 archetypes *** lib/archetypes 11 Jun 2004 06:21:42 -0000 1.151 --- lib/archetypes 29 Aug 2004 18:16:42 -0000 *************** *** 35496,35506 **** range_modifier 4 maxsp 9 type 101 subtype 7 value 10 - attacktype 4 no_drop 1 invisible 1 editor_folder arch/spell/Ability end Object abil_fear --- 35496,35505 ---- *************** *** 41563,41573 **** end Object rune_drain_magic name Rune of Magic Draining type 154 speed 1 - slaying magic drain hp 1 face drain_magic.111 msg You feel depleted of psychic energy! endmsg --- 41562,41571 ---- *************** *** 41576,41586 **** is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 - attacktype 18 Cha 20 other_arch spell_magic_drain editor_folder arch/spell/Rune end Object generic_rune --- 41574,41583 ---- *************** *** 41640,41650 **** end Object rune_ball_lightning name Rune of Ball Lightning type 154 face rune_blightning.111 ! slaying ball lightning hp 1 speed 1 msg You detonate a Rune of Ball Lightning endmsg --- 41637,41647 ---- end Object rune_ball_lightning name Rune of Ball Lightning type 154 face rune_blightning.111 ! other_arch spell_ball_lightning hp 1 speed 1 msg You detonate a Rune of Ball Lightning endmsg *************** *** 41662,41672 **** end Object rune_create_bomb name Rune of Create Bomb type 154 face rune_bomb.111 ! slaying create bomb speed 1 hp 1 msg RUN! The timer's ticking! endmsg --- 41659,41669 ---- end Object rune_create_bomb name Rune of Create Bomb type 154 face rune_bomb.111 ! other_arch spell_create_bomb speed 1 hp 1 msg RUN! The timer's ticking! endmsg *************** *** 41675,41692 **** is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 ! attacktype 3 dam 90 Cha 20 editor_folder arch/spell/Rune end Object rune_confusion name Rune of Confusion ! slaying mass confusion type 154 face rune_confusion.111 hp 2 msg You detonate a Rune of Mass Confusion! --- 41672,41689 ---- is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 ! attacktype 1 dam 90 Cha 20 editor_folder arch/spell/Rune end Object rune_confusion name Rune of Confusion ! other_arch spell_mass_confusion type 154 face rune_confusion.111 hp 2 msg You detonate a Rune of Mass Confusion! *************** *** 41697,41707 **** is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 - attacktype 6 Cha 20 editor_folder arch/spell/Rune end Object rune_death name Rune of Death --- 41694,41703 ---- *************** *** 41746,41756 **** editor_folder arch/spell/Rune end # Object rune_burning_hands name Rune of Burning Hands - slaying burning hands type 154 face rune_fire.111 hp 1 other_arch spell_burning_hands msg --- 41742,41751 ---- *************** *** 41762,41778 **** is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 - attacktype 6 Cha 20 editor_folder arch/spell/Rune end Object rune_dragonbreath name Rune of Dragon's Breath - slaying dragonbreath type 154 face rune_fire.111 hp 1 other_arch spell_dragonbreath msg --- 41757,41771 ---- *************** *** 41784,41803 **** is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 - attacktype 6 Cha 20 editor_folder arch/spell/Rune end Object rune_medium_fireball name Rune of Fireball type 154 speed 1 hp 1 ! slaying medium fireball face rune_fireball.111 msg You set off a fireball! endmsg animation rune_medium_fireball --- 41777,41795 ---- is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 Cha 20 editor_folder arch/spell/Rune end Object rune_medium_fireball name Rune of Fireball type 154 speed 1 hp 1 ! other_arch spell_medium_fireball face rune_fireball.111 msg You set off a fireball! endmsg animation rune_medium_fireball *************** *** 41805,41826 **** is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 ! attacktype 18 dam 90 Cha 20 - maxhp 5 editor_folder arch/spell/Rune end Object rune_large_fireball name Rune of Fireball type 154 speed 1 hp 1 ! slaying large fireball face rune_fireball.111 msg You set off a large fireball! endmsg animation rune_large_fireball --- 41797,41817 ---- is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 ! attacktype 6 dam 90 Cha 20 editor_folder arch/spell/Rune end Object rune_large_fireball name Rune of Fireball type 154 speed 1 hp 1 ! other_arch spell_large_fireball face rune_fireball.111 msg You set off a large fireball! endmsg animation rune_large_fireball *************** *** 41828,41841 **** is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 ! attacktype 18 dam 90 Cha 20 - maxhp 5 editor_folder arch/spell/Rune end Object rune_frost name Rune of Frost type 154 --- 41819,41831 ---- is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 ! attacktype 6 dam 90 Cha 20 editor_folder arch/spell/Rune end Object rune_frost name Rune of Frost type 154 *************** *** 41857,41867 **** Cha 20 editor_folder arch/spell/Rune end Object rune_icestorm name Rune of Icestorm - slaying icestorm type 154 face rune_frost.111 hp 1 other_arch spell_icestorm speed 1 --- 41847,41856 ---- *************** *** 41873,41889 **** is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 - attacktype 18 Cha 20 editor_folder arch/spell/Rune end Object rune_large_icestorm name Rune of Large Icestorm - slaying large icestorm type 154 face rune_frost.111 hp 1 other_arch spell_large_icestorm speed 1 --- 41862,41876 ---- *************** *** 41895,41914 **** is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 - attacktype 18 Cha 20 editor_folder arch/spell/Rune end Object rune_heal name Rune of Heal speed 1 type 154 face rune_heal.111 ! slaying heal hp 1 msg You set off a Rune of Heal endmsg animation rune_heal --- 41882,41900 ---- is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 Cha 20 editor_folder arch/spell/Rune end Object rune_heal name Rune of Heal speed 1 type 154 face rune_heal.111 ! other_arch spell_heal hp 1 msg You set off a Rune of Heal endmsg animation rune_heal *************** *** 41916,41935 **** is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 - attacktype 1 Cha 1 editor_folder arch/spell/Rune end Object rune_small_lightning name Rune of Lightning type 154 speed 1 hp 2 ! slaying small lightning face rune_lightning.111 msg You set off a bolt of lightning! endmsg animation rune_small_lightning --- 41902,41920 ---- is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 Cha 1 editor_folder arch/spell/Rune end Object rune_small_lightning name Rune of Lightning type 154 speed 1 hp 2 ! other_arch spell_sm_lightning face rune_lightning.111 msg You set off a bolt of lightning! endmsg animation rune_small_lightning *************** *** 41937,41955 **** is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 ! attacktype 18 dam 90 Cha 20 - maxhp 5 editor_folder arch/spell/Rune end Object rune_paralysis name Rune of Paralysis ! slaying paralyze type 154 face rune_paralysis.111 hp 4 msg You detonate a Rune of Paralysis! --- 41922,41939 ---- is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 ! attacktype 10 dam 90 Cha 20 editor_folder arch/spell/Rune end Object rune_paralysis name Rune of Paralysis ! other_arch spell_paralyze type 154 face rune_paralysis.111 hp 4 msg You detonate a Rune of Paralysis! *************** *** 41960,41976 **** is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 - attacktype 6 Cha 20 editor_folder arch/spell/Rune end Object rune_poison_cloud name Rune of Poison Cloud ! slaying poison cloud type 154 face rune_pcloud.111 hp 1 msg You detonate a Rune of Poison Cloud! --- 41944,41959 ---- is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 Cha 20 editor_folder arch/spell/Rune end Object rune_poison_cloud name Rune of Poison Cloud ! other_arch spell_poison_cloud type 154 face rune_pcloud.111 hp 1 msg You detonate a Rune of Poison Cloud! *************** *** 41981,42000 **** is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 - attacktype 6 Cha 20 editor_folder arch/spell/Rune end Object rune_restoration name Rune of Restoration speed 1 type 154 face rune_heal.111 ! slaying restoration hp 1 msg You set off a Rune of Restoration endmsg animation rune_restoration --- 41964,41982 ---- is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 Cha 20 editor_folder arch/spell/Rune end Object rune_restoration name Rune of Restoration speed 1 type 154 face rune_heal.111 ! other_arch spell_restoration hp 1 msg You set off a Rune of Restoration endmsg animation rune_restoration *************** *** 42002,42012 **** is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 - attacktype 1 Cha 1 editor_folder arch/spell/Rune end Object rune_shock name Rune of Shocking --- 41984,41993 ---- *************** *** 42031,42041 **** end Object rune_regenerate_spellpoints name Rune of Magic Power type 154 speed 1 ! slaying regenerate spellpoints hp 1 face rune_sp_res.111 msg You feel powerful! endmsg --- 42012,42022 ---- end Object rune_regenerate_spellpoints name Rune of Magic Power type 154 speed 1 ! other_arch spell_regenerate_spellpoints hp 1 face rune_sp_res.111 msg You feel powerful! endmsg *************** *** 42044,42063 **** is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 - attacktype 18 editor_folder arch/spell/Rune end Object rune_summon_air_elemental name Rune of Summoning type 154 - race air_elemental speed 1 hp 1 ! slaying summon air elemental face rune_summon_air.111 msg A portal opens up, and screaming hordes pour through! endmsg animation rune_summon_air_elemental --- 42025,42042 ---- is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 editor_folder arch/spell/Rune end Object rune_summon_air_elemental name Rune of Summoning type 154 speed 1 hp 1 ! other_arch spell_summon_air_elemental face rune_summon_air.111 msg A portal opens up, and screaming hordes pour through! endmsg animation rune_summon_air_elemental *************** *** 42065,42088 **** is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 ! attacktype 18 dam 90 Cha 20 maxhp 5 editor_folder arch/spell/Rune end # Object rune_summon_devil name Rune of Summoning type 154 - race devil speed 1 hp 1 ! slaying summon devil face rune_summon.111 msg A portal opens up, and screaming hordes pour through! endmsg animation rune_summon_devil --- 42044,42066 ---- is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 ! attacktype 2 dam 90 Cha 20 maxhp 5 editor_folder arch/spell/Rune end # Object rune_summon_devil name Rune of Summoning type 154 speed 1 hp 1 ! other_arch spell_summon_devil face rune_summon.111 msg A portal opens up, and screaming hordes pour through! endmsg animation rune_summon_devil *************** *** 42090,42113 **** is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 ! attacktype 18 dam 90 Cha 20 maxhp 5 editor_folder arch/spell/Rune end # Object rune_summon_earth_elemental name Rune of Summoning type 154 - race earth_elemental speed 1 hp 1 ! slaying summon earth elemental face rune_sum_earth.111 msg A portal opens up, and screaming hordes pour through! endmsg animation rune_summon_earth_elemental --- 42068,42090 ---- is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 ! attacktype 2 dam 90 Cha 20 maxhp 5 editor_folder arch/spell/Rune end # Object rune_summon_earth_elemental name Rune of Summoning type 154 speed 1 hp 1 ! other_arch spell_summon_earth_elemental face rune_sum_earth.111 msg A portal opens up, and screaming hordes pour through! endmsg animation rune_summon_earth_elemental *************** *** 42115,42137 **** is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 ! attacktype 18 dam 90 Cha 20 maxhp 5 editor_folder arch/spell/Rune end Object rune_summon_fire_elemental name Rune of Summoning type 154 - race fire_elemental speed 1 hp 1 ! slaying summon fire elemental face rune_sum_fire.111 msg A portal opens up, and screaming hordes pour through! endmsg animation rune_summon_fire_elemental --- 42092,42113 ---- is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 ! attacktype 2 dam 90 Cha 20 maxhp 5 editor_folder arch/spell/Rune end Object rune_summon_fire_elemental name Rune of Summoning type 154 speed 1 hp 1 ! other_arch spell_summon_fire_elemental face rune_sum_fire.111 msg A portal opens up, and screaming hordes pour through! endmsg animation rune_summon_fire_elemental *************** *** 42139,42162 **** is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 ! attacktype 18 dam 90 Cha 20 maxhp 5 editor_folder arch/spell/Rune end # Object rune_summon_water_elemental name Rune of Summoning type 154 - race water_elemental speed 1 hp 1 ! slaying summon water elemental face rune_sum_water.111 msg A portal opens up, and screaming hordes pour through! endmsg animation rune_summon_water_elemental --- 42115,42137 ---- is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 ! attacktype 2 dam 90 Cha 20 maxhp 5 editor_folder arch/spell/Rune end # Object rune_summon_water_elemental name Rune of Summoning type 154 speed 1 hp 1 ! other_arch spell_summon_water_elemental face rune_sum_water.111 msg A portal opens up, and screaming hordes pour through! endmsg animation rune_summon_water_elemental *************** *** 42164,42174 **** is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 ! attacktype 18 dam 90 Cha 20 maxhp 5 editor_folder arch/spell/Rune end --- 42139,42149 ---- is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 ! attacktype 2 dam 90 Cha 20 maxhp 5 editor_folder arch/spell/Rune end *************** *** 42186,42196 **** is_animated 0 invisible 1 no_pick 1 walk_on 1 editable 32 - attacktype 18 other_arch spell_transference editor_folder arch/spell/Rune end Object runedet name trap --- 42161,42170 ---- Index: server/rune.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/rune.c,v retrieving revision 1.38 diff -c -5 -r1.38 rune.c *** server/rune.c 18 Jun 2004 07:45:29 -0000 1.38 --- server/rune.c 29 Aug 2004 18:16:42 -0000 *************** *** 266,282 **** --- 266,284 ---- trap->y=victim->y; insert_ob_in_map(trap,victim->map,trap,0); if (was_destroyed (trap, trap_tag)) return; + for(i = 0; i < MAX(1, trap->stats.maxhp); i++) { if (trap->inv) cast_spell(trap,trap,trap->direction,trap->inv,NULL); else { spell = arch_to_object(trap->other_arch); cast_spell(trap,trap,trap->direction,spell,NULL); free_object(spell); } + } } else { rune_attack(trap,victim); if (was_destroyed (trap, trap_tag)) return; } *************** *** 424,434 **** /* now we set the trap level to match the difficulty of the level * the formula below will give a level from 1 to (2*difficulty) with * a peak probability at difficulty */ ! trap->level = MAX(1, rndm(0, difficulty-1) + rndm(0, difficulty-1)); /* set the hiddenness of the trap, similar formula to above */ trap->stats.Cha = rndm(0, 19) + rndm(0, difficulty-1) + rndm(0, difficulty-1); if (!trap->other_arch && !trap->inv) { --- 426,438 ---- /* now we set the trap level to match the difficulty of the level * the formula below will give a level from 1 to (2*difficulty) with * a peak probability at difficulty */ ! trap->level = rndm(0, difficulty-1) + rndm(0, difficulty-1); ! if(trap->level < 1) ! trap->level = 1; /* set the hiddenness of the trap, similar formula to above */ trap->stats.Cha = rndm(0, 19) + rndm(0, difficulty-1) + rndm(0, difficulty-1); if (!trap->other_arch && !trap->inv) { *************** *** 440,451 **** trap->stats.dam = 0; for(i=0;istats.dam+=rndm(0, 4); /* the poison trap special case */ ! if(trap->attacktype & AT_POISON) ! trap->stats.dam = MAX(1, rndm(0, difficulty-1)); /* so we get an appropriate amnt of exp for AT_DEATH traps */ if(trap->attacktype & AT_DEATH) trap->stats.dam = 127; } --- 444,458 ---- trap->stats.dam = 0; for(i=0;istats.dam+=rndm(0, 4); /* the poison trap special case */ ! if(trap->attacktype & AT_POISON) { ! trap->stats.dam = rndm(0, difficulty-1); ! if(trap->stats.dam < 1) ! trap->stats.dam = 1; ! } /* so we get an appropriate amnt of exp for AT_DEATH traps */ if(trap->attacktype & AT_DEATH) trap->stats.dam = 127; } -------------- next part -------------- rune name dam attacktype slaying maxhp other_arch randomitems ====================================================================================================== Ball Lightning 1 magic elec ball lightning Blasting 90 phys magic Burning Hands 0 magic fire burning hands spell_burning_hands Confusion 0 magic fire mass confusion Create Bomb 90 phys magic create bomb Death 400 death diseased needle 10 phys needle_diseases Dragon's Breath 0 magic fire dragonbreath spell_dragonbreath Fire 30 magic fire Fireball 90 magic cold large fireball 5 Fireball 90 magic cold medium fireball 5 Frost 35 magic cold Heal 0 phys heal Icestorm 0 magic cold icestorm spell_icestorm Large Icestorm 0 magic cold large icestorm spell_large_icestorm Lightning 90 magic cold small lightning 5 Magic Draining 0 magic cold magic drain spell_magic_drain Magic Power 0 magic cold regenerate spellpoints Magical Rune 0 magic Nullification 1 magic cancellation Paralysis 0 magic fire paralyze Poison Cloud 0 magic fire poison cloud Restoration 0 phys restoration Shocking 40 magic elec Summoning 90 magic cold summon air elemental 5 Summoning 90 magic cold summon devil 5 Summoning 90 magic cold summon earth elemental 5 Summoning 90 magic cold summon fire elemental 5 Summoning 90 magic cold summon water elemental 5 Transferrence 0 magic cold spell_transference -------------- next part -------------- randomitems ====================================================================================================== Ball Lightning 1 magic elec spell_ball_lightning Blasting 90 phys magic Burning Hands 0 spell_burning_hands Confusion 0 spell_mass_confusion Create Bomb 90 phys spell_create_bomb Death 400 death diseased needle 10 phys needle_diseases Dragon's Breath 0 spell_dragonbreath Fire 30 magic fire Fireball 90 magic fire spell_large_fireball Fireball 90 magic fire spell_medium_fireball Frost 35 magic cold Heal 0 spell_heal Icestorm 0 spell_icestorm Large Icestorm 0 spell_large_icestorm Lightning 90 magic elec spell_sm_lightning Magic Draining 0 spell_magic_drain Magic Power 0 spell_regenerate_spellpoints Magical Rune 0 magic Nullification 1 magic cancellation Paralysis 0 spell_paralyze Poison Cloud 0 spell_poison_cloud Restoration 0 spell_restoration Shocking 40 magic elec Summoning 90 magic 5 spell_summon_air_elemental Summoning 90 magic 5 spell_summon_devil Summoning 90 magic 5 spell_summon_earth_elemental Summoning 90 magic 5 spell_summon_fire_elemental Summoning 90 magic 5 spell_summon_water_elemental Transferrence 0 spell_transference -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Aug 30 01:36:58 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:59 2005 Subject: [CF-Devel] Improvements to 'tell' and 'reply' commands In-Reply-To: <20040825180306.GA12970@idefix2.dvlp.in-medias-res.com> References: <20040825180306.GA12970@idefix2.dvlp.in-medias-res.com> Message-ID: <4132CB0A.8080301@sonic.net> Andreas Kirschbaum wrote: > Here are two small improvements to the commands 'tell' and 'reply': > > > The patch tell.diff enables you to talk to players with ambiguous names: > Currently you can't talk to (for example) 'abc' if both 'abc' and > 'abcII' are currently logged in. This patch prefers exact matches over > prefix/case-folded matches. > > > The patch reply.diff allows you to reply to players that logged out but > did not yet drop the connection. (The current situation is somewhat > inconsistent: 'talk' does work but 'reply' does not work.) I don't see any problem with the first one. I'd have to check the CVS logs, but there is probably a reason that there is an explict check for FLAG_REMOVED in the second case. My guess would be you could ge in odd situations with a logged out player, possibly resulting in crashes. In fact, I've seen a lot of crashes with logged out but still connected players. Really, all that logic should get cleaned up/removed (I think I mentioned before, but ideal situation would be for client to send both name and password as part of connection instead of having the the server have to handle those states, which I think there is an open bug against right now) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Aug 30 01:45:26 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:59 2005 Subject: [CF-Devel] Scroll issues In-Reply-To: <4130EB58.7010706@laposte.net> References: <4130EB58.7010706@laposte.net> Message-ID: <4132CD06.6090209@sonic.net> Nicolas Weeger wrote: > Hello. > > I've been playing with inscription, and there are a few bugs with > scrolls use ;) > > If you write a scroll of glyph/pentagram, you can't use it, when > applying you get a 'write what spell?' > > Dimension door scrolls are useless too, it'll say 'in which direction?' > and not move you. > > I'd guess it's related to player's orientation not being used when > applying scrolls. It's not a perfect world :) The issue really comes down that the code allows you to inscribe any spell you want, whether or not it makes sense. Some spells, like glyph or dimension door, would normally never appear on scrolls. In the days before the spell redo, it was the case that each spell had a flag saying where it appeared (spellbooks, scrolls, wands, etc). That is now handled by treasurelists, so it much more difficult to parse (you'd basically have to parse the treasurelists and see if it shows up, which is a little less trivial when treasure lists can jump to other treasurelists). I believe I sent out mail when coding this, asking peoples opinions (as well as the issue of special spells which only appear in quests), and seem to recall the answer was let the players inscribe them, if they inscribe spells they can't use, that is their problem. Certainly, dimension door could be fixed to look at the players current facing. But glyp/pentagram/magic rune/etc have no fix what so ever - you're just hosed if you put that in a scroll. > > Nicolas 'Ryo' > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Aug 30 01:39:12 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:59 2005 Subject: [CF-Devel] Windows regular snapshot releases In-Reply-To: <412FB455.9060003@laposte.net> References: <412FB455.9060003@laposte.net> Message-ID: <4132CB90.9040401@sonic.net> Nicolas Weeger wrote: > Hello. > > Unless someone objects really loudly & with good arguments, I plan on > doing regular Windows client/server releases :) > Named snapshot-, or something like that. > > The rationale is that, under Windows, it's harder to compile than other > platforms like linux - need the tools, and such, and not everyone knows > how to do it > (it's harder'an 'cvs update && make clean && make && make install ;p gtk > for one is a real pain) > > And of course it isn't nice to wait some months between official > releases... I see no problem with that. I agree that official releases should be done more often, but it seems to always take more time than I have available to do it (maybe it is more the issue that it just nevers seems like that high a priority issue to me. Not an excuse, but probably why I don't get around to making official releases as often as I should _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Aug 30 02:00:33 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:59 2005 Subject: [CF-Devel] Traps not working reliable In-Reply-To: <20040829182942.GA23666@idefix2.dvlp.in-medias-res.com> References: <20040829182942.GA23666@idefix2.dvlp.in-medias-res.com> Message-ID: <4132D091.9090302@sonic.net> Andreas Kirschbaum wrote: > I noticed that some traps (in chests and doors) do not work reliable > anymore. Sometimes you set off a trap, but nothing happens. > > My investigations resulted in: > > - There is a bug in trap_adjust() in server/rune.c. The code basically > does "level = MAX(1, rndm(...))" to ensure "level >= 1". > > This does not work because MAX() is a macro and evaluates its > arguments multiple times. The result may be a trap (RUNE) with level > zero: a rune that does not detonate. That seems bad. Taking a very quick look at the code (for all other uses of MAX), I'm a little concerned with random_roll() and die_roll() which is pasiing RANDOM() into MAX (actually, it passes it into MIN, which is inside a MAX construct). > > - It seem me that there are three ways to puts spells into runes: > > 1) put an item (spell) into inventory > > 2) use spell name in 'slaying' field > > 3) use archetype name in 'other_arch' field > > For traps, > > 1) can't be used because inventory items can't be used in archetypes. Yeah - that's been a problem. My solution to that is to create a one item treasurelist with the desired object. > > 2) The 'slaying' field (or the obsolete spell number in the 'sp' > field) is converted to an inventory item by check_loaded_object() > in loader.l. However, this conversion is not done by > create_all_treasures()/create_one_treasure() in treasure.c. > > spring_trap() in server/rune.c does not use the 'slaying' field, > only inventory items or the 'other_arch' field. > > Therefore runes using the slaying field do not work when created > by a treasure list. This is perhaps left over from the old code - probably no reason it has to be used. > > 3) The other_arch field does work. But I'm not sure if that is the > preferred way: doc/Developers/runes, server/rune.c, and > CFJavaEditor specify to use the 'slaying' field but do not mention > the 'other_arch' field. One difference is slaying is just a text field, where as other_arch has to point to another active archetype. Now in most all cases, I can't think of this being a problem (a new spell created on a map can't be put into a rune, because you can never be sure that object is available). other_arch is certainly faster to resolve, but probably no issue here. So I think using other_arch works out good here. > > After fixing the bug in rune.c and changing most runes in the archetypes > file according to 3), I got all kinds of traps working again. I > summarized some attributes of the runes in runes-old.txt/runes-new.txt, > because the diff of the archetypes file is not very clear. Note that you can do diffs in the arch directory - that would probably produce the clearer, albeit more verbose results. I agree that a diff of the archetype file is relative hard to see. > > Besides that, I re-enabled the 'maxhp' field for runes to cast more than > one spell. Now it works for all types of spells, not just for summoning > spells. I don't see any problems with the code in my quick look over. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Aug 30 12:19:33 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:59 2005 Subject: [CF-Devel] Traps not working reliable In-Reply-To: <4132D091.9090302@sonic.net> Message-ID: On 30-Aug-2004 Mark Wedel wrote: > That seems bad. Taking a very quick look at the code (for all other uses > of > MAX), I'm a little concerned with random_roll() and die_roll() which is > pasiing > RANDOM() into MAX (actually, it passes it into MIN, which is inside a MAX > construct). Yeah.. I just ran a quick proof. Thats bad. Oops. :) --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Aug 30 12:22:55 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:59 2005 Subject: [CF-Devel] Improvements to 'tell' and 'reply' commands In-Reply-To: <4132CB0A.8080301@sonic.net> References: <20040825180306.GA12970@idefix2.dvlp.in-medias-res.com> <4132CB0A.8080301@sonic.net> Message-ID: <20040830172255.GA5867@idefix2.dvlp.in-medias-res.com> Mark Wedel wrote: > I don't see any problem with the first one. Committed to CVS. > I'd have to check the CVS logs, but there is probably a reason that there > is an explict check for FLAG_REMOVED in the second case. My guess would be > you could ge in odd situations with a logged out player, possibly resulting > in crashes. I checked some random code with loops over the first_player list: I found no other player that checked for FLAG_REMOVED or even bothered to check "pl->ob!=NULL". Therefore you can cause the problem fixed in find_player() ('reply' command) by just using 'tell' (find_player_partial_name()) or 'gsay' (send_party_message()). > In fact, I've seen a lot of crashes with logged out but still connected > players. Really, all that logic should get cleaned up/removed (I think I > mentioned before, but ideal situation would be for client to send both name > and password as part of connection instead of having the the server have to > handle those states, which I think there is an open bug against right now) I'll leave it unchanged then. Anyways, it was just a little inconsistency I noticed between the similar commands 'tell' and 'reply'. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Aug 30 12:43:33 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:59 2005 Subject: [CF-Devel] Traps not working reliable In-Reply-To: <4132D091.9090302@sonic.net> References: <20040829182942.GA23666@idefix2.dvlp.in-medias-res.com> <4132D091.9090302@sonic.net> Message-ID: <20040830174333.GA16587@idefix2.dvlp.in-medias-res.com> Mark Wedel wrote: > That seems bad. Taking a very quick look at the code (for all other > uses of MAX), I'm a little concerned with random_roll() and die_roll() > which is pasiing RANDOM() into MAX (actually, it passes it into MIN, > which is inside a MAX construct). I did check other occurrences of MAX/MIN(...rndm()...) but forgot to check other critical functions. I'll check them when I'm done fixing the traps. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel