From don_grey at hotmail.com Sat Aug 25 11:24:36 2001 From: don_grey at hotmail.com (Don Grey) Date: Thu Jan 13 17:53:03 2005 Subject: [cf-admin] Problem that Crashes MiDS. Can you also bring MIDS back up? Message-ID: Hi guys, I found a bug that makes MIDS go down for good. I did it last night but thought it was a coincidence because 2 or 3 people had joined before it crashed. Anyway, anyone who plays on MIDS is used to the constant crashing but it comes back up in a minute or so usually. WELL, this bug causes it to die and NOT come back up. Anyway to reproduce it: Stand on a building or near a building and read "Summon Pet Monster" scrolls. I did it last night and again today. I think it has to be more than 1 for it to die. Anyway.. When it dies it nevercomes back :( So please bring MiDS up and disable summon pet monster until its fixed!! Thanks Don Grey _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From mwedel at scruz.net Wed Aug 1 01:04:07 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:31 2005 Subject: [CF-Devel] Fog of war code checked in References: <20010722120107.A92234@CSUA.Berkeley.EDU> <20010724164210.A19757@CSUA.Berkeley.EDU> <3B5E5956.9B7CBD1F@scruz.net> <20010726181129.A12271@CSUA.Berkeley.EDU> <3B665529.665E4864@scruz.net> <20010731162444.A8532@CSUA.Berkeley.EDU> Message-ID: <3B679BD7.D3EE9229@scruz.net> > That would be neat but using the existing lighting code would end up > doing the wrong thing on the client side, if the interpolated stuff > is used anyway. If you are thinking that the end effect would be to > darken tiles that are blocked by LOS, you don't want full bright tiles > adjancent to these 'blocked' tiles leaking light in since it isn't > a lighting issue, it is a blocked view issue. Your probably right - it would work right without interpolated code for darkness. I'd actually have to think about this further - since the blocking in this case would move this blocking/darkening to squares it blocks, the results may be OK. For example, if you have the case: ..XXX P1XXX ..XXX the 1 would be darkness for those spaces. No matter what, all the X's would be at least darkness one, since the blocking that the 1 provides would spill over to those other ones. There may be cases with strange situations where it doesn't look right (lone spot that has some blocking). > Oh yeah, guess I could have worded that better. I was hoping you could > do it cause I don't have time to do anymore crossfire features until > I get back from my sabbatical in November. I still have some bugs to > fix in the gtkSDL client that dnh reported to me and fix up the other > transport mechanisms to get fog working properly in all cases before > I go. Ok. I'll look at this - I would guess it shouldn't be too hard. > > Do you have any sort of release schedule in mind? Are we just gonna add > lots of features to crossfire and do a 2.0 release in like a year or two > or do you plan on a 1.1 release? I have no schedule in mind. The problem with trying to make a release is that it requires forking trees and makes for a bit more work (presumably we want to try and make a stable release). OTOH, most of the servers are still keeping pretty up to date, which helps verify stability. From lohner at debian.org Wed Aug 1 06:47:55 2001 From: lohner at debian.org (Nils Lohner) Date: Thu Jan 13 18:01:31 2005 Subject: [CF-Devel] Technical Object Questions Message-ID: <200108011147.NAA14970@topaze.ecf.teradyne.com> I'm still working on the autopickup, and have a few questions. - some items (keys, shields, arrows) have no names ...answer: they use their archetype name tmp->arch->name - daggers aren't throwable ...find throwing daggers :) - chairs and tables are classed as 'weapons' item name chair item type 15 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 ...and chairs (if weapons :) should at least be throwable as well. ...should/could a type 'FURNITURE' be created for them? - looking at food (generic food) FOOD item name==NULL food item type 6 0 [31] 0010 0000 0000 0000 0000 0000 0000 1100 [0] 1 [63] 0000 0000 0000 0000 0000 0000 0000 0000 [32] 2 [95] 0000 0000 0000 0001 0000 0000 0000 0000 [64] 3 [127] 0000 0000 0000 0000 0000 0000 0000 0000 [96] ...the flag[2] is #define FLAG_CAN_USE_SKILL 79 /* The monster can use skills */ ...is this normal??!?? Otherwise, I have a good idea of how I want it to work, how to integrate it with the existing one, and how to finish it. Suggestions for other autopickup classes welcome. two more to add: LITERATURE books, scrolls DRINKS drinks POTIONS Maybe even get more detailed, but at that point the functionality should come from search-items since that takes game-time. Just grabbing one type of thing shouldn't take time, sorting for something should. Also, can I get read-only CVS access on SF? I don't need write, I don't know how much I'll contribute, and I can submit a lot as patches if someone's willing to apply them. Thanks, Nils. From mwedel at scruznet.com Wed Aug 1 13:01:54 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:31 2005 Subject: [CF-Devel] Technical Object Questions In-Reply-To: <200108011147.NAA14970@topaze.ecf.teradyne.com> Message-ID: On Wed, 1 Aug 2001, Nils Lohner wrote: > > - some items (keys, shields, arrows) have no names > ...answer: they use their archetype name tmp->arch->name That sounds correct. > - daggers aren't throwable > ...find throwing daggers :) You can actually throw anything (chairs, swords, etc). However, items that are specially throwable throw a lot better. To be honest, I don't think many people actually use the throwing feature of crossfire - I think this to some extent is because it is hard to get enough throwable items to make it worth the bother to use this (and using bows is more effective). > - chairs and tables are classed as 'weapons' > item name chair > item type 15 > 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 > ...and chairs (if weapons :) should at least be throwable as well. > ...should/could a type 'FURNITURE' be created for them? I think they should be throwable (as said, I believe everything is throwable). Now it may be that they are not the first thing to be chosen. > - looking at food (generic food) > FOOD > item name==NULL food > item type 6 > 0 [31] 0010 0000 0000 0000 0000 0000 0000 1100 [0] > 1 [63] 0000 0000 0000 0000 0000 0000 0000 0000 [32] > 2 [95] 0000 0000 0000 0001 0000 0000 0000 0000 [64] > 3 [127] 0000 0000 0000 0000 0000 0000 0000 0000 [96] > ...the flag[2] is #define FLAG_CAN_USE_SKILL 79 /* The monster can use skills */ > ...is this normal??!?? If I read your table above, would that entry actually be 80? That one is FLAG_BEEN_APPLIED, which meant the player has applied (eaten) at least one of the food objects. > Otherwise, I have a good idea of how I want it to work, how to integrate > it with the existing one, and how to finish it. Suggestions for other > autopickup classes welcome. > > two more to add: > LITERATURE books, scrolls > DRINKS drinks > POTIONS Most people use value density pickup, which covers things like potions and scrolls and leaves the heavier stuff alone. But having more choices is never bad. > Maybe even get more detailed, but at that point the functionality should > come from search-items since that takes game-time. Just grabbing one > type of thing shouldn't take time, sorting for something should. Really, this is a matter of playability and fun. In theory, any amount of choosing on any criteria should take time. IF there is a pile of 20 items, and you only want to pick up 5 of those, it should realistically take some time to pick those out. And while many items group together into large sums, in reality, they would probably be scattered apart - that 500 gp wouldn't be a nice pile, but rather scattered all over the area in single coin pieces in most cases. > Also, can I get read-only CVS access on SF? I don't need write, I don't > know how much I'll contribute, and I can submit a lot as patches if > someone's willing to apply them. Look at the notes on sourceforge - it has directions on setting up your CVS stuff (anyone who wants it gets read-only access to all sourceforge stuff, because everything is set up that way). I would say that if you do plan to do more work on crossfire, you should get write access at some point. I certainly do like to look over and review submissions by new developers, but at some point, this just becomes a time waster and better for the person to just check in their stuff directly. From mwedel at scruz.net Thu Aug 2 01:33:18 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:31 2005 Subject: [CF-Devel] make distclean problems/cleanups References: <200107311656.SAA06650@topaze.ecf.teradyne.com> Message-ID: <3B68F42E.C9759F31@scruz.net> I've fixed what I believe are all the problems with make distclean. From mwedel at scruz.net Thu Aug 2 02:02:17 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:31 2005 Subject: [CF-Devel] server problems References: Message-ID: <3B68FAF9.A4451A71@scruz.net> Moved back to mailing list as this may have some broader interest. Michael Toennies wrote: > > H, one problem is, that the server will run without getting a version cmd > from client. > Is this a problem or not? We can ignore it, implicit setting "base" version > or we > can assume it as "broken" connect. At this point, probably ignore it. For these interim releases, I don't really want to have to worry about the version information and trying to figure it out. The setup command is probably the way to go for any future enhancements, and at some point, the versioncmd could probably go away. The only issue right now might be if some people have really old clients. > > For the version itself it has no effect, but the server determinate for > example the face/face1 > cmd with it. Yeah - the version stuff was useful for transitional information. As part of the server cleanup, at some point, only the most recent version of some commands will be supported. This reduces codes, which typically means fewer bugs. And if the client knows it only needs to support the latest command, that is less work on that side also. > This works fine, but perhaps we should have here a stronger, server side > directed login procedure? Really the handling of much the login and character creation should be moved to the client. For example: Client connects to server, does negotiating (making sure it can play on this server). Client prompts for user name and password. It then sends this to server in one protocol command. If authentication is successful, go to play game. If not, confirmation of password is requested (player may have entered password incorrectly of course). For this, the server should actually just use some state code, so that the client can key in on this easily. Alternately, you could have something like: C->S: login C->S: newplayer In the second case, the server has already double checked the password, and sends the newplayer after the player has confirmed. The advantage this has is that it removes some of the state tracking from the server. Also, the the stat stuff should be redone. Instead of having the player cycle through swap and the yes/no, it would be something like: S->C: newplayer_stats 18 15 14 13 12 11 10 C->S: newplayer_stats 10 18 15 32 12 11 14 (player has re-ordered them, but this is all done on the client), or C->S: newplayer_stats roll_again IMO other than simplifying the server by having the client deal with this, it also means that the client is free to be more intelligent about menus or whatever else that it shows up. The only disadvantage here is that the player won't necessarily be able to see how the change of strength and int affects some abilities. > Giving the server here more "control" will help avoid abusing programms > (which perhaps try to fload > the server with senseless packets) or broken logins. He can then kill this > connects fast. When we > get more player, this makes alot sense. Some things will always be hard to deal with. Certainly some timeout should probably be in order (must log in within 5 minutes or the like) - doing that would not be hard. Trying to prevent floods is more difficult - it strikes me that most services that listen to ports can conceivably be flooded (http, sendmail, etc). Perhaps adding some memory of hosts in the last X amount of time that appeared abusive automatically get put into the deny file or the like. I'd also have to double check, but the ban file should have simple matching for ip addresses, and if a banned ip address shows up, server closes connection before even talking to it. From lohner at debian.org Thu Aug 2 03:57:20 2001 From: lohner at debian.org (Nils Lohner) Date: Thu Jan 13 18:01:31 2005 Subject: [CF-Devel] Technical Object Questions In-Reply-To: ; "mwedel@scruznet.com on Wed, 01 Aug 2001 11:01:54 PDT" Message-ID: <200108020857.KAA17245@topaze.ecf.teradyne.com> On Wed, 1 Aug 2001 11:01:54 -0700 (PDT), Mark Wedel wrote: >On Wed, 1 Aug 2001, Nils Lohner wrote: >> - daggers aren't throwable >> ...find throwing daggers :) > > You can actually throw anything (chairs, swords, etc). However, items >that are specially throwable throw a lot better. > > To be honest, I don't think many people actually use the throwing feature >of crossfire - I think this to some extent is because it is hard to get enough >throwable items to make it worth the bother to use this (and using bows >is more effective). Well, I find a lot of daggers (doesn't take me long to have a good amount of them) and I wouldn't mind being able to throw them effectively at shorter ranges. Should be quicker than firing a bow too, IMO. But since there are specifically throwing daggers, this is OK. It's a waste of ammo though :) >> - chairs and tables are classed as 'weapons' >> item name chair >> item type 15 >> 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 >> ...and chairs (if weapons :) should at least be throwable as well. >> ...should/could a type 'FURNITURE' be created for them? > > I think they should be throwable (as said, I believe everything is >throwable). Now it may be that they are not the first thing to be chosen. My main problem is with them being WEAPON... that's a misclassification in my opinion. I have a pickup mode of ALLWEAPONS, and only realized that this was a bad idea after walking around with a complete collection of a Church's chairs... :) So throwable means 'effectively throwable' in the flags, but anything can be thrown? >> - looking at food (generic food) >> FOOD >> item name==NULL food >> item type 6 >> 0 [31] 0010 0000 0000 0000 0000 0000 0000 1100 [0] >> 1 [63] 0000 0000 0000 0000 0000 0000 0000 0000 [32] >> 2 [95] 0000 0000 0000 0001 0000 0000 0000 0000 [64] >> 3 [127] 0000 0000 0000 0000 0000 0000 0000 0000 [96] >> ...the flag[2] is #define FLAG_CAN_USE_SKILL 79 /* The monster can use >skills */ >> ...is this normal??!?? > > If I read your table above, would that entry actually be 80? >That one is FLAG_BEEN_APPLIED, which meant the player has applied >(eaten) at least one of the food objects. Right you are. I added the [##] prints afterwards, and at the time I was counting from the wrong end. >> Otherwise, I have a good idea of how I want it to work, how to integrate >> it with the existing one, and how to finish it. Suggestions for other >> autopickup classes welcome. >> >> two more to add: >> LITERATURE books, scrolls >> DRINKS drinks >> POTIONS > > Most people use value density pickup, which covers things like potions >and scrolls and leaves the heavier stuff alone. But having more choices >is never bad. How possible/easy would it be to split WEAPON into subclasses? Armor is split into shield, helmet, gloves, boots, etc. I'd propose splitting WEAPON into SWORD (long, short, broad, etc.) KNIFE (knives and daggers etc.) POLE (pole arms, lances, etc.) /* question: do these give you a longer attack range, i.e. one or two squares? IMO they sh/could...) OTHER (axes, maces, clubs, etc.) /* better name for these? */ The armor is very detailed, weapon only has bow/arrow split out atm. THis would make the definitions more consistent. And easier to implement for autopickup :) >> Maybe even get more detailed, but at that point the functionality should >> come from search-items since that takes game-time. Just grabbing one >> type of thing shouldn't take time, sorting for something should. > > Really, this is a matter of playability and fun. In theory, any amount >of choosing on any criteria should take time. IF there is a pile of 20 >items, and you only want to pick up 5 of those, it should realistically >take some time to pick those out. And while many items group together >into large sums, in reality, they would probably be scattered apart - that >500 gp wouldn't be a nice pile, but rather scattered all over the area in >single coin pieces in most cases. I agree with this, but seeign a big pile of stuff and jsut grabbing arrows and money is pretty quick. When you get to types of arrows or specific coins or gems, then it should take time. I think this is a good general rule that I'll stick to for the autopickup. >> Also, can I get read-only CVS access on SF? I don't need write, I don't >> know how much I'll contribute, and I can submit a lot as patches if >> someone's willing to apply them. > > Look at the notes on sourceforge - it has directions on setting up >your CVS stuff (anyone who wants it gets read-only access to all sourceforge >stuff, because everything is set up that way). ... I'll look through the docs. The thing is I need :ext: cvs read-only because I'm firewalled and the pserver port is blocked. Thanks, Nils. From michael.toennies at nord-com.net Thu Aug 2 09:18:29 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:31 2005 Subject: [CF-Devel] strange bugs Message-ID: hum, this looks not good mark... From andi.vogl at gmx.net Thu Aug 2 09:25:38 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:32 2005 Subject: [CF-Devel] current server is very unstable Message-ID: I just wanted to note that the current crossfire server crashes very often. Mids server has been reported to crash every 5-10 minutes at times. These problems started only a few days ago, so it might be somehow related to the latest cvs (server) checkins. Unfortunatley it's still unknown how to cause the crash, but at least we've got some crash logs: Maybe they give someone an idea what's wrong? Andreas V. ---------- load_original_map: /pup_land/rainbow/Lv2/sticky (0) Saving map /pup_land/rainbow/Lv2/h_pass hit_map(): next object destroyed hit_map(): next object destroyed hit_map(): next object destroyed hit_map(): next object destroyed hit_map(): next object destroyed hit_map(): next object destroyed hit_map(): next object destroyed hit_map(): next object destroyed SIGSEGV received. ----------- load_original_map: /peterm/CTower/TowerTop (0) Trying to load map /home/crossfire/var/crossfire/players/Drifter/_santo_dominion_sdomino_appart ment. load_original_map: /home/crossfire/var/crossfire/players/Drifter/_santo_dominion_sdomino_appart ment (2) make_path_tofile /home/crossfire/var/crossfire/players/Drifter/Drifter.pl... SIGSEGV received. From mwedel at scruznet.com Thu Aug 2 20:02:58 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:32 2005 Subject: [CF-Devel] Technical Object Questions In-Reply-To: <200108020857.KAA17245@topaze.ecf.teradyne.com> Message-ID: On Thu, 2 Aug 2001, Nils Lohner wrote: > Well, I find a lot of daggers (doesn't take me long to have a good > amount of them) and I wouldn't mind being able to throw them effectively > at shorter ranges. Should be quicker than firing a bow too, IMO. But > since there are specifically throwing daggers, this is OK. It's a waste > of ammo though :) IMO, the bigger problem is that there are not convenient keys/button clicks/whatever shortcuts to make this fast. It should be a bit faster than firing arrows yes, but with the current weight of daggers vs arrows and the need to say something like 'throw dagger', using them is more a pain. A lot of this has to do with the way the game is set up - monsters have a lot more HP than players do, so while 4 or 5 spears should realistically kill most humans, for most monsters, that is nothing more than a scratch. Even arrows at higher levels have a similar problem, as damage done via arrow may not be faster than the monsters regen rate. I beleive there is already logic in place for special handling of throwing things like dusts. Throwing may get used more if more items that gave special properties when thrown were available (think of AD&D, with hammers that return to the thrower, or javelins that turn into lightning or one dart that when thrown turns into a whole bunch) > My main problem is with them being WEAPON... that's a misclassification > in my opinion. I have a pickup mode of ALLWEAPONS, and only realized > that this was a bad idea after walking around with a complete collection > of a Church's chairs... :) Note that item types when originally done were meant as a classification for internal handling of objects (ie, what happens when this object is equipped, and how is it used). At the time it was done, I am sure the type was not necessarily envisaged as being used for pickup criteria. > So throwable means 'effectively throwable' in the flags, but anything can be > thrown? Correct. If an item is throwable, it travels farther, does more damage (in some cases), etc. I believe it really means that many values within the object itself is used for that. If you pick up a sword and throw it, the program figures out range and other factors based on formula. > > How possible/easy would it be to split WEAPON into subclasses? Armor is > split into shield, helmet, gloves, boots, etc. It depends. Note that the reason that armor is split up is because they have different uses - the helmets go on your head, gloves go on your hands, etc, so you can wear these combinations together. In the case of weapons, all are held in your hand so have pretty similiar characteristics. > I'd propose splitting WEAPON into > SWORD (long, short, broad, etc.) > KNIFE (knives and daggers etc.) > POLE (pole arms, lances, etc.) /* question: do these give you a longer > attack range, i.e. one or two squares? IMO they sh/could...) No they do not. > OTHER (axes, maces, clubs, etc.) /* better name for these? */ > > The armor is very detailed, weapon only has bow/arrow split out atm. > THis would make the definitions more consistent. And easier to > implement for autopickup :) I have often talked (well typed) about splitting objects into type/subtype. In that vision, that split would still be functional within the item. You can search the archives at real-time for more info, but the basic idea is that everything the player might have would have type equipment, and then below that may get split into armor, shield, weapon, etc. This would make for more consistent values of some of the fields in the object, and would also make it easier to add new types (since the equipment type would cover most everything except what particular part of the body it may go on). Right now, other than auto pickup, such a split above has no use. That isn't to say it can't be done, but seems like a bit of work for that purpose if all weapons are effectively the same. Currently, all classes can use any of those weapons if they have melee skill. It has been suggested before, and I think your idea goes right with this, is that items should have a 'sort_type' or the like. This type is effectively public, would get sent to the client (so it can sort things appropriately without having to look up via name). This should also be what gets used for autopickup instead of splitting up the current weapon type - IMO, the current type fields should really be used for functional use in the code, and not really relied on for anything as far as the player is concerned. Longer term, I could also see weapons getting changed around some. For example, think of these types: Knives (dagger, knife, shortsword) swords (as described above) pole (as described above) bludgeoning weapons (mace, flail, club, hammer) cleaving weapons (axe) two handed weapons (either as a total type, or another one for each of the above) Two handed weapons would prevent use of a shield. In addition, some weapons could be more/less useful against certain things. If you go back to old AD&D, things like daggers and spears are not very effective against skeletons, but hammers are. Also, the melee weapon skill could get broken out into a skill for each weapon type, with the ability to learn certain things limited (the wizard won't be able to learn cleaving weapons for example). This could get used to add more flavor to some of the classes. > I agree with this, but seeign a big pile of stuff and jsut grabbing > arrows and money is pretty quick. When you get to types of arrows or > specific coins or gems, then it should take time. I think this is a > good general rule that I'll stick to for the autopickup. I dunno. Take a handful of quarters and toss them on your lawn and see how quickly you can pick them up. Realistically, anything in large numbers take time to pickup. I generally don't think we should get worried about the time it takes to pick things up (even search items should probably be made free). While we can make it realistic and have it take time to pick things up, the game is really meant to be fun. If your playing an archer type character, you probably want to pick up any arrow you run across of. You really don't want to die as you run onto some big pile of mixed arrows that freezes you as you pick them all up. (note that picking up too much stuff has the inherent danger in that more weight slows you down already). > > Look at the notes on sourceforge - it has directions on setting up > >your CVS stuff (anyone who wants it gets read-only access to all sourceforge > >stuff, because everything is set up that way). > ... > I'll look through the docs. The thing is I need :ext: cvs read-only > because I'm firewalled and the pserver port is blocked. I think that is available. But to be honest, I'm not positive - I know that is used for people with write access. From mwedel at scruz.net Fri Aug 3 01:53:20 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:32 2005 Subject: [CF-Devel] strange bugs References: Message-ID: <3B6A4A60.2BEBE77F@scruz.net> I've just checked in a change which will hopefully fix the most common of the crashes. I had played with my changes for quite a while without finding bugs, but of course I could not envisage all the possible cases. Please keep me informed of future crashes. From yann.chachkoff at mailandnews.com Fri Aug 3 08:53:21 2001 From: yann.chachkoff at mailandnews.com (Chachkoff Yann) Date: Thu Jan 13 18:01:32 2005 Subject: [CF-Devel] Technical Object Questions In-Reply-To: References: Message-ID: <01080309532100.01339@localhost.localdomain> About the object classes/subclasses... What do you think of a simple "Object tree" ? I was thinking of a hierarchy of objects like this one (it is only an incomplete example !): Object - Non-living -- Weapon --- Swords --- Knives --- Poles -- Armour --- Body armour --- Helmet --- Gloves --- Boots -- Jewels --- Rings --- Talismans -- Organic --- Food --- Body parts -- Misc. --- Furniture --- Walls - Living -- Player -- Monster ---NPC And so on. The common functions used by all objects (query_name for example) could be referenced in the archetype itself (by function pointers). If a specific subclass of object requires a different procedure, simply reference another one in its archetype. This could give more flexibility to the code, because it would allow a clear separation of "What the server should do" (the rules of the game and the global interactions between objects) and "What the objects do" (The server no longer need to know how the object store its datas). I know that it could be a lot of work. I just want to know: - If anyone is against the idea (and the possible objections); - If anyone has an idea for a complete object hierarchy; > Longer term, I could also see weapons getting changed around some. > For example, think of these types: > > Knives (dagger, knife, shortsword) > swords (as described above) > pole (as described above) > bludgeoning weapons (mace, flail, club, hammer) > cleaving weapons (axe) > two handed weapons (either as a total type, or another one for each of the > above) > > Two handed weapons would prevent use of a shield. > > In addition, some weapons could be more/less useful against certain > things. If you go back to old AD&D, things like daggers and spears are not > very effective against skeletons, but hammers are. Also, the melee weapon > skill could get broken out into a skill for each weapon type, with the > ability to learn certain things limited (the wizard won't be able to learn > cleaving weapons for example). This could get used to add more flavor to > some of the classes. Maybe reusing the old Advanced Combat System ideas and preliminary code could be interesting for that ? Chachkoff Y. From dweeves at hotmail.com Fri Aug 3 12:38:20 2001 From: dweeves at hotmail.com (Sebastien Bracquemont) Date: Thu Jan 13 18:01:32 2005 Subject: [CF-Devel] Technical Object Questions Message-ID: >From: Chachkoff Yann >To: crossfire-devel@lists.real-time.com >Subject: Re: [CF-Devel] Technical Object Questions >Date: Fri, 3 Aug 2001 09:53:21 -0400 > >About the object classes/subclasses... >What do you think of a simple "Object tree" ? I was thinking of a hierarchy >of objects like this one (it is only an incomplete example !): > >Object > - Non-living > -- Weapon > --- Swords > --- Knives > --- Poles > -- Armour > --- Body armour > --- Helmet > --- Gloves > --- Boots > -- Jewels > --- Rings > --- Talismans > -- Organic > --- Food > --- Body parts > -- Misc. > --- Furniture > --- Walls > - Living > -- Player > -- Monster > ---NPC > I think the idea is good but it relies typical object oriented programming concepts (inheritance, polymorphism).The implementation will be complex and tricky in pure C.(reinventing the wheel... to only get a wooden one !) I always had the thought that a language that supports OO concept (C++ for example)is much better suited for CF and the implementation of the server can be much more simple,maintanable,and evolutive by this way. Another thing is that what is exposed here is a clear "reconception" of the object system that is the heart of CF (in the limit of my knowledge). Not a bad thing IMO but had to be really discussed with the principal developers. I was supposed to do some work on the Java Editor but i had a really hard work for the last months. MichToen did a fantastic work on the Editor. Still getting better each day. If there is a move to OO , i'll be happy to help you for the (re)design. dweeves _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From lohner at debian.org Fri Aug 3 08:27:31 2001 From: lohner at debian.org (Nils Lohner) Date: Thu Jan 13 18:01:32 2005 Subject: [CF-Devel] autopickup GTK client patch Message-ID: <200108031327.PAA25454@topaze.ecf.teradyne.com> This is part 1 of the patch. It adds the options to the actions menu in the GTK client. For more info, see the second mail. Nils. -------------- next part -------------- --- crossfire-client-1.0.0/gx11.c Mon May 14 00:03:07 2001 +++ crossfire-client-1.0.0.new/gx11.c Fri Aug 3 14:44:53 2001 @@ -4774,6 +4774,24 @@ /* Various routines for setting modes by menu choices. */ +void new_menu_pickup(GtkWidget *button, int val) +{ + static unsigned int pmode=0; + char modestr[128]; + + /* widget is GtkCheckMenuItem */ + if(GTK_CHECK_MENU_ITEM (button)->active) pmode=pmode|val; + else pmode=pmode&~val; + +#if 0 + fprintf(stderr,"val=0x%8x\n",val); + fprintf(stderr,"mode=0x%8x\n",pmode); +#endif + + sprintf(modestr,"pickup %u",pmode); + send_command(modestr, -1, 0); +} + void menu_pickup0 () { pickup_mode = 0; @@ -4879,6 +4897,8 @@ GtkWidget *filemenu; GtkWidget *actionmenu; GtkWidget *pickupmenu; + GtkWidget *newpickupmenu; + GtkWidget *ratiopickupmenu; GtkWidget *clientmenu; GtkWidget *helpmenu; GtkWidget *menu_bar; @@ -4889,7 +4909,12 @@ GtkWidget *root_clientmenu; GtkWidget *menu_items; GtkWidget *pickup_menu_item; + GtkWidget *newpickup_menu_item; + GtkWidget *ratiopickup_menu_item; GSList *pickupgroup; + GSList *ratiopickupgroup; + int i; + char menustring[128]; /* Init the menu-widget, and remember -- never @@ -5032,6 +5057,10 @@ GTK_SIGNAL_FUNC(menu_apply), NULL);*/ gtk_widget_show(pickup_menu_item); + newpickup_menu_item = gtk_menu_item_new_with_label("NEWPickup"); + gtk_menu_append(GTK_MENU (actionmenu), newpickup_menu_item); + gtk_widget_show(newpickup_menu_item); + menu_items = gtk_menu_item_new_with_label("Search"); gtk_menu_append(GTK_MENU (actionmenu), menu_items); gtk_signal_connect_object(GTK_OBJECT(menu_items), "activate", @@ -5143,8 +5172,230 @@ gtk_widget_show(sub_pickupmenu);*/ gtk_menu_item_set_submenu(GTK_MENU_ITEM (pickup_menu_item), pickupmenu); +/* ENDPICKUP */ + +/* --------------------------------------------------------------------- */ +/* --------------------------------------------------------------------- */ +/* --------------------------------------------------------------------- */ +/* --------------------------------------------------------------------- */ +/* --------------------------------------------------------------------- */ + + + /* copy from server: include/define.h */ +#define PU_NOTHING 0x00000000 + +#define PU_DEBUG 0x10000000 +#define PU_INHIBIT 0x20000000 +#define PU_STOP 0x40000000 +#define PU_NEWMODE 0x80000000 + +#define PU_RATIO 0x0000000F + +#define PU_FOOD 0x00000010 +#define PU_DRINK 0x00000020 +#define PU_VALUABLES 0x00000040 +#define PU_BOW 0x00000080 + +#define PU_ARROW 0x00000100 +#define PU_HELMET 0x00000200 +#define PU_SHIELD 0x00000400 +#define PU_ARMOUR 0x00000800 + +#define PU_BOOTS 0x00001000 +#define PU_GLOVES 0x00002000 +#define PU_CLOAK 0x00004000 +#define PU_KEY 0x00008000 + +#define PU_MISSILEWEAPON 0x00010000 +#define PU_ALLWEAPON 0x00020000 +#define PU_MAGICAL 0x00040000 +#define PU_POTION 0x00080000 + + newpickupmenu = gtk_menu_new(); + +#ifdef GTK_HAVE_FEATURES_1_1_12 + menu_items = gtk_tearoff_menu_item_new (); + gtk_menu_append (GTK_MENU (newpickupmenu), menu_items); + gtk_widget_show (menu_items); +#endif + + menu_items = gtk_check_menu_item_new_with_label("Enable NEW autopickup"); + gtk_check_menu_item_set_show_toggle (GTK_CHECK_MENU_ITEM (menu_items), TRUE); + gtk_menu_append(GTK_MENU (newpickupmenu), menu_items); + gtk_signal_connect(GTK_OBJECT(menu_items), "activate", + GTK_SIGNAL_FUNC(new_menu_pickup), PU_NEWMODE); + gtk_widget_show(menu_items); + + menu_items = gtk_check_menu_item_new_with_label("Inhibit autopickup"); + gtk_check_menu_item_set_show_toggle (GTK_CHECK_MENU_ITEM (menu_items), TRUE); + gtk_menu_append(GTK_MENU (newpickupmenu), menu_items); + gtk_signal_connect(GTK_OBJECT(menu_items), "activate", + GTK_SIGNAL_FUNC(new_menu_pickup), PU_INHIBIT); + gtk_widget_show(menu_items); + + menu_items = gtk_check_menu_item_new_with_label("Stop before pickup"); + gtk_check_menu_item_set_show_toggle (GTK_CHECK_MENU_ITEM (menu_items), TRUE); + gtk_menu_append(GTK_MENU (newpickupmenu), menu_items); + gtk_signal_connect(GTK_OBJECT(menu_items), "activate", + GTK_SIGNAL_FUNC(new_menu_pickup), PU_STOP); + gtk_widget_show(menu_items); + + menu_items = gtk_check_menu_item_new_with_label("Debug autopickup"); + gtk_check_menu_item_set_show_toggle (GTK_CHECK_MENU_ITEM (menu_items), TRUE); + gtk_menu_append(GTK_MENU (newpickupmenu), menu_items); + gtk_signal_connect(GTK_OBJECT(menu_items), "activate", + GTK_SIGNAL_FUNC(new_menu_pickup), PU_DEBUG); + gtk_widget_show(menu_items); + + + /* the ratio pickup submenu */ + ratiopickupmenu = gtk_menu_new(); + +#ifdef GTK_HAVE_FEATURES_1_1_12 + menu_items = gtk_tearoff_menu_item_new (); + gtk_menu_append (GTK_MENU (ratiopickupmenu), menu_items); + gtk_widget_show (menu_items); +#endif + + ratiopickupgroup=NULL; + + menu_items = gtk_check_menu_item_new_with_label("Ratio Pickup"); + gtk_check_menu_item_set_show_toggle (GTK_CHECK_MENU_ITEM (menu_items), TRUE); + ratiopickup_menu_item = gtk_menu_item_new_with_label("Weight/Value Ratio"); + gtk_menu_append(GTK_MENU (newpickupmenu), ratiopickup_menu_item); + gtk_widget_show(ratiopickup_menu_item); + + menu_items = gtk_radio_menu_item_new_with_label(pickupgroup, "Pick up all magic items."); + pickupgroup = gtk_radio_menu_item_group (GTK_RADIO_MENU_ITEM (menu_items)); + gtk_check_menu_item_set_show_toggle (GTK_CHECK_MENU_ITEM (menu_items), TRUE); + gtk_menu_append(GTK_MENU (pickupmenu), menu_items); + gtk_signal_connect_object(GTK_OBJECT(menu_items), "activate", + GTK_SIGNAL_FUNC(menu_pickup6), NULL); + gtk_widget_show(menu_items); + + for(i=0;i<16;i++) + { + if(i==0) sprintf(menustring,"Ratio pickup OFF"); + else sprintf(menustring,"Ratio >= %d",i*5); + menu_items = gtk_radio_menu_item_new_with_label(ratiopickupgroup, menustring); + ratiopickupgroup = gtk_radio_menu_item_group (GTK_RADIO_MENU_ITEM (menu_items)); + gtk_check_menu_item_set_show_toggle (GTK_CHECK_MENU_ITEM (menu_items), TRUE); + gtk_menu_append(GTK_MENU (ratiopickupmenu), menu_items); + gtk_signal_connect(GTK_OBJECT(menu_items), "activate", + GTK_SIGNAL_FUNC(new_menu_pickup), i); + gtk_widget_show(menu_items); + } + gtk_menu_item_set_submenu(GTK_MENU_ITEM (ratiopickup_menu_item), ratiopickupmenu); + + + /* continue with the rest of the stuff... */ + + menu_items = gtk_check_menu_item_new_with_label("Food"); + gtk_check_menu_item_set_show_toggle (GTK_CHECK_MENU_ITEM (menu_items), TRUE); + gtk_menu_append(GTK_MENU (newpickupmenu), menu_items); + gtk_signal_connect(GTK_OBJECT(menu_items), "activate", + GTK_SIGNAL_FUNC(new_menu_pickup), PU_FOOD); + gtk_widget_show(menu_items); + menu_items = gtk_check_menu_item_new_with_label("Drinks"); + gtk_check_menu_item_set_show_toggle (GTK_CHECK_MENU_ITEM (menu_items), TRUE); + gtk_menu_append(GTK_MENU (newpickupmenu), menu_items); + gtk_signal_connect(GTK_OBJECT(menu_items), "activate", + GTK_SIGNAL_FUNC(new_menu_pickup), PU_DRINK); + gtk_widget_show(menu_items); + menu_items = gtk_check_menu_item_new_with_label("Valuables (Money, Gems)"); + gtk_check_menu_item_set_show_toggle (GTK_CHECK_MENU_ITEM (menu_items), TRUE); + gtk_menu_append(GTK_MENU (newpickupmenu), menu_items); + gtk_signal_connect(GTK_OBJECT(menu_items), "activate", + GTK_SIGNAL_FUNC(new_menu_pickup), PU_VALUABLES); + gtk_widget_show(menu_items); + menu_items = gtk_check_menu_item_new_with_label("Bows"); + gtk_check_menu_item_set_show_toggle (GTK_CHECK_MENU_ITEM (menu_items), TRUE); + gtk_menu_append(GTK_MENU (newpickupmenu), menu_items); + gtk_signal_connect(GTK_OBJECT(menu_items), "activate", + GTK_SIGNAL_FUNC(new_menu_pickup), PU_BOW); + gtk_widget_show(menu_items); + menu_items = gtk_check_menu_item_new_with_label("Arrows"); + gtk_check_menu_item_set_show_toggle (GTK_CHECK_MENU_ITEM (menu_items), TRUE); + gtk_menu_append(GTK_MENU (newpickupmenu), menu_items); + gtk_signal_connect(GTK_OBJECT(menu_items), "activate", + GTK_SIGNAL_FUNC(new_menu_pickup), PU_ARROW); + gtk_widget_show(menu_items); + menu_items = gtk_check_menu_item_new_with_label("Helmets"); + gtk_check_menu_item_set_show_toggle (GTK_CHECK_MENU_ITEM (menu_items), TRUE); + gtk_menu_append(GTK_MENU (newpickupmenu), menu_items); + gtk_signal_connect(GTK_OBJECT(menu_items), "activate", + GTK_SIGNAL_FUNC(new_menu_pickup), PU_HELMET); + gtk_widget_show(menu_items); + menu_items = gtk_check_menu_item_new_with_label("Shields"); + gtk_check_menu_item_set_show_toggle (GTK_CHECK_MENU_ITEM (menu_items), TRUE); + gtk_menu_append(GTK_MENU (newpickupmenu), menu_items); + gtk_signal_connect(GTK_OBJECT(menu_items), "activate", + GTK_SIGNAL_FUNC(new_menu_pickup), PU_SHIELD); + gtk_widget_show(menu_items); + menu_items = gtk_check_menu_item_new_with_label("Armour"); + gtk_check_menu_item_set_show_toggle (GTK_CHECK_MENU_ITEM (menu_items), TRUE); + gtk_menu_append(GTK_MENU (newpickupmenu), menu_items); + gtk_signal_connect(GTK_OBJECT(menu_items), "activate", + GTK_SIGNAL_FUNC(new_menu_pickup), PU_ARMOUR); + gtk_widget_show(menu_items); + menu_items = gtk_check_menu_item_new_with_label("Boots"); + gtk_check_menu_item_set_show_toggle (GTK_CHECK_MENU_ITEM (menu_items), TRUE); + gtk_menu_append(GTK_MENU (newpickupmenu), menu_items); + gtk_signal_connect(GTK_OBJECT(menu_items), "activate", + GTK_SIGNAL_FUNC(new_menu_pickup), PU_BOOTS); + gtk_widget_show(menu_items); + menu_items = gtk_check_menu_item_new_with_label("Gloves"); + gtk_check_menu_item_set_show_toggle (GTK_CHECK_MENU_ITEM (menu_items), TRUE); + gtk_menu_append(GTK_MENU (newpickupmenu), menu_items); + gtk_signal_connect(GTK_OBJECT(menu_items), "activate", + GTK_SIGNAL_FUNC(new_menu_pickup), PU_GLOVES); + gtk_widget_show(menu_items); + menu_items = gtk_check_menu_item_new_with_label("Cloaks"); + gtk_check_menu_item_set_show_toggle (GTK_CHECK_MENU_ITEM (menu_items), TRUE); + gtk_menu_append(GTK_MENU (newpickupmenu), menu_items); + gtk_signal_connect(GTK_OBJECT(menu_items), "activate", + GTK_SIGNAL_FUNC(new_menu_pickup), PU_CLOAK); + gtk_widget_show(menu_items); + menu_items = gtk_check_menu_item_new_with_label("Keys"); + gtk_check_menu_item_set_show_toggle (GTK_CHECK_MENU_ITEM (menu_items), TRUE); + gtk_menu_append(GTK_MENU (newpickupmenu), menu_items); + gtk_signal_connect(GTK_OBJECT(menu_items), "activate", + GTK_SIGNAL_FUNC(new_menu_pickup), PU_KEY); + gtk_widget_show(menu_items); + menu_items = gtk_check_menu_item_new_with_label("Missile Weapons"); + gtk_check_menu_item_set_show_toggle (GTK_CHECK_MENU_ITEM (menu_items), TRUE); + gtk_menu_append(GTK_MENU (newpickupmenu), menu_items); + gtk_signal_connect(GTK_OBJECT(menu_items), "activate", + GTK_SIGNAL_FUNC(new_menu_pickup), PU_MISSILEWEAPON); + gtk_widget_show(menu_items); + menu_items = gtk_check_menu_item_new_with_label("All weapons"); + gtk_check_menu_item_set_show_toggle (GTK_CHECK_MENU_ITEM (menu_items), TRUE); + gtk_menu_append(GTK_MENU (newpickupmenu), menu_items); + gtk_signal_connect(GTK_OBJECT(menu_items), "activate", + GTK_SIGNAL_FUNC(new_menu_pickup), PU_ALLWEAPON); + gtk_widget_show(menu_items); + menu_items = gtk_check_menu_item_new_with_label("Magical Items"); + gtk_check_menu_item_set_show_toggle (GTK_CHECK_MENU_ITEM (menu_items), TRUE); + gtk_menu_append(GTK_MENU (newpickupmenu), menu_items); + gtk_signal_connect(GTK_OBJECT(menu_items), "activate", + GTK_SIGNAL_FUNC(new_menu_pickup), PU_MAGICAL); + gtk_widget_show(menu_items); + + menu_items = gtk_check_menu_item_new_with_label("Potions"); + gtk_check_menu_item_set_show_toggle (GTK_CHECK_MENU_ITEM (menu_items), TRUE); + gtk_menu_append(GTK_MENU (newpickupmenu), menu_items); + gtk_signal_connect(GTK_OBJECT(menu_items), "activate", + GTK_SIGNAL_FUNC(new_menu_pickup), PU_POTION); + gtk_widget_show(menu_items); + + + gtk_menu_item_set_submenu(GTK_MENU_ITEM (newpickup_menu_item), newpickupmenu); + +/* --------------------------------------------------------------------- */ +/* --------------------------------------------------------------------- */ +/* --------------------------------------------------------------------- */ +/* --------------------------------------------------------------------- */ - /*Do the helpmenu */ helpmenu = gtk_menu_new(); From lohner at debian.org Fri Aug 3 08:39:56 2001 From: lohner at debian.org (Nils Lohner) Date: Thu Jan 13 18:01:32 2005 Subject: [CF-Devel] autopickup server patch Message-ID: <200108031339.PAA27749@topaze.ecf.teradyne.com> THis patch is for version 1.0.0 of the server. It implements a new autopickup scheme that's basically a superset of the old one, but it doesn't break compatibility so old clients will still work normally with it. One big change was turning mode from uint16->32; this requires all server files to be recompiled otherwise you'll see nice segv's. Nils. -------------- next part -------------- diff -ruN crossfire-1.0.0/include/define.h crossfire-1.0.0.autopickup/include/define.h --- crossfire-1.0.0/include/define.h Sun May 13 23:55:41 2001 +++ crossfire-1.0.0.autopickup/include/define.h Thu Aug 2 18:48:33 2001 @@ -257,6 +257,42 @@ #define MAX_NAME 16 #define BIG_NAME 32 + +/* definitions for detailed pickup descriptions. + * The objective is to define intelligent groups of items that the + * user can pick up or leave as he likes. */ + +/* high bit as flag for new pickup options */ +#define PU_NOTHING 0x00000000 + +#define PU_DEBUG 0x10000000 +#define PU_INHIBIT 0x20000000 +#define PU_STOP 0x40000000 +#define PU_NEWMODE 0x80000000 + +#define PU_RATIO 0x0000000F + +#define PU_FOOD 0x00000010 +#define PU_DRINK 0x00000020 +#define PU_VALUABLES 0x00000040 +#define PU_BOW 0x00000080 + +#define PU_ARROW 0x00000100 +#define PU_HELMET 0x00000200 +#define PU_SHIELD 0x00000400 +#define PU_ARMOUR 0x00000800 + +#define PU_BOOTS 0x00001000 +#define PU_GLOVES 0x00002000 +#define PU_CLOAK 0x00004000 +#define PU_KEY 0x00008000 + +#define PU_MISSILEWEAPON 0x00010000 +#define PU_ALLWEAPON 0x00020000 +#define PU_MAGICAL 0x00040000 +#define PU_POTION 0x00080000 + + /* Instead of using arbitrary constants for indexing the * freearr, add these values. <= SIZEOFFREE1 will get you * within 1 space. <= SIZEOFFREE2 wll get you withing @@ -354,6 +390,7 @@ #define FLAG_APPLIED 5 /* Object is ready for use by living */ #define FLAG_UNPAID 6 /* Object hasn't been paid for yet */ #define FLAG_AN 7 /* Name must be prepended by "an", not "a"*/ + #define FLAG_NO_PICK 8 /* Object can't be picked up */ #define FLAG_WALK_ON 9 /* Applied when it's walked upon */ #define FLAG_NO_PASS 10 /* Nothing can pass (wall() is true) */ @@ -362,6 +399,7 @@ #define FLAG_FLYING 13 /* Not affected by WALK_ON or SLOW_MOVE) */ #define FLAG_MONSTER 14 /* Will attack players */ #define FLAG_FRIENDLY 15 /* Will help players */ + #define FLAG_GENERATOR 16 /* Will generate type ob->stats.food */ #define FLAG_IS_THROWN 17 /* Object is designed to be thrown. */ #define FLAG_AUTO_APPLY 18 /* Will be applied when created */ @@ -371,6 +409,7 @@ #define FLAG_CAN_ROLL 22 /* Object can be rolled */ /* FLAG_IS_TURNING is no longer used */ /*#define FLAG_IS_TURNING 23 *//* Object will turn after player */ + #define FLAG_IS_TURNABLE 24 /* Object can change face with direction */ #define FLAG_WALK_OFF 25 /* Object is applied when left */ #define FLAG_FLY_ON 26 /* As WALK_ON, but only with FLAG_FLYING */ @@ -379,6 +418,7 @@ #define FLAG_IDENTIFIED 29 /* Not implemented yet */ #define FLAG_REFLECTING 30 /* Object reflects from walls (lightning) */ #define FLAG_CHANGING 31 /* Changes to other_arch when anim is done*/ + /* Start of values in flags[1] */ #define FLAG_SPLITTING 32 /* Object splits into stats.food other objs */ #define FLAG_HITBACK 33 /* Object will hit back when hit */ @@ -388,6 +428,7 @@ #define FLAG_SCARED 37 /* Monster is scared (mb player in future)*/ #define FLAG_UNAGGRESSIVE 38 /* Monster doesn't attack players */ #define FLAG_REFL_MISSILE 39 /* Arrows will reflect from object */ + #define FLAG_REFL_SPELL 40 /* Spells (some) will reflect from object */ #define FLAG_NO_MAGIC 41 /* Spells (some) can't pass this object */ #define FLAG_NO_FIX_PLAYER 42 /* fix_player() won't be called */ @@ -398,6 +439,7 @@ #define FLAG_PASS_THRU 46 /* Objects with can_pass_thru can pass \ thru this object as if it wasn't there */ #define FLAG_CAN_PASS_THRU 47 /* Can pass thru... */ + #define FLAG_PICK_UP 48 /* Can pick up */ #define FLAG_UNIQUE 49 /* Item is really unique (UNIQUE_ITEMS) */ #define FLAG_NO_DROP 50 /* Object can't be dropped */ @@ -406,6 +448,7 @@ #define FLAG_USE_SCROLL 53 /* (Monster) can read scroll */ #define FLAG_USE_WAND 54 /* (Monster) can apply and use wands */ #define FLAG_USE_BOW 55 /* (Monster) can apply and fire bows */ + #define FLAG_USE_ARMOUR 56 /* (Monster) can wear armour/shield/helmet */ #define FLAG_USE_WEAPON 57 /* (Monster) can wield weapons */ #define FLAG_USE_RING 58 /* (Monster) can use rings, boots, gauntlets, etc */ @@ -414,8 +457,9 @@ #define FLAG_XRAYS 61 /* X-ray vision */ #define FLAG_NO_APPLY 62 /* Avoids step_on/fly_on to this object */ #define FLAG_IS_FLOOR 63 /* Can't see what's underneath this object */ -#define FLAG_LIFESAVE 64 /* Saves a players' life once, then destr. */ + /* Start of values in flags[2] */ +#define FLAG_LIFESAVE 64 /* Saves a players' life once, then destr. */ #define FLAG_NO_STRENGTH 65 /* Strength-bonus not added to wc/dam */ #define FLAG_SLEEP 66 /* NPC is sleeping */ #define FLAG_STAND_STILL 67 /* NPC will not (ever) move */ @@ -423,6 +467,7 @@ #define FLAG_ONLY_ATTACK 69 /* NPC will evaporate if there is no enemy */ #define FLAG_CONFUSED 70 /* Will also be unable to cast spells */ #define FLAG_STEALTH 71 /* Will wake monsters with less range */ + #define FLAG_WIZPASS 72 /* The wizard can go through walls */ #define FLAG_IS_LINKED 73 /* The object is linked with other objects */ #define FLAG_CURSED 74 /* The object is cursed */ @@ -431,6 +476,7 @@ #define FLAG_KNOWN_MAGICAL 77 /* The object is known to be magical */ #define FLAG_KNOWN_CURSED 78 /* The object is known to be cursed */ #define FLAG_CAN_USE_SKILL 79 /* The monster can use skills */ + #define FLAG_BEEN_APPLIED 80 /* The object has been applied */ #define FLAG_READY_ROD 81 /* (Monster) has a rod readied... 8) */ #define FLAG_USE_ROD 82 /* (Monster) can apply and use rods */ @@ -439,6 +485,7 @@ #define FLAG_MAKE_INVIS 85 /* (Item) gives invisibility when applied */ #define FLAG_INV_LOCKED 86 /* Item will not be dropped from inventory */ #define FLAG_IS_WOODED 87 /* Item is wooded terrain */ + #define FLAG_IS_HILLY 88 /* Item is hilly/mountain terrain */ #define FLAG_READY_SKILL 89 /* (Monster or Player) has a skill readied */ #define FLAG_READY_WEAPON 90 /* (Monster or Player) has a weapon readied */ @@ -447,6 +494,7 @@ #define FLAG_SEE_IN_DARK 93 /* if set ob not effected by darkness */ #define FLAG_IS_CAULDRON 94 /* container can make alchemical stuff */ #define FLAG_DUST 95 /* item is a 'powder', effects throwing */ + /* Start of values in flags[3] */ #define FLAG_NO_STEAL 96 /* Item can't be stolen */ #define FLAG_ONE_HIT 97 /* Monster can only hit once before going diff -ruN crossfire-1.0.0/include/player.h crossfire-1.0.0.autopickup/include/player.h --- crossfire-1.0.0/include/player.h Sun May 13 23:55:41 2001 +++ crossfire-1.0.0.autopickup/include/player.h Thu Aug 2 12:58:59 2001 @@ -89,7 +89,7 @@ unsigned char prev_fire_on; unsigned char prev_keycode; /* Previous command executed */ unsigned char key_down; /* Last move-key still held down */ - uint16 mode; /* Mode of player for pickup. */ + uint32 mode; /* Mode of player for pickup. */ signed char digestion; /* Any bonuses/penalties to digestion */ signed char gen_hp; /* Bonuses to regeneration speed of hp */ signed char gen_sp; /* Bonuses to regeneration speed of sp */ Binary files crossfire-1.0.0/random_maps/standalone.o and crossfire-1.0.0.autopickup/random_maps/standalone.o differ diff -ruN crossfire-1.0.0/server/c_object.c crossfire-1.0.0.autopickup/server/c_object.c --- crossfire-1.0.0/server/c_object.c Sun May 13 23:55:41 2001 +++ crossfire-1.0.0.autopickup/server/c_object.c Thu Aug 2 21:27:46 2001 @@ -1235,19 +1235,99 @@ int command_pickup (object *op, char *params) { - int i; + unsigned int i, j; + char putstring[128]; if(!params) { + /* if the new mode is used, just print the settings */ + /* yes, a GOTO is ugly, but its simpple and should stay until this + * mode is cleanly integrated and the old one deprecated */ + if(op->contr->mode & PU_NEWMODE) + { + i=op->contr->mode; + goto NEWPICKUP; + } + if(1)fprintf(stderr,"command_pickup: !params\n"); op->contr->count_left=0; set_pickup_mode(op, (op->contr->mode > 6)? 0: op->contr->mode+1); return 0; } if(params==NULL || !sscanf(params, "%d", &i) || i<0 ) { - new_draw_info(NDI_UNIQUE, 0,op,"Usage: pickup <0-7> or ."); - return 1; - } - set_pickup_mode(op,i); - return 1; + if(1)fprintf(stderr,"command_pickup: params==NULL\n"); + new_draw_info(NDI_UNIQUE, 0,op,"Usage: pickup <0-7> or ."); + return 1; + } + set_pickup_mode(op,i); + + + sprintf(putstring,"command_pickup: set_pickup_mode\ndec %u, 0x%x", i, i); + new_draw_info(NDI_UNIQUE, 0,op,putstring); + + sprintf(putstring,"0b"); + for(j=0;j<32;j++) + { + strcat(putstring,((i>>(31-j))&0x01)?"1":"0"); + if(!((j+1)%4))strcat(putstring," "); + } + new_draw_info(NDI_UNIQUE, 0,op,putstring); + +#if 1 +NEWPICKUP: + if(!(i & PU_NEWMODE)) return 1; + + sprintf(putstring,"%d NEWMODE",i & PU_NEWMODE?1:0); + new_draw_info(NDI_UNIQUE, 0,op,putstring); + sprintf(putstring,"%d DEBUG",i & PU_DEBUG?1:0); + new_draw_info(NDI_UNIQUE, 0,op,putstring); + sprintf(putstring,"%d INHIBIT",i & PU_INHIBIT?1:0); + new_draw_info(NDI_UNIQUE, 0,op,putstring); + sprintf(putstring,"%d STOP",i & PU_STOP?1:0); + new_draw_info(NDI_UNIQUE, 0,op,putstring); + + sprintf(putstring,"%d <= x pickup weight/value RATIO (0==off)",(i & PU_RATIO)*5); + new_draw_info(NDI_UNIQUE, 0,op,putstring); + + sprintf(putstring,"%d FOOD",i & PU_FOOD?1:0); + new_draw_info(NDI_UNIQUE, 0,op,putstring); + sprintf(putstring,"%d DRINK",i & PU_DRINK?1:0); + new_draw_info(NDI_UNIQUE, 0,op,putstring); + sprintf(putstring,"%d VALUABLES",i & PU_VALUABLES?1:0); + new_draw_info(NDI_UNIQUE, 0,op,putstring); + + sprintf(putstring,"%d BOW",i & PU_BOW?1:0); + new_draw_info(NDI_UNIQUE, 0,op,putstring); + sprintf(putstring,"%d ARROW",i & PU_ARROW?1:0); + new_draw_info(NDI_UNIQUE, 0,op,putstring); + + sprintf(putstring,"%d HELMET",i & PU_HELMET?1:0); + new_draw_info(NDI_UNIQUE, 0,op,putstring); + sprintf(putstring,"%d SHIELD",i & PU_SHIELD?1:0); + new_draw_info(NDI_UNIQUE, 0,op,putstring); + sprintf(putstring,"%d ARMOUR",i & PU_ARMOUR?1:0); + new_draw_info(NDI_UNIQUE, 0,op,putstring); + + sprintf(putstring,"%d BOOTS",i & PU_BOOTS?1:0); + new_draw_info(NDI_UNIQUE, 0,op,putstring); + sprintf(putstring,"%d GLOVES",i & PU_GLOVES?1:0); + new_draw_info(NDI_UNIQUE, 0,op,putstring); + sprintf(putstring,"%d CLOAK",i & PU_CLOAK?1:0); + new_draw_info(NDI_UNIQUE, 0,op,putstring); + sprintf(putstring,"%d KEY",i & PU_KEY?1:0); + new_draw_info(NDI_UNIQUE, 0,op,putstring); + + sprintf(putstring,"%d MISSILEWEAPON",i & PU_MISSILEWEAPON?1:0); + new_draw_info(NDI_UNIQUE, 0,op,putstring); + sprintf(putstring,"%d ALLWEAPON",i & PU_ALLWEAPON?1:0); + new_draw_info(NDI_UNIQUE, 0,op,putstring); + sprintf(putstring,"%d MAGICAL",i & PU_MAGICAL?1:0); + new_draw_info(NDI_UNIQUE, 0,op,putstring); + sprintf(putstring,"%d POTION",i & PU_POTION?1:0); + new_draw_info(NDI_UNIQUE, 0,op,putstring); + + new_draw_info(NDI_UNIQUE, 0,op,""); +#endif + + return 1; } void set_pickup_mode(object *op,int i) { diff -ruN crossfire-1.0.0/server/player.c crossfire-1.0.0.autopickup/server/player.c --- crossfire-1.0.0/server/player.c Sun May 13 23:55:41 2001 +++ crossfire-1.0.0.autopickup/server/player.c Fri Aug 3 15:21:19 2001 @@ -184,7 +184,7 @@ */ if (checkbanned (defname, ns->host)){ - fprintf (logfile, "Banned player tryed to add. [%s@%s]\n", defname, ns->host); + fprintf (logfile, "Banned player tried to add. [%s@%s]\n", defname, ns->host); fflush (logfile); return 0; } @@ -863,7 +863,11 @@ object *tmp, *next; tag_t next_tag=0, op_tag; int stop = 0; + int j, k, wvratio; + char putstring[128], tmpstr[16]; + + /* if you're flying, you cna't pick up anything */ if (QUERY_FLAG (op, FLAG_FLYING)) return 1; @@ -872,6 +876,9 @@ next = op->below; if (next) next_tag = next->count; + + /* loop while there are items on the floor that are not marked as + * destroyed */ while (next && ! was_destroyed (next, next_tag)) { tmp = next; @@ -894,28 +901,21 @@ } #endif /* SEARCH_ITEMS */ + /* high bit set? We're using the new autopickup model */ + if(!(op->contr->mode & PU_NEWMODE)) + { switch (op->contr->mode) { case 0: return 1; /* don't pick up */ - - case 1: - pick_up (op, tmp); + case 1: pick_up (op, tmp); return 1; - - case 2: - pick_up (op, tmp); + case 2: pick_up (op, tmp); return 0; - case 3: return 0; /* stop before pickup */ - - case 4: - pick_up (op, tmp); + case 4: pick_up (op, tmp); break; - - case 5: - pick_up (op, tmp); + case 5: pick_up (op, tmp); stop = 1; break; - case 6: if (QUERY_FLAG (tmp, FLAG_KNOWN_MAGICAL) && ! QUERY_FLAG(tmp, FLAG_KNOWN_CURSED)) @@ -935,6 +935,179 @@ >= op->contr->mode) pick_up(op,tmp); } + } /* old model */ + else + { + /* NEW pickup handling */ + if(op->contr->mode & PU_DEBUG) + { + /* some debugging code to figure out item information */ + if(tmp->name!=NULL) + sprintf(putstring,"item name: %s item type: %d weight/value: %d", + tmp->name, tmp->type, + (query_cost(tmp, op, F_TRUE)*100 / (tmp->weight * MAX(tmp->nrof,1)))); + else + sprintf(putstring,"item name: %s item type: %d weight/value: %d", + tmp->arch->name, tmp->type, + (query_cost(tmp, op, F_TRUE)*100 / (tmp->weight * MAX(tmp->nrof,1)))); + new_draw_info(NDI_UNIQUE, 0,op,putstring); + + sprintf(putstring,"...flags: "); + for(k=0;k<4;k++) + { + for(j=0;j<32;j++) + { + if((tmp->flags[k]>>j)&0x01) + { + sprintf(tmpstr,"%d ",k*32+j); + strcat(putstring, tmpstr); + } + } + } + new_draw_info(NDI_UNIQUE, 0,op,putstring); + +#if 0 + /* print the flags too */ + for(k=0;k<4;k++) + { + fprintf(stderr,"%d [%d] ", k, k*32+31); + for(j=0;j<32;j++) + { + fprintf(stderr,"%d",tmp->flags[k]>>(31-j)&0x01); + if(!((j+1)%4))fprintf(stderr," "); + } + fprintf(stderr," [%d]\n", k*32); + } +#endif + } + /* philosophy: + * It's easy to grab an item type from a pile, as long as it's + * generic. This takes no game-time. For more detailed pickups + * and selections, select-items shoul dbe used. This is a + * grab-as-you-run type mode that's really useful for arrows for + * example. + * The drawback: right now it has no frontend, so you need to + * stick the bits you want into a calculator in hex mode and then + * convert to decimal and then 'pickup <#> + */ + + /* the first two modes are exclusive: if NOTHING we return, if + * STOP then we stop. All the rest are applied sequentially, + * meaning if any test passes, the item gets picked up. */ + + /* if mode is set to pick nothing up, return */ + if(op->contr->mode & PU_NOTHING) return 1; + /* if mode is set to stop when encountering objects, return */ + /* take STOP before INHIBIT since it doesn't actually pick + * anything up */ + if(op->contr->mode & PU_STOP) return 0; + /* useful for going into stores and not losing your settings... */ + /* and for battles wher you don't want to get loaded down while + * fighting *. + if(op->contr->mode & PU_INHIBIT) return 1; + + /* prevent us from turning into auto-thieves :) */ + if (QUERY_FLAG (tmp, FLAG_UNPAID)) continue; + + /* all food and drink if desired */ + /* question: don't pick up known-poisonous stuff? */ + if(op->contr->mode & PU_FOOD) + if (tmp->type == FOOD) + { pick_up(op, tmp); if(0)fprintf(stderr,"FOOD\n"); continue; } + if(op->contr->mode & PU_DRINK) + if (tmp->type == DRINK) + { pick_up(op, tmp); if(0)fprintf(stderr,"DRINK\n"); continue; } + if(op->contr->mode & PU_POTION) + if (tmp->type == POTION) + { pick_up(op, tmp); if(0)fprintf(stderr,"POTION\n"); continue; } + + /* pick up all magical items */ + if(op->contr->mode & PU_MAGICAL) + if (QUERY_FLAG (tmp, FLAG_KNOWN_MAGICAL) && ! QUERY_FLAG(tmp, FLAG_KNOWN_CURSED)) + { pick_up(op, tmp); if(0)fprintf(stderr,"MAGICAL\n"); continue; } + + if(op->contr->mode & PU_VALUABLES) + { + if (tmp->type == MONEY || tmp->type == GEM) + { pick_up(op, tmp); if(0)fprintf(stderr,"MONEY/GEM\n"); continue; } + } + + /* bows and arrows. Bows are good for selling! */ + if(op->contr->mode & PU_BOW) + if (tmp->type == BOW) + { pick_up(op, tmp); if(0)fprintf(stderr,"BOW\n"); continue; } + if(op->contr->mode & PU_ARROW) + if (tmp->type == ARROW) + { pick_up(op, tmp); if(0)fprintf(stderr,"ARROW\n"); continue; } + + /* all kinds of armor etc. */ + if(op->contr->mode & PU_ARMOUR) + if (tmp->type == ARMOUR) + { pick_up(op, tmp); if(0)fprintf(stderr,"ARMOUR\n"); continue; } + if(op->contr->mode & PU_HELMET) + if (tmp->type == HELMET) + { pick_up(op, tmp); if(0)fprintf(stderr,"HELMET\n"); continue; } + if(op->contr->mode & PU_SHIELD) + if (tmp->type == SHIELD) + { pick_up(op, tmp); if(0)fprintf(stderr,"SHIELD\n"); continue; } + if(op->contr->mode & PU_BOOTS) + if (tmp->type == BOOTS) + { pick_up(op, tmp); if(0)fprintf(stderr,"BOOTS\n"); continue; } + if(op->contr->mode & PU_GLOVES) + if (tmp->type == GLOVES) + { pick_up(op, tmp); if(0)fprintf(stderr,"GLOVES\n"); continue; } + if(op->contr->mode & PU_CLOAK) + if (tmp->type == CLOAK) + { pick_up(op, tmp); if(0)fprintf(stderr,"GLOVES\n"); continue; } + + /* hoping to catch throwing daggers here */ + if(op->contr->mode & PU_MISSILEWEAPON) + if(tmp->type == WEAPON && QUERY_FLAG(tmp, FLAG_IS_THROWN)) + { pick_up(op, tmp); if(0)fprintf(stderr,"MISSILEWEAPON\n"); continue; } + + /* careful: chairs and tables are weapons! */ + if(op->contr->mode & PU_ALLWEAPON) + { + if(tmp->type == WEAPON && tmp->name!=NULL) + { + if(strstr(tmp->name,"table")==NULL && + strstr(tmp->name,"chair")==NULL) + { pick_up(op, tmp); if(0)fprintf(stderr,"WEAPON\n"); continue; } + } + if(tmp->type == WEAPON && tmp->name==NULL) + { + if(strstr(tmp->arch->name,"table")==NULL && + strstr(tmp->arch->name,"chair")==NULL) + { pick_up(op, tmp); if(0)fprintf(stderr,"WEAPON\n"); continue; } + } + } + + /* misc stuff that's useful */ + if(op->contr->mode & PU_KEY) + if (tmp->type == KEY || tmp->type == SPECIAL_KEY) + { pick_up(op, tmp); if(0)fprintf(stderr,"KEY\n"); continue; } + + /* any of the last 4 bits set means we use the ratio for value + * pickups */ + if(op->contr->mode & PU_RATIO) + { + /* use value density to decide what else to grab */ + /* >=7 was >= op->contr->mode */ + /* >=7 is the old standard setting. Now we take the last 4 bits + * and multiply them by 5, giving 0..15*5== 5..75 */ + wvratio=(op->contr->mode & PU_RATIO) * 5; + if ((query_cost(tmp, op, F_TRUE)*100 / (tmp->weight * MAX(tmp->nrof, 1))) >= wvratio) + { + pick_up(op, tmp); + if(0)fprintf(stderr,"HIGH WEIGHT/VALUE ["); + if(tmp->name!=NULL) if(0)fprintf(stderr,"%s", tmp->name); + else if(0)fprintf(stderr,"%s",tmp->arch->name); + if(0)fprintf(stderr,",%d] = ", tmp->type); + if(0)fprintf(stderr,"%d\n",query_cost(tmp,op,F_TRUE)*100 / (tmp->weight * MAX(tmp->nrof,1))); + continue; + } + } + } /* the new pickup model */ } return ! stop; } From andi.vogl at gmx.net Fri Aug 3 12:08:27 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:32 2005 Subject: [CF-Devel] current bugs Message-ID: It looks like there's a number of serious bugs that sneaked into crossfire recently: 1) Most invisible items are visible to the players (inv. exits, directors and stuff). You can see this wherever there are "invisible" exits. 2) Directors and Movers don't work anymore. Players don't get moved, bullets/missiles don't get affected by directors. 3) Sometimes it happens that walls get teleported by teleporters. (Walls are of course supposed to be unaffected by teleporters). This can be seen in the map /peterm/Demonology/EarthStudy for example. When you speak the twisted name of the earth elemental, sometimes it happens that peaces of the walls get teleported together with the monster. Any ideas what has caused this? Andreas V. From mwedel at scruznet.com Fri Aug 3 14:02:04 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:32 2005 Subject: [CF-Devel] Technical Object Questions In-Reply-To: <01080309532100.01339@localhost.localdomain> Message-ID: On Fri, 3 Aug 2001, Chachkoff Yann wrote: > About the object classes/subclasses... > What do you think of a simple "Object tree" ? I was thinking of a hierarchy > of objects like this one (it is only an incomplete example !): I'd do it a bit differently - I had basically come up with something like: Object - Items (anything that can be picked up carried) -- Equipment (anything that can be applied) --- armor/weapons/gloves/helmet/rings/etc The rationale for that is that way anything that modifies the player has the same code loop to use. That ring could add an attacktype, increase damage, etc. By in large, all of those have similar abilities. -- Spell casting objects (eg potions, scrolls, wands, rods) > The common functions used by all objects (query_name for example) could be > referenced in the archetype itself (by function pointers). If a specific > subclass of object requires a different procedure, simply reference another > one in its archetype. This could give more flexibility to the code, because > it would allow a clear separation of "What the server should do" (the rules > of the game and the global interactions between objects) and "What the > objects do" (The server no longer need to know how the object store its > datas). Note that one issue here is that this data still needs to get saved to disk. My way to handle this would be that the base loader would know about the command values (name, x and y location, etc), and if it get a field it did not know about, it would pass that line off to the loader for that specific object type. > I know that it could be a lot of work. I just want to know: > - If anyone is against the idea (and the possible objections); The biggest issue is the amount of work (basically, all the archetypes would need to get changed, and a lot of the code within the program needs to get changed). And while it would make the code more extensible, the immediate effect of all this change is nothing readily apparant to those who player the game - it just makes future enhancements easier. I had started down the road a little, and came to the conclusion that it was going to be a lot of work, and that there were more important things to work on. Note that the engine/rules split does not necessarily require a redo of the object layout - just doing that would make such a split more useful if people do want to develop other rule based systems. > - If anyone has an idea for a complete object hierarchy; I have a bit more breakdown. However, almost anything will probably get changed as work is done on it, as you realize sub object X also uses field Z, which subobject Y also uses, so maybe X and Y should get merged, etc. > Maybe reusing the old Advanced Combat System ideas and preliminary code could > be interesting for that ? Perhaps. I never looked at the advanced combat system much. From mwedel at scruz.net Sat Aug 4 20:02:08 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:33 2005 Subject: [CF-Devel] current bugs References: Message-ID: <3B6C9B10.5A123CF0@scruz.net> Andreas Vogl wrote: > > It looks like there's a number of serious bugs that sneaked > into crossfire recently: > > 1) Most invisible items are visible to the players (inv. exits, directors > and stuff). You can see this wherever there are "invisible" exits. Error in coding of the update_position. I believe I have a fix for this - is there a specific map example you can give me so that I can verify this? > > 2) Directors and Movers don't work anymore. Players don't get moved, > bullets/missiles don't get affected by directors. Fixed this (will check into CVS shortly). The check for spell like objects (which once we find one, we stop the walk on checks) was checking the wrong value and checking too early.) > > 3) Sometimes it happens that walls get teleported by teleporters. > (Walls are of course supposed to be unaffected by teleporters). > This can be seen in the map /peterm/Demonology/EarthStudy for example. > When you speak the twisted name of the earth elemental, sometimes > it happens that peaces of the walls get teleported together > with the monster. This is not really a new bug in terms of teleporters. What used to be the case is that multipart objects were also saved/loaded last, so they would always be on top of any walls (in terms of pentagrams). With the new map code, this is no longer the case - a wall may in fact be in top of a section of the pentagram (as demonstrated in the map above). Currently, the teleport code does no checking to see the nature of the object it is moving. It will be easy to put in a check so things like walls and other objects that should be stationary don't get moved. I'll do that and put that in with the other checkins. From andi.vogl at gmx.net Sun Aug 5 02:48:38 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:33 2005 Subject: [CF-Devel] current bugs In-Reply-To: <3B6C9B10.5A123CF0@scruz.net> Message-ID: Mark W. wrote: > > It looks like there's a number of serious bugs that sneaked > > into crossfire recently: > > > > 1) Most invisible items are visible to the players (inv. exits, directors > > and stuff). You can see this wherever there are "invisible" exits. > > Error in coding of the update_position. I believe I have a fix for > this - is there a specific map example you can give me so that I can > verify this? Yes, the portgate and citygate maps in scorn are supposed to have invisible exits. Currently those are visible. The strange part is that they're not only supposed to be invisible, but also hidden below the floor. Both of which seems to fail... > > 2) Directors and Movers don't work anymore. Players don't get > > moved, bullets/missiles don't get affected by directors. > > Fixed this (will check into CVS shortly). The check for spell like > objects (which once we find one, we stop the walk on checks) was > checking the wrong value and checking too early.) Thanks a lot Mark. That was the real ugly one. (Had broken many maps). > > > > 3) Sometimes it happens that walls get teleported by teleporters. > > (Walls are of course supposed to be unaffected by teleporters). > > This can be seen in the map /peterm/Demonology/EarthStudy for > > example. When you speak the twisted name of the earth elemental, > > sometimes it happens that peaces of the walls get teleported > > together with the monster. > > This is not really a new bug in terms of teleporters. > > What used to be the case is that multipart objects were also saved/loaded > last, so they would always be on top of any walls (in terms of pentagrams). > > With the new map code, this is no longer the case - a wall may in fact be > in top of a section of the pentagram (as demonstrated in the map above). > Currently, the teleport code does no checking to see the nature of the > object it is moving. It will be easy to put in a check so things like > walls and other objects that should be stationary don't get moved. I'll > do that and put that in with the other checkins. As far as I've seen, the problem appeared only with the multipart teleporters (the pentagrams in Demontower and Chaoslair). Those seemed not to work correctly before and thus nobody noticed there are some walls on them which are not meant to be teleported. Maybe it is an easier and better way to correct those maps instead of not allowing walls (and other stuff) to be teleported. I could think of many cases where teleporting "special" objects like magic_ears/walls/ exits etc might be quite useful. Only things that should not be allowed to get teleported IMO are teleporters themselves and floors ("is_floor 1"). Actually it would be great if floors were completely ignored by teleporters to allow the latter being put below floors and still working properly. But there might be more important stuff to do. Andreas V. From mwedel at scruz.net Sun Aug 5 16:23:40 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:33 2005 Subject: [CF-Devel] current bugs References: Message-ID: <3B6DB95C.51419426@scruz.net> > Yes, the portgate and citygate maps in scorn are supposed to have > invisible exits. Currently those are visible. The strange part is that > they're not only supposed to be invisible, but also hidden below > the floor. Both of which seems to fail... That seems to be OK now. > > As far as I've seen, the problem appeared only with the multipart > teleporters (the pentagrams in Demontower and Chaoslair). Those seemed > not to work correctly before and thus nobody noticed there are some > walls on them which are not meant to be teleported. That is correct. single space teleporters would still get put in the appropriate stacking on the map. Multipart teleporters are what have changed. > > Maybe it is an easier and better way to correct those maps instead > of not allowing walls (and other stuff) to be teleported. I could think > of many cases where teleporting "special" objects like magic_ears/walls/ > exits etc might be quite useful. > > Only things that should not be allowed to get teleported IMO are > teleporters themselves and floors ("is_floor 1"). > Actually it would be great if floors were completely ignored by > teleporters to allow the latter being put below floors and still > working properly. But there might be more important stuff to do. the code change I made will have it such that floors and no_pass objects will not get teleported. Currently, the teleporter code only looks for the object immediately above. I'm putting a change in right now so that it will skip over the floors and no pass objectts looking for one to move. This will allow teleporters to get buried below floors. Removing the no_pass check is easy to do. Note that teleporting such objects may be of questionable use, because once teleported, nothing else can get teleported to that space (its blocked after all). From mwedel at scruz.net Sun Aug 5 16:34:50 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:33 2005 Subject: [CF-Devel] Various proposed changes Message-ID: <3B6DBBFA.5FFA22EF@scruz.net> All of these are very easy to do, but may have consequences that I don't fully see. Eating flesh when starving: Currently, when food gets to zero, your character blindly grabs for a bite to eat. This only looks for food/drink/poison items. It does not look for flesh items. If you have a big pile of wyvern stakes or other body parts and no other food, you will die of starvation. I suggest that this grabbing for a bite to eat also work on flesh items. It could very easily be coded that eating a flesh item happens after we don't find any better suitable items. detect magic/detect curse detecting non equipment items: If you case either of these spells, things like gates, buttons, and various other non pickable objects will flash magical - often times something buried beneath a floor may flash (or maybe its the floor). IMO, this is just a little odd - things like the gates aren't really magical, they are just keyed such to denote that magic can not pass if I recall. My suggestion is that we only flash the magical effect (and so mark the objects) that can actually get picked up. My only thought on this is that monsters won't get flashed (don't know if they do right now, but shouldn't detect monster get used for that anyways? But my thought is that some maps in pupland (or elsewhere) may require players being able to see the no magic areas to successfully do the map? detect monster improvement (just thought of this one): I've never found much use for this spell, but have an idea that may make it more useful, especially combined with fog of war code - instead of just doing the little magical flash showing where monsters are, show the actual face of the monster? I think this can be done pretty easily just by copying the monster face over to the magical effect. This can be done for other spells also - think of things like 'detect walls' that let you know the layout of the walls in the area? detect treasure, etc. From mwedel at scruz.net Sun Aug 5 17:33:26 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:33 2005 Subject: [CF-Devel] Bug report - Persistent book pictures References: <01073113423701.01820@localhost.localdomain> Message-ID: <3B6DC9B6.DF02DD17@scruz.net> Chachkoff Yann wrote: > > Put some spellbooks in a bookshelf. Learn them. The book pictures will not > disappear as expected. Fixed in CVS. From jbontje at suespammers.org Sun Aug 5 17:56:20 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:01:33 2005 Subject: [CF-Devel] current bugs In-Reply-To: <3B6DB95C.51419426@scruz.net> References: <3B6DB95C.51419426@scruz.net> Message-ID: <20010806005620.A1768@mids.student.utwente.nl> After Marks last fixes the code looks stable again. Big thanks! Joris Bontje / mids From tanner at real-time.com Sun Aug 5 21:09:13 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:01:33 2005 Subject: [CF-Devel] current bugs In-Reply-To: <20010806005620.A1768@mids.student.utwente.nl>; from jbontje@suespammers.org on Mon, Aug 06, 2001 at 12:56:20AM +0200 References: <3B6DB95C.51419426@scruz.net> <20010806005620.A1768@mids.student.utwente.nl> Message-ID: <20010805210913.B29128@real-time.com> Quoting Joris Bontje (jbontje@suespammers.org): > After Marks last fixes the code looks stable again. > Big thanks! Are we keeping track of the bugs in bugzilla or on sourceforge anywhere? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From lohner at debian.org Mon Aug 6 04:29:24 2001 From: lohner at debian.org (Nils Lohner) Date: Thu Jan 13 18:01:33 2005 Subject: [CF-Devel] autopickup patch summary Message-ID: <200108060929.LAA06522@topaze.ecf.teradyne.com> Here's some info regarding the autopickup patches I posted. Mark, can you please try this and check it into CVS? The patch takes into account the 'old' way of doing things and tries to conform to it as much as possible. The weight/value pickup ratio is there, as are the 'stop' and 'valubales' options. Nils. - they're against 1.0.0 of the server and gtk client - they touch only one file in the client - they touch only 3-4 files (one routine each) in the server - the server mods don't break any clients, i.e. the old autopickup stuff is 100% available. BUGS - typo: + * fighting *. + if(op->contr->mode & PU_INHIBIT) return 1; ...that should be a */ to terminate the comment - omission: + if(tmp->type == WEAPON && tmp->name!=NULL) under that statement, both tmp->name and tmp->arch->name should check for 'bed' as well, else you'll pick up beds automatically. Chairs, beds and tables are classed 'weapon'... From andi.vogl at gmx.net Mon Aug 6 16:19:13 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:33 2005 Subject: [CF-Devel] current bugs In-Reply-To: <3B6DB95C.51419426@scruz.net> Message-ID: Mark W. wrote: > > Maybe it is an easier and better way to correct those maps instead > > of not allowing walls (and other stuff) to be teleported. > > the code change I made will have it such that floors and no_pass > objects will not get teleported. > > Currently, the teleporter code only looks for the object immediately > above. I'm putting a change in right now so that it will skip over the > floors and no pass objectts looking for one to move. This will allow > teleporters to get buried below floors. That's a great improvement actually. Thanks for this. > Removing the no_pass check is easy to do. Note that teleporting such > objects may be of questionable use, because once teleported, nothing > else can get teleported to that space (its blocked after all). Well, in fact teleporting boulders and walls (= no_pass objects) is already in use for several maps in pupland and the mak tower. I know this sounds silly now, but I really forgot about this in my first post - Sorry for that. These teleporters are designed to work only once, e.g. teleporting a wall away, similar to opening a gate but with different "style". The problem you mentioned above does not occur as long as teleporting no_pass objects is used in the correct way. So, I suggest to enable teleporting of no_pass objects again. If nobody has objections I will do this myself (It is very easy anyways). Andreas V. From ttunturi at cc.hut.fi Thu Aug 9 13:09:08 2001 From: ttunturi at cc.hut.fi (Timo Tunturi) Date: Thu Jan 13 18:01:33 2005 Subject: [CF-Devel] bless Message-ID: There is a feature in bless that makes it powerful enough to be considered a bug, imo. Any low lev character can bless themself to -120 wc and -120 ac... Just keep on blessing yourself, the effect stacks. After reaching high figures in wc and ac, you can just cast one bless every now and then to keep the effect. Recasting resets the timer. With full bless bonii a lvl10 player can kill for example cyclops in melee. Using bless I leveled a quetzal to 66 in 2 days with no hand-down equipment. Just a weapon of Mostrai, slays giants and very easy to get, and blessing to kill cyclops and titans. /Timo Tuna From bugs at real-time.com Fri Aug 10 02:10:01 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:33 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200108100710.f7A7A1M24167@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=368 http://bugzilla.real-time.com/show_bug.cgi?id=369 http://bugzilla.real-time.com/show_bug.cgi?id=374 From joel at mamia.prninfo.com Sun Aug 12 20:35:31 2001 From: joel at mamia.prninfo.com (Joel South) Date: Thu Jan 13 18:01:33 2005 Subject: [CF-Devel] bug in warrior prooving tower Message-ID: <200108130135.VAA00911@mamia.prninfo.com> The pentagrams at /mak/chaos/down5 and /mak/chaos/up5 are broken. The pentagrams did not teleport me anywhere,even after i dropped the required items. I tried this quest a few other times,but i each time,the pentagrams do not teleport me anywhere. The pentagram still takes my items,but does not teleport me anywhere. Could other pentagrams be broken as well,or is it just the warrior tower. Please fix this soon,i really want to fight lorkas. Joel Southall From andi.vogl at gmx.net Mon Aug 13 06:20:31 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:33 2005 Subject: [CF-Devel] bug in mutliparts (RE: warrior prooving tower) In-Reply-To: <200108130135.VAA00911@mamia.prninfo.com> Message-ID: > The pentagrams at /mak/chaos/down5 and /mak/chaos/up5 are broken. The > pentagrams did not teleport me anywhere,even after i dropped the required > items. I tried this quest a few other times,but i each time,the pentagrams > do not teleport me anywhere. The pentagram still takes my items,but does > not teleport me anywhere. Could other pentagrams be broken as well,or is > it just the warrior tower. Please fix this soon,i really want to fight > lorkas. Joel S. is pointing out to a serious bug in the way multipart objects are handled today. All multisquare teleporters seem to be broken apparently. Even more, *all* multisquares behave strangely different than they used to. The reason is that the handling of multipart objects has been changed fundamentally. Here is an excerpt of "crossfire/doc/map-techical.txt" (a formidable docu btw.): "Multipart objects pose a tricky problem, in that they have to appear together in the map file - this makes proper handling of layers hard to deal with. In old map code, all the single spaces objects were saved, and then all the multi part objects were saved. This effectively means that the multi part objects always ended up on top. [...] Current code now only saves the head of the object. When the map is loaded, the objects on the map are examined to see what objects need to have more objects added on. Additional parts linked in are put just above floor level when linked in, [...] The effect of saving only the head does have the effect of not being able to customize the non head parts of the object. [...]" The problem is, that in several cases, all the multisquare objects (not only the head) need to have certain attributes set in order to work as they should do. But since only the head is saved, these attributes are now missing in the other parts. E.g. to make a multipart invisible, all parts need "invisible 1". To make it blockable, all parts need "no_pass 1". To make it work as a teleporter, all parts need the connected and path attributes. All this is is broken currently. I think the best solution to this problem would be to make the code look at the head only, whenever there is a multipart object to be dealt with. This is already the case for most attributes (like monster stats) and should be extended to the rest. Besides, it might be a good idea to place monster multis always ontop of non-alive multis at map-loading, in order to make multi-teleporters work. Andreas V. From mwedel at scruz.net Tue Aug 14 01:25:53 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:33 2005 Subject: [CF-Devel] bug in mutliparts (RE: warrior prooving tower) References: Message-ID: <3B78C471.A425AD9E@scruz.net> Andreas Vogl wrote: > I think the best solution to this problem would be to make the > code look at the head only, whenever there is a multipart object > to be dealt with. This is already the case for most attributes > (like monster stats) and should be extended to the rest. > Besides, it might be a good idea to place monster multis always ontop > of non-alive multis at map-loading, in order to make multi-teleporters > work. Looking at the head of the object would be the right thing to do. I had already done that for exits. I'm not sure what all multipart objects are out there that need special handling. Obviously, teleporters are one. Exits have already been done. I'm not sure what other objects may have a similar problem. For simplicity, copying the flags from the head to the more parts will at least take care of the blocked and invisible flags. This is a tradeoff, in that it means the other parts contain some real values, but it means that some basic functions, like update_position don't need to look at the head for one piece of information (invisible) while looking at the more part for the actual face to use if any. From mwedel at scruz.net Tue Aug 14 02:24:48 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:33 2005 Subject: [CF-Devel] bug in mutliparts (RE: warrior prooving tower) References: <3B78C471.A425AD9E@scruz.net> Message-ID: <3B78D240.D605332F@scruz.net> I just thought of a case where the blocked value of the head should not get transferred to the reast of the objects - the shop buildings. In most cases, the head is blocked, but if that gets extended to all parts, that obviously won't work very well. I'm not sure what the best solution is. One might be to clear to the blocked flag from the shops, and if desired, put an invisible blocked force object to prevent access to certain shop spaces. Generally, the blocking of some of the shops generally doesn't work as it sort of presumes the entrance should always be on the southern side, and that certainly is not the case in many cities. From andi.vogl at gmx.net Tue Aug 14 04:54:16 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:33 2005 Subject: [CF-Devel] bug in mutliparts (RE: warrior prooving tower) In-Reply-To: <3B78C471.A425AD9E@scruz.net> Message-ID: Mark W. wrote: > I'm not sure what all multipart objects are out there that need > special handling. Obviously, teleporters are one. Exits have > already been done. I'm not sure what other objects may have a > similar problem. Currently, to my knowing the following types of mutliparts exist: - floor (big mountains) - buildings (= exits) - pentagram teleporters - monsters I think monsters and buildings should be placed always ontop (like all currently do). Teleporters should be placed ontop everything except monsters. Floor should probably be placed below everything else, but that's hard to say. I could imagine wanting both to put sth below and above it. > For simplicity, copying the flags from the head to the more parts > will at least take care of the blocked and invisible flags. Hm... Are you sure it is better to copy the values into the body, rather than making the code always look at the head? Since every body object has a pointer directly to the head, I don't think this would cost any cpu time. > I just thought of a case where the blocked value of the head should > not get transferred to the reast of the objects - the shop buildings. > In most cases, the head is blocked, but if that gets extended to all > parts, that obviously won't work very well. > > I'm not sure what the best solution is. One might be to clear to the > blocked flag from the shops [...] True. Unfortunately, as long as we keep the current scheme of saving only the multi-heads, the no_pass won't work for buildings anyways. I do agree that this is a tricky problem. Walking over rooftops of big buildings feels kinda odd. Andreas V. From mwedel at scruz.net Wed Aug 15 02:00:59 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:33 2005 Subject: [CF-Devel] bug in mutliparts (RE: warrior prooving tower) References: Message-ID: <3B7A1E2B.AF51EDE2@scruz.net> Andreas Vogl wrote: > Currently, to my knowing the following types of mutliparts exist: > - floor (big mountains) > - buildings (= exits) > - pentagram teleporters > - monsters > > I think monsters and buildings should be placed always ontop (like > all currently do). Teleporters should be placed ontop everything > except monsters. > Floor should probably be placed below everything else, but > that's hard to say. I could imagine wanting both to put sth below > and above it. With the new system, you need to seperate internal stacking from visible stacking. Visible stacking is how it appears to the client. Internal stacking is how the above/below pointers really point. These two are no longer connecte in much any way. If there is a monster on the space, no matter what the internal stacking is, it will be put at the top of the visible stacking. The only case internal stacking really makes a difference is for the floor objects - objects below the floor in the internal stacking are not visible. currently, when the additional parts of multipart objects are linked in, they are put just above the floor object. This unfortunately means you can't hide a multipart object beneath the floor. I guess it wouldn't be too hard to fix this - if the head is beneath the floor, put the rest beneath the floor, otherwise it goes above the floor. > > > For simplicity, copying the flags from the head to the more parts > > will at least take care of the blocked and invisible flags. > > Hm... Are you sure it is better to copy the values into the > body, rather than making the code always look at the head? > Since every body object has a pointer directly to the head, > I don't think this would cost any cpu time. Costs a little, in that you need to have a if (op->head) look at op->head values, otherwise look at op values. Real performance effects are probably not that great. However, currently link_multipart_object, which is what adds in these other object parts, does duplicate the name and title - duplicating invisible and blocked would be pretty trivial, and keeps life simpler (this way, things like looking a the space does not need to get updated, nor do other functions). Plus, adding the invislbe and blocked values to link_multipart_objects would be pretty trivial to do. > True. Unfortunately, as long as we keep the current scheme of saving > only the multi-heads, the no_pass won't work for buildings anyways. > I do agree that this is a tricky problem. Walking over rooftops > of big buildings feels kinda odd. The building is sort of a no one situation. If you make it so that you can't walk on the roofs, it means that shops can only be on the north side of roads. Its a little tricky, in that when the other parts of the multipart objects are linked in, it will inherit the flags of the archetype for the more section (blocked and/or invisible). So these really need to be set or cleared, depending mostly on if the head is different from the archetype. From bugs at real-time.com Thu Aug 16 09:25:01 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:33 2005 Subject: [CF-Devel] [Bug 376] New - Increasing INT with potions Message-ID: <200108161425.f7GEP1Y24648@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=376 *** shadow/376 Thu Aug 16 09:25:01 2001 --- shadow/376.tmp.24645 Thu Aug 16 09:25:01 2001 *************** *** 0 **** --- 1,23 ---- + +============================================================================+ + | Increasing INT with potions | + +----------------------------------------------------------------------------+ + | Bug #: 376 Product: Crossfire | + | Status: NEW Version: CVS | + | Resolution: Platform: PC | + | Severity: normal OS/Version: Windows 2000 | + | Priority: P2 Component: documentation | + +----------------------------------------------------------------------------+ + | Assigned To: crossfire-devel@lists.real-time.com | + | Reported By: lorenzee@sci.fi | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | URL: | + +============================================================================+ + | DESCRIPTION | + Im playing Gnome priest, INT max should be 29, still I cant increase it over 20 + with INT potions, even if I unwield all items i have. I only receive message: + nothing happened after drinking stat potion + + running windows 2000 pro dx-client + + -component is just quessed.... didn't get it. \ No newline at end of file From bugs at real-time.com Thu Aug 16 23:34:25 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:34 2005 Subject: [CF-Devel] [Bug 376] Changed - Increasing INT with potions Message-ID: <200108170434.f7H4YP906374@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=376 *** shadow/376 Thu Aug 16 09:25:01 2001 --- shadow/376.tmp.6370 Thu Aug 16 23:34:25 2001 *************** *** 2,9 **** | Increasing INT with potions | +----------------------------------------------------------------------------+ | Bug #: 376 Product: Crossfire | ! | Status: NEW Version: CVS | ! | Resolution: Platform: PC | | Severity: normal OS/Version: Windows 2000 | | Priority: P2 Component: documentation | +----------------------------------------------------------------------------+ --- 2,9 ---- | Increasing INT with potions | +----------------------------------------------------------------------------+ | Bug #: 376 Product: Crossfire | ! | Status: RESOLVED Version: CVS | ! | Resolution: INVALID Platform: PC | | Severity: normal OS/Version: Windows 2000 | | Priority: P2 Component: documentation | +----------------------------------------------------------------------------+ *************** *** 21,23 **** --- 21,32 ---- running windows 2000 pro dx-client -component is just quessed.... didn't get it. + + ------- Additional Comments From mwedel@scruz.net 2001-08-16 23:34 ------- + Unclear why you think a gnome priest should be able to have an int of 29. + Gnomes have no int modifier. + Priests have no int modifier. + This means that the max natural stat they can get is 20. + + If there actually is documentation that say that max is 29, please give more + details as to where it actually says that. \ No newline at end of file From leaf at real-time.com Fri Aug 17 00:02:10 2001 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:01:34 2005 Subject: [CF-Devel] [Bug 376] Changed - Increasing INT with potions In-Reply-To: <200108170434.f7H4YP906374@crusader.real-time.com> Message-ID: I have a typo on the website in the "natural stat limits" table for gnomes. I will fix it tomorrow morning. Sorry about that. - Rick Tanner leaf@real-time.com On Thu, 16 Aug 2001, bugs@real-time.com wrote: > + > + ------- Additional Comments From mwedel@scruz.net 2001-08-16 23:34 ------- > + Unclear why you think a gnome priest should be able to have an int of 29. > + Gnomes have no int modifier. > + Priests have no int modifier. > + This means that the max natural stat they can get is 20. > + > + If there actually is documentation that say that max is 29, please give more > + details as to where it actually says that. > \ No newline at end of file From yann.chachkoff at mailandnews.com Sat Aug 18 11:02:27 2001 From: yann.chachkoff at mailandnews.com (Chachkoff Yann) Date: Thu Jan 13 18:01:34 2005 Subject: [CF-Devel] Guile vs Python Message-ID: <01081812022701.01323@localhost.localdomain> Some CF-people asked me to get Python support in Crossfire. After some work around the serpent, I finally managed to make it run with Crossfire as a loadable module. The question I ask now is quite simple: knowing that: - Python and Guile are both scripting languages, doing more or less the same things; - both requiring their own dependencies to be built; - Python seems more popular than Guile; - As far as I know, only two scripted objects do exist right now in the game; should I: - Replace Guile by Python in the main Crossfire stream ? - Add Python support without removing Guile ? - Another clever solution ? Chachkoff Y. From mwedel at scruz.net Mon Aug 20 00:27:10 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:34 2005 Subject: [CF-Devel] Guile vs Python References: <01081812022701.01323@localhost.localdomain> Message-ID: <3B809FAE.4020204@scruz.net> My thought is this: 1) Crossfire should standardize on one scripting language and stick to that. While the argument could be made that more options are always better, the argument that simplicity is good also holds true (one could say that if there are already 2 scripting languages, why not 3 or 4 or whatever). As people who maintain things like maps and archetypes, it isn't a lot to ask people doing that to learn one scripting language and know how it works, but asking them to know a whole bunch may be difficult. 2) My personal choice for scripting would be perl, as that is what I am most familiar with. I have a feeling that the answers below would largely depend on what people are familiar with. Now my understanding is that python is much more similiar to perl than guile is. That, and the fact that python is probably much more commonly used than guile is probably a good thing. A scripting language that people know how to write in with minimal learning will probably promote more people to write scripted objects. Chachkoff Yann wrote: > should I: > - Replace Guile by Python in the main Crossfire stream ? > - Add Python support without removing Guile ? > - Another clever solution ? > > Chachkoff Y. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From leaf at real-time.com Mon Aug 20 19:30:59 2001 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:01:34 2005 Subject: [CF-Devel] checking server status Message-ID: Besides checking with the metaserver page or logging in with a client, is there any way to check and see if a Crossfire server is up and runing? For instance, telnet to (or ping) a certain port? - Rick Tanner leaf@real-time.com -- From jbontje at suespammers.org Tue Aug 21 02:03:50 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:01:34 2005 Subject: [CF-Devel] checking server status In-Reply-To: References: Message-ID: <20010821090350.A8358@mids.student.utwente.nl> On Mon, Aug 20, 2001 at 07:30:59PM -0500, Rick Tanner wrote: > Besides checking with the metaserver page or logging in with a client, is > there any way to check and see if a Crossfire server is up and runing? Well actually it IS logging in, but it works: mids@debian:~$ telnet mids.student.utwente.nl 13327 Trying 130.89.221.177... Connected to cal005307.student.utwente.nl. Escape character is '^]'. #version 1023 1026 Crossfire Server quit Connection closed by foreign host. You can also enter the command 'oldsocketmode' it doesnt work well, but you then can use some other commands like 'who' 'hiscore' and probably 'shout'. Joris Bontje / mids From jbontje at suespammers.org Sun Aug 26 16:53:00 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:01:34 2005 Subject: [CF-Devel] Bug Message-ID: <20010826235300.A6414@mids.student.utwente.nl> Hello, My server keeps crashing too much these days, here is some information that hopefully gives someone a clue about the cause. Running latest version of server from CVS (no updates after last compilation) --- log of crash 0 --- Saving map /pup_land/ancient/world Trying to load map /home/crossfire/share/crossfire/maps/pup_land/nurnberg/reception/reception. load_original_map: /pup_land/nurnberg/reception/reception (0) Adding friendly object woman. Adding friendly object woman. make_path_tofile /home/crossfire/var/crossfire/players/Gilded/_pup_land_nurnberg_apartment_main... Saving map /home/crossfire/var/crossfire/players/Gilded/_pup_land_nurnberg_apartment_main Trying to load map /home/crossfire/var/crossfire/players/Gilded/_city_apartment_apartments. load_original_map: /home/crossfire/var/crossfire/players/Gilded/_city_apartment_apartments (2) make_path_tofile /home/crossfire/var/crossfire/players/Gilded/Gilded.pl... LOGOUT: Player named Gilded from ip 195.68.114.34 LOGOUT: Player named Gilded from ip 195.68.114.34 Saving map /pup_land/port_e Saving map /pup_land/port_e_house Saving map /pup_land/port_w Saving map /pup_land/world Saving map /pup_land/lone_town/town Adding friendly object Poppy the pup. Saving map /pup_land/nurnberg/dick/house Saving map /pup_land/terminal Saving map /city/anthony/portgate Trying to load map /home/crossfire/share/crossfire/maps/pup_land/cave_weapon/cave1. load_original_map: /pup_land/cave_weapon/cave1 (0) Saving map /pup_land/nurnberg/dick/hell SIGSEGV received. Emergency saves disabled, no save attempted Cleaning up... make_path_tofile /home/crossfire/var/crossfire/players/Fido/_city_apartment_apartments... Saving map /home/crossfire/var/crossfire/players/Fido/_city_apartment_apartments Player on map that is being saved Saving map /pup_land/nurnberg/city Saving map /city/city Saving map /pup_land/world Saving map /city/taverns/inn Player on map that is being saved make_path_tofile /home/crossfire/var/crossfire/players/Joyir/_santo_dominion_sdomino_appartment... Saving map /home/crossfire/var/crossfire/players/Joyir/_santo_dominion_sdomino_appartment Player on map that is being saved Saving map /city/towers/tower.mad Player on map that is being saved make_path_tofile /home/crossfire/var/crossfire/players/Asclep/_city_apartment_apartments... Saving map /home/crossfire/var/crossfire/players/Asclep/_city_apartment_apartments Player on map that is being saved Saving map /pup_land/nurnberg/dick/heaven Saving map /pup_land/nurnberg/reception/reception make_path_tofile /home/crossfire/var/crossfire/players/Gilded/_city_apartment_apartments... Saving map /home/crossfire/var/crossfire/players/Gilded/_city_apartment_apartments Saving map /pup_land/cave_weapon/cave1 Player on map that is being saved --- end of log 0 --- --- gdb backtrace of crash 0 --- #0 0x40143881 in kill () from /lib/libc.so.6 #1 0x40109b8e in pthread_kill () from /lib/libpthread.so.0 #2 0x4010a05d in raise () from /lib/libpthread.so.0 #3 0x40144ce1 in abort () from /lib/libc.so.6 #4 0x0805fb54 in fatal_signal (make_core=1, close_sockets=1) at init.c:627 #5 0x0805fa2d in rec_sigsegv (i=11) at init.c:569 #6 0x40109c84 in pthread_sighandler () from /lib/libpthread.so.0 #7 0x401437b8 in sigaction () from /lib/libc.so.6 #8 0x0809f41c in blocked (m=0x0, x=-1, y=5) at map.c:298 #9 0x0806891e in path_to_player (mon=0x970c85c, pl=0x9752a84, mindiff=0) at player.c:358 #10 0x08064968 in monster_cast_spell (head=0x970c85c, part=0x970c85c, pl=0x9752a84, dir=136994603, rv=0xbffff940) at monster.c:527 #11 0x080642de in move_monster (op=0x970c85c) at monster.c:352 #12 0x0808c644 in process_object (op=0x970c85c) at time.c:980 #13 0x080633c9 in process_events (map=0x0) at main.c:860 #14 0x080638ee in main_crossfire (argc=2, argv=0xbffffd94) at main.c:1072 #15 0x400aeca1 in gh_call3 () from /usr/lib/libguile.so.9 #16 0x400b2408 in scm_boot_guile () from /usr/lib/libguile.so.9 #17 0x400d63e3 in scm_internal_lazy_catch () from /usr/lib/libguile.so.9 #18 0x400b23b6 in scm_boot_guile () from /usr/lib/libguile.so.9 #19 0x400b20b4 in scm_boot_guile () from /usr/lib/libguile.so.9 #20 0x400aecd4 in gh_enter () from /usr/lib/libguile.so.9 #21 0x080638a5 in main (argc=2, argv=0xbffffd94) at main.c:1046 #22 0x4013364f in __libc_start_main () from /lib/libc.so.6 --- end of gdb backtrace --- --- log of crash 1 --- Saving map /navar_city/city1enter Trying to load map /home/crossfire/var/crossfire/players/Gallos/_city_apartment_apartments. load_original_map: /home/crossfire/var/crossfire/players/Gallos/_city_apartment_apartments (2) Saving map /navar_city/city1 Trying to load map /home/crossfire/share/crossfire/maps/mak/giant/mainfloor. load_original_map: /mak/giant/mainfloor (0) Saving map /dtabb/darcap/darcap Saving map /world/world_e2 Saving map /world/world_e1 Saving map /mak/Entrance Trying to load map /home/crossfire/share/crossfire/maps/mak/giant/secondfloor. load_original_map: /mak/giant/secondfloor (0) Saving map /mak/MainFloor make_path_tofile /home/crossfire/var/crossfire/players/Gallos/Gallos.pl... Trying to load map /home/crossfire/share/crossfire/maps/city/mansion/entrance. load_original_map: /city/mansion/entrance (0) Trying to load map /home/crossfire/share/crossfire/maps/city/misc/beginners. load_original_map: /city/misc/beginners (0) make_path_tofile /home/crossfire/var/crossfire/players/Nigel/Nigel.pl... Trying to load map /home/crossfire/share/crossfire/maps/city/mansion/garden. load_original_map: /city/mansion/garden (0) hit_map(): next object destroyed hit_map(): next object destroyed Saving map /mak/giant/mainfloor SIGSEGV received. Emergency saves disabled, no save attempted Cleaning up... make_path_tofile /home/crossfire/var/crossfire/players/Fido/_city_apartment_apartments... Saving map /home/crossfire/var/crossfire/players/Fido/_city_apartment_apartments Player on map that is being saved Saving map /city/city Saving map /santo_dominion/tollpost Player on map that is being saved make_path_tofile /home/crossfire/var/crossfire/players/Gallos/_city_apartment_apartments... Saving map /home/crossfire/var/crossfire/players/Gallos/_city_apartment_apartments Saving map /mak/giant/secondfloor Player on map that is being saved Saving map /city/mansion/entrance Saving map /city/misc/beginners Player on map that is being saved Saving map /city/mansion/garden Player on map that is being saved --- end of log 1 --- --- gdb backtrace of crash 1 --- #0 0x40143881 in kill () from /lib/libc.so.6 #1 0x40109b8e in pthread_kill () from /lib/libpthread.so.0 #2 0x4010a05d in raise () from /lib/libpthread.so.0 #3 0x40144ce1 in abort () from /lib/libc.so.6 #4 0x0805fb54 in fatal_signal (make_core=1, close_sockets=1) at init.c:627 #5 0x0805fa2d in rec_sigsegv (i=11) at init.c:569 #6 0x40109c84 in pthread_sighandler () from /lib/libpthread.so.0 #7 0x401437b8 in sigaction () from /lib/libc.so.6 #8 0x0809f41c in blocked (m=0x0, x=-1, y=0) at map.c:298 #9 0x0806891e in path_to_player (mon=0x95bf768, pl=0x91d8e18, mindiff=0) at player.c:358 #10 0x08064968 in monster_cast_spell (head=0x95bf768, part=0x95bf768, pl=0x91d8e18, dir=137734507, rv=0xbffff940) at monster.c:527 #11 0x080642de in move_monster (op=0x95bf768) at monster.c:352 #12 0x0808c644 in process_object (op=0x95bf768) at time.c:980 #13 0x080633c9 in process_events (map=0x0) at main.c:860 #14 0x080638ee in main_crossfire (argc=2, argv=0xbffffd94) at main.c:1072 #15 0x400aeca1 in gh_call3 () from /usr/lib/libguile.so.9 #16 0x400b2408 in scm_boot_guile () from /usr/lib/libguile.so.9 #17 0x400d63e3 in scm_internal_lazy_catch () from /usr/lib/libguile.so.9 #18 0x400b23b6 in scm_boot_guile () from /usr/lib/libguile.so.9 #19 0x400b20b4 in scm_boot_guile () from /usr/lib/libguile.so.9 #20 0x400aecd4 in gh_enter () from /usr/lib/libguile.so.9 #21 0x080638a5 in main (argc=2, argv=0xbffffd94) at main.c:1046 #22 0x4013364f in __libc_start_main () from /lib/libc.so.6 --- end of gdb backtrace --- etc etc etc Hope this helps, Joris Bontje / mids From yann.chachkoff at mailandnews.com Mon Aug 27 18:00:11 2001 From: yann.chachkoff at mailandnews.com (Chachkoff Yann) Date: Thu Jan 13 18:01:34 2005 Subject: [CF-Devel] Bug In-Reply-To: <20010826235300.A6414@mids.student.utwente.nl> References: <20010826235300.A6414@mids.student.utwente.nl> Message-ID: <01082719001100.01406@localhost.localdomain> Le Dimanche 26 Ao?t 2001 17:53, vous avez ?crit : > Hello, > > My server keeps crashing too much these days, here is some information that > hopefully gives someone a clue about the cause. As you already know, I corrected those bugs (At least I expect it is correct now). I strongly suggest coders to read and test at least for some minutes their code before putting it into CVS - that could prevent such huge bugs to happen. Chachkoff Y. From don_grey at hotmail.com Mon Aug 27 23:16:56 2001 From: don_grey at hotmail.com (Don Grey) Date: Thu Jan 13 18:01:34 2005 Subject: [CF-Devel] BUG: crashes MiDS Message-ID: Upon completion of the Wizard Tower quest and getting the ying/yang key.. The game crashes.. I checked it 3 times and each time it died.. FYI Asclep _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From jbontje at suespammers.org Wed Aug 29 15:54:54 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:01:34 2005 Subject: [CF-Devel] Bug caused in /Lake_Country/Mwizard/Mwizard6 Message-ID: <20010829225454.A10401@mids.student.utwente.nl> Here I am again :-) Running latest CVS version (update Aug 29 20:40 CEST) when someone goes to /Lake_Country/Mwizard/Mwizard6 and kills opie and fonzie and goes into the teleporter the server crashes Joris Bontje / mids --- piece of end of logfile --- load_original_map: /pup_land/nurnberg/apartment/to_past (0) Warning: Tried to insert object wrong part of multipart object. Warning: Tried to insert object wrong part of multipart object. Warning: Tried to insert object wrong part of multipart object. Warning: Tried to insert object wrong part of multipart object. victim (arch door_1, name door) already dead in hit_player() Warning: Tried to insert object wrong part of multipart object. hit_map(): next object destroyed hit_map(): next object destroyed hit_map(): next object destroyed Saving map /Lake_Country/Mwizard/Mwizard5 load_original_map: /styles/monsterstyles/angel/angel_6 (8) Trying to load map /home/crossfire/share/crossfire/maps/pup_land/ancient/world. load_original_map: /pup_land/ancient/world (0) Adding friendly object Ancient of Poppy the pup. Trying to load map /home/crossfire/share/crossfire/maps/pup_land/ancient/ruin/village. load_original_map: /pup_land/ancient/ruin/village (0) Warning: Tried to insert object wrong part of multipart object. Trying to load map /home/crossfire/share/crossfire/maps/pup_land/ancient/ruin/house2. load_original_map: /pup_land/ancient/ruin/house2 (0) Resetting map /HallOfSelection. Saving map /city/anthony/portgate Saving map /random/0000000000000024 Saving map /random/0000000000000023 Saving map /city/city make_path_tofile /home/crossfire/var/crossfire/players/Aule/Aule.pl... make_path_tofile /home/crossfire/var/crossfire/players/Gilded/_city_apartment_apartments... Saving map /home/crossfire/var/crossfire/players/Gilded/_city_apartment_apartments Saving map /pup_land/nurnberg/city Trying to load map /home/crossfire/share/crossfire/maps/Lake_Country/Mwizard/Mwizard0. load_original_map: /Lake_Country/Mwizard/Mwizard0 (0) --- end of piece --- --- gdb backtrace --- #0 0x08065fe5 in disthit_att (dir=5, ob=0x961f4cc, enemy=0x912bbb8, part=0x961f4cc, rv=0xbffff908) at monster.c:1118 1118 if ((ob->stats.hp*100)/ob->stats.maxhp < ob->run_away) (gdb) bt #0 0x08065fe5 in disthit_att (dir=5, ob=0x961f4cc, enemy=0x912bbb8, part=0x961f4cc, rv=0xbffff908) at monster.c:1118 #1 0x0806498a in move_monster (op=0x961f4cc) at monster.c:401 #2 0x0808d094 in process_object (op=0x961f4cc) at time.c:980 #3 0x080637d9 in process_events (map=0x0) at main.c:864 #4 0x08063cfe in main_crossfire (argc=2, argv=0xbffffd34) at main.c:1076 #5 0x400aeca1 in gh_call3 () from /usr/lib/libguile.so.9 #6 0x400b2408 in scm_boot_guile () from /usr/lib/libguile.so.9 #7 0x400d63e3 in scm_internal_lazy_catch () from /usr/lib/libguile.so.9 #8 0x400b23b6 in scm_boot_guile () from /usr/lib/libguile.so.9 #9 0x400b20b4 in scm_boot_guile () from /usr/lib/libguile.so.9 #10 0x400aecd4 in gh_enter () from /usr/lib/libguile.so.9 #11 0x08063cb5 in main (argc=2, argv=0xbffffd34) at main.c:1050 #12 0x4013364f in __libc_start_main () from /lib/libc.so.6 --- end of backtrace --- From mwedel at scruz.net Thu Aug 30 00:18:03 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:34 2005 Subject: [CF-Devel] Bug caused in /Lake_Country/Mwizard/Mwizard6 References: <20010829225454.A10401@mids.student.utwente.nl> Message-ID: <3B8DCC8B.D697967@scruz.net> I've just fixed this and put it in CVS. Its very reproducible given the right circumstance (monster has a max hp value of 0). Generally, this is really a map error, but I put a fix in the server as minor problems in maps should not cause crashes on the server. From natecars at real-time.com Thu Aug 30 13:45:05 2001 From: natecars at real-time.com (Nate Carlson) Date: Thu Jan 13 18:01:34 2005 Subject: [CF-Devel] CVS Server Moving Message-ID: We are moving the CVS server ('cvs.real-time.com') from it's current IP (65.193.16.100) to a new public IP on our network (208.20.202.43). If you have problems accessing the CVS server, please try using the IP address. The change should be happening later today. Thanks! -- Nate Carlson | Phone : (952)943-8700 http://www.real-time.com | Fax : (952)943-8500 From mwedel at scruz.net Wed Aug 1 00:09:58 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:04:05 2005 Subject: [CF List] more general comments References: <200107281128.NAA29513@topaze.ecf.teradyne.com> Message-ID: <3B678F26.2992D575@scruz.net> Nils Lohner wrote: > - when I apply to bed of reality, and then select quit I get: > Got error on read (error 0) > gtk_main exited, returning from event_loop That is normal. We really need to add a 'goodbye' protocol command so the client knows that the connection should be closed. > - the game is too slow for me to play well on an ultra 5. This means > that I have typeahead, and I don't always know when which keystrokes > will be used. It should at least be an option to empty the keyboard > buffer every move, so that only the current keystroke is used. This > is a great help when trying to escape in battle the cwindow command (command window) controls this - it basically determines how many unacknowledged commands it will send to the server (in a sense, the typeahead). Default is 10. Right value depends on the latency between you and the server. If you playing on a local lan or the same machine, setting this to 2 would probably be fine. > - along the same lines, have a blood spot or something when someone > dies. Its tough to read the 'grazed' etc. message to realize that > something has or hasn't died. Something quick and visual would be a > great help. That way you know who you've killed and who to attack next > (i.e. not the monster that juat took the place of what you killed but > something else already weakened for example). I really want to redo the message handling, so that the client could filter these out and display them more intelligently. > - in the quiver, how do you select which arrows you're using??? You can't really. The general logic is that it will use arrows in your inventory first, then go to the containers. There is no way to order the arrows in your container. What many people will do is have multiple quivers - one for the general purpose stuff (+1, etc), and another for the special (slaying/assasinating of some creature). When they meet the appropriate creature, they pull the arrows out of that other container, otherwise they keep it closed so items won't get used from it. > - sometimes I can't fire my bow even when its readied. Why not? It > would make sense that 'fire' automatically readies the skill etc. for > the range weapon selected. Fire is a general purpose command. I'm not positive what you are saying - are you saying that you range says bow, yet you still can't fire? That should automatically happen. However, if your range is set to something else, even if you have a bow readied, it will fire whatever your range is set to. > - when picking up items that can get added to something outside of the > sack (or quiver) add them outside. THis avoids 10 arrows in the > quiver and 20 outside for example. I'm sure some people will disagree with this. not positive, > - is ther a way to disable the sack? Once active, I can't disactivate > it, and it's annoying to have keys drop into it by default. Open the sack, then click the close button above the inventory that appears. Not positive why, but the gtk client used a different behavior in that the container will not fully close just be clicking on the item in your inventory (the old x11 client would cycle between open, active, and closed) > - what's the 'Count' for in the inventory window??? If you want to drop/pick up some amount other than the total. Ie, you have 5000 gp, but want to drop 500, you type 500 and then right click. the 500 will show up in the count window. > - wishlist: draw all explored areas in the window, and just grey out the > ones you can't see at the moment. This would help you see where you > are. You could even leave the artifacts, and just update them the next > time you 'see' them. Anything alive should not be displayed if you > can't see it of course. Scotts fog of war code does this I think. > - wishlist: allow for a bigger viewing area. You can really play this > cgame in several ways: nethack (strategic goal based) or gauntlet > (hack-em-up) and for both a bigger display would be nice. Have you tried the different -mapsize options? Max size right now is 25x25, which amounts to an 800x800 viewable area. From ccalzone at quarry.com Fri Aug 31 17:41:22 2001 From: ccalzone at quarry.com (Christopher Calzonetti) Date: Thu Jan 13 18:04:05 2005 Subject: [CF List] Building client, getting undefined reference to `init_pngx_loader' Message-ID: Hi. I'm not sure why I'm getting this message. After I got it the first time I went and updated my libpng libraries to 1.0.12 from sourceforge, but I'm still getting the error. Any help would be appreciated. I'm trying to build on a SuSE based linux box running 2.4.9 and using gcc 2.95.2. I'll be happy to answer any other questions to resolve this issue. Cheers