From tanner at real-time.com Wed Apr 16 22:41:02 2003 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 17:53:05 2005 Subject: [CF-Devel] Testing Message-ID: <20030416221222.A12167@real-time.com> Testing From tanner at real-time.com Wed Apr 16 22:41:05 2003 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 17:53:05 2005 Subject: [CF-Devel] Testing Message-ID: <20030416221158.A11861@real-time.com> Testing From crossfire-devel-admin at archives.real-time.com Fri Apr 4 02:03:04 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:07 2005 Subject: [CF-Devel] Directory permissions In-Reply-To: <20030324163809.GA28159@mids.student.utwente.nl> References: <20030324163809.GA28159@mids.student.utwente.nl> Message-ID: <3E8D3C38.9050003@sonic.net> Joris Bontje wrote: > New directories created by the crossfire server are mode 777 > which means that they are world readable and writable! > > The filemodes however are 660. > Would there be a problem changing the directory mode in (atleast) 770 ? I have made changes so that there is a SAVE_DIR_MODE define in config.h that lets you specify what permissions the directories should be created at. I'll check this in in the next day or so. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Apr 3 15:03:50 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:07 2005 Subject: [CF-Devel] win32 gtk client Message-ID: <007501c2fa24$87cf9490$0201a8c0@cavancentral.net> Over the past couple of weeks, I have been working with Somebody's win32 source ( http://www.theperlguru.com/crossfire/gcfclient-src.zip ) and have a fairly stable client that supports: gtk, sdl, client-images and sound. binary: http://www.gazellevillage.com/download/gcfclient/gcfclient-install.exe source: http://www.gazellevillage.com/download/gcfclient/win32-crossfire-client-1.5. 0-src.zip In order to compile the source, you will need glib 2.2.1, gtk+ 2.2.1 and the other dependencies thereof ( atk, pango, etc ), sdl, sdl-image, sdl-mixer. I did all my compiling using Visual Studio, so I don't really have a make file. Sorry. :( There is a persistent bug that I am trying to figure out, mebbe you guys could help. When using the "download all information" config option, the client runs out of memory after downloading about 3500 or so images on my win2k dev machine. Somebody had informed me that his experience on his win9x box was around 200 or so images. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Apr 10 09:23:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:08 2005 Subject: [CF-Devel] crossfire-devel post from darsie@gmx.at requires approval Message-ID: <20030410142301.24452.65299.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: darsie@gmx.at Subject: food beep frequency, etc Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Tue Apr 1 11:36:00 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:08 2005 Subject: [CF-Devel] crossfire-devel post from beprox@mail.net4b.pt requires approval Message-ID: <20030401173600.977.49318.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: beprox@mail.net4b.pt Subject: =?windows-1252?Q?UM_ESCRIT=D3RIO_EM_MOVIMENTO...?= Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Mon Apr 14 23:47:16 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:08 2005 Subject: [CF-Devel] Fw: Diamonds In-Reply-To: References: Message-ID: <3E9B8ED4.2070801@sonic.net> It could be argued that -5 plate armor is armor that was very poorly made or has been damaged. Having that cursed flag is a little odd. There is no doubt that there are examples that make sense. But there are probably just as many, or more cases, where the different material makes little/no difference. Your example for arrows is a good one - balsa ones are useful because they don't weight much. But how much should I care if the arrow is oak, pine, yew, spruce, etc? There are minor difference there, but more likely, having half a dozen of different types of arrows listed in your inventory/quiver is perhaps annoying. The issue of the material name being in the inventory is also just a point of annoyance. There has always been the point of trying to get as much useful information in your inventory window as possible. Including a material name you may not care about sort of defeats that goal. Perhaps one way to make this better is to do something like put (material) at the end of the name, and not at the start. Thus, instead of '15 spruce arrows' you would get '15 arrows (spruce)'. This way, the information you care about is at the start of the line. As for selecting material types, there are ways to do it. Something better than the existing method is certainly needed in IMO. The material selection for armor might very well be different than that for weapons, which could then be different than that chosen for something else. As it is now, there is one case where items don't get randomized types where they would cause the least annoyance - rings. Rings, as is, tend not to stack, so to note if the ring is silver, gold, bronze, or whatever isn't likely to cause any extra annoyance. Now the material type wouldn't make any difference for the rings (except maybe value) As I've said before, using the artifacts file to choose material types would have been ideal - that already has support to do match on very specific items (not just 'weapons' or 'armor). One could specify exactly what the material does for that item. Eg, a steel sword may have a bonus to hit and damage. But a steel mace (vs iron) really doesn't have any advantage. I also don't like the material file in that order that the materials is listed in is relevant. So the meaning of the chance field becomes non intuitive - a 'chance 10' if at the end of the materials is pretty much a 10% chance. But if you put that at the start, the chance of that material is now less than 10% - perhaps much less than 10% depending on the chance of the material that follow it. As an aside, the addition of material types adds more to item power inflation. Eg, that snakeskin armor has 1 point AC more than I could have gotten before. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 15 04:52:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:09 2005 Subject: [CF-Devel] crossfire-devel post from darsie@gmx.at requires approval Message-ID: <20030415095201.24966.76790.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: darsie@gmx.at Subject: Re: [CF-Devel] Fw: Diamonds Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Tue Apr 15 00:01:57 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:09 2005 Subject: [CF-Devel] food beep frequency, etc In-Reply-To: <3E95776C.3A8F1F35@gmx.at> References: <3E95776C.3A8F1F35@gmx.at> Message-ID: <3E9B9245.7090107@sonic.net> Bernhard Kuemel wrote: > Hi! > > I whish the food beep frequency(/duration) were configureable so I > could better distinguish it from my irc clients beeps or my father's > crossfire beeps in the same room. Food threshold and how many food's > per beep would be nice to configure, too. Code is there for people to work on. (this basically means, I don't plan to make any such improvement). However, the one addiiton that may be worth making is that instead of making a beep, play an actual sound. This would make it easier to distinguish (presumably). > > It would also be cool if I could set what food will be grabbed blindly > or set my character to automatically eat some food at a configurable > level, maybe even whenever there is enough room in his stomach to fit > another piece in. If only that doesn't make the game boring. This is a very low priority item. IMO, if your blindly grabbing for a bite to food, it should perhaps be even more random than it is now. Perhaps I'm biased because I almost never have a case where food is blindly grabbed. Perhaps the one adjustment I would make is not cause extra food to be consumed when an hp/sp/grace is regained. I can sort of understand the logic (extra energy being expended, therefor extra food). OTOH, this also means you need to worry about managing food in a time where you really don't have the time to spend this. And if you wanted to be more realistic, just travelling should use more food than standing still for example. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Apr 14 02:23:58 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:09 2005 Subject: [CF-Devel] Fw: Diamonds In-Reply-To: <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> References: <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> Message-ID: <3E9A620E.8060700@sonic.net> There are certainly various issues with the materials. In terms of the question at hand - the code that checks for quantity of an item, which is used in all sorts of places, only checks for the quantity of one 'grouping' of an item. Thus, if you have 50 spruce arrows and 30 oak arrows, and something is looking for arrows, it will say there are either 50 or 30 arrows on that space, and not 80 (the 50/30 depends on the order of stacking on the space). Thus is actually a fairly old bug, but until the material stuff showed up, almost never posed a problem (once in a while, I seem to recall someone would find issues related to potions, as they were identified differently or somehow wouldn't merge, even though they were the same). The reason why the logout/login works is because there is a special hack to update the material type when an object is loaded. To answer Todd's question: I certainly want the expanded material form to be in an external file - to have to update values in the server and recompile for any new material isn't a good idea IMO. I communicated this to garbled when he was doing the work on this, and this was done. However, that said, there are certainly some issues with materials: 1) Items of the same type (eg diamonds) of different materials don't merge. This isn't a fixable problem. but the problem it leads to is that now instead of a just a pile of +1 arrows, you might have +1 spruce arrows, +1 oak arrows, +1 pine arrows, etc. In a sense, creating a lot more inventory clutter. 2) The control for material generation is poor. Basically, as it is now, weapons and armor types will get random materials. But this then gets odd combinations - no one in their right mind would ever make lead weapons or armor (ok, maybe sling bullets, but not much else). Yet lead plate armor could show up. I personally don't mind seeing a whole bunch of materials in the game. The problem is that when you get bombarded with all these material types, it looses much of any specialness. Also, I don't know if there is in fact any code that actually makes use of this new material stuff (alchemy/skill stuff), and thus as a player, you care even less about what material an item may be made out o It certainly wouldn't be hard to remove the material name from the object name (As presented to the player). I just wonder if that may cause extra confusion - why do I have 5 stacks of arrows, of which they are all identified, but they don't merge? You'd have to then examine them to see that they are of different materials). I'm not sure what the ideal situation to this is. One thought is to just have the majority items of base (generic) material like in the old days, eg, wood, stone, iron, etc, and thus not detail what it is made out of. Then a relative small number get made out of special materials, and these are added to the name (thus, those pine arrows may be relatively rare, so they'd be unlikely to clutter up your inventory much, because its less likely they'd show up) It'd also be useful to see how the material stuff is expected to play out with the alchemy related code.. Why do we care that the arrow is pine vs oak for example? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 15 17:11:06 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:09 2005 Subject: [CF-Devel] Fw: Diamonds References: <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> <3E9A620E.8060700@sonic.net> <001501c30197$248fd000$0802a8c0@ott.ca.dmr> Message-ID: <003d01c3039b$ea7ed260$0802a8c0@ott.ca.dmr> Ok, colour me stupid for not fully reading up on the all the relevant material stuff including the changelog earlier. Apparently adding in a materialname in an arch will manually set the material type, otherwise the material is randomly selected from the bitmask material value so there is a type of class/subclass going on here. So I apologize to Tim for yapping off before fully reading all the source code, especially when much of the stuff I was complaining should be done, he already did. I still want to make it clear, I had no problems per se with idea here (that was clear no?), in fact you could say I am for it, but some of the implementation was not making sense to me. I didn't like having a bit value for item material and then having a materialname being added to the item when it was created, but that was a knee jerk reaction. I also didn't realize how many modifiers there were to the material types, assuming incorrectly that much of it was just name play. SO I AM SORRY (I'm grovelling here Tim). I do wish there had been more talk about this implementation however. (maybe there was but the mailing list has been out for a while now and it's hard to follow a thread when you have three or four workstations...) Also one paragraph in the /doc/Developers/objects file would have straightened me right out. I still think that there is room to smooth things out however. This is only part of a material system. I am still not clear on how material should be applied to items which are not weapons or armor. Also now there is a more generic way to generate items in a range now. You now essentially have all the backend requirements to have some much more generic arches if there was a good way to specify a range of materials in the arch: a cloth shirt (silk, cotton...), a 'hide' shirt (the various leathers, snake skin...), a chain shirt (brass to iron to mithril or magical metals) brestplate(again brass to mithril to magic metals) - and it would make sense to reflect this in map making technique and arch development. A map maker would now drop a chain shirt and set the material to 'mithril' if they wanted to place a mithril shirt as an item, or leave it as is for a random type. A coin arch (or a nugget arch) could have a range silver -- platiumn, a gem arch... you get the idea . There is a TODO about implementing object type -> subtype in the arches, this is something along this line. The material code goes halfway towards this, I suggest that perhaps it should be examined closer. This is what I was speaking of when I said it would be a pain to implement since material type could really change the arches (in a positive way I think)but would require some clean up afterwards. I still think that there is some problems with the way this was implemented since it does add another layer of confustion to people whom primarily work within the archetypes and maps and not in the source code - and there is too much of this as it is already. I suppose that this is a designer vs coder type issue however. That being said - I still think it is a bit clunky and would like to see an all in one solution to the material system. Having a material field and a materialname field in an arch is not nice and having to manage a bitvalue and a material name is not nice. For the sake of designers, how hard would it be to go the extra step and ditch the bitmask and have a material type by name where if 'metal' (parent object) is specified a type of metal will be selected, but where if 'iron' (specific material object) is specified the object will be iron. I also would prefer item properties to be managed in arches instead of a list for the sake of consistancy and portability and since having an arch for each material would be useful for item deconstruction anyway. Also this all works well for single material items, but what about items with multiple materials? Also the 'magical' materials is a bit strange and how does it relate to item enchantment (I'm guessing it doesn't so is there a point to it?) I still don't like having the material name in front of a lot of these objects but admit it is more a client space issue than anything else really. I still like the DX client where the item icons were shown and the name shown only when the item was highlighted. I can see better why the material is important however when I consider items like leather armor or silver coin or gold nugget however. Depending on the object and the material importance and general English language foolery however it is hard to say I want it here and not there. I did like Mark's suggestion to have Arrow (pine) or brestplate (admantium), but can see that not being nice if the system was expanded - coin (gold) is a crapy thing to see and I would hate to have 'Plate mail (dr' as much as I don't like 'Snake skin c'. Now it is interesting to hear the mention of deconstructing objects. This was my primary reason for bringing this up in the first place - a consistant material system would allow item creation and destruction with relative ease and with a bit of predicatbility, it would also make simpler such stuff as mining and logging and tanning. This is the main reason I thought that having material objects in the arches would be better than a list (aside from the fact that you wouldn't need to change the server code to add a new material, and this is the way other stuff is handled). It would also simplify mixing skills with materials (tanning, smithing, boyer...) if there were a more consistant (and I think object based) material system. Well - this has gone way beyond where I started. Now were talking about whether rings should have a material type and how things should stack and probably we'll get into identification issues next, then whether it is better to store information in arches or in lists and if magical items require magical materials... _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 15 04:12:41 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:10 2005 Subject: [CF-Devel] Fw: Diamonds References: Message-ID: <3E9BCD09.E79949B0@gmx.at> Tim Rightnour wrote: > > I elected not to implement the use of materials on any items where I hadn't yet > come up with a good use of the effects. It's not just a decoration. I see no > reason to implement them on the rings unless it will have an effect of some > sort. Heh, if there was magic for real I would actually expect that the material a magic ring is made of plays an important role. Well, still we can ignore this and achive the same results without material type, but the same is true for armour and weapons. We wouldn't have to care whether an armour is made of leather or mithril, but we do. We could invite some witches, wizards, alchemists, astrologists from the real world for advice. Silver might be a good choice for rings of ice as it must feel quite cool for it is the best conductor of heat - and electricity as well, so maybe for 'ring of storm', too. OTOH, a gold ring might make a (str-1, cha+2) ring. There could even be non metal rings and they may be combustible. I would, however, not like rings with equal properties to have different materials and so would not stack. I do have 2 rings of wisdom+2, adamant, fire, resist confusion +24, strength +2, acid, ice. > Doubly so if there exists the chance that someday we will come up with a > good use for the materials on rings, but not be able to implement it properly > because we buggered it making a decoration. Bernhard -- Low end Serverhousing ab 25 e inkl. 1x 11 e/GB, etc.: http://bksys.at _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Apr 13 07:22:13 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:10 2005 Subject: [CF-Devel] Fw: Diamonds References: <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> <3E98B105.1070301@sympatico.ca> Message-ID: <3E995675.CABC9629@gmx.at> Todd wrote: > > kind of thing would be better to manage in the arches no? Make an arch > for gold chainmail rather than add a random material type to the > chainmail arch. IIRC my father found an otherwise simple sword made of platinum. It weighed about 12 kg and had a value if it were made of iron. Making a sword of platinum is complete nonsense for it has inferior strength than iron and a density higher than gold (21.4 g/cm3). Bernhard -- Low end Serverhousing ab 25 e inkl. 1x 11 e/GB, etc.: http://bksys.at _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Apr 10 13:39:00 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:12 2005 Subject: [CF-Devel] crossfire-devel post from mark7@andrew.cmu.edu requires approval Message-ID: <20030410183900.4719.74080.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: mark7@andrew.cmu.edu Subject: [BUG] 1.5 Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Sat Apr 12 18:48:49 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:12 2005 Subject: [CF-Devel] Fw: Login problems. Message-ID: <20030412204849.3a7b7c58.kstenger@montevideo.com.uy> Hi again!, I've been having some problems to re log in when my character hangs up and it stays logged in but I'm not really controlling it. I know this is on the wishing list but I just want to know if it's not forgotten or the reasons because the possibility to log in with the same character even if it's already logged in it's not implemented yet. I have very often this problem because of my dynamic IP that changes twice a day. Regards! -- +-----------------------------+ | Karla M? Stenger S?bat | | Pando . Canelones . Uruguay | | kstenger@montevideo.com.uy | +-----------------------------+ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Apr 13 11:30:17 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:12 2005 Subject: [CF-Devel] Fw: Diamonds In-Reply-To: <3E98B105.1070301@sympatico.ca> References: <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> <3E98B105.1070301@sympatico.ca> Message-ID: <200304131830.20063.paco@arsfortunata.com> El Domingo, 13 de Abril de 2003 02:36, Todd escribi?: > I am going to jump on this comment because I think it related to the new > material types and this material type thing has been bothering me for a > bit. Sorry Karla, I can't give you an answer but I do have a question > to ask. > I'm not an experienced programmer either but there seems to be a lot of > issues with the new material types and I am not sure that it is worth it > to keep on just fixing them as has been happening. I understand the > reason for the new materials was for expanding the item creation/alchemy > system (yes?), but there has to be a better way to do this with the old > system of material types, no? I was pretty happy having the bitmask > material type and not having these problems with item matching, stacking > and weird materials for common objects. Could not the old system be > expanded to include more mateirals or the old material bitmask system is > replaced with something more like this new thing? I think that this > kind of thing would be better to manage in the arches no? Make an arch > for gold chainmail rather than add a random material type to the > chainmail arch. > Plus I do not like to see the material type in the name, 'pine arrow' or > 'dog-skin leather armour' is not necessary for me to know. If the item > is something that does have a material in the name anyway (like > DragonScale Plate Armor or Golden sheild) then it is usually otherwise > special too and has a diffrent archetype and properties. Otherwise it > is just Plate Armor or a shield. Only when I examine something, eat > someting, when it is valued, when it gets burned up or reacts to a > spell, or otherwise has unique properties do I need to know what it is > made of. Now there may be a good reason for doing things this way - but > from my view (I admit it is a limited view) it seems unweildy and there > are too many special cases (like mithril and leather armours - or stone > axes?) and patchy type fixes to make it work. Is there a solution to be > had, it seems like there should be a better way to do this - is there > even a problem anymore and I missed it being fixed? I'm not against the > idea in theory, but the execution seems to be a problem here. Maybe > it's just me that doesn't get it? I post a message about the same some time ago I just repost some parts of it now (yes I'm lazy :-) : (talking about ideas to steal in the game IVAN) Items have 2 material, one is the head/tip/blade or the main material of the item. The appereance of the item changes if you change the material of the item (you can wish for scrolls of change material) The wood/metal items should only display the metal part name .. no no more spruce axes. Also it will be nice to limit the number of wooden materias .. what the it's the diference if I use an oak arror or a spruce one ? wooden arrows (only sharpened wood , no tip) bambu arrows (no tip) and metal ones (wooden with metal tip : copper, iron ...) will be nice. A percent of the item made of the main material should be included so .. an arrow have 20% base tip weigth that changes if material change and a 80% from unimportant material. Same for axes, spears, maces, hammers, horned helmets (the horns are mere addonament and usually allways made from ... horn!!!), etc ... Or a second material to every item could be added .. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 19 01:45:59 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:12 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <3EA050BD.8060500@sympatico.ca> Message-ID: On 18-Apr-03 Todd wrote: > Well I for one am a bit sorry [snip] No apology neccesary. > It is implemented better than I thought > (IMHO). Not that there isn't still room for stuff to be done however. There is allways room for tweaking.. > I think there is a misrepresentation on this random material thing. > Since I may have contributed to this I feel obligated to address it. > Now it is fully possible to specify a material using the materialname > field (what happens if the 'material' is '4096' (ice) and the > materialname is 'oak'?) so it is a bit annoying but the basic idea is > good. This is my fault, as I have not provided adequate enough documentation. The way it works is this: material: specify the general category of material. Only used when randomizing a material, and in a few weather routines. In an ideal world, the code would no longer pay attention to this. The idea is this is the category that the random material is drawn from. materialname: The actual material. Right now if you were to do something like set the materialname to oak, and the material to ice, you would only get one bizzare result, and that would be that the routine that sweeps the world decaying objects on the bigworld map would treat you as ice rather than wood. utils.c:decay_objects() is the only routine left that still decides what to do based on the material field. All saves and whatnot are based on materialname. If a mapmaker made an object and set materialname without material, it would not be an error, and the effects would not be bizzare. Basically, if you want a random material, set material, and not materialname. If you want a specific one, set materialname. If anyone is wondering.. the correct fix for this IMHO is to pick one of the saves, perhaps physical, or make a new "weather" save, and have decay objects just roll saving throws rather than the little if/else loop. > It is only a matter of explicity setting the 'materialname' in > the arch to create the specific item you want (the appearance of > randomness is because this wasn't done in many cases - most likely to > get some of these things in circulation fast), not because of the design > of the code. Actually the code makes it real easy to specity a > particular material but this wasn't done to many arches so many things > are assigned a random material. It was actually done because I went through and marked up all the ones that were obvious to me.. but evidently I missed alot. > There may be some tweeking to do as well. It might be an idea to change > Iron to Metal and Leather to Hide and make another organic type to > seperate flesh from vegetable matter. I can see that maybe gold and > lead (others?) should be in the soft metal category (no more gold or > lead swords by accident?) M_IRON -> M_METAL is just a naming thing.. I just left it M_IRON for old code compatibility. Same with leather->hide. As for organics.. That is a very complex and touchy subject.. For example, what would you use flesh and vegetable for. would you mark meat as being the specific meat of an animal? Is that useful? What about vegetables? Is it useful to know that the rose is made of "rose matter"? basically.. I wasn't sure what to do with organics.. so I left it the heck alone. If someone comes up with a good use.. please implement it. > I am not sure how the magical materials > should work (seems strange - especially since there are other magical > object fields). There are also a lot of stones missing, namely the gem > types (diamond, ruby...) which would fix the 'granite' diamond issue. I was thinking of that, but didn't really see it is very neccesary. perhaps a "crystaline" material for gemtypes. The granite diamond isn't much worse than the "stone" diamonds of old, just slightly more specific. As for magical materials.. the concept was to have a single magical, and a single cursed material for each category. So when randomizing, there is a small chance that you get something bizzare. It might be fun to go around collecting astolare to make yourself an astolare cloak, if item creation ever happened. > metal) or mithril (specific). This is good in my opinion. I do wonder > about what to do with items with multiple materials however. They should probably just be converted to a single one.. but in some cases it doesn't bother me that much. Wooden axe, metal axe.. they are both reasonable possibilities.. > One thing that would be nice (read WISHLIST) would be that you could > specify a colour in the material so that generic images could be made > for some things and the colour applied based on the material. This > would make it easy to have a single image for so many items (armour, > ore, ingots). There is little point of having a materials system like > this if you have to create arches for every damn item anyway just to get > a picture. Yeah.. I don't know a good way to do this. > There is tons more to say, I have run out of time however. I would > like to talk about fireballs and acid and mining and stuff too... Yes.. much to speak of here. Worth noting is that I feel too many things are just invulnerable to destruction. Nothing should be wholly invulnerable.. just varying degrees of hard to destroy. > electrum* -->electrum is a precious metal like silver no? perhaps > electisium Yeah.. but it works well and makes sense.. it's a fantasy world.. :) > SPECIAL 8192 > ? #define M_SPECIAL 8192 /* when displaying names, don't show the materialname */ This is so you don't end up with stuff like "mithril mithril crystal", "leather leather armour", or "organic eyeshield". --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 19 02:31:00 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:12 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <3EA050BD.8060500@sympatico.ca> References: <13861.1050656159@www23.gmx.net> <3EA050BD.8060500@sympatico.ca> Message-ID: <3EA0FB34.50200@sonic.net> Well, my original thought was that 'materialname' should just be an arbitrary string, and it would look at the material bitmask when it comes to saving throws. In this way, you could have something made of 'tin' just be editing the object (if on a map). The material bitmask would be used for saving throws - the map maker itself could adjust other values accordingly (weight, value, saving throws, etc). That said, having detailed saving throws in the materials table for different materials isn't bad. But it does mean that a map maker just can't add a new material and have it work. Also, setting the 'materialname' for an object in the editor is not going to do what you want it to do. When an object is first created, it is assigned a materialname at that point, and the bonuses are done then. If the object already has a materialname set, none of this happens when it is loaded (there is no way to know if the bonuses have already been taken into account). So if you make a sword, and give it 'materialname gold', it will be the same as if the materialname was iron in terms of weight, value, damage, etc. IMO, there is no good solution for this - the idea of the editor having the smarts to make such changes is probably not a great idea, but at the same time, ability of a map designer to change those fields is unlikely at best. However, there is no good solution to that - that random artifacts have the same problem - you can create one in a map by hand, but you basically have to patch in the values yourself. In some sense, I think the random artifacts is a bad idea simply for that reason. OTOH, there are 327 random artifacts - to make those archs would be at least 327 new archs (many of the random artifacts may modify more than just one arch). The main reason I'd like the generation of random objects materials in the artifacts file is control. The materials file has very generic control - it is hard coded that armor and weapons get random material types. And what material is determined on a global basis by the materials file - there is no way to say 'don't have material X show up for this type of object'. I think one way or the other, it is inevitible that the ability to change materialname will show up in the artifacts file, simply because someone is going to want to make some type of object (narrowly defined, like 'arrow' or 'dagger' and not all weapons) to show up with some material - having weapons show up with that new material may not be desirable. So I say this change should get made sooner. I've worked on crossfire long enough to know to do it right the first time, because in the end, it will eventually get done right no matter what. However, if it is done wrong the first time, you then have an intervening time with all sorts of problems. It is also unclear to me if it is in fact to override the adamant material type. One could argue that all items should be destructible. But the right solution in that case is to probably remove/change archetypes that have their type currently set to adamant if they should be destroyable. Actually, if anything, adamant is probably the one material that should not be modified at all. Artifacts and other rare items are made out of adamant - screwing with their weight, value, or other bonus is probably 10 times worse than doing so to what might just be a +2 sword. Also, one thing I _still_ have not heard an explanation for is how it is expected material types play into item creation. Is it just a matter that if I have a 'yew club', I could then make a 'yew bow' from it? If I have a mithril chain, I can then make a mithril shield, etc? Or something more? As for 'granite' diamonds - in some sense, the fact that the material name is now more specific means it is now wrong. If for example I point over yonder and say 'that is a tree', I can be correct in that statement whether it is an oak tree, redwood, pine, etc. If, however, I point yonder and say 'that is a pine tree' when it is in fact an oak, I am wrong in my statement. And that is similar with diamonds. If you call them 'stone', it may not be very desriptive, but is accurate. If you say they are 'granite', it is more specific, but incorrect. However, I think rather than saying what is wrong with the current system, it would probably be more useful to say what the ideal system is. Here is my short list: 1) Ability to control what materials show up in a more specific fashion (eg, only these weapons will show up as silver, and not every weapon - basically artifact file level specificness) 2) Some way to set a material in the map editor, and have the right thing done when it is loaded by the server (eg, to actually apply the various adjustments and so forth). Easiest way to do this is probably to set a flag like 'FLAG_MATERIAL_ADJUSTED' - the editor would have it unset, but whenever the server loads an object, it checks for that flag - if it isn't set, it adjusts the item based on the material set. If it is set, it doesn't do anything more. This allows map maker to set the material of an object in the editor and have the right thing happen. 3) Removal of the material bitmask field - it is no longer needed with the materialname field. Add special material keywords, eg, random_paper, random_cloth. Alternative/better, allow a list of materials 'material iron|mithril|bronze' - this sort of addresses point #1 above. 4) From todd - name suffix for object names. Eg, yellow/gold objects could have the suffix be 'gold'. This, if there is an image 'chainmail.111.gold', and the current name is just 'chainmail.111', it can update what it looks like. This could similarly be used for animations. Eg, if for example you want to have wands made of different materials, it could look for an animation 'wand_gold' if the normal animation is jsut wand. 5) Some better way to display the materialname in inventory. This may simply be moving the material to the end of the list. Eg, instead of 'spruce longbow', it could be 'longbow, spruce'. Thus, if you have a 'Bow of auriga +3' that is made of pine, it would be 'bow of auriga +3, pine'. In this way, the details you are more likely to care abou are presented first, and the material is presented later. 6) this more a minor point, but I'd like the materials file to be more humanly readable/easier to parse. Eg, instead of: saves 15,10,17,9,5,7,13,0,20,15,0,0,0,0,0,10,0,0,0,0,0,0,0,0,0 it would be something like save_physical 15 save_fire 10 (or whatever). Same for the 'mods' string. All values should default to zero, so you only need to list values that actually are differently. 7) Also a minor point, but more sensical handling of how the random determination works. Right now, something like: name iron chance 20 name steel chance 30 name bronze chance 15 name gold chance 10 name lead chance 15 does not mean that iron will show up 20% of the time. If you re-arrange the materials, what shows up when changes. This of course makes it very confusing (and hard to judge) what really shows up (actually chance of iron showing up in the above talbe is 9% btw). It'd be much better if the total chance for matching materials was determined, and then just one roll is made to figure out the material. Any other points? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Apr 18 21:08:57 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:13 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <3EA050BD.8060500@sympatico.ca> References: <13861.1050656159@www23.gmx.net> <3EA050BD.8060500@sympatico.ca> Message-ID: <3EA0AFB9.2070005@sympatico.ca> > I was worried about mention of mithril crystal because mithril melted > on a particular map- wouldn't it be better to raise the durability of > mithril? Actually on further thought it is amusing to have 'crystal mith' in the game. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 12 19:36:21 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:16 2005 Subject: [CF-Devel] Fw: Diamonds In-Reply-To: <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> References: <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> Message-ID: <3E98B105.1070301@sympatico.ca> Karla Stenger wrote: >Hi, > >This is my first post to this list, and I'm not an experienced programmer >but I think I can contribute in the little I can see while I play crossfire. > >I've seen a little detail about diamonds in the metalforge server (didn't try >on another server yet) when collecting the 10K needed to the apartment >extension. I noticed there are two kinds of diamonds that appear to be alike. >One is the diamond you find in some dungeon made of granite and the other is the >one you exchange for gold at the bank apparently made of nothing (the >description doesn't tell anything about its material). > >Then if you try to buy your extension with 9K of one kind and 1K of another, >it's not accepted as 10K in total. > >The other detail about this is that if you have some diamonds from the bank and >you log off and then log in again those are turned into the granite kind of >diamonds, no matter if you have it in your inventory, into a pouch or in your >apartment. I don't know if this is the only way to make them turn into their >real form. > >I hope for my comments to be useful. >Bye! > > > I am going to jump on this comment because I think it related to the new material types and this material type thing has been bothering me for a bit. Sorry Karla, I can't give you an answer but I do have a question to ask. I'm not an experienced programmer either but there seems to be a lot of issues with the new material types and I am not sure that it is worth it to keep on just fixing them as has been happening. I understand the reason for the new materials was for expanding the item creation/alchemy system (yes?), but there has to be a better way to do this with the old system of material types, no? I was pretty happy having the bitmask material type and not having these problems with item matching, stacking and weird materials for common objects. Could not the old system be expanded to include more mateirals or the old material bitmask system is replaced with something more like this new thing? I think that this kind of thing would be better to manage in the arches no? Make an arch for gold chainmail rather than add a random material type to the chainmail arch. Plus I do not like to see the material type in the name, 'pine arrow' or 'dog-skin leather armour' is not necessary for me to know. If the item is something that does have a material in the name anyway (like DragonScale Plate Armor or Golden sheild) then it is usually otherwise special too and has a diffrent archetype and properties. Otherwise it is just Plate Armor or a shield. Only when I examine something, eat someting, when it is valued, when it gets burned up or reacts to a spell, or otherwise has unique properties do I need to know what it is made of. Now there may be a good reason for doing things this way - but from my view (I admit it is a limited view) it seems unweildy and there are too many special cases (like mithril and leather armours - or stone axes?) and patchy type fixes to make it work. Is there a solution to be had, it seems like there should be a better way to do this - is there even a problem anymore and I missed it being fixed? I'm not against the idea in theory, but the execution seems to be a problem here. Maybe it's just me that doesn't get it? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 12 20:37:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:16 2005 Subject: [CF-Devel] crossfire-devel post from 236319@dtwc.com requires approval Message-ID: <20030413013701.16861.70358.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: 236319@dtwc.com Subject: all internet users need this9 Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Sun Apr 6 11:00:36 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:16 2005 Subject: [CF-Devel] Diseases in the arena In-Reply-To: <3E8E5212.7050406@sonic.net> Message-ID: On 05-Apr-03 Mark Wedel wrote: > A simple fix for this would be that disease won't spread to no magic (or no > cleric magic) spaces. This would kind of suck, as on occasion I have used diseases creatively in no-magic areas. To make them not spread just to fix the arena seems a bit of overkill. > Other alternative would be diseases don't spread on battleground spaces. This might be preferrable.. Or perhaps a no-disease space that could line the outer walls separating the battleground and the spectators. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 16 19:49:05 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:17 2005 Subject: [CF-Devel] dragon food messages Message-ID: This patch will generate more precise messages for dragons eating body parts. In the old way "The blah had a boring taste." could mean anything from 0 to 5.9 % chance of gaining a resistance. (Yes, including zero as (int)chance*100 will floor x < 0.01 to 0) With this patch, any "boring" food does have a chance of at least 0.01 % . I also filled the gap from "boring" to "good" with "bland". So now we have: chance | message | average amount needed for +1 x = 0 no taste {} 0.01 <= x <= 0.1 boring [1000,10000) 0.1 < x <= 1.0 bland [100,1000) 1.0 < x <= 10.0 good [10,100) 10.0 < x <= 50.0 very good [2,10) 50.0 < x delicious [1,2) With x the total chance (in %) of gaining a resistance level. I have not changed the chance to get resistances, only the feedback. Bernd Edler -------------- next part -------------- *** apply.c.old Thu Apr 17 00:30:49 2003 --- apply.c Thu Apr 17 01:49:08 2003 *************** *** 1868,1874 **** char buf[MAX_BUF]; /* tmp. string buffer */ double chance; /* improvement-chance of one resistance type */ ! double maxchance=0; /* highest chance of any type */ double bonus=0; /* level bonus (improvement is easier at lowlevel) */ double mbonus=0; /* monster bonus */ int atnr_winner[NROFATTACKS]; /* winning candidates for resistance improvement */ --- 1868,1874 ---- char buf[MAX_BUF]; /* tmp. string buffer */ double chance; /* improvement-chance of one resistance type */ ! double totalchance=1; /* total chance of gaining one resistance */ double bonus=0; /* level bonus (improvement is easier at lowlevel) */ double mbonus=0; /* monster bonus */ int atnr_winner[NROFATTACKS]; /* winning candidates for resistance improvement */ *************** *** 1941,1960 **** winners++; } ! if (chance > maxchance) maxchance = chance; /*printf(" %s: bonus %.1f, chance %.1f\n", attacks[i], bonus, chance);*/ } } ! /* print message according to maxchance */ ! if (maxchance > 50.) sprintf(buf, "Hmm! The %s tasted delicious!", meal->name); ! else if (maxchance > 10.) sprintf(buf, "The %s tasted very good.", meal->name); ! else if (maxchance > 1.) sprintf(buf, "The %s tasted good.", meal->name); ! else if (maxchance > 0.0001) sprintf(buf, "The %s had a boring taste.", meal->name); else if (meal->last_eat > 0 && atnr_is_dragon_enabled(meal->last_eat)) sprintf(buf, "The %s tasted strange.", meal->name); --- 1941,1964 ---- winners++; } ! if (chance >= 0.01 ) totalchance *= 1 - chance; /*printf(" %s: bonus %.1f, chance %.1f\n", attacks[i], bonus, chance);*/ } } ! /* inverse totalchance as until now we have the failure-chance */ ! totalchance = 1 - totalchance; ! /* print message according to totalchance */ ! if (totalchance > 50.) sprintf(buf, "Hmm! The %s tasted delicious!", meal->name); ! else if (totalchance > 10.) sprintf(buf, "The %s tasted very good.", meal->name); ! else if (totalchance > 1.) sprintf(buf, "The %s tasted good.", meal->name); ! else if (totalchance > 0.1) ! sprintf(buf, "The %s tasted bland.", meal->name); ! else if (totalchance >= 0.01) sprintf(buf, "The %s had a boring taste.", meal->name); else if (meal->last_eat > 0 && atnr_is_dragon_enabled(meal->last_eat)) sprintf(buf, "The %s tasted strange.", meal->name); From crossfire-devel-admin at archives.real-time.com Sun Apr 13 07:52:00 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:17 2005 Subject: [CF-Devel] crossfire-devel post from darsie@gmx.at requires approval Message-ID: <20030413125200.24975.29736.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: darsie@gmx.at Subject: Re: [CF-Devel] Fw: Diamonds Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Tue Apr 15 04:43:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:17 2005 Subject: [CF-Devel] crossfire-devel post from darsie@gmx.at requires approval Message-ID: <20030415094301.24596.81628.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: darsie@gmx.at Subject: Re: [CF-Devel] Fw: Diamonds Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Wed Apr 16 15:51:11 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:17 2005 Subject: [CF-Devel] Fw: Diamonds In-Reply-To: <003d01c3039b$ea7ed260$0802a8c0@ott.ca.dmr> Message-ID: On 15-Apr-03 Todd Mitchell wrote: > Now it is interesting to hear the mention of deconstructing objects. This > was my primary reason for bringing this up in the first place - a consistant > material system would allow item creation and destruction with relative ease > and with a bit of predicatbility, it would also make simpler such stuff as > mining and logging and tanning. This is the main reason I thought that > having material objects in the arches would be better than a list (aside > from the fact that you wouldn't need to change the server code to add a new > material, and this is the way other stuff is handled). It would also > simplify mixing skills with materials (tanning, smithing, boyer...) if there > were a more consistant (and I think object based) material system. Thats basically what the item creation code does. The basic concept is that you gather together a pile of raw gold, and say "build longsword" and with a little fiddling, it makes a gold longsword with your smithery skill. The problem being.. that it's not enabled because: 1) There are no images/arches for the build facilities. 2) There are no images/arches for many of the raw materials. 3) There are no images/arches for the tools. 4) There is no image/arch for the destructor device. Writing code for a destructor would probably be trivial. But I have tested it fairly well.. and it works, and it's fun to play with. Once it was in place.. it would also be pretty trivial to do something like making mountains made out of metal, so a random metal was chosen for them. Mining could look at the metal that was chosen randomly, and mine out a chunk of it. Trees could obviously do the same thing for wood. Various hides would be direct forms of raw material, as would some monster parts. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 1 01:09:07 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:17 2005 Subject: [CF-Devel] python plugin Message-ID: <1049180947.9535ef00yann.chachkoff@myrealbox.com> >On Sat, 29 Mar 2003, Mark Wedel wrote: >> >> I believe the plugin is in fact installed on metalforge. >> It's just by default, >> I don't think anything uses the plugin. >> >Afaik the occidental stuff is there by default. >The 1.5 tarballs has it. >When i use the occidental sword on my local server, i get >quite frequently reactions from it. >e.g "Your weapon feels warmer" (attacktype switched to fire) >I cleared the whole newbie tower with this sword on metalforge. >As nothing special happened,i assumed the plugin was not enabled. A simple way to check if the plugin is correctly loaded is to send a "pluglist" DM command. It displays the list of all plugins running. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 1 04:29:53 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:18 2005 Subject: [CF-Devel] crossfire-devel post from temitchell@sympatico.ca requires approval Message-ID: <20030401102953.18298.50830.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: temitchell@sympatico.ca Subject: Re: [CF-Devel] CVS Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Tue Apr 1 02:58:04 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:18 2005 Subject: [CF-Devel] crossfire-devel post from temitchell@sympatico.ca requires approval Message-ID: <20030401085804.17067.7269.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: temitchell@sympatico.ca Subject: Fw: unique-map recycling Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Tue Apr 1 11:12:09 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:19 2005 Subject: [CF-Devel] crossfire-devel post from leaf@real-time.com requires approval Message-ID: <20030401171209.21684.77942.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: leaf@real-time.com Subject: unique-items question (repost2) Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Wed Apr 2 09:19:36 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:19 2005 Subject: [CF-Devel] crossfire-devel post from ut`@usa.net requires approval Message-ID: <20030402151936.31537.39579.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: ¸u¸t¸`@usa.net Subject: =?Big5?B?MjAwMqZ+stdNQUlMpua+UKpavrmkaq5p?= Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Wed Apr 2 01:45:05 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:19 2005 Subject: [CF-Devel] (automatic) apply rings In-Reply-To: <3E883364.42BC2704@gmx.at> References: <3E86EA81.BA2EB008@gmx.at> <3E87E154.7060103@sonic.net> <3E883364.42BC2704@gmx.at> Message-ID: <3E8A9501.7020801@sonic.net> Bernhard Kuemel wrote: > Mark Wedel wrote: > Mhm. But the client could not keep track of last recently applied > rings after quitting or sleeping in bed of reality. It could try so in > a save file but there might be some confusion if the player used a > different client in the meanwhile. That would not matter much for my > FIFO, but for your stack (keep longest worn ring on). Well, I'd be a bit less worried in that case - it wouldn't take very long for the player to establish the ring wear order, and which things would work as expectedly. > I also like it much better not to remove things before I use others. > This is an extra command that takes time and may open a short time > vulnerability. If the unapply happens automatically (in the server) > this is maybe even an atomic action. But, well, atomic key changing is > not realistic so it need not be in the game. An extra command also > takes up space in the byte limited keybindings. The fact that applying an item automatically un applies something else and then applies the new item really quickly should really be considered a bug. At minimum, such actions should take longer (twice as long). In a more realistic sense, the times for equip/unequip are quite fast - switching from the dragon armor to power plate mail in one tick is quite a trick. It'd be relative easy to add some real times to what it takes to switch items. It's basically just a matter of reducing the players speed_left by a higher amount. Doing it in an incremental fashion would be a lot harder (eg, 5 ticks to remove armor, and say 5 ticks to put armor on, and in those 8 ticks where armor is being removed/equipped, you get no benefit of it). This is getting unrelated to the question at hand. But mostly a note that consider the atomic process of a ring being unequipped and a new ring being equipped in the same tick a bonus, and not something to be expected. In any case, I think Bernd's solution looks to be the best. I'd rather not have to try to track when/what orders rings were applied, and it does look like Bernd's solution is sufficient to allow everything that needs to be done via keybinding. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Apr 4 14:02:42 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:19 2005 Subject: [CF-Devel] Diseases in the arena In-Reply-To: <3E8D24B0.2010406@sonic.net> References: <007501c2fa24$87cf9490$0201a8c0@cavancentral.net> <200304032238576.SM01220@adsl-68-21-14-48.dsl.chcgil.ameritech.net> <3E8D24B0.2010406@sonic.net> Message-ID: <200304041506526.SM01220@adsl-66-72-99-171.dsl.chcgil.ameritech.net> On Thu, 03 Apr 2003 22:22:40 -0800, Mark Wedel wrote: >phil@theperlguru.com wrote: >>>From CVS: > >> >> Has any work been done on the fact that diseases can skip from inside >> a battleground to outside? Namely, if a player uses diseases in arena >> combat, then that player may catch the disease again after he dies in >> the duel, and die again for real. This was reported some time ago, >> but I'm not sure if anybody took note of it at the time. >> > > The checkin may or may not fix it. > > In practice, when a player dies, cure disease is called upon the player, which >should remove all diseases. However, that doesn't seem to always happen in the >past - it appears the disease would be removed, sometimes the symptoms would not >be removed. > > The change I put in fixes that last bit - symptoms are now always removed. Well, I was referring more to the bug where diseases can leave the arena. ie. if there is an arena battle with spectators, the spectators can be killed by diseases running rampant. This is especially bad, as the spectator areas are no_magic'ed, so the spectators can't cure themselves. -Philip _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Apr 3 19:21:37 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:19 2005 Subject: [CF-Devel] crossfire-devel post from root@garbled.net requires approval Message-ID: <20030404012137.14121.94552.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: root@garbled.net Subject: Money issues Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Thu Apr 3 21:34:29 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:19 2005 Subject: [CF-Devel] Diseases in the arena In-Reply-To: <007501c2fa24$87cf9490$0201a8c0@cavancentral.net> References: <007501c2fa24$87cf9490$0201a8c0@cavancentral.net> Message-ID: <200304032238576.SM01220@adsl-68-21-14-48.dsl.chcgil.ameritech.net> From crossfire-devel-admin at archives.real-time.com Sat Apr 5 04:20:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:20 2005 Subject: [CF-Devel] crossfire-devel post from darsie@gmx.at requires approval Message-ID: <20030405102001.9829.34884.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: darsie@gmx.at Subject: Re: [CF-Devel] (automatic) apply rings Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Wed Apr 9 05:52:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:20 2005 Subject: [CF-Devel] crossfire-devel post from beprox@mail.net4b.pt requires approval Message-ID: <20030409105201.22283.7096.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: beprox@mail.net4b.pt Subject: IMAGEM DIGITAL BEPROX Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Sat Apr 5 01:41:58 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:20 2005 Subject: [CF-Devel] skill doc. Message-ID: <3E8E88C6.9000502@sonic.net> Started working on the new skill system. I decided to update the documentation first to get an idea of where to go to/what to write. I figured I might as well put it out to the list and see any comments or other notes people might have. SKILLS/EXPERIENCE DOCUMENTATION for DEVELOPERS ---------------------------------------------- - Summary - 0. Introduction 1. Sketch of system a. Initialization - how skills and experience are linked 2. How to add new skills a. creation of new skill: outline of needed steps 3. Detail of skill archetype values. 4. Skill Tools 5. Skill Scrolls 6. Workings of the Skill System ------------------------------------------------------------------------- 0. Introduction --------------- Skills were redone to a large extent in April 2003. This document has been updated to reflect how the skills work. The main change is that experience categories were removed from the game. Instead, experience goes to the skill itself. Thus. how good a player is at the skills is directly proportional to how good they are at that skill, and not the category itself. 1. Sketch of system ------------------- In the skills/experience code, players gain experience for the activities which they perform in the game ("You are what you do"). The activities a player may engage in are controlled by the skills they possess. All players start with a basic set of skills which they may expand through adventuring. While monsters do not gain experience from the use of skills, they may use any skills which exist in their inventory if they have the can_use_skill flag set. In the code, skills are objects which exist in the player/monster inventory. Both NPC/monsters and players use the same skill archetypes. Not all skills are however enabled for monster use. Check the Skills_players.doc for available NPC skills. The experience one gets for a skill is greatly simplified. No longer is it weighted based on the stats of the player. Rather, the experience is based on what the skill was used for - opening a tough trap gets more exp than opening an easy trap. The stats the player has will improve the chances of success in most cases - this is bonus enough without also gaining additional experience. The chracters total experience is no longer related to the sum of experience in the players skills - A player could for example only of 1000 exp, but have skills with 2500 exp, 300 exp, etc. Removing the tie between skills and total experience allows for reasonable skill advancement - you can allow a player to easily get to level 20 in a skill without them now being level 20 player. Note also that the only tunables are now in the code or in the archetypes - if the exp for disarming is out of whack, the code would need to be changed to give more appropriate amounts. 2. How to add new skills ------------------------- Adding a new skill to CF is not overly difficult, it is little more difficult than adding new archetypes and a spell to the game. a. creation of new skill: outline of needed steps A number of steps are required to create a new skill. 1) Edit a new skills archetype. See below for appropriate parameters. If you desire the skill to be a skill tool, edit a "face" for the new skill. If you want to have the skill to be learned via a skill scroll, edit a skillscroll for the skill. Place the new archetype(s) in the lib/arch/skills directory. Remember to name your new skill appropriately (ie skill_). Make sure you select a unique subtype for your new skill. 2) Edit skill_util.c. Add an entry for the skill in do_skill() (so that it may be used as a "long-range attack"). If the new skill is a hth attack take a look at the attack_hth_skills[] table in do_skill_attack() -- where does the hth attack rank? The most useful attacks should occur earlier in the table. 3) Create the skill code. If you created a hth attack, you probably can get away with just using attack_hth. For other skills, put the skill code in skills.c. If your new skill is to be an "associated" skill, then make sure that it returns the value of calc_skill_exp(). 4) Edit treasures/artifacts file as needed (esp. if your skill will become one of the starting skills, or will show up in shops.) 3. Detail of skill archetype values. ------------------------------------ This section details the various object/archetype values. First, we detail skill objects: type: SKILL subtype: subtype of skill invisible: 1 no_drop: 1 name: Name of the skill, used by things like 'use_skill', as well as output of 'skills' command. stats (Str, Dex, sp, grace, etc): These modify the abilities of the player, in a sense giving bonuses. expmul: this is the ratio of experience the players total should increase by when this skill is use. If this is zero, then experience only goes to to the skill. Values higher than 1 are allowed. Note that experience rewarded to the players total is in addition to that given to the skill. Eg, if player should get 500 exp for using a skill, and expmul is 1, the player will get 500 added to that skill as well as 500 to their total. exp: The exp the player has in the skill. level: The level of this skill can_use_skill (flag): If this is set, the player knows the skill natively (eg, does not need a skill tool, see below). If this is not set, then this skill object is acting as a container for experience. For example, if a player is using a holy symbol in order to get his praying skill, we still need to have skill_praying in the players inventory to store the experience in. However, the player can't use that praying skill without a holy symbole until they learn it from a skill scroll. 4. Skill Tools ----------------- Skill tools are items that let a player use a skill they do not otherwise know. Skill tools may also have advantages, eg, spellpaths they grant to the caster, stat bonuses, etc. Most of the values for the skill tools are just like normal equipment (value, weight, face, body_..., ) fields. type: skill_tool skill: Name of the skill this object allows the user of. 5. Skill Scrolls ---------------- type: SKILLSCROLL skill: Name of the skill to be learned Rest of the values are per normal equipment (weight, value, identified, etc). 6. Workings of the Skill System ------------------------------- This section attempts to briefly explain how this all works. Due to the addition of the skill pointer, it is no longer required that a skill be in the ready_skill position to gain experience. Whenever a player tries to use skill either directly (ready_skill ..) or indirectly (cast a spell which requires knowledge of the skill), the code will examine the players inventory to see if they an in fact use the skill. This first checks to see if the player has the appropriate skill archetype in their object. If they do, and can_use_skill is set to 1, nothing more is done. If that is not the case, we then look for a skill tool. If none is found, we tell the player the can't use the skill. If one is found, we try to apply the skill tool - if this can not be done, we also error out. Only if the player explicitly activates a skill with ready_skill do we change the players range pointer. Otherwise, it will remain as is (but not that casting a spell might also change the range pointer). add_exp has been modified to take two additional parameters - skill_name and flag. skill_name is the skill to add the experience to. By passing this to add exp, a lot of the code no longer needs to change chosen_skill, then reset it back again. flag determines what to do if the player does not currently have the skill pointer in their inventory. This can arise if the player is using a skill tool, or part of a party. In the default case of flag being 0, if the player does not currently have the skill in their inventory, this is added (with can_use_skill 0). If flag is 1, we add the exp to the players total exp, but don't give them any in the skill. If it is 2, the player gets nothing. This fixes many of the abuses of party combat - if a member of your party is killing things with wizardry, you'll get wizardry exp. If you don't have wizardry, you'll get some general exp, but you can't funnel it into things like alchemy anymore. The effect of flag 1 to add exp is so that that a player can't have thousands of exp in a skill and never have used in themselves - for a player to have any exp in a skill, he will have had to use it at least once. Note however that a player could have used the skill just once (to say kill a kobold) and yet get a bunch more exp from party members that are actually good wizards. The handling of add_exp with skill_name is pretty simple. In most cases, we know immediately the skill that was used (eg, melee combat, search, disarm, etc). In cases of indirect death (spells), we set the skill in the spell object to the skill that it should get awarded to. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 8 23:58:52 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:20 2005 Subject: [CF-Devel] lore In-Reply-To: <3E936C0C.2000204@sympatico.ca> References: <3E936C0C.2000204@sympatico.ca> Message-ID: <3E93A88C.4080905@sonic.net> Todd wrote: > Ok I want to run this up the flagpole - a proposal for the lore field. > The lore - endlore bit is in place now and I was playing with entering > in some stuff and fell into the following routine: > > lore > The wolf is a common animal found in forests throughout the land. > Wolves are likely to flee if injured. > The wolf has a keen sense of smell and excellent hearing. > endlore > I like this idea a lot. A few notes: Rather than each piece of lore be denoted by end of line, I'd suggest something like: lore --1-- The behemoth is a very large creature, but quite quick. --2-- The behemouth can be identified by their size and long, black, hairy, poision-dripping hides. --3-- Behemoths are very poisionous. --4-- Behemoths have a slight resistance to magic. --5-- Behemoths are immune to fear based attacks. endlore The use of ---- is just an arbitrary value - any unique string would work. I like the idea of enclosing some number to denote 'how good' the information is - thus you could have lots of pieces of knowledge at the same 'difficulty' level. I just think using a newline is dangerous - someone is bound to look at some point and say 'boy - that 200 character line is messy - I'll break it up into more reasonable sized lines', and not realize that this would break anything. Doing this for maps is more difficult - there is no archetype entries for all the maps. And while you could encapsulate it in the map headers, the program won't know about those until they are accessed. Information on maps should probably remain in the messages file. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Apr 7 07:00:59 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:20 2005 Subject: [CF-Devel] skill doc. In-Reply-To: <31430.1049710823@www29.gmx.net> References: <3E8E88C6.9000502@sonic.net> <31430.1049710823@www29.gmx.net> Message-ID: <20030407120059.GB22495@hawthorn.csse.monash.edu.au> And I will just point out that this is one of the few rare times I have ever seen AV write anything so resoundingly positive about an idea :). Congrats to you ;). It must be good indeed. dnh > Just wanted to say that I very much like this new skill > system, as you described it in the doc. > > I'm sure it will need some time till it is fully implemented, > used and everything. But I have no doubt that this is > going to bring a richer gameplay and add to the long-term > fun in Crossfire. > > > AndreasV > > -- > +++ GMX - Mail, Messaging & more http://www.gmx.net +++ > Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Apr 17 13:46:09 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:20 2005 Subject: [CF-Devel] Diamonds References: Message-ID: <3E9EF671.20D5DAB1@gmx.at> The many different materials make identifying objects harder. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 16 22:25:43 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:20 2005 Subject: [CF-Devel] crossfire-devel post from tanner@real-time.com requires approval Message-ID: <20030417032543.1637.5870.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: tanner@real-time.com Subject: Testing Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Wed Apr 16 20:59:25 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:20 2005 Subject: [CF-Devel] dragon food messages In-Reply-To: References: Message-ID: Rather use this diff, i wrongly used mathematical propabilities instead of percentage values. -------------- next part -------------- *** apply.c.old Thu Apr 17 00:30:49 2003 --- apply.c Thu Apr 17 03:50:41 2003 *************** *** 1868,1874 **** char buf[MAX_BUF]; /* tmp. string buffer */ double chance; /* improvement-chance of one resistance type */ ! double maxchance=0; /* highest chance of any type */ double bonus=0; /* level bonus (improvement is easier at lowlevel) */ double mbonus=0; /* monster bonus */ int atnr_winner[NROFATTACKS]; /* winning candidates for resistance improvement */ --- 1868,1874 ---- char buf[MAX_BUF]; /* tmp. string buffer */ double chance; /* improvement-chance of one resistance type */ ! double totalchance=1; /* total chance of gaining one resistance */ double bonus=0; /* level bonus (improvement is easier at lowlevel) */ double mbonus=0; /* monster bonus */ int atnr_winner[NROFATTACKS]; /* winning candidates for resistance improvement */ *************** *** 1941,1960 **** winners++; } ! if (chance > maxchance) maxchance = chance; /*printf(" %s: bonus %.1f, chance %.1f\n", attacks[i], bonus, chance);*/ } } ! /* print message according to maxchance */ ! if (maxchance > 50.) sprintf(buf, "Hmm! The %s tasted delicious!", meal->name); ! else if (maxchance > 10.) sprintf(buf, "The %s tasted very good.", meal->name); ! else if (maxchance > 1.) sprintf(buf, "The %s tasted good.", meal->name); ! else if (maxchance > 0.0001) sprintf(buf, "The %s had a boring taste.", meal->name); else if (meal->last_eat > 0 && atnr_is_dragon_enabled(meal->last_eat)) sprintf(buf, "The %s tasted strange.", meal->name); --- 1941,1964 ---- winners++; } ! if (chance >= 0.01 ) totalchance *= 1 - chance/100; /*printf(" %s: bonus %.1f, chance %.1f\n", attacks[i], bonus, chance);*/ } } ! /* inverse totalchance as until now we have the failure-chance */ ! totalchance = 100 - totalchance*100; ! /* print message according to totalchance */ ! if (totalchance > 50.) sprintf(buf, "Hmm! The %s tasted delicious!", meal->name); ! else if (totalchance > 10.) sprintf(buf, "The %s tasted very good.", meal->name); ! else if (totalchance > 1.) sprintf(buf, "The %s tasted good.", meal->name); ! else if (totalchance > 0.1) ! sprintf(buf, "The %s tasted bland.", meal->name); ! else if (totalchance >= 0.01) sprintf(buf, "The %s had a boring taste.", meal->name); else if (meal->last_eat > 0 && atnr_is_dragon_enabled(meal->last_eat)) sprintf(buf, "The %s tasted strange.", meal->name); From crossfire-devel-admin at archives.real-time.com Wed Apr 16 22:38:56 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:20 2005 Subject: [CF-Devel] crossfire-devel post from tanner@real-time.com requires approval Message-ID: <20030417033856.2232.84838.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: tanner@real-time.com Subject: Testing Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Tue Apr 1 07:13:38 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:20 2005 Subject: [CF-Devel] crossfire-devel post from leaf@real-time.com requires approval Message-ID: <20030401131338.19627.61126.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: leaf@real-time.com Subject: unique-items question (repost) Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Fri Apr 18 21:00:02 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:21 2005 Subject: [CF-Devel] bugfix for gtk experience table display Message-ID: In gcfclient , you can get overlapping text in the experience table display. Even if there is enough space. You can see this when you make the central column smaller. The reason was that instead of gtk_table_new (2, 3 we need gtk_table_new (3, 2 as it is rows,columns not vice versa. Thus we had a 3rd column, eating up space. I also changed it to rather cut part of table from view than to make the text overlap. Bernd Edler -------------- next part -------------- *** gx11.c.old Fri Apr 18 23:32:03 2003 --- gx11.c Fri Apr 18 23:52:21 2003 *************** *** 64,72 **** #include "config.h" - #ifdef __CYGWIN__ #include - #endif /* gtk */ #include --- 64,70 ---- *************** *** 2106,2119 **** * so that spacing is uniform - this should look better. */ ! table = gtk_table_new (2, 3, TRUE); x=0; y=0; /* this is all the same - we just pack it in different places */ for (i=0; i As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: darsie@gmx.at Subject: Diamonds Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Sat Apr 5 03:51:43 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:21 2005 Subject: [CF-Devel] (automatic) apply rings References: <3E86EA81.BA2EB008@gmx.at> <3E87E154.7060103@sonic.net> <3E883364.42BC2704@gmx.at> <3E8A9501.7020801@sonic.net> Message-ID: <3E8EA72F.B6B29CBA@gmx.at> Mark Wedel wrote: > In any case, I think Bernd's solution looks to be the best. I'd rather not > have to try to track when/what orders rings were applied, and it does look like > Bernd's solution is sufficient to allow everything that needs to be done via > keybinding. Yes, it is a solution for keybindings. I'd still love a solution for the mouse so I can put on 2 rings and end up wearing them. Bernhard -- Low end Serverhousing ab 25 e inkl. 1x 11 e/GB, etc.: http://bksys.at _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 9 17:00:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:21 2005 Subject: [CF-Devel] 1 crossfire-devel admin request(s) waiting Message-ID: <20030409220001.15283.53576.Mailman@pirate.real-time.com> The crossfire-devel@lists.real-time.com mailing list has 1 request(s) waiting for your consideration at: https://mailman.real-time.com/mailman/admindb/crossfire-devel Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: beprox@mail.net4b.pt on Wed Apr 9 05:52:01 2003 Cause: Post by non-member to a members-only list From crossfire-devel-admin at archives.real-time.com Fri Apr 4 21:48:34 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:21 2005 Subject: [CF-Devel] Diseases in the arena In-Reply-To: <200304041506526.SM01220@adsl-66-72-99-171.dsl.chcgil.ameritech.net> References: <007501c2fa24$87cf9490$0201a8c0@cavancentral.net> <200304032238576.SM01220@adsl-68-21-14-48.dsl.chcgil.ameritech.net> <3E8D24B0.2010406@sonic.net> <200304041506526.SM01220@adsl-66-72-99-171.dsl.chcgil.ameritech.net> Message-ID: <3E8E5212.7050406@sonic.net> phil@theperlguru.com wrote: > Well, I was referring more to the bug where diseases can leave the > arena. ie. if there is an arena battle with spectators, the > spectators can be killed by diseases running rampant. This is > especially bad, as the spectator areas are no_magic'ed, so the > spectators can't cure themselves. Ok. Now that I no what the bug is... The problem is most likely in infect_disease - it doesn't check for no magic, blocked, etc. A simple fix for this would be that disease won't spread to no magic (or no cleric magic) spaces. Other alternative would be diseases don't spread on battleground spaces. Given how battleground is currently done, this would be a bit of a resource hog, but it probably wouldn't be hard to add another map flag like P_BATTLEGROUND which fixes up that performance problem. The way diseases spread is basically just a square around the infection point. Thus, checking for walls (if desired) would still be very tricky, eg, the disease should still be able to get around corners, so you just can't stop processing some direction just because there is a wall there. Eg, a simple cast like. ...... ..D... ..#... ..M... ...... that monster (M) should still get infected by disease D, even though there is a wall right in the path. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 2 09:00:51 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:22 2005 Subject: [CF-Devel] crossfire-devel post from andi.vogl@gmx.net requires approval Message-ID: <20030402150051.31400.5695.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: andi.vogl@gmx.net Subject: RE: [CF-Devel] improved Aljwaf for Bigworld Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Wed Apr 16 01:42:31 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:22 2005 Subject: [CF-Devel] Fw: Diamonds In-Reply-To: <003d01c3039b$ea7ed260$0802a8c0@ott.ca.dmr> References: <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> <3E9A620E.8060700@sonic.net> <001501c30197$248fd000$0802a8c0@ott.ca.dmr> <003d01c3039b$ea7ed260$0802a8c0@ott.ca.dmr> Message-ID: <3E9CFB57.4060809@sonic.net> Well, I think Todd has some valid points. With a material strings, the bitmask material really makes no sense. I don't remember how much discussion went on with the material type stuff, and how much of that was in mail and what might have been done in irc. That said, I agree setting the material string in the archetypes makes a lot more sense. It also makes it much easier to deal with special images (eg, someone could make a gold chain mail image for example, and the gold chain mail arch would use it. To do something like that with the current system would require some really ugly hacks). The disadvantage of this is that it means a bunch more arcs, and a lot of updating of the treasure lists. It should be noted that for maps, there has never been a good way for a map maker to select a random generation of items, other than selecting an appropriate treasure list (eg, there is no way to say 'I want this to be a club of lythander or club of gnarg.' Or something like 'I want this to either be a +3 sword, +2 plate, or potion of strength'. Some of that can sort of be faked out by by using teleporters/gates/spikes/boulders type of thing, but there is no simple way to currently do that. I'd personally be opposed to the idea of arch's have information for material that is randomly selected. I think that wouldn't really fix much, and your left with the same hacks of trying to figure out what bonuses that iron sword should have instead of a steel sword, etc. At least if you have seperate archs, you can also set up relevant bonuses. But making them all be unique objects opens a new can of worms - why do that instead of using the existing artifacts file/code? Or maybe conversely, if we're going to make new artifacts for all of them, why have the artifacts file at all - why not just have everything be its own object. I personally think the artifacts file is the way to go. In that, you can change the material type. You can adjust values specific to types (eg, shields may be made of one of these 3 materials. As an interesting point, maybe the items of mass should be made of lead as an example). And you can get these changes in the game without having to manage a bunch of archetypes and new treasure lists. I did communicate to Tim that this is what he should have done with the material code when he wrote it - unfortunately, he did not do so. As for naming, that is a bit simpler - really, the name of the object should determine what it is called. EG, the code should never include the material name in the object name. If we think the material name is important, the object should so be renamed (eg, spruce bow instead of just bow). So things like coins would just have the name 'gold coin'. Thus, things liek the example above of the 'of mass' items work out fine. you really don't need to say it is a 'lead plate mail of mass'. Just 'plate mail of mass' would work fine. For some things, you may decide to add a moniker (eg, mithril high shield). Extending the artifacts file (and code) to do that would be easy. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 1 05:23:58 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:23 2005 Subject: [CF-Devel] crossfire-devel post from qiaqjcsipl@firemail.de requires approval Message-ID: <20030401112358.18889.80142.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: qiaqjcsipl@firemail.de Subject: THE ULTIMATE DRUG STORE! Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Thu Apr 10 08:53:48 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:23 2005 Subject: [CF-Devel] food beep frequency, etc Message-ID: <3E95776C.3A8F1F35@gmx.at> Hi! I whish the food beep frequency(/duration) were configureable so I could better distinguish it from my irc clients beeps or my father's crossfire beeps in the same room. Food threshold and how many food's per beep would be nice to configure, too. It would also be cool if I could set what food will be grabbed blindly or set my character to automatically eat some food at a configurable level, maybe even whenever there is enough room in his stomach to fit another piece in. If only that doesn't make the game boring. Bernhard -- Low end Serverhousing ab 25 e inkl. 1x 11 e/GB, etc.: http://bksys.at _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Apr 10 12:43:34 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:23 2005 Subject: [CF-Devel] food beep frequency, etc Message-ID: <200304101743.h3AHhY3f020375@lol1120.lss.emc.com> >It would also be cool if I could set what food will be grabbed blindly One way to do this is to create a new container: A lunch box. Whenever you auto-eat, items in a lunch box are considered first. Lunch boxes would only be able to hold edible items. >or set my character to automatically eat some food at a configurable >level, maybe even whenever there is enough room in his stomach to fit >another piece in. If only that doesn't make the game boring. If I have food in my lunch box, I want to eat whenever I can do so without wasting food, as it lowers my weight with no side effects. If my lunch box is empty, I don't want to eat unless I have to, as I might have random stuff that I don't want to eat. That might be non-trivial to implement, but would be nice. With such a setup, the food beep would only happen when my lunch box is empty, as otherwise I would eat before it got down to that level. --PC _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 12 18:48:09 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:23 2005 Subject: [CF-Devel] Fw: Diamonds Message-ID: <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> Hi, This is my first post to this list, and I'm not an experienced programmer but I think I can contribute in the little I can see while I play crossfire. I've seen a little detail about diamonds in the metalforge server (didn't try on another server yet) when collecting the 10K needed to the apartment extension. I noticed there are two kinds of diamonds that appear to be alike. One is the diamond you find in some dungeon made of granite and the other is the one you exchange for gold at the bank apparently made of nothing (the description doesn't tell anything about its material). Then if you try to buy your extension with 9K of one kind and 1K of another, it's not accepted as 10K in total. The other detail about this is that if you have some diamonds from the bank and you log off and then log in again those are turned into the granite kind of diamonds, no matter if you have it in your inventory, into a pouch or in your apartment. I don't know if this is the only way to make them turn into their real form. I hope for my comments to be useful. Bye! -- +-----------------------------+ | Karla M? Stenger S?bat | | Pando . Canelones . Uruguay | | kstenger@montevideo.com.uy | +-----------------------------+ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Apr 3 17:03:38 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:24 2005 Subject: [CF-Devel] crossfire-devel post from root@garbled.net requires approval Message-ID: <20030403230338.13111.45514.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: root@garbled.net Subject: Monsters sleeping Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Sat Apr 12 18:39:43 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:24 2005 Subject: [CF-Devel] Login problems. Message-ID: <20030412203943.45309985.kstenger@montevideo.com.uy> Hi again!, I've been having some problems to re log in when my character hangs up and it stays logged in but I'm not really controlling it. I know this is on the wishing list but I just want to know if it's not forgotten or the reasons because the possibility to log in with the same character even if it's already logged in it's not implemented yet. I have very often this problem because of my dynamic IP that changes twice a day. Regards! -- +-----------------------------+ | Karla M? Stenger S?bat | | Pando . Canelones . Uruguay | | kstenger@montevideo.com.uy | +-----------------------------+ From crossfire-devel-admin at archives.real-time.com Thu Apr 3 15:20:10 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:24 2005 Subject: [CF-Devel] Returned mail: User unknown Message-ID: <1049404810-278@smtp-send.myrealbox.com> The original message was received Thu, 03 Apr 2003 14:20:08 -0700 from - ----- The following address(es) had permanent fatal errors ----- ; originally to yann.chachkoff@smtp-send.myrealbox.com (unrecoverable error) The recipient 'yann.chachkoff' is unknown at host 'firemail.de' ----- Transcript of session follows ----- >>> RCPT TO: <<< 550 relaying to prohibited by administrator -------------- next part -------------- Skipped content of type message/delivery-status-------------- next part -------------- An embedded message was scrubbed... From: "Yua CaVan" Subject: [CF-Devel] win32 gtk client Date: Thu, 3 Apr 2003 15:03:50 -0600 Size: 2425 Url: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030403/b405f11a/attachment.mht From crossfire-devel-admin at archives.real-time.com Thu Apr 3 16:08:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:25 2005 Subject: [CF-Devel] crossfire-devel member aszlig@uni.de bouncing - disabled Message-ID: <20030403220801.17984.90271.Mailman@pirate.real-time.com> Content-type: text/plain; charset=us-ascii This is a Mailman mailing list bounce action notice: List: crossfire-devel Member: aszlig@uni.de Action: Subscription disabled. Reason: Excessive or fatal bounces. You can reenable their subscription by visiting the membership management page at https://mailman.real-time.com/mailman/admin/crossfire-devel/members and setting their options accordingly The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman-owner@lists.real-time.com. -------------- next part -------------- This is a MIME-encapsulated message. --9C955AF64E.1049405916/racket.ball.reliam.net Content-Description: Notification Content-Type: text/plain This is the Postfix program at host racket.ball.reliam.net. I'm sorry to have to inform you that the message returned below could not be delivered to one or more destinations. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the message returned below. The Postfix program : host 127.0.0.1[127.0.0.1] said: 552 4.2.2 : Mailbox full -- Quota exceeded (in reply to end of DATA command) --9C955AF64E.1049405916/racket.ball.reliam.net Content-Description: Delivery error report Content-Type: message/delivery-status Reporting-MTA: dns; racket.ball.reliam.net Arrival-Date: Thu, 3 Apr 2003 23:38:35 +0200 (CEST) Final-Recipient: rfc822; aszlig@uni.de Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; host 127.0.0.1[127.0.0.1] said: 552 4.2.2 : Mailbox full -- Quota exceeded (in reply to end of DATA command) --9C955AF64E.1049405916/racket.ball.reliam.net Content-Description: Undelivered Message Content-Type: message/rfc822 Received: from pirate.real-time.com (pirate.real-time.com [208.20.202.13]) by racket.ball.reliam.net (Postfix) with ESMTP id 9C955AF64E for ; Thu, 3 Apr 2003 23:38:35 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1] helo=pirate.real-time.com) by pirate.real-time.com with esmtp (Exim 4.12 #5 (Red Hat Linux)) id 191CY4-0004ZM-00; Thu, 03 Apr 2003 15:47:04 -0600 Received: from [205.218.89.26] (helo=pobox5236.gazellevillage.com) by pirate.real-time.com with esmtp (Exim 4.12 #5 (Red Hat Linux)) id 191CX6-0004Z7-00 for ; Thu, 03 Apr 2003 15:46:04 -0600 Received: from yualaptop (12-217-232-32.client.mchsi.com [12.217.232.32]) by pobox5236.gazellevillage.com (8.11.1/pre1.0-MySQL/8.11.4) with SMTP id h33LLF306174 for ; Thu, 3 Apr 2003 15:21:15 -0600 Message-ID: <007501c2fa24$87cf9490$0201a8c0@cavancentral.net> From: "Yua CaVan" To: Date: Thu, 3 Apr 2003 15:03:50 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4920.2300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-Spam-Score: 0.0 (/) X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *191CX6-0004Z7-00*vbqmcTg4zMU* Subject: [CF-Devel] win32 gtk client Sender: crossfire-devel-admin@lists.real-time.com Errors-To: crossfire-devel-admin@lists.real-time.com X-BeenThere: crossfire-devel@lists.real-time.com X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: crossfire-devel@lists.real-time.com List-Help: List-Post: List-Subscribe: , List-Id: Crossfire Development Mailing List List-Unsubscribe: , X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *191CY4-0004ZM-00*y9W7BtiH/GU* Over the past couple of weeks, I have been working with Somebody's win32 source ( http://www.theperlguru.com/crossfire/gcfclient-src.zip ) and have a fairly stable client that supports: gtk, sdl, client-images and sound. binary: http://www.gazellevillage.com/download/gcfclient/gcfclient-install.exe source: http://www.gazellevillage.com/download/gcfclient/win32-crossfire-client-1.5. 0-src.zip In order to compile the source, you will need glib 2.2.1, gtk+ 2.2.1 and the other dependencies thereof ( atk, pango, etc ), sdl, sdl-image, sdl-mixer. I did all my compiling using Visual Studio, so I don't really have a make file. Sorry. :( There is a persistent bug that I am trying to figure out, mebbe you guys could help. When using the "download all information" config option, the client runs out of memory after downloading about 3500 or so images on my win2k dev machine. Somebody had informed me that his experience on his win9x box was around 200 or so images. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel --9C955AF64E.1049405916/racket.ball.reliam.net-- From crossfire-devel-admin at archives.real-time.com Fri Apr 18 03:55:59 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:25 2005 Subject: [CF-Devel] Fw: Diamonds References: Message-ID: <13861.1050656159@www23.gmx.net> A lot of people have complained about the new material code since it has been put in place. That is something we shouldn't ignore. My opinion is that the idea is good - which I think most all agree with - but the implementation is not so good. As I understand it, Tim's main point in this thread was that the full item-creation should be enabled. This would create a better use for materials, but I'm not convinced that it would fix any of the problems. In fact, I'm not too euphoric about the whole material- to-item-creation thing. This is just going to indroduce yet another balancing nightmare, and I don't see why it would be significally more fun than the alchemy skills we currently have. All games where full item-creation really works (like ultima online) have a relyable economy system and a fully balanced set of materials and items. In crossfire such a system is going to fail, because we have neither of that. Past discussions have shown that several people are actually against full item-creation because they are not excited about spending their time with activities like wood-chopping or mining. So, all that being said, I agree with Mark's point of view: It would be better to integrate materials in the artifacts file, and let it focus more on creating special items rather than adding random materials to everything. On the other hand, if this is something Tim cannot agree with, I would also consider to let Tim work on fixing/improving the adressed problems in "his" version of the material code if he wants to. AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Apr 18 02:28:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:25 2005 Subject: [CF-Devel] crossfire-devel post from lms_3862@yahoo.com requires approval Message-ID: <20030418072801.23236.48013.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: lms_3862@yahoo.com Subject: NO Cost Mail Extractor. Bulk Mail Is Made Easy 100% LEGAL Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Mon Apr 14 13:33:26 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:25 2005 Subject: [CF-Devel] Fw: Diamonds In-Reply-To: <3E9A620E.8060700@sonic.net> Message-ID: On 14-Apr-03 Mark Wedel wrote: > 2) The control for material generation is poor. Basically, as it is now, > weapons and armor types will get random materials. But this then gets odd > combinations - no one in their right mind would ever make lead weapons or > armor > (ok, maybe sling bullets, but not much else). Yet lead plate armor could > show > up. Nobody in thier right mind would make a -5 cursed plate either, but you see those. The idea of the lead is similar, in that it's a rare curse. But on the other side.. if we ever implement item destruction to gather raw materials, it's a great source of lead. There are plenty of reasons someone might make something out of most of the other materials.. perhaps an ancient civilization had access to only copper. Heck.. in real life, kings used to make armour out of gold. I mean, how stupid is that, protectively speaking? Another interesting example, is balsa. I created balsa as a "cursed" wood, like lead. The effect on objects is pretty debilitating. However, I noticed that balsa arrows, while extremely weak, could be carried by the millions because they weigh practially nothing. I actually seek them out now. > Also, I don't know if there is in fact any code that actually makes use of > this new material stuff (alchemy/skill stuff), and thus as a player, you care > even less about what material an item may be made out o Each material has special characteristics that make it better or worse than others of the same type. It would be trivial to make silver weapons do extra damage to undead or something like that as well. And if the work is ever done to make the arches for the item creation stuff.. a whole world of uses will pop up. (all that needs be done for item creation to work is add a destructor routine, to basically break an item down into it's raw materials for a fee, and arches/images for the various tools, tables etc. Mostly it's the arches that kept me from ever turning it on.) As for diamonds.. that problem has allways existed. It was just never obvious why it happened before. The same happens with holy symbols, and allways has. The ones you buy in a store don't stack with found ones. > It'd also be useful to see how the material stuff is expected to play out > with the alchemy related code.. Why do we care that the arrow is pine vs oak > for example? For the arrow, you might not care as much.. sans perhaps the balsa example above. But lets take a look at the bow. The yew bow is *way* better than the pine bow. If you were really interested in finding the best bow, you would hunt and seek one made of yew, or one of the other special woods. Just like finding a mithril sword is a blessing. If you want less variety, and want to make the various materials more special.. it's easy enough to tune down the random chance in the materials file. If you do that, most items will be made of a certain type, say lead, or pine. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Apr 13 13:47:53 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:27 2005 Subject: [CF-Devel] Fw: Diamonds In-Reply-To: <3E995675.CABC9629@gmx.at> References: <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> <3E98B105.1070301@sympatico.ca> <3E995675.CABC9629@gmx.at> Message-ID: <3E99B0D9.7060704@sympatico.ca> Bernhard Kuemel wrote: >Todd wrote: > > >>kind of thing would be better to manage in the arches no? Make an arch >>for gold chainmail rather than add a random material type to the >>chainmail arch. >> >> > >IIRC my father found an otherwise simple sword made of platinum. It >weighed about 12 kg and had a value if it were made of iron. Making a >sword of platinum is complete nonsense for it has inferior strength >than iron and a density higher than gold (21.4 g/cm3). > >Bernhard > > > Well I think that's another discussion. Obviously that sword was magical, perhaps forged by dwarves. You father likely found it deep under a mountain perhaps in a Troll's den. I don't mind the idea of a platinum sword, I just think that there should be a consistant object material system to account for it. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 15 00:03:30 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:27 2005 Subject: [CF-Devel] Fw: Login problems. In-Reply-To: <20030412204849.3a7b7c58.kstenger@montevideo.com.uy> References: <20030412204849.3a7b7c58.kstenger@montevideo.com.uy> Message-ID: <3E9B92A2.2010205@sonic.net> Karla Stenger wrote: > Hi again!, > > I've been having some problems to re log in when my character hangs up and it > stays logged in but I'm not really controlling it. > > I know this is on the wishing list but I just want to know if it's not forgotten > or the reasons because the possibility to log in with the same character > even if it's already logged in it's not implemented yet. > > I have very often this problem because of my dynamic IP that changes twice a > day. This isn't forgotton, just a low priority item to fix. Probably wouldn't be really hard to fix, but would still take some amount of effort. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 15 00:55:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:27 2005 Subject: [CF-Devel] [BUG] 1.5 In-Reply-To: <20030410180929.GA28025@ion.res.cmu.edu> References: <20030410180929.GA28025@ion.res.cmu.edu> Message-ID: <3E9B9EB5.5040706@sonic.net> Mark Schreiber wrote: > I can karate chop people to death without them ever becoming angry and > fighting back. > Can you give some more details? What are you attacking? Friendly people in the tavern? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Apr 6 14:00:42 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:28 2005 Subject: [CF-Devel] bonecrusher names on metalforge broken In-Reply-To: from "Bernd Edler" at Apr 06, 2003 06:47:49 PM Message-ID: <200304061900.h36J0gnT010582@mamia.prninfo.com> I've seen harakiri swords and other weapons having this behavior aswell. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Apr 6 11:47:49 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:29 2005 Subject: [CF-Devel] bonecrusher names on metalforge broken Message-ID: The bonecrusher i find now are mostly named like : marble ????????????????????? and they change their names while i play eg.: obsidian wig of comliness + 3 etc. This also effects old bonecrushers in my appartment. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Apr 6 12:59:31 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:29 2005 Subject: [CF-Devel] Diseases in the arena In-Reply-To: Message-ID: <200304061759.h36HxVCA065849@soda.csua.berkeley.edu> >Or perhaps a no-disease space that could line the outer walls separating the >battleground and the spectators. The way I originally implemented diseases, they won't necessarily respect "blocked" squares when looking for someone to infect. They very simply looked at everything within a certain radius, walls or no. And simple is good, because of the expense of doing LOS calculations or some such. Probably best would be to have a disease-free square. PeterM _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 15 11:45:43 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:29 2005 Subject: [CF-Devel] Again with the Lore Message-ID: <003201c3036e$755cae80$0802a8c0@ott.ca.dmr> I think that we are getting somewhere with this. Two things I have been thinking. I would suggest using @ as the delimiter instead of something like --#-- or another invention as this is consistant with the message field for npc speaking and I am a fan of consistancy. So you would see: lore @The llama is a quadraped. @Llamas are not frogs. endlore lore @1The llama is a quadreped. @1Llamas are not frogs. @2Llamas sometimes lay golden eggs. endlore I am not sure that assigning value by number is better than simply assigning value by position since it will not be consistant across arches (one person my set resistance info at @3 another at @5 for example.) I would argue that simply weighting the data according to their position would be alright since more interesting creatures would have more lore lines attributed to them. Another option would be to put the weight value (as a percent?) after the @ so you would have: lore @60The llama is a quadreped. @30Llamas are not frogs @9Llamas sometimes lay golden eggs. @1Llamas explode instantly when you say 'Ni'. endlore It doesn't really matter to me however and I would go along with whatever the consensus is on this. As for the map lore - I do agree that a message file should be used to house information on quests and landmarks and other mappish information, (I didn't think to load this when the map is loaded for example since the lore should be available before the map is used presumably) but I would like to suggest a lore field in maps anyway and script that can be manually run which will collect this info and feed it into this message file. For a standard map set this will only be required to be generated in the same way as the arches are collected (and with the same frequency as the arches are collected in CVS), and the messages file will ship with the server the same way the collected arches do now. It is simply a way to encourage the generation of lore during map design, and a way to modularize the data so that servers with custom maps do not have to manually add or remove the data. You've probably guessed by now I'm big on the seperation of server and design. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Apr 13 03:31:54 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:30 2005 Subject: [CF-Devel] Fw: Diamonds References: <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> <3E9A620E.8060700@sonic.net> Message-ID: <001501c30197$248fd000$0802a8c0@ott.ca.dmr> One way I would posit this to work would be to get rid of existing material type field and have a new field for material type in the arch and a material object type (more arches with modifiers for weight and value and other stuff) maybe even have aclass and subclass like metals --> gold, silver or textiles --> cloth, silk. The material type field in the arch would be able to contain a number of possible materials that the item could be made of so for example: arch chainmail ... material bronze copper iron silver gold mithril admantium ... or arch cloak .... material hides cloth silk leather snakeskin ... and the chainmail would be generated with one of these materials randomly (weighted?) or could be subtyped on a map to be made of a specific material. Not sure how you would have items with multiple materials though (primary and secondary, material fields or a system of bitmasks or something?) This makes it easy to control things so you never get lead swords and you don't have a long list of exceptions and special cases. It makes it fairly easy to add new materials. It would also make it easy to do stuff like melt down your gold sword to get coins or use the base material in formulas (like you need x amount of gold but you can use nuggets or coins or whatever yo ulike) I can see this as being a real pain to implement however. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Apr 14 03:09:04 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:30 2005 Subject: [CF-Devel] Fw: Diamonds In-Reply-To: <3E9A620E.8060700@sonic.net> References: <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> Message-ID: <5.1.0.14.0.20030414030638.02592c40@postoffice.worldnet.att.net> > It'd also be useful to see how the material stuff is expected to play out with the alchemy related code.. Why do we care that the arrow is pine vs oak for example? Well, for one thing, if you play a low-level character, you'll find that any armor item made out of snakeskin is remarkably better than anything else. The material apparently sometimes has an effect on the item's characteristics, or so it would appear. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 1 05:46:22 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:30 2005 Subject: [CF-Devel] crossfire-devel post from temitchell@sympatico.ca requires approval Message-ID: <20030401114622.19023.43943.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: temitchell@sympatico.ca Subject: unique-items question Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Fri Apr 18 14:23:41 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:30 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <13861.1050656159@www23.gmx.net> References: <13861.1050656159@www23.gmx.net> Message-ID: <3EA050BD.8060500@sympatico.ca> Andreas Vogl wrote: >A lot of people have complained about the new material code >since it has been put in place. That is something we >shouldn't ignore. > [...] > > >As I understand it, Tim's main point in this thread was >that the full item-creation should be enabled. >This would create a better use for materials, but I'm >not convinced that it would fix any of the problems. > > Well I for one am a bit sorry with the initial tone I took on this, but it was based on the other reactions showing up in the list about buggy behaviour and a first impression of a pile of weirdly named items and my not carefully looking at how the material stuff worked. It is implemented better than I thought (IMHO). Not that there isn't still room for stuff to be done however. The issues were legit, but they were fixed more with tweeking than patching I think. And even without considering construction and deconstruction of items, this is still a useful addition I think. > >So, all that being said, I agree with Mark's point of view: >It would be better to integrate materials in the >artifacts file, and let it focus more on creating >special items rather than adding random materials >to everything. > I think there is a misrepresentation on this random material thing. Since I may have contributed to this I feel obligated to address it. Now it is fully possible to specify a material using the materialname field (what happens if the 'material' is '4096' (ice) and the materialname is 'oak'?) so it is a bit annoying but the basic idea is good. It is only a matter of explicity setting the 'materialname' in the arch to create the specific item you want (the appearance of randomness is because this wasn't done in many cases - most likely to get some of these things in circulation fast), not because of the design of the code. Actually the code makes it real easy to specity a particular material but this wasn't done to many arches so many things are assigned a random material. There may be some tweeking to do as well. It might be an idea to change Iron to Metal and Leather to Hide and make another organic type to seperate flesh from vegetable matter. I can see that maybe gold and lead (others?) should be in the soft metal category (no more gold or lead swords by accident?) I am not sure how the magical materials should work (seems strange - especially since there are other magical object fields). There are also a lot of stones missing, namely the gem types (diamond, ruby...) which would fix the 'granite' diamond issue. On the other hand I would hate to see a new material created for everything under the sun rather than making a good set of materials with significant differences (I was worried about mention of mithril crystal because mithril melted on a particular map- wouldn't it be better to raise the durability of mithril?) These are fairly minor things though and don't really speak to the code. For your edification there's a current list of materials following the body of this message. I don't see much advantage in moving the materials from it's own file to the artifacts file. If it is to be on the server side at least it is currently in one place now. It wouldn't make things any better integrating it into another file and might be more confusing. Right now it is one stop shopping (even if you need to download the server code...) Now I think every one would agree that the material field has to be fixed so that there isn't two places to specify the material, but it is totally alright in my opinion to keep the basic functionality the same so that if you specify 'metal' you get a random metal, but if you specify silver, you get silver. This was my initial worry that there was no control on the material generation, but I was mistaken. (I was under the impression that Tim was having to change the code to fix stuff like 'leather armor' or 'mithril mithril chainmail', not merely tweeking the arches...) The current having two field thing is more nitpicky (but still it should be fixed) than a real problem. If there was no way to randomly specify a material type, then it would be nesessary to make an arch for every possibe item to generate random items which would suck. On the other hand, when making a map it is possible to specify a material so this is good. Even better the materials do have modifiers for value, weight, saving throws, damage, magic(?). I used the example before, you can have an arch for say a breastplate, specifying the material as metal. A map maker can easily take this arch, drop it on a map and either leave it as metal (resulting in a random metal) or mithril (specific). This is good in my opinion. I do wonder about what to do with items with multiple materials however. One thing that would be nice (read WISHLIST) would be that you could specify a colour in the material so that generic images could be made for some things and the colour applied based on the material. This would make it easy to have a single image for so many items (armour, ore, ingots). There is little point of having a materials system like this if you have to create arches for every damn item anyway just to get a picture. There is tons more to say, I have run out of time however. I would like to talk about fireballs and acid and mining and stuff too... MATERIAL LIST PAPER (1) none IRON (2) gold silver copper platinum lead steel bronze mithril GLASS 4 none LEATHER 8 snakeskin humanskin bearskin dragonhide wolfhide deerskin WOOD 16 oak birch spruce balsa yew bamboo ironwood wyrmwood ORGANIC 32 none STONE 64 marble obsidian limestone runestone CLOTH 128 silk velvet burlap wool kashmir astolare asbestos rubber ADAMANT 256 argonite sanguinite abyssium astrium celestium damascus adamantium magmasium electrum* -->electrum is a precious metal like silver no? perhaps electisium glacium LIQUID 512 none SOFT_METAL 1024 none BONE 2048 ivory dragonscale ICE 4096 none SPECIAL 8192 ? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 8 19:40:44 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:30 2005 Subject: [CF-Devel] lore Message-ID: <3E936C0C.2000204@sympatico.ca> Ok I want to run this up the flagpole - a proposal for the lore field. The lore - endlore bit is in place now and I was playing with entering in some stuff and fell into the following routine: lore The wolf is a common animal found in forests throughout the land. Wolves are likely to flee if injured. The wolf has a keen sense of smell and excellent hearing. endlore lore The behemoth is a very large creature, but quite quick. The behemouth can be identified by their size and long, black, hairy, poision-dripping hides. Behemoths are very poisionous. Behemoths have a slight resistance to magic. Behemoths are immune to fear based attacks. endlore lore Banshee are the undead spirits of elven maidens who have been murdered. It is hard to say which is more dangerous, banshee cries or banshee claws. The scream of the banshee can scare you stiff. The touch of a banshee can paralyze. The Banshee sees only the face of her murderer, but her other senses are very sharp. Banshee are very resistant to both magic and physical harm.s often endlore You can see the idea here I think. Enter a series of short informative statements increasing in value. On the other end when using this info to generate books or put words in peoples' mouths, you can harvest this information in a way that weights the lines. Why bother? Well it would make the information more interesting - rather than having a paragraph spit out about something every time - you get different stuff in a semi random way - you get common lore and more rare lore. Also it is easy to add in stuff one line at a time instead of writing a little exposition - so more people might do it. Also you can easily pepper in some hints for recipies or what ever by inserting some lines. I could easily add in a line for behemoth hide at the end of the list: Interestingly enough, the behemoth's oily hide can be used in making clothing that resists poision. I also like the idea that it keeps things in the arches rather than in a seperate file - which makes it easier to customize things. It would work for most arches - spells, items, monsters... I also like the idea of doing this for maps too. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Apr 7 05:20:23 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:30 2005 Subject: [CF-Devel] skill doc. References: <3E8E88C6.9000502@sonic.net> Message-ID: <31430.1049710823@www29.gmx.net> Mark Wedel wrote: > > Started working on the new skill system. I decided to update > the documentation first to get an idea of where to go to/what > to write. I figured I might as well put it out to the list and > see any comments or other notes people might have. > [...] Just wanted to say that I very much like this new skill system, as you described it in the doc. I'm sure it will need some time till it is fully implemented, used and everything. But I have no doubt that this is going to bring a richer gameplay and add to the long-term fun in Crossfire. AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 16 01:24:09 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:31 2005 Subject: [CF-Devel] Again with the Lore In-Reply-To: <003201c3036e$755cae80$0802a8c0@ott.ca.dmr> References: <003201c3036e$755cae80$0802a8c0@ott.ca.dmr> Message-ID: <3E9CF709.6090506@sonic.net> Todd Mitchell wrote: > I think that we are getting somewhere with this. Two things I have been > thinking. > > I would suggest using @ as the delimiter instead of something like --#-- or > another invention as this is consistant with the message field for npc > speaking and I am a fan of consistancy. So you would see: Well, what the seperator is isn't really important. Just as long as it is something other than a newline. > I am not sure that assigning value by number is better than simply assigning > value by position since it will not be consistant across arches (one person > my set resistance info at @3 another at @5 for example.) I would argue that > simply weighting the data according to their position would be alright since > more interesting creatures would have more lore lines attributed to them. > Another option would be to put the weight value (as a percent?) after the @ > so you would have: > > lore > @60The llama is a quadreped. > @30Llamas are not frogs > @9Llamas sometimes lay golden eggs. > @1Llamas explode instantly when you say 'Ni'. > endlore This might be more interested, combined with ranking them. Thus you could do something like have useful information show up even in low level books, but more likely to show up in higher level books. I personally would remove the idea of a percentage, and just have it a weighting. If the person decides to have the values total up to 100, that is fine. If someone instead has them total to 23, that also works. It just something with a ranking of 3 would be 3 times more likely to show up than something with a ranking of 1. Your point about people using different difficulty for ranking is valid. However, the converse is that maybe you have something you want to have 20 different lore entries for, but maybe the info should be basic. > As for the map lore - I do agree that a message file should be used to house > information on quests and landmarks and other mappish information, (I didn't > think to load this when the map is loaded for example since the lore should > be available before the map is used presumably) but I would like to suggest > a lore field in maps anyway and script that can be manually run which will > collect this info and feed it into this message file. For a standard map > set this will only be required to be generated in the same way as the arches > are collected (and with the same frequency as the arches are collected in > CVS), and the messages file will ship with the server the same way the > collected arches do now. It is simply a way to encourage the generation of > lore during map design, and a way to modularize the data so that servers > with custom maps do not have to manually add or remove the data. You've > probably guessed by now I'm big on the seperation of server and design. Given the complexity of doing this (extending the map header, writing a script to collect it, etc), I'd rather just have people put it in the messages file by hand. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Apr 4 00:22:40 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:31 2005 Subject: [CF-Devel] Diseases in the arena In-Reply-To: <200304032238576.SM01220@adsl-68-21-14-48.dsl.chcgil.ameritech.net> References: <007501c2fa24$87cf9490$0201a8c0@cavancentral.net> <200304032238576.SM01220@adsl-68-21-14-48.dsl.chcgil.ameritech.net> Message-ID: <3E8D24B0.2010406@sonic.net> phil@theperlguru.com wrote: >>From CVS: > > Has any work been done on the fact that diseases can skip from inside > a battleground to outside? Namely, if a player uses diseases in arena > combat, then that player may catch the disease again after he dies in > the duel, and die again for real. This was reported some time ago, > but I'm not sure if anybody took note of it at the time. > The checkin may or may not fix it. In practice, when a player dies, cure disease is called upon the player, which should remove all diseases. However, that doesn't seem to always happen in the past - it appears the disease would be removed, sometimes the symptoms would not be removed. The change I put in fixes that last bit - symptoms are now always removed. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Apr 4 01:50:48 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:32 2005 Subject: [CF-Devel] Crossfire highscore list script In-Reply-To: <20030324194422.B11292@cc.jyu.fi> References: <20030324194422.B11292@cc.jyu.fi> Message-ID: <3E8D3958.2090400@sonic.net> Pertti Karppinen (OH6KTR) wrote: > Enclosed with this message is my scores.pl higihscore html-generator script. > The source code is not pretty, as the state-machine was done without reading > the actual source code that makes that file. It was done in a > reverse-engineering fashion, but it seems to be working ... :-) > > To use that script, as it reloads the page every 6 minutes, you should add > it to crontab like: > */5 * * * * $HOME/crossfire/var/www/bin/scores.pl > /dev/null 2>&1 I've made a few changes (to pick up some data from autoconf) and will put the file into utils/scores.pl.in unless someone sees some issues. Thats probably as a good as a repository as any. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 12 18:31:05 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:32 2005 Subject: [CF-Devel] Diamonds Message-ID: <20030412203105.48ab28e1.kstenger@montevideo.com.uy> Hi, This is my first post to this list, and I'm not an experienced programmer but I think I can contribute in the little I can see while I play crossfire. I've seen a little detail about diamonds in the metalforge server (didn't try on another server yet) when collecting the 10K needed to the apartment extension. I noticed there are two kinds of diamonds that appear to be alike. One is the diamond you find in some dungeon made of granite and the other is the one you exchange for gold at the bank apparently made of nothing (the description doesn't tell anything about its material). Then if you try to buy your extension with 9K of one kind and 1K of another, it's not accepted as 10K in total. The other detail about this is that if you have some diamonds from the bank and you log off and then log in again those are turned into the granite kind of diamonds, no matter if you have it in your inventory, into a pouch or in your apartment. I don't know if this is the only way to make them turn into their real form. I hope for my comments to be useful. Bye! -- +-----------------------------+ | Karla M? Stenger S?bat | | Pando . Canelones . Uruguay | | kstenger@montevideo.com.uy | +-----------------------------+ From crossfire-devel-admin at archives.real-time.com Thu Apr 10 13:09:29 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:32 2005 Subject: [CF-Devel] [BUG] 1.5 Message-ID: <20030410180929.GA28025@ion.res.cmu.edu> I can karate chop people to death without them ever becoming angry and fighting back. -- Best of luck, Mark Schreiber -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030410/9cbb8800/attachment.pgp From crossfire-devel-admin at archives.real-time.com Tue Apr 15 03:08:26 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:32 2005 Subject: [CF-Devel] Fw: Diamonds In-Reply-To: <3E9B8ED4.2070801@sonic.net> Message-ID: On 15-Apr-03 Mark Wedel wrote: > As it is now, there is one case where items don't get randomized types > where > they would cause the least annoyance - rings. Rings, as is, tend not to > stack, > so to note if the ring is silver, gold, bronze, or whatever isn't likely to > cause any extra annoyance. Now the material type wouldn't make any > difference > for the rings (except maybe value) I elected not to implement the use of materials on any items where I hadn't yet come up with a good use of the effects. It's not just a decoration. I see no reason to implement them on the rings unless it will have an effect of some sort. Doubly so if there exists the chance that someday we will come up with a good use for the materials on rings, but not be able to implement it properly because we buggered it making a decoration. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 15 04:21:49 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:32 2005 Subject: [CF-Devel] Fw: Diamonds References: <3E9B8ED4.2070801@sonic.net> Message-ID: <3E9BCF2D.15C1ED6@gmx.at> Mark Wedel wrote: > > As it is now, there is one case where items don't get randomized types where > they would cause the least annoyance - rings. Rings, as is, tend not to stack, > so to note if the ring is silver, gold, bronze, or whatever isn't likely to > cause any extra annoyance. Now the material type wouldn't make any difference > for the rings (except maybe value) The value of a magic ring is largly determined by it's magic, material playing a minor role. Bernhard -- Low end Serverhousing ab 25 e inkl. 1x 11 e/GB, etc.: http://bksys.at _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Apr 18 17:00:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:32 2005 Subject: [CF-Devel] 1 crossfire-devel admin request(s) waiting Message-ID: <20030418220001.24977.59047.Mailman@pirate.real-time.com> The crossfire-devel@lists.real-time.com mailing list has 1 request(s) waiting for your consideration at: https://mailman.real-time.com/mailman/admindb/crossfire-devel Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: lms_3862@yahoo.com on Fri Apr 18 02:28:01 2003 Cause: Post by non-member to a members-only list From crossfire-devel-admin at archives.real-time.com Sat Apr 5 04:20:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:34 2005 Subject: [CF-Devel] crossfire-devel post from darsie@gmx.at requires approval Message-ID: <20030405102001.9829.34884.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: darsie@gmx.at Subject: Re: [CF-Devel] (automatic) apply rings Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Wed Apr 16 19:49:05 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:34 2005 Subject: [CF-Devel] dragon food messages Message-ID: This patch will generate more precise messages for dragons eating body parts. In the old way "The blah had a boring taste." could mean anything from 0 to 5.9 % chance of gaining a resistance. (Yes, including zero as (int)chance*100 will floor x < 0.01 to 0) With this patch, any "boring" food does have a chance of at least 0.01 % . I also filled the gap from "boring" to "good" with "bland". So now we have: chance | message | average amount needed for +1 x = 0 no taste {} 0.01 <= x <= 0.1 boring [1000,10000) 0.1 < x <= 1.0 bland [100,1000) 1.0 < x <= 10.0 good [10,100) 10.0 < x <= 50.0 very good [2,10) 50.0 < x delicious [1,2) With x the total chance (in %) of gaining a resistance level. I have not changed the chance to get resistances, only the feedback. Bernd Edler -------------- next part -------------- *** apply.c.old Thu Apr 17 00:30:49 2003 --- apply.c Thu Apr 17 01:49:08 2003 *************** *** 1868,1874 **** char buf[MAX_BUF]; /* tmp. string buffer */ double chance; /* improvement-chance of one resistance type */ ! double maxchance=0; /* highest chance of any type */ double bonus=0; /* level bonus (improvement is easier at lowlevel) */ double mbonus=0; /* monster bonus */ int atnr_winner[NROFATTACKS]; /* winning candidates for resistance improvement */ --- 1868,1874 ---- char buf[MAX_BUF]; /* tmp. string buffer */ double chance; /* improvement-chance of one resistance type */ ! double totalchance=1; /* total chance of gaining one resistance */ double bonus=0; /* level bonus (improvement is easier at lowlevel) */ double mbonus=0; /* monster bonus */ int atnr_winner[NROFATTACKS]; /* winning candidates for resistance improvement */ *************** *** 1941,1960 **** winners++; } ! if (chance > maxchance) maxchance = chance; /*printf(" %s: bonus %.1f, chance %.1f\n", attacks[i], bonus, chance);*/ } } ! /* print message according to maxchance */ ! if (maxchance > 50.) sprintf(buf, "Hmm! The %s tasted delicious!", meal->name); ! else if (maxchance > 10.) sprintf(buf, "The %s tasted very good.", meal->name); ! else if (maxchance > 1.) sprintf(buf, "The %s tasted good.", meal->name); ! else if (maxchance > 0.0001) sprintf(buf, "The %s had a boring taste.", meal->name); else if (meal->last_eat > 0 && atnr_is_dragon_enabled(meal->last_eat)) sprintf(buf, "The %s tasted strange.", meal->name); --- 1941,1964 ---- winners++; } ! if (chance >= 0.01 ) totalchance *= 1 - chance; /*printf(" %s: bonus %.1f, chance %.1f\n", attacks[i], bonus, chance);*/ } } ! /* inverse totalchance as until now we have the failure-chance */ ! totalchance = 1 - totalchance; ! /* print message according to totalchance */ ! if (totalchance > 50.) sprintf(buf, "Hmm! The %s tasted delicious!", meal->name); ! else if (totalchance > 10.) sprintf(buf, "The %s tasted very good.", meal->name); ! else if (totalchance > 1.) sprintf(buf, "The %s tasted good.", meal->name); ! else if (totalchance > 0.1) ! sprintf(buf, "The %s tasted bland.", meal->name); ! else if (totalchance >= 0.01) sprintf(buf, "The %s had a boring taste.", meal->name); else if (meal->last_eat > 0 && atnr_is_dragon_enabled(meal->last_eat)) sprintf(buf, "The %s tasted strange.", meal->name); From crossfire-devel-admin at archives.real-time.com Mon Apr 7 07:00:59 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:35 2005 Subject: [CF-Devel] skill doc. In-Reply-To: <31430.1049710823@www29.gmx.net> References: <3E8E88C6.9000502@sonic.net> <31430.1049710823@www29.gmx.net> Message-ID: <20030407120059.GB22495@hawthorn.csse.monash.edu.au> And I will just point out that this is one of the few rare times I have ever seen AV write anything so resoundingly positive about an idea :). Congrats to you ;). It must be good indeed. dnh > Just wanted to say that I very much like this new skill > system, as you described it in the doc. > > I'm sure it will need some time till it is fully implemented, > used and everything. But I have no doubt that this is > going to bring a richer gameplay and add to the long-term > fun in Crossfire. > > > AndreasV > > -- > +++ GMX - Mail, Messaging & more http://www.gmx.net +++ > Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Apr 10 12:43:34 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:35 2005 Subject: [CF-Devel] food beep frequency, etc Message-ID: <200304101743.h3AHhY3f020375@lol1120.lss.emc.com> >It would also be cool if I could set what food will be grabbed blindly One way to do this is to create a new container: A lunch box. Whenever you auto-eat, items in a lunch box are considered first. Lunch boxes would only be able to hold edible items. >or set my character to automatically eat some food at a configurable >level, maybe even whenever there is enough room in his stomach to fit >another piece in. If only that doesn't make the game boring. If I have food in my lunch box, I want to eat whenever I can do so without wasting food, as it lowers my weight with no side effects. If my lunch box is empty, I don't want to eat unless I have to, as I might have random stuff that I don't want to eat. That might be non-trivial to implement, but would be nice. With such a setup, the food beep would only happen when my lunch box is empty, as otherwise I would eat before it got down to that level. --PC _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Apr 10 13:39:00 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:36 2005 Subject: [CF-Devel] crossfire-devel post from mark7@andrew.cmu.edu requires approval Message-ID: <20030410183900.4719.74080.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: mark7@andrew.cmu.edu Subject: [BUG] 1.5 Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Sat Apr 12 20:37:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:37 2005 Subject: [CF-Devel] crossfire-devel post from 236319@dtwc.com requires approval Message-ID: <20030413013701.16861.70358.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: 236319@dtwc.com Subject: all internet users need this9 Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Sat Apr 12 19:36:21 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:37 2005 Subject: [CF-Devel] Fw: Diamonds In-Reply-To: <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> References: <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> Message-ID: <3E98B105.1070301@sympatico.ca> Karla Stenger wrote: >Hi, > >This is my first post to this list, and I'm not an experienced programmer >but I think I can contribute in the little I can see while I play crossfire. > >I've seen a little detail about diamonds in the metalforge server (didn't try >on another server yet) when collecting the 10K needed to the apartment >extension. I noticed there are two kinds of diamonds that appear to be alike. >One is the diamond you find in some dungeon made of granite and the other is the >one you exchange for gold at the bank apparently made of nothing (the >description doesn't tell anything about its material). > >Then if you try to buy your extension with 9K of one kind and 1K of another, >it's not accepted as 10K in total. > >The other detail about this is that if you have some diamonds from the bank and >you log off and then log in again those are turned into the granite kind of >diamonds, no matter if you have it in your inventory, into a pouch or in your >apartment. I don't know if this is the only way to make them turn into their >real form. > >I hope for my comments to be useful. >Bye! > > > I am going to jump on this comment because I think it related to the new material types and this material type thing has been bothering me for a bit. Sorry Karla, I can't give you an answer but I do have a question to ask. I'm not an experienced programmer either but there seems to be a lot of issues with the new material types and I am not sure that it is worth it to keep on just fixing them as has been happening. I understand the reason for the new materials was for expanding the item creation/alchemy system (yes?), but there has to be a better way to do this with the old system of material types, no? I was pretty happy having the bitmask material type and not having these problems with item matching, stacking and weird materials for common objects. Could not the old system be expanded to include more mateirals or the old material bitmask system is replaced with something more like this new thing? I think that this kind of thing would be better to manage in the arches no? Make an arch for gold chainmail rather than add a random material type to the chainmail arch. Plus I do not like to see the material type in the name, 'pine arrow' or 'dog-skin leather armour' is not necessary for me to know. If the item is something that does have a material in the name anyway (like DragonScale Plate Armor or Golden sheild) then it is usually otherwise special too and has a diffrent archetype and properties. Otherwise it is just Plate Armor or a shield. Only when I examine something, eat someting, when it is valued, when it gets burned up or reacts to a spell, or otherwise has unique properties do I need to know what it is made of. Now there may be a good reason for doing things this way - but from my view (I admit it is a limited view) it seems unweildy and there are too many special cases (like mithril and leather armours - or stone axes?) and patchy type fixes to make it work. Is there a solution to be had, it seems like there should be a better way to do this - is there even a problem anymore and I missed it being fixed? I'm not against the idea in theory, but the execution seems to be a problem here. Maybe it's just me that doesn't get it? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 2 01:45:05 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:37 2005 Subject: [CF-Devel] (automatic) apply rings In-Reply-To: <3E883364.42BC2704@gmx.at> References: <3E86EA81.BA2EB008@gmx.at> <3E87E154.7060103@sonic.net> <3E883364.42BC2704@gmx.at> Message-ID: <3E8A9501.7020801@sonic.net> Bernhard Kuemel wrote: > Mark Wedel wrote: > Mhm. But the client could not keep track of last recently applied > rings after quitting or sleeping in bed of reality. It could try so in > a save file but there might be some confusion if the player used a > different client in the meanwhile. That would not matter much for my > FIFO, but for your stack (keep longest worn ring on). Well, I'd be a bit less worried in that case - it wouldn't take very long for the player to establish the ring wear order, and which things would work as expectedly. > I also like it much better not to remove things before I use others. > This is an extra command that takes time and may open a short time > vulnerability. If the unapply happens automatically (in the server) > this is maybe even an atomic action. But, well, atomic key changing is > not realistic so it need not be in the game. An extra command also > takes up space in the byte limited keybindings. The fact that applying an item automatically un applies something else and then applies the new item really quickly should really be considered a bug. At minimum, such actions should take longer (twice as long). In a more realistic sense, the times for equip/unequip are quite fast - switching from the dragon armor to power plate mail in one tick is quite a trick. It'd be relative easy to add some real times to what it takes to switch items. It's basically just a matter of reducing the players speed_left by a higher amount. Doing it in an incremental fashion would be a lot harder (eg, 5 ticks to remove armor, and say 5 ticks to put armor on, and in those 8 ticks where armor is being removed/equipped, you get no benefit of it). This is getting unrelated to the question at hand. But mostly a note that consider the atomic process of a ring being unequipped and a new ring being equipped in the same tick a bonus, and not something to be expected. In any case, I think Bernd's solution looks to be the best. I'd rather not have to try to track when/what orders rings were applied, and it does look like Bernd's solution is sufficient to allow everything that needs to be done via keybinding. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Apr 10 09:23:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:37 2005 Subject: [CF-Devel] crossfire-devel post from darsie@gmx.at requires approval Message-ID: <20030410142301.24452.65299.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: darsie@gmx.at Subject: food beep frequency, etc Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Wed Apr 16 15:51:11 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:37 2005 Subject: [CF-Devel] Fw: Diamonds In-Reply-To: <003d01c3039b$ea7ed260$0802a8c0@ott.ca.dmr> Message-ID: On 15-Apr-03 Todd Mitchell wrote: > Now it is interesting to hear the mention of deconstructing objects. This > was my primary reason for bringing this up in the first place - a consistant > material system would allow item creation and destruction with relative ease > and with a bit of predicatbility, it would also make simpler such stuff as > mining and logging and tanning. This is the main reason I thought that > having material objects in the arches would be better than a list (aside > from the fact that you wouldn't need to change the server code to add a new > material, and this is the way other stuff is handled). It would also > simplify mixing skills with materials (tanning, smithing, boyer...) if there > were a more consistant (and I think object based) material system. Thats basically what the item creation code does. The basic concept is that you gather together a pile of raw gold, and say "build longsword" and with a little fiddling, it makes a gold longsword with your smithery skill. The problem being.. that it's not enabled because: 1) There are no images/arches for the build facilities. 2) There are no images/arches for many of the raw materials. 3) There are no images/arches for the tools. 4) There is no image/arch for the destructor device. Writing code for a destructor would probably be trivial. But I have tested it fairly well.. and it works, and it's fun to play with. Once it was in place.. it would also be pretty trivial to do something like making mountains made out of metal, so a random metal was chosen for them. Mining could look at the metal that was chosen randomly, and mine out a chunk of it. Trees could obviously do the same thing for wood. Various hides would be direct forms of raw material, as would some monster parts. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Apr 13 03:31:54 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:38 2005 Subject: [CF-Devel] Fw: Diamonds References: <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> <3E9A620E.8060700@sonic.net> Message-ID: <001501c30197$248fd000$0802a8c0@ott.ca.dmr> One way I would posit this to work would be to get rid of existing material type field and have a new field for material type in the arch and a material object type (more arches with modifiers for weight and value and other stuff) maybe even have aclass and subclass like metals --> gold, silver or textiles --> cloth, silk. The material type field in the arch would be able to contain a number of possible materials that the item could be made of so for example: arch chainmail ... material bronze copper iron silver gold mithril admantium ... or arch cloak .... material hides cloth silk leather snakeskin ... and the chainmail would be generated with one of these materials randomly (weighted?) or could be subtyped on a map to be made of a specific material. Not sure how you would have items with multiple materials though (primary and secondary, material fields or a system of bitmasks or something?) This makes it easy to control things so you never get lead swords and you don't have a long list of exceptions and special cases. It makes it fairly easy to add new materials. It would also make it easy to do stuff like melt down your gold sword to get coins or use the base material in formulas (like you need x amount of gold but you can use nuggets or coins or whatever yo ulike) I can see this as being a real pain to implement however. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 1 07:13:38 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:38 2005 Subject: [CF-Devel] crossfire-devel post from leaf@real-time.com requires approval Message-ID: <20030401131338.19627.61126.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: leaf@real-time.com Subject: unique-items question (repost) Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Tue Apr 1 05:23:58 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:38 2005 Subject: [CF-Devel] crossfire-devel post from qiaqjcsipl@firemail.de requires approval Message-ID: <20030401112358.18889.80142.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: qiaqjcsipl@firemail.de Subject: THE ULTIMATE DRUG STORE! Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Tue Apr 1 11:12:09 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:38 2005 Subject: [CF-Devel] crossfire-devel post from leaf@real-time.com requires approval Message-ID: <20030401171209.21684.77942.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: leaf@real-time.com Subject: unique-items question (repost2) Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Tue Apr 1 11:36:00 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:38 2005 Subject: [CF-Devel] crossfire-devel post from beprox@mail.net4b.pt requires approval Message-ID: <20030401173600.977.49318.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: beprox@mail.net4b.pt Subject: =?windows-1252?Q?UM_ESCRIT=D3RIO_EM_MOVIMENTO...?= Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Tue Apr 1 04:29:53 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:39 2005 Subject: [CF-Devel] crossfire-devel post from temitchell@sympatico.ca requires approval Message-ID: <20030401102953.18298.50830.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: temitchell@sympatico.ca Subject: Re: [CF-Devel] CVS Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Tue Apr 15 04:52:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:39 2005 Subject: [CF-Devel] crossfire-devel post from darsie@gmx.at requires approval Message-ID: <20030415095201.24966.76790.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: darsie@gmx.at Subject: Re: [CF-Devel] Fw: Diamonds Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Tue Apr 15 00:55:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:39 2005 Subject: [CF-Devel] [BUG] 1.5 In-Reply-To: <20030410180929.GA28025@ion.res.cmu.edu> References: <20030410180929.GA28025@ion.res.cmu.edu> Message-ID: <3E9B9EB5.5040706@sonic.net> Mark Schreiber wrote: > I can karate chop people to death without them ever becoming angry and > fighting back. > Can you give some more details? What are you attacking? Friendly people in the tavern? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Apr 14 03:09:04 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:39 2005 Subject: [CF-Devel] Fw: Diamonds In-Reply-To: <3E9A620E.8060700@sonic.net> References: <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> Message-ID: <5.1.0.14.0.20030414030638.02592c40@postoffice.worldnet.att.net> > It'd also be useful to see how the material stuff is expected to play out with the alchemy related code.. Why do we care that the arrow is pine vs oak for example? Well, for one thing, if you play a low-level character, you'll find that any armor item made out of snakeskin is remarkably better than anything else. The material apparently sometimes has an effect on the item's characteristics, or so it would appear. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Apr 6 14:00:42 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:40 2005 Subject: [CF-Devel] bonecrusher names on metalforge broken In-Reply-To: from "Bernd Edler" at Apr 06, 2003 06:47:49 PM Message-ID: <200304061900.h36J0gnT010582@mamia.prninfo.com> I've seen harakiri swords and other weapons having this behavior aswell. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Apr 14 02:23:58 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:40 2005 Subject: [CF-Devel] Fw: Diamonds In-Reply-To: <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> References: <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> Message-ID: <3E9A620E.8060700@sonic.net> There are certainly various issues with the materials. In terms of the question at hand - the code that checks for quantity of an item, which is used in all sorts of places, only checks for the quantity of one 'grouping' of an item. Thus, if you have 50 spruce arrows and 30 oak arrows, and something is looking for arrows, it will say there are either 50 or 30 arrows on that space, and not 80 (the 50/30 depends on the order of stacking on the space). Thus is actually a fairly old bug, but until the material stuff showed up, almost never posed a problem (once in a while, I seem to recall someone would find issues related to potions, as they were identified differently or somehow wouldn't merge, even though they were the same). The reason why the logout/login works is because there is a special hack to update the material type when an object is loaded. To answer Todd's question: I certainly want the expanded material form to be in an external file - to have to update values in the server and recompile for any new material isn't a good idea IMO. I communicated this to garbled when he was doing the work on this, and this was done. However, that said, there are certainly some issues with materials: 1) Items of the same type (eg diamonds) of different materials don't merge. This isn't a fixable problem. but the problem it leads to is that now instead of a just a pile of +1 arrows, you might have +1 spruce arrows, +1 oak arrows, +1 pine arrows, etc. In a sense, creating a lot more inventory clutter. 2) The control for material generation is poor. Basically, as it is now, weapons and armor types will get random materials. But this then gets odd combinations - no one in their right mind would ever make lead weapons or armor (ok, maybe sling bullets, but not much else). Yet lead plate armor could show up. I personally don't mind seeing a whole bunch of materials in the game. The problem is that when you get bombarded with all these material types, it looses much of any specialness. Also, I don't know if there is in fact any code that actually makes use of this new material stuff (alchemy/skill stuff), and thus as a player, you care even less about what material an item may be made out o It certainly wouldn't be hard to remove the material name from the object name (As presented to the player). I just wonder if that may cause extra confusion - why do I have 5 stacks of arrows, of which they are all identified, but they don't merge? You'd have to then examine them to see that they are of different materials). I'm not sure what the ideal situation to this is. One thought is to just have the majority items of base (generic) material like in the old days, eg, wood, stone, iron, etc, and thus not detail what it is made out of. Then a relative small number get made out of special materials, and these are added to the name (thus, those pine arrows may be relatively rare, so they'd be unlikely to clutter up your inventory much, because its less likely they'd show up) It'd also be useful to see how the material stuff is expected to play out with the alchemy related code.. Why do we care that the arrow is pine vs oak for example? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 1 01:09:07 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:40 2005 Subject: [CF-Devel] python plugin Message-ID: <1049180947.9535ef00yann.chachkoff@myrealbox.com> >On Sat, 29 Mar 2003, Mark Wedel wrote: >> >> I believe the plugin is in fact installed on metalforge. >> It's just by default, >> I don't think anything uses the plugin. >> >Afaik the occidental stuff is there by default. >The 1.5 tarballs has it. >When i use the occidental sword on my local server, i get >quite frequently reactions from it. >e.g "Your weapon feels warmer" (attacktype switched to fire) >I cleared the whole newbie tower with this sword on metalforge. >As nothing special happened,i assumed the plugin was not enabled. A simple way to check if the plugin is correctly loaded is to send a "pluglist" DM command. It displays the list of all plugins running. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 12 18:48:49 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:40 2005 Subject: [CF-Devel] Fw: Login problems. Message-ID: <20030412204849.3a7b7c58.kstenger@montevideo.com.uy> Hi again!, I've been having some problems to re log in when my character hangs up and it stays logged in but I'm not really controlling it. I know this is on the wishing list but I just want to know if it's not forgotten or the reasons because the possibility to log in with the same character even if it's already logged in it's not implemented yet. I have very often this problem because of my dynamic IP that changes twice a day. Regards! -- +-----------------------------+ | Karla M? Stenger S?bat | | Pando . Canelones . Uruguay | | kstenger@montevideo.com.uy | +-----------------------------+ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Apr 3 15:20:10 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:42 2005 Subject: [CF-Devel] Returned mail: User unknown Message-ID: <1049404810-278@smtp-send.myrealbox.com> The original message was received Thu, 03 Apr 2003 14:20:08 -0700 from - ----- The following address(es) had permanent fatal errors ----- ; originally to yann.chachkoff@smtp-send.myrealbox.com (unrecoverable error) The recipient 'yann.chachkoff' is unknown at host 'firemail.de' ----- Transcript of session follows ----- >>> RCPT TO: <<< 550 relaying to prohibited by administrator -------------- next part -------------- Skipped content of type message/delivery-status-------------- next part -------------- An embedded message was scrubbed... From: "Yua CaVan" Subject: [CF-Devel] win32 gtk client Date: Thu, 3 Apr 2003 15:03:50 -0600 Size: 2425 Url: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030403/b405f11a/attachment-0001.mht From crossfire-devel-admin at archives.real-time.com Thu Apr 3 19:21:37 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:42 2005 Subject: [CF-Devel] crossfire-devel post from root@garbled.net requires approval Message-ID: <20030404012137.14121.94552.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: root@garbled.net Subject: Money issues Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Thu Apr 3 16:08:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:42 2005 Subject: [CF-Devel] crossfire-devel member aszlig@uni.de bouncing - disabled Message-ID: <20030403220801.17984.90271.Mailman@pirate.real-time.com> Content-type: text/plain; charset=us-ascii This is a Mailman mailing list bounce action notice: List: crossfire-devel Member: aszlig@uni.de Action: Subscription disabled. Reason: Excessive or fatal bounces. You can reenable their subscription by visiting the membership management page at https://mailman.real-time.com/mailman/admin/crossfire-devel/members and setting their options accordingly The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman-owner@lists.real-time.com. -------------- next part -------------- This is a MIME-encapsulated message. --9C955AF64E.1049405916/racket.ball.reliam.net Content-Description: Notification Content-Type: text/plain This is the Postfix program at host racket.ball.reliam.net. I'm sorry to have to inform you that the message returned below could not be delivered to one or more destinations. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the message returned below. The Postfix program : host 127.0.0.1[127.0.0.1] said: 552 4.2.2 : Mailbox full -- Quota exceeded (in reply to end of DATA command) --9C955AF64E.1049405916/racket.ball.reliam.net Content-Description: Delivery error report Content-Type: message/delivery-status Reporting-MTA: dns; racket.ball.reliam.net Arrival-Date: Thu, 3 Apr 2003 23:38:35 +0200 (CEST) Final-Recipient: rfc822; aszlig@uni.de Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; host 127.0.0.1[127.0.0.1] said: 552 4.2.2 : Mailbox full -- Quota exceeded (in reply to end of DATA command) --9C955AF64E.1049405916/racket.ball.reliam.net Content-Description: Undelivered Message Content-Type: message/rfc822 Received: from pirate.real-time.com (pirate.real-time.com [208.20.202.13]) by racket.ball.reliam.net (Postfix) with ESMTP id 9C955AF64E for ; Thu, 3 Apr 2003 23:38:35 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1] helo=pirate.real-time.com) by pirate.real-time.com with esmtp (Exim 4.12 #5 (Red Hat Linux)) id 191CY4-0004ZM-00; Thu, 03 Apr 2003 15:47:04 -0600 Received: from [205.218.89.26] (helo=pobox5236.gazellevillage.com) by pirate.real-time.com with esmtp (Exim 4.12 #5 (Red Hat Linux)) id 191CX6-0004Z7-00 for ; Thu, 03 Apr 2003 15:46:04 -0600 Received: from yualaptop (12-217-232-32.client.mchsi.com [12.217.232.32]) by pobox5236.gazellevillage.com (8.11.1/pre1.0-MySQL/8.11.4) with SMTP id h33LLF306174 for ; Thu, 3 Apr 2003 15:21:15 -0600 Message-ID: <007501c2fa24$87cf9490$0201a8c0@cavancentral.net> From: "Yua CaVan" To: Date: Thu, 3 Apr 2003 15:03:50 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4920.2300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-Spam-Score: 0.0 (/) X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *191CX6-0004Z7-00*vbqmcTg4zMU* Subject: [CF-Devel] win32 gtk client Sender: crossfire-devel-admin@lists.real-time.com Errors-To: crossfire-devel-admin@lists.real-time.com X-BeenThere: crossfire-devel@lists.real-time.com X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: crossfire-devel@lists.real-time.com List-Help: List-Post: List-Subscribe: , List-Id: Crossfire Development Mailing List List-Unsubscribe: , X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *191CY4-0004ZM-00*y9W7BtiH/GU* Over the past couple of weeks, I have been working with Somebody's win32 source ( http://www.theperlguru.com/crossfire/gcfclient-src.zip ) and have a fairly stable client that supports: gtk, sdl, client-images and sound. binary: http://www.gazellevillage.com/download/gcfclient/gcfclient-install.exe source: http://www.gazellevillage.com/download/gcfclient/win32-crossfire-client-1.5. 0-src.zip In order to compile the source, you will need glib 2.2.1, gtk+ 2.2.1 and the other dependencies thereof ( atk, pango, etc ), sdl, sdl-image, sdl-mixer. I did all my compiling using Visual Studio, so I don't really have a make file. Sorry. :( There is a persistent bug that I am trying to figure out, mebbe you guys could help. When using the "download all information" config option, the client runs out of memory after downloading about 3500 or so images on my win2k dev machine. Somebody had informed me that his experience on his win9x box was around 200 or so images. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel --9C955AF64E.1049405916/racket.ball.reliam.net-- From crossfire-devel-admin at archives.real-time.com Wed Apr 2 09:00:51 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:42 2005 Subject: [CF-Devel] crossfire-devel post from andi.vogl@gmx.net requires approval Message-ID: <20030402150051.31400.5695.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: andi.vogl@gmx.net Subject: RE: [CF-Devel] improved Aljwaf for Bigworld Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Wed Apr 2 09:19:36 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:42 2005 Subject: [CF-Devel] crossfire-devel post from ut`@usa.net requires approval Message-ID: <20030402151936.31537.39579.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: ¸u¸t¸`@usa.net Subject: =?Big5?B?MjAwMqZ+stdNQUlMpua+UKpavrmkaq5p?= Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Sun Apr 13 11:30:17 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:43 2005 Subject: [CF-Devel] Fw: Diamonds In-Reply-To: <3E98B105.1070301@sympatico.ca> References: <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> <3E98B105.1070301@sympatico.ca> Message-ID: <200304131830.20063.paco@arsfortunata.com> El Domingo, 13 de Abril de 2003 02:36, Todd escribi?: > I am going to jump on this comment because I think it related to the new > material types and this material type thing has been bothering me for a > bit. Sorry Karla, I can't give you an answer but I do have a question > to ask. > I'm not an experienced programmer either but there seems to be a lot of > issues with the new material types and I am not sure that it is worth it > to keep on just fixing them as has been happening. I understand the > reason for the new materials was for expanding the item creation/alchemy > system (yes?), but there has to be a better way to do this with the old > system of material types, no? I was pretty happy having the bitmask > material type and not having these problems with item matching, stacking > and weird materials for common objects. Could not the old system be > expanded to include more mateirals or the old material bitmask system is > replaced with something more like this new thing? I think that this > kind of thing would be better to manage in the arches no? Make an arch > for gold chainmail rather than add a random material type to the > chainmail arch. > Plus I do not like to see the material type in the name, 'pine arrow' or > 'dog-skin leather armour' is not necessary for me to know. If the item > is something that does have a material in the name anyway (like > DragonScale Plate Armor or Golden sheild) then it is usually otherwise > special too and has a diffrent archetype and properties. Otherwise it > is just Plate Armor or a shield. Only when I examine something, eat > someting, when it is valued, when it gets burned up or reacts to a > spell, or otherwise has unique properties do I need to know what it is > made of. Now there may be a good reason for doing things this way - but > from my view (I admit it is a limited view) it seems unweildy and there > are too many special cases (like mithril and leather armours - or stone > axes?) and patchy type fixes to make it work. Is there a solution to be > had, it seems like there should be a better way to do this - is there > even a problem anymore and I missed it being fixed? I'm not against the > idea in theory, but the execution seems to be a problem here. Maybe > it's just me that doesn't get it? I post a message about the same some time ago I just repost some parts of it now (yes I'm lazy :-) : (talking about ideas to steal in the game IVAN) Items have 2 material, one is the head/tip/blade or the main material of the item. The appereance of the item changes if you change the material of the item (you can wish for scrolls of change material) The wood/metal items should only display the metal part name .. no no more spruce axes. Also it will be nice to limit the number of wooden materias .. what the it's the diference if I use an oak arror or a spruce one ? wooden arrows (only sharpened wood , no tip) bambu arrows (no tip) and metal ones (wooden with metal tip : copper, iron ...) will be nice. A percent of the item made of the main material should be included so .. an arrow have 20% base tip weigth that changes if material change and a 80% from unimportant material. Same for axes, spears, maces, hammers, horned helmets (the horns are mere addonament and usually allways made from ... horn!!!), etc ... Or a second material to every item could be added .. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Apr 3 21:34:29 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:43 2005 Subject: [CF-Devel] Diseases in the arena In-Reply-To: <007501c2fa24$87cf9490$0201a8c0@cavancentral.net> References: <007501c2fa24$87cf9490$0201a8c0@cavancentral.net> Message-ID: <200304032238576.SM01220@adsl-68-21-14-48.dsl.chcgil.ameritech.net> From crossfire-devel-admin at archives.real-time.com Fri Apr 4 14:02:42 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:44 2005 Subject: [CF-Devel] Diseases in the arena In-Reply-To: <3E8D24B0.2010406@sonic.net> References: <007501c2fa24$87cf9490$0201a8c0@cavancentral.net> <200304032238576.SM01220@adsl-68-21-14-48.dsl.chcgil.ameritech.net> <3E8D24B0.2010406@sonic.net> Message-ID: <200304041506526.SM01220@adsl-66-72-99-171.dsl.chcgil.ameritech.net> On Thu, 03 Apr 2003 22:22:40 -0800, Mark Wedel wrote: >phil@theperlguru.com wrote: >>>From CVS: > >> >> Has any work been done on the fact that diseases can skip from inside >> a battleground to outside? Namely, if a player uses diseases in arena >> combat, then that player may catch the disease again after he dies in >> the duel, and die again for real. This was reported some time ago, >> but I'm not sure if anybody took note of it at the time. >> > > The checkin may or may not fix it. > > In practice, when a player dies, cure disease is called upon the player, which >should remove all diseases. However, that doesn't seem to always happen in the >past - it appears the disease would be removed, sometimes the symptoms would not >be removed. > > The change I put in fixes that last bit - symptoms are now always removed. Well, I was referring more to the bug where diseases can leave the arena. ie. if there is an arena battle with spectators, the spectators can be killed by diseases running rampant. This is especially bad, as the spectator areas are no_magic'ed, so the spectators can't cure themselves. -Philip _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Apr 4 02:03:04 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:44 2005 Subject: [CF-Devel] Directory permissions In-Reply-To: <20030324163809.GA28159@mids.student.utwente.nl> References: <20030324163809.GA28159@mids.student.utwente.nl> Message-ID: <3E8D3C38.9050003@sonic.net> Joris Bontje wrote: > New directories created by the crossfire server are mode 777 > which means that they are world readable and writable! > > The filemodes however are 660. > Would there be a problem changing the directory mode in (atleast) 770 ? I have made changes so that there is a SAVE_DIR_MODE define in config.h that lets you specify what permissions the directories should be created at. I'll check this in in the next day or so. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Apr 4 01:50:48 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:44 2005 Subject: [CF-Devel] Crossfire highscore list script In-Reply-To: <20030324194422.B11292@cc.jyu.fi> References: <20030324194422.B11292@cc.jyu.fi> Message-ID: <3E8D3958.2090400@sonic.net> Pertti Karppinen (OH6KTR) wrote: > Enclosed with this message is my scores.pl higihscore html-generator script. > The source code is not pretty, as the state-machine was done without reading > the actual source code that makes that file. It was done in a > reverse-engineering fashion, but it seems to be working ... :-) > > To use that script, as it reloads the page every 6 minutes, you should add > it to crontab like: > */5 * * * * $HOME/crossfire/var/www/bin/scores.pl > /dev/null 2>&1 I've made a few changes (to pick up some data from autoconf) and will put the file into utils/scores.pl.in unless someone sees some issues. Thats probably as a good as a repository as any. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Apr 4 00:22:40 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:44 2005 Subject: [CF-Devel] Diseases in the arena In-Reply-To: <200304032238576.SM01220@adsl-68-21-14-48.dsl.chcgil.ameritech.net> References: <007501c2fa24$87cf9490$0201a8c0@cavancentral.net> <200304032238576.SM01220@adsl-68-21-14-48.dsl.chcgil.ameritech.net> Message-ID: <3E8D24B0.2010406@sonic.net> phil@theperlguru.com wrote: >>From CVS: > > Has any work been done on the fact that diseases can skip from inside > a battleground to outside? Namely, if a player uses diseases in arena > combat, then that player may catch the disease again after he dies in > the duel, and die again for real. This was reported some time ago, > but I'm not sure if anybody took note of it at the time. > The checkin may or may not fix it. In practice, when a player dies, cure disease is called upon the player, which should remove all diseases. However, that doesn't seem to always happen in the past - it appears the disease would be removed, sometimes the symptoms would not be removed. The change I put in fixes that last bit - symptoms are now always removed. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 1 05:46:22 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:46 2005 Subject: [CF-Devel] crossfire-devel post from temitchell@sympatico.ca requires approval Message-ID: <20030401114622.19023.43943.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: temitchell@sympatico.ca Subject: unique-items question Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Tue Apr 1 02:58:04 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:47 2005 Subject: [CF-Devel] crossfire-devel post from temitchell@sympatico.ca requires approval Message-ID: <20030401085804.17067.7269.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: temitchell@sympatico.ca Subject: Fw: unique-map recycling Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Sun Apr 6 11:47:49 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:47 2005 Subject: [CF-Devel] bonecrusher names on metalforge broken Message-ID: The bonecrusher i find now are mostly named like : marble ????????????????????? and they change their names while i play eg.: obsidian wig of comliness + 3 etc. This also effects old bonecrushers in my appartment. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Apr 6 11:00:36 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:47 2005 Subject: [CF-Devel] Diseases in the arena In-Reply-To: <3E8E5212.7050406@sonic.net> Message-ID: On 05-Apr-03 Mark Wedel wrote: > A simple fix for this would be that disease won't spread to no magic (or no > cleric magic) spaces. This would kind of suck, as on occasion I have used diseases creatively in no-magic areas. To make them not spread just to fix the arena seems a bit of overkill. > Other alternative would be diseases don't spread on battleground spaces. This might be preferrable.. Or perhaps a no-disease space that could line the outer walls separating the battleground and the spectators. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Apr 13 07:52:00 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:48 2005 Subject: [CF-Devel] crossfire-devel post from darsie@gmx.at requires approval Message-ID: <20030413125200.24975.29736.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: darsie@gmx.at Subject: Re: [CF-Devel] Fw: Diamonds Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Sat Apr 5 03:51:43 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:48 2005 Subject: [CF-Devel] (automatic) apply rings References: <3E86EA81.BA2EB008@gmx.at> <3E87E154.7060103@sonic.net> <3E883364.42BC2704@gmx.at> <3E8A9501.7020801@sonic.net> Message-ID: <3E8EA72F.B6B29CBA@gmx.at> Mark Wedel wrote: > In any case, I think Bernd's solution looks to be the best. I'd rather not > have to try to track when/what orders rings were applied, and it does look like > Bernd's solution is sufficient to allow everything that needs to be done via > keybinding. Yes, it is a solution for keybindings. I'd still love a solution for the mouse so I can put on 2 rings and end up wearing them. Bernhard -- Low end Serverhousing ab 25 e inkl. 1x 11 e/GB, etc.: http://bksys.at _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 15 11:45:43 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:48 2005 Subject: [CF-Devel] Again with the Lore Message-ID: <003201c3036e$755cae80$0802a8c0@ott.ca.dmr> I think that we are getting somewhere with this. Two things I have been thinking. I would suggest using @ as the delimiter instead of something like --#-- or another invention as this is consistant with the message field for npc speaking and I am a fan of consistancy. So you would see: lore @The llama is a quadraped. @Llamas are not frogs. endlore lore @1The llama is a quadreped. @1Llamas are not frogs. @2Llamas sometimes lay golden eggs. endlore I am not sure that assigning value by number is better than simply assigning value by position since it will not be consistant across arches (one person my set resistance info at @3 another at @5 for example.) I would argue that simply weighting the data according to their position would be alright since more interesting creatures would have more lore lines attributed to them. Another option would be to put the weight value (as a percent?) after the @ so you would have: lore @60The llama is a quadreped. @30Llamas are not frogs @9Llamas sometimes lay golden eggs. @1Llamas explode instantly when you say 'Ni'. endlore It doesn't really matter to me however and I would go along with whatever the consensus is on this. As for the map lore - I do agree that a message file should be used to house information on quests and landmarks and other mappish information, (I didn't think to load this when the map is loaded for example since the lore should be available before the map is used presumably) but I would like to suggest a lore field in maps anyway and script that can be manually run which will collect this info and feed it into this message file. For a standard map set this will only be required to be generated in the same way as the arches are collected (and with the same frequency as the arches are collected in CVS), and the messages file will ship with the server the same way the collected arches do now. It is simply a way to encourage the generation of lore during map design, and a way to modularize the data so that servers with custom maps do not have to manually add or remove the data. You've probably guessed by now I'm big on the seperation of server and design. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 15 04:12:41 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:48 2005 Subject: [CF-Devel] Fw: Diamonds References: Message-ID: <3E9BCD09.E79949B0@gmx.at> Tim Rightnour wrote: > > I elected not to implement the use of materials on any items where I hadn't yet > come up with a good use of the effects. It's not just a decoration. I see no > reason to implement them on the rings unless it will have an effect of some > sort. Heh, if there was magic for real I would actually expect that the material a magic ring is made of plays an important role. Well, still we can ignore this and achive the same results without material type, but the same is true for armour and weapons. We wouldn't have to care whether an armour is made of leather or mithril, but we do. We could invite some witches, wizards, alchemists, astrologists from the real world for advice. Silver might be a good choice for rings of ice as it must feel quite cool for it is the best conductor of heat - and electricity as well, so maybe for 'ring of storm', too. OTOH, a gold ring might make a (str-1, cha+2) ring. There could even be non metal rings and they may be combustible. I would, however, not like rings with equal properties to have different materials and so would not stack. I do have 2 rings of wisdom+2, adamant, fire, resist confusion +24, strength +2, acid, ice. > Doubly so if there exists the chance that someday we will come up with a > good use for the materials on rings, but not be able to implement it properly > because we buggered it making a decoration. Bernhard -- Low end Serverhousing ab 25 e inkl. 1x 11 e/GB, etc.: http://bksys.at _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 12 18:39:43 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:48 2005 Subject: [CF-Devel] Login problems. Message-ID: <20030412203943.45309985.kstenger@montevideo.com.uy> Hi again!, I've been having some problems to re log in when my character hangs up and it stays logged in but I'm not really controlling it. I know this is on the wishing list but I just want to know if it's not forgotten or the reasons because the possibility to log in with the same character even if it's already logged in it's not implemented yet. I have very often this problem because of my dynamic IP that changes twice a day. Regards! -- +-----------------------------+ | Karla M? Stenger S?bat | | Pando . Canelones . Uruguay | | kstenger@montevideo.com.uy | +-----------------------------+ From crossfire-devel-admin at archives.real-time.com Tue Apr 15 04:43:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:48 2005 Subject: [CF-Devel] crossfire-devel post from darsie@gmx.at requires approval Message-ID: <20030415094301.24596.81628.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: darsie@gmx.at Subject: Re: [CF-Devel] Fw: Diamonds Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Sun Apr 13 13:47:53 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:48 2005 Subject: [CF-Devel] Fw: Diamonds In-Reply-To: <3E995675.CABC9629@gmx.at> References: <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> <3E98B105.1070301@sympatico.ca> <3E995675.CABC9629@gmx.at> Message-ID: <3E99B0D9.7060704@sympatico.ca> Bernhard Kuemel wrote: >Todd wrote: > > >>kind of thing would be better to manage in the arches no? Make an arch >>for gold chainmail rather than add a random material type to the >>chainmail arch. >> >> > >IIRC my father found an otherwise simple sword made of platinum. It >weighed about 12 kg and had a value if it were made of iron. Making a >sword of platinum is complete nonsense for it has inferior strength >than iron and a density higher than gold (21.4 g/cm3). > >Bernhard > > > Well I think that's another discussion. Obviously that sword was magical, perhaps forged by dwarves. You father likely found it deep under a mountain perhaps in a Troll's den. I don't mind the idea of a platinum sword, I just think that there should be a consistant object material system to account for it. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Apr 6 12:59:31 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:48 2005 Subject: [CF-Devel] Diseases in the arena In-Reply-To: Message-ID: <200304061759.h36HxVCA065849@soda.csua.berkeley.edu> >Or perhaps a no-disease space that could line the outer walls separating the >battleground and the spectators. The way I originally implemented diseases, they won't necessarily respect "blocked" squares when looking for someone to infect. They very simply looked at everything within a certain radius, walls or no. And simple is good, because of the expense of doing LOS calculations or some such. Probably best would be to have a disease-free square. PeterM _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 16 01:42:31 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:50 2005 Subject: [CF-Devel] Fw: Diamonds In-Reply-To: <003d01c3039b$ea7ed260$0802a8c0@ott.ca.dmr> References: <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> <3E9A620E.8060700@sonic.net> <001501c30197$248fd000$0802a8c0@ott.ca.dmr> <003d01c3039b$ea7ed260$0802a8c0@ott.ca.dmr> Message-ID: <3E9CFB57.4060809@sonic.net> Well, I think Todd has some valid points. With a material strings, the bitmask material really makes no sense. I don't remember how much discussion went on with the material type stuff, and how much of that was in mail and what might have been done in irc. That said, I agree setting the material string in the archetypes makes a lot more sense. It also makes it much easier to deal with special images (eg, someone could make a gold chain mail image for example, and the gold chain mail arch would use it. To do something like that with the current system would require some really ugly hacks). The disadvantage of this is that it means a bunch more arcs, and a lot of updating of the treasure lists. It should be noted that for maps, there has never been a good way for a map maker to select a random generation of items, other than selecting an appropriate treasure list (eg, there is no way to say 'I want this to be a club of lythander or club of gnarg.' Or something like 'I want this to either be a +3 sword, +2 plate, or potion of strength'. Some of that can sort of be faked out by by using teleporters/gates/spikes/boulders type of thing, but there is no simple way to currently do that. I'd personally be opposed to the idea of arch's have information for material that is randomly selected. I think that wouldn't really fix much, and your left with the same hacks of trying to figure out what bonuses that iron sword should have instead of a steel sword, etc. At least if you have seperate archs, you can also set up relevant bonuses. But making them all be unique objects opens a new can of worms - why do that instead of using the existing artifacts file/code? Or maybe conversely, if we're going to make new artifacts for all of them, why have the artifacts file at all - why not just have everything be its own object. I personally think the artifacts file is the way to go. In that, you can change the material type. You can adjust values specific to types (eg, shields may be made of one of these 3 materials. As an interesting point, maybe the items of mass should be made of lead as an example). And you can get these changes in the game without having to manage a bunch of archetypes and new treasure lists. I did communicate to Tim that this is what he should have done with the material code when he wrote it - unfortunately, he did not do so. As for naming, that is a bit simpler - really, the name of the object should determine what it is called. EG, the code should never include the material name in the object name. If we think the material name is important, the object should so be renamed (eg, spruce bow instead of just bow). So things like coins would just have the name 'gold coin'. Thus, things liek the example above of the 'of mass' items work out fine. you really don't need to say it is a 'lead plate mail of mass'. Just 'plate mail of mass' would work fine. For some things, you may decide to add a moniker (eg, mithril high shield). Extending the artifacts file (and code) to do that would be easy. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 12 18:48:09 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:51 2005 Subject: [CF-Devel] Fw: Diamonds Message-ID: <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> Hi, This is my first post to this list, and I'm not an experienced programmer but I think I can contribute in the little I can see while I play crossfire. I've seen a little detail about diamonds in the metalforge server (didn't try on another server yet) when collecting the 10K needed to the apartment extension. I noticed there are two kinds of diamonds that appear to be alike. One is the diamond you find in some dungeon made of granite and the other is the one you exchange for gold at the bank apparently made of nothing (the description doesn't tell anything about its material). Then if you try to buy your extension with 9K of one kind and 1K of another, it's not accepted as 10K in total. The other detail about this is that if you have some diamonds from the bank and you log off and then log in again those are turned into the granite kind of diamonds, no matter if you have it in your inventory, into a pouch or in your apartment. I don't know if this is the only way to make them turn into their real form. I hope for my comments to be useful. Bye! -- +-----------------------------+ | Karla M? Stenger S?bat | | Pando . Canelones . Uruguay | | kstenger@montevideo.com.uy | +-----------------------------+ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Apr 10 13:09:29 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:52 2005 Subject: [CF-Devel] [BUG] 1.5 Message-ID: <20030410180929.GA28025@ion.res.cmu.edu> I can karate chop people to death without them ever becoming angry and fighting back. -- Best of luck, Mark Schreiber -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030410/9cbb8800/attachment-0001.pgp From crossfire-devel-admin at archives.real-time.com Tue Apr 15 04:21:49 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:52 2005 Subject: [CF-Devel] Fw: Diamonds References: <3E9B8ED4.2070801@sonic.net> Message-ID: <3E9BCF2D.15C1ED6@gmx.at> Mark Wedel wrote: > > As it is now, there is one case where items don't get randomized types where > they would cause the least annoyance - rings. Rings, as is, tend not to stack, > so to note if the ring is silver, gold, bronze, or whatever isn't likely to > cause any extra annoyance. Now the material type wouldn't make any difference > for the rings (except maybe value) The value of a magic ring is largly determined by it's magic, material playing a minor role. Bernhard -- Low end Serverhousing ab 25 e inkl. 1x 11 e/GB, etc.: http://bksys.at _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 8 23:58:52 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:53 2005 Subject: [CF-Devel] lore In-Reply-To: <3E936C0C.2000204@sympatico.ca> References: <3E936C0C.2000204@sympatico.ca> Message-ID: <3E93A88C.4080905@sonic.net> Todd wrote: > Ok I want to run this up the flagpole - a proposal for the lore field. > The lore - endlore bit is in place now and I was playing with entering > in some stuff and fell into the following routine: > > lore > The wolf is a common animal found in forests throughout the land. > Wolves are likely to flee if injured. > The wolf has a keen sense of smell and excellent hearing. > endlore > I like this idea a lot. A few notes: Rather than each piece of lore be denoted by end of line, I'd suggest something like: lore --1-- The behemoth is a very large creature, but quite quick. --2-- The behemouth can be identified by their size and long, black, hairy, poision-dripping hides. --3-- Behemoths are very poisionous. --4-- Behemoths have a slight resistance to magic. --5-- Behemoths are immune to fear based attacks. endlore The use of ---- is just an arbitrary value - any unique string would work. I like the idea of enclosing some number to denote 'how good' the information is - thus you could have lots of pieces of knowledge at the same 'difficulty' level. I just think using a newline is dangerous - someone is bound to look at some point and say 'boy - that 200 character line is messy - I'll break it up into more reasonable sized lines', and not realize that this would break anything. Doing this for maps is more difficult - there is no archetype entries for all the maps. And while you could encapsulate it in the map headers, the program won't know about those until they are accessed. Information on maps should probably remain in the messages file. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 16 01:24:09 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:54 2005 Subject: [CF-Devel] Again with the Lore In-Reply-To: <003201c3036e$755cae80$0802a8c0@ott.ca.dmr> References: <003201c3036e$755cae80$0802a8c0@ott.ca.dmr> Message-ID: <3E9CF709.6090506@sonic.net> Todd Mitchell wrote: > I think that we are getting somewhere with this. Two things I have been > thinking. > > I would suggest using @ as the delimiter instead of something like --#-- or > another invention as this is consistant with the message field for npc > speaking and I am a fan of consistancy. So you would see: Well, what the seperator is isn't really important. Just as long as it is something other than a newline. > I am not sure that assigning value by number is better than simply assigning > value by position since it will not be consistant across arches (one person > my set resistance info at @3 another at @5 for example.) I would argue that > simply weighting the data according to their position would be alright since > more interesting creatures would have more lore lines attributed to them. > Another option would be to put the weight value (as a percent?) after the @ > so you would have: > > lore > @60The llama is a quadreped. > @30Llamas are not frogs > @9Llamas sometimes lay golden eggs. > @1Llamas explode instantly when you say 'Ni'. > endlore This might be more interested, combined with ranking them. Thus you could do something like have useful information show up even in low level books, but more likely to show up in higher level books. I personally would remove the idea of a percentage, and just have it a weighting. If the person decides to have the values total up to 100, that is fine. If someone instead has them total to 23, that also works. It just something with a ranking of 3 would be 3 times more likely to show up than something with a ranking of 1. Your point about people using different difficulty for ranking is valid. However, the converse is that maybe you have something you want to have 20 different lore entries for, but maybe the info should be basic. > As for the map lore - I do agree that a message file should be used to house > information on quests and landmarks and other mappish information, (I didn't > think to load this when the map is loaded for example since the lore should > be available before the map is used presumably) but I would like to suggest > a lore field in maps anyway and script that can be manually run which will > collect this info and feed it into this message file. For a standard map > set this will only be required to be generated in the same way as the arches > are collected (and with the same frequency as the arches are collected in > CVS), and the messages file will ship with the server the same way the > collected arches do now. It is simply a way to encourage the generation of > lore during map design, and a way to modularize the data so that servers > with custom maps do not have to manually add or remove the data. You've > probably guessed by now I'm big on the seperation of server and design. Given the complexity of doing this (extending the map header, writing a script to collect it, etc), I'd rather just have people put it in the messages file by hand. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 5 01:41:58 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:54 2005 Subject: [CF-Devel] skill doc. Message-ID: <3E8E88C6.9000502@sonic.net> Started working on the new skill system. I decided to update the documentation first to get an idea of where to go to/what to write. I figured I might as well put it out to the list and see any comments or other notes people might have. SKILLS/EXPERIENCE DOCUMENTATION for DEVELOPERS ---------------------------------------------- - Summary - 0. Introduction 1. Sketch of system a. Initialization - how skills and experience are linked 2. How to add new skills a. creation of new skill: outline of needed steps 3. Detail of skill archetype values. 4. Skill Tools 5. Skill Scrolls 6. Workings of the Skill System ------------------------------------------------------------------------- 0. Introduction --------------- Skills were redone to a large extent in April 2003. This document has been updated to reflect how the skills work. The main change is that experience categories were removed from the game. Instead, experience goes to the skill itself. Thus. how good a player is at the skills is directly proportional to how good they are at that skill, and not the category itself. 1. Sketch of system ------------------- In the skills/experience code, players gain experience for the activities which they perform in the game ("You are what you do"). The activities a player may engage in are controlled by the skills they possess. All players start with a basic set of skills which they may expand through adventuring. While monsters do not gain experience from the use of skills, they may use any skills which exist in their inventory if they have the can_use_skill flag set. In the code, skills are objects which exist in the player/monster inventory. Both NPC/monsters and players use the same skill archetypes. Not all skills are however enabled for monster use. Check the Skills_players.doc for available NPC skills. The experience one gets for a skill is greatly simplified. No longer is it weighted based on the stats of the player. Rather, the experience is based on what the skill was used for - opening a tough trap gets more exp than opening an easy trap. The stats the player has will improve the chances of success in most cases - this is bonus enough without also gaining additional experience. The chracters total experience is no longer related to the sum of experience in the players skills - A player could for example only of 1000 exp, but have skills with 2500 exp, 300 exp, etc. Removing the tie between skills and total experience allows for reasonable skill advancement - you can allow a player to easily get to level 20 in a skill without them now being level 20 player. Note also that the only tunables are now in the code or in the archetypes - if the exp for disarming is out of whack, the code would need to be changed to give more appropriate amounts. 2. How to add new skills ------------------------- Adding a new skill to CF is not overly difficult, it is little more difficult than adding new archetypes and a spell to the game. a. creation of new skill: outline of needed steps A number of steps are required to create a new skill. 1) Edit a new skills archetype. See below for appropriate parameters. If you desire the skill to be a skill tool, edit a "face" for the new skill. If you want to have the skill to be learned via a skill scroll, edit a skillscroll for the skill. Place the new archetype(s) in the lib/arch/skills directory. Remember to name your new skill appropriately (ie skill_). Make sure you select a unique subtype for your new skill. 2) Edit skill_util.c. Add an entry for the skill in do_skill() (so that it may be used as a "long-range attack"). If the new skill is a hth attack take a look at the attack_hth_skills[] table in do_skill_attack() -- where does the hth attack rank? The most useful attacks should occur earlier in the table. 3) Create the skill code. If you created a hth attack, you probably can get away with just using attack_hth. For other skills, put the skill code in skills.c. If your new skill is to be an "associated" skill, then make sure that it returns the value of calc_skill_exp(). 4) Edit treasures/artifacts file as needed (esp. if your skill will become one of the starting skills, or will show up in shops.) 3. Detail of skill archetype values. ------------------------------------ This section details the various object/archetype values. First, we detail skill objects: type: SKILL subtype: subtype of skill invisible: 1 no_drop: 1 name: Name of the skill, used by things like 'use_skill', as well as output of 'skills' command. stats (Str, Dex, sp, grace, etc): These modify the abilities of the player, in a sense giving bonuses. expmul: this is the ratio of experience the players total should increase by when this skill is use. If this is zero, then experience only goes to to the skill. Values higher than 1 are allowed. Note that experience rewarded to the players total is in addition to that given to the skill. Eg, if player should get 500 exp for using a skill, and expmul is 1, the player will get 500 added to that skill as well as 500 to their total. exp: The exp the player has in the skill. level: The level of this skill can_use_skill (flag): If this is set, the player knows the skill natively (eg, does not need a skill tool, see below). If this is not set, then this skill object is acting as a container for experience. For example, if a player is using a holy symbol in order to get his praying skill, we still need to have skill_praying in the players inventory to store the experience in. However, the player can't use that praying skill without a holy symbole until they learn it from a skill scroll. 4. Skill Tools ----------------- Skill tools are items that let a player use a skill they do not otherwise know. Skill tools may also have advantages, eg, spellpaths they grant to the caster, stat bonuses, etc. Most of the values for the skill tools are just like normal equipment (value, weight, face, body_..., ) fields. type: skill_tool skill: Name of the skill this object allows the user of. 5. Skill Scrolls ---------------- type: SKILLSCROLL skill: Name of the skill to be learned Rest of the values are per normal equipment (weight, value, identified, etc). 6. Workings of the Skill System ------------------------------- This section attempts to briefly explain how this all works. Due to the addition of the skill pointer, it is no longer required that a skill be in the ready_skill position to gain experience. Whenever a player tries to use skill either directly (ready_skill ..) or indirectly (cast a spell which requires knowledge of the skill), the code will examine the players inventory to see if they an in fact use the skill. This first checks to see if the player has the appropriate skill archetype in their object. If they do, and can_use_skill is set to 1, nothing more is done. If that is not the case, we then look for a skill tool. If none is found, we tell the player the can't use the skill. If one is found, we try to apply the skill tool - if this can not be done, we also error out. Only if the player explicitly activates a skill with ready_skill do we change the players range pointer. Otherwise, it will remain as is (but not that casting a spell might also change the range pointer). add_exp has been modified to take two additional parameters - skill_name and flag. skill_name is the skill to add the experience to. By passing this to add exp, a lot of the code no longer needs to change chosen_skill, then reset it back again. flag determines what to do if the player does not currently have the skill pointer in their inventory. This can arise if the player is using a skill tool, or part of a party. In the default case of flag being 0, if the player does not currently have the skill in their inventory, this is added (with can_use_skill 0). If flag is 1, we add the exp to the players total exp, but don't give them any in the skill. If it is 2, the player gets nothing. This fixes many of the abuses of party combat - if a member of your party is killing things with wizardry, you'll get wizardry exp. If you don't have wizardry, you'll get some general exp, but you can't funnel it into things like alchemy anymore. The effect of flag 1 to add exp is so that that a player can't have thousands of exp in a skill and never have used in themselves - for a player to have any exp in a skill, he will have had to use it at least once. Note however that a player could have used the skill just once (to say kill a kobold) and yet get a bunch more exp from party members that are actually good wizards. The handling of add_exp with skill_name is pretty simple. In most cases, we know immediately the skill that was used (eg, melee combat, search, disarm, etc). In cases of indirect death (spells), we set the skill in the spell object to the skill that it should get awarded to. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 15 03:08:26 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:54 2005 Subject: [CF-Devel] Fw: Diamonds In-Reply-To: <3E9B8ED4.2070801@sonic.net> Message-ID: On 15-Apr-03 Mark Wedel wrote: > As it is now, there is one case where items don't get randomized types > where > they would cause the least annoyance - rings. Rings, as is, tend not to > stack, > so to note if the ring is silver, gold, bronze, or whatever isn't likely to > cause any extra annoyance. Now the material type wouldn't make any > difference > for the rings (except maybe value) I elected not to implement the use of materials on any items where I hadn't yet come up with a good use of the effects. It's not just a decoration. I see no reason to implement them on the rings unless it will have an effect of some sort. Doubly so if there exists the chance that someday we will come up with a good use for the materials on rings, but not be able to implement it properly because we buggered it making a decoration. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 12 18:31:05 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:55 2005 Subject: [CF-Devel] Diamonds Message-ID: <20030412203105.48ab28e1.kstenger@montevideo.com.uy> Hi, This is my first post to this list, and I'm not an experienced programmer but I think I can contribute in the little I can see while I play crossfire. I've seen a little detail about diamonds in the metalforge server (didn't try on another server yet) when collecting the 10K needed to the apartment extension. I noticed there are two kinds of diamonds that appear to be alike. One is the diamond you find in some dungeon made of granite and the other is the one you exchange for gold at the bank apparently made of nothing (the description doesn't tell anything about its material). Then if you try to buy your extension with 9K of one kind and 1K of another, it's not accepted as 10K in total. The other detail about this is that if you have some diamonds from the bank and you log off and then log in again those are turned into the granite kind of diamonds, no matter if you have it in your inventory, into a pouch or in your apartment. I don't know if this is the only way to make them turn into their real form. I hope for my comments to be useful. Bye! -- +-----------------------------+ | Karla M? Stenger S?bat | | Pando . Canelones . Uruguay | | kstenger@montevideo.com.uy | +-----------------------------+ From crossfire-devel-admin at archives.real-time.com Tue Apr 15 00:03:30 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:55 2005 Subject: [CF-Devel] Fw: Login problems. In-Reply-To: <20030412204849.3a7b7c58.kstenger@montevideo.com.uy> References: <20030412204849.3a7b7c58.kstenger@montevideo.com.uy> Message-ID: <3E9B92A2.2010205@sonic.net> Karla Stenger wrote: > Hi again!, > > I've been having some problems to re log in when my character hangs up and it > stays logged in but I'm not really controlling it. > > I know this is on the wishing list but I just want to know if it's not forgotten > or the reasons because the possibility to log in with the same character > even if it's already logged in it's not implemented yet. > > I have very often this problem because of my dynamic IP that changes twice a > day. This isn't forgotton, just a low priority item to fix. Probably wouldn't be really hard to fix, but would still take some amount of effort. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Apr 14 13:33:26 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:56 2005 Subject: [CF-Devel] Fw: Diamonds In-Reply-To: <3E9A620E.8060700@sonic.net> Message-ID: On 14-Apr-03 Mark Wedel wrote: > 2) The control for material generation is poor. Basically, as it is now, > weapons and armor types will get random materials. But this then gets odd > combinations - no one in their right mind would ever make lead weapons or > armor > (ok, maybe sling bullets, but not much else). Yet lead plate armor could > show > up. Nobody in thier right mind would make a -5 cursed plate either, but you see those. The idea of the lead is similar, in that it's a rare curse. But on the other side.. if we ever implement item destruction to gather raw materials, it's a great source of lead. There are plenty of reasons someone might make something out of most of the other materials.. perhaps an ancient civilization had access to only copper. Heck.. in real life, kings used to make armour out of gold. I mean, how stupid is that, protectively speaking? Another interesting example, is balsa. I created balsa as a "cursed" wood, like lead. The effect on objects is pretty debilitating. However, I noticed that balsa arrows, while extremely weak, could be carried by the millions because they weigh practially nothing. I actually seek them out now. > Also, I don't know if there is in fact any code that actually makes use of > this new material stuff (alchemy/skill stuff), and thus as a player, you care > even less about what material an item may be made out o Each material has special characteristics that make it better or worse than others of the same type. It would be trivial to make silver weapons do extra damage to undead or something like that as well. And if the work is ever done to make the arches for the item creation stuff.. a whole world of uses will pop up. (all that needs be done for item creation to work is add a destructor routine, to basically break an item down into it's raw materials for a fee, and arches/images for the various tools, tables etc. Mostly it's the arches that kept me from ever turning it on.) As for diamonds.. that problem has allways existed. It was just never obvious why it happened before. The same happens with holy symbols, and allways has. The ones you buy in a store don't stack with found ones. > It'd also be useful to see how the material stuff is expected to play out > with the alchemy related code.. Why do we care that the arrow is pine vs oak > for example? For the arrow, you might not care as much.. sans perhaps the balsa example above. But lets take a look at the bow. The yew bow is *way* better than the pine bow. If you were really interested in finding the best bow, you would hunt and seek one made of yew, or one of the other special woods. Just like finding a mithril sword is a blessing. If you want less variety, and want to make the various materials more special.. it's easy enough to tune down the random chance in the materials file. If you do that, most items will be made of a certain type, say lead, or pine. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Apr 13 07:22:13 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:56 2005 Subject: [CF-Devel] Fw: Diamonds References: <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> <3E98B105.1070301@sympatico.ca> Message-ID: <3E995675.CABC9629@gmx.at> Todd wrote: > > kind of thing would be better to manage in the arches no? Make an arch > for gold chainmail rather than add a random material type to the > chainmail arch. IIRC my father found an otherwise simple sword made of platinum. It weighed about 12 kg and had a value if it were made of iron. Making a sword of platinum is complete nonsense for it has inferior strength than iron and a density higher than gold (21.4 g/cm3). Bernhard -- Low end Serverhousing ab 25 e inkl. 1x 11 e/GB, etc.: http://bksys.at _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 8 19:40:44 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:57 2005 Subject: [CF-Devel] lore Message-ID: <3E936C0C.2000204@sympatico.ca> Ok I want to run this up the flagpole - a proposal for the lore field. The lore - endlore bit is in place now and I was playing with entering in some stuff and fell into the following routine: lore The wolf is a common animal found in forests throughout the land. Wolves are likely to flee if injured. The wolf has a keen sense of smell and excellent hearing. endlore lore The behemoth is a very large creature, but quite quick. The behemouth can be identified by their size and long, black, hairy, poision-dripping hides. Behemoths are very poisionous. Behemoths have a slight resistance to magic. Behemoths are immune to fear based attacks. endlore lore Banshee are the undead spirits of elven maidens who have been murdered. It is hard to say which is more dangerous, banshee cries or banshee claws. The scream of the banshee can scare you stiff. The touch of a banshee can paralyze. The Banshee sees only the face of her murderer, but her other senses are very sharp. Banshee are very resistant to both magic and physical harm.s often endlore You can see the idea here I think. Enter a series of short informative statements increasing in value. On the other end when using this info to generate books or put words in peoples' mouths, you can harvest this information in a way that weights the lines. Why bother? Well it would make the information more interesting - rather than having a paragraph spit out about something every time - you get different stuff in a semi random way - you get common lore and more rare lore. Also it is easy to add in stuff one line at a time instead of writing a little exposition - so more people might do it. Also you can easily pepper in some hints for recipies or what ever by inserting some lines. I could easily add in a line for behemoth hide at the end of the list: Interestingly enough, the behemoth's oily hide can be used in making clothing that resists poision. I also like the idea that it keeps things in the arches rather than in a seperate file - which makes it easier to customize things. It would work for most arches - spells, items, monsters... I also like the idea of doing this for maps too. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 9 05:52:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:57 2005 Subject: [CF-Devel] crossfire-devel post from beprox@mail.net4b.pt requires approval Message-ID: <20030409105201.22283.7096.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-devel@lists.real-time.com From: beprox@mail.net4b.pt Subject: IMAGEM DIGITAL BEPROX Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-devel to approve or deny the request. From crossfire-devel-admin at archives.real-time.com Thu Apr 10 08:53:48 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:57 2005 Subject: [CF-Devel] food beep frequency, etc Message-ID: <3E95776C.3A8F1F35@gmx.at> Hi! I whish the food beep frequency(/duration) were configureable so I could better distinguish it from my irc clients beeps or my father's crossfire beeps in the same room. Food threshold and how many food's per beep would be nice to configure, too. It would also be cool if I could set what food will be grabbed blindly or set my character to automatically eat some food at a configurable level, maybe even whenever there is enough room in his stomach to fit another piece in. If only that doesn't make the game boring. Bernhard -- Low end Serverhousing ab 25 e inkl. 1x 11 e/GB, etc.: http://bksys.at _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 15 00:01:57 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:57 2005 Subject: [CF-Devel] food beep frequency, etc In-Reply-To: <3E95776C.3A8F1F35@gmx.at> References: <3E95776C.3A8F1F35@gmx.at> Message-ID: <3E9B9245.7090107@sonic.net> Bernhard Kuemel wrote: > Hi! > > I whish the food beep frequency(/duration) were configureable so I > could better distinguish it from my irc clients beeps or my father's > crossfire beeps in the same room. Food threshold and how many food's > per beep would be nice to configure, too. Code is there for people to work on. (this basically means, I don't plan to make any such improvement). However, the one addiiton that may be worth making is that instead of making a beep, play an actual sound. This would make it easier to distinguish (presumably). > > It would also be cool if I could set what food will be grabbed blindly > or set my character to automatically eat some food at a configurable > level, maybe even whenever there is enough room in his stomach to fit > another piece in. If only that doesn't make the game boring. This is a very low priority item. IMO, if your blindly grabbing for a bite to food, it should perhaps be even more random than it is now. Perhaps I'm biased because I almost never have a case where food is blindly grabbed. Perhaps the one adjustment I would make is not cause extra food to be consumed when an hp/sp/grace is regained. I can sort of understand the logic (extra energy being expended, therefor extra food). OTOH, this also means you need to worry about managing food in a time where you really don't have the time to spend this. And if you wanted to be more realistic, just travelling should use more food than standing still for example. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 9 17:00:01 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:58 2005 Subject: [CF-Devel] 1 crossfire-devel admin request(s) waiting Message-ID: <20030409220001.15283.53576.Mailman@pirate.real-time.com> The crossfire-devel@lists.real-time.com mailing list has 1 request(s) waiting for your consideration at: https://mailman.real-time.com/mailman/admindb/crossfire-devel Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: beprox@mail.net4b.pt on Wed Apr 9 05:52:01 2003 Cause: Post by non-member to a members-only list From crossfire-devel-admin at archives.real-time.com Mon Apr 14 23:47:16 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:59 2005 Subject: [CF-Devel] Fw: Diamonds In-Reply-To: References: Message-ID: <3E9B8ED4.2070801@sonic.net> It could be argued that -5 plate armor is armor that was very poorly made or has been damaged. Having that cursed flag is a little odd. There is no doubt that there are examples that make sense. But there are probably just as many, or more cases, where the different material makes little/no difference. Your example for arrows is a good one - balsa ones are useful because they don't weight much. But how much should I care if the arrow is oak, pine, yew, spruce, etc? There are minor difference there, but more likely, having half a dozen of different types of arrows listed in your inventory/quiver is perhaps annoying. The issue of the material name being in the inventory is also just a point of annoyance. There has always been the point of trying to get as much useful information in your inventory window as possible. Including a material name you may not care about sort of defeats that goal. Perhaps one way to make this better is to do something like put (material) at the end of the name, and not at the start. Thus, instead of '15 spruce arrows' you would get '15 arrows (spruce)'. This way, the information you care about is at the start of the line. As for selecting material types, there are ways to do it. Something better than the existing method is certainly needed in IMO. The material selection for armor might very well be different than that for weapons, which could then be different than that chosen for something else. As it is now, there is one case where items don't get randomized types where they would cause the least annoyance - rings. Rings, as is, tend not to stack, so to note if the ring is silver, gold, bronze, or whatever isn't likely to cause any extra annoyance. Now the material type wouldn't make any difference for the rings (except maybe value) As I've said before, using the artifacts file to choose material types would have been ideal - that already has support to do match on very specific items (not just 'weapons' or 'armor). One could specify exactly what the material does for that item. Eg, a steel sword may have a bonus to hit and damage. But a steel mace (vs iron) really doesn't have any advantage. I also don't like the material file in that order that the materials is listed in is relevant. So the meaning of the chance field becomes non intuitive - a 'chance 10' if at the end of the materials is pretty much a 10% chance. But if you put that at the start, the chance of that material is now less than 10% - perhaps much less than 10% depending on the chance of the material that follow it. As an aside, the addition of material types adds more to item power inflation. Eg, that snakeskin armor has 1 point AC more than I could have gotten before. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Apr 7 05:20:23 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:59 2005 Subject: [CF-Devel] skill doc. References: <3E8E88C6.9000502@sonic.net> Message-ID: <31430.1049710823@www29.gmx.net> Mark Wedel wrote: > > Started working on the new skill system. I decided to update > the documentation first to get an idea of where to go to/what > to write. I figured I might as well put it out to the list and > see any comments or other notes people might have. > [...] Just wanted to say that I very much like this new skill system, as you described it in the doc. I'm sure it will need some time till it is fully implemented, used and everything. But I have no doubt that this is going to bring a richer gameplay and add to the long-term fun in Crossfire. AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 15 17:11:06 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:59 2005 Subject: [CF-Devel] Fw: Diamonds References: <20030412204809.0b5bfabe.kstenger@montevideo.com.uy> <3E9A620E.8060700@sonic.net> <001501c30197$248fd000$0802a8c0@ott.ca.dmr> Message-ID: <003d01c3039b$ea7ed260$0802a8c0@ott.ca.dmr> Ok, colour me stupid for not fully reading up on the all the relevant material stuff including the changelog earlier. Apparently adding in a materialname in an arch will manually set the material type, otherwise the material is randomly selected from the bitmask material value so there is a type of class/subclass going on here. So I apologize to Tim for yapping off before fully reading all the source code, especially when much of the stuff I was complaining should be done, he already did. I still want to make it clear, I had no problems per se with idea here (that was clear no?), in fact you could say I am for it, but some of the implementation was not making sense to me. I didn't like having a bit value for item material and then having a materialname being added to the item when it was created, but that was a knee jerk reaction. I also didn't realize how many modifiers there were to the material types, assuming incorrectly that much of it was just name play. SO I AM SORRY (I'm grovelling here Tim). I do wish there had been more talk about this implementation however. (maybe there was but the mailing list has been out for a while now and it's hard to follow a thread when you have three or four workstations...) Also one paragraph in the /doc/Developers/objects file would have straightened me right out. I still think that there is room to smooth things out however. This is only part of a material system. I am still not clear on how material should be applied to items which are not weapons or armor. Also now there is a more generic way to generate items in a range now. You now essentially have all the backend requirements to have some much more generic arches if there was a good way to specify a range of materials in the arch: a cloth shirt (silk, cotton...), a 'hide' shirt (the various leathers, snake skin...), a chain shirt (brass to iron to mithril or magical metals) brestplate(again brass to mithril to magic metals) - and it would make sense to reflect this in map making technique and arch development. A map maker would now drop a chain shirt and set the material to 'mithril' if they wanted to place a mithril shirt as an item, or leave it as is for a random type. A coin arch (or a nugget arch) could have a range silver -- platiumn, a gem arch... you get the idea . There is a TODO about implementing object type -> subtype in the arches, this is something along this line. The material code goes halfway towards this, I suggest that perhaps it should be examined closer. This is what I was speaking of when I said it would be a pain to implement since material type could really change the arches (in a positive way I think)but would require some clean up afterwards. I still think that there is some problems with the way this was implemented since it does add another layer of confustion to people whom primarily work within the archetypes and maps and not in the source code - and there is too much of this as it is already. I suppose that this is a designer vs coder type issue however. That being said - I still think it is a bit clunky and would like to see an all in one solution to the material system. Having a material field and a materialname field in an arch is not nice and having to manage a bitvalue and a material name is not nice. For the sake of designers, how hard would it be to go the extra step and ditch the bitmask and have a material type by name where if 'metal' (parent object) is specified a type of metal will be selected, but where if 'iron' (specific material object) is specified the object will be iron. I also would prefer item properties to be managed in arches instead of a list for the sake of consistancy and portability and since having an arch for each material would be useful for item deconstruction anyway. Also this all works well for single material items, but what about items with multiple materials? Also the 'magical' materials is a bit strange and how does it relate to item enchantment (I'm guessing it doesn't so is there a point to it?) I still don't like having the material name in front of a lot of these objects but admit it is more a client space issue than anything else really. I still like the DX client where the item icons were shown and the name shown only when the item was highlighted. I can see better why the material is important however when I consider items like leather armor or silver coin or gold nugget however. Depending on the object and the material importance and general English language foolery however it is hard to say I want it here and not there. I did like Mark's suggestion to have Arrow (pine) or brestplate (admantium), but can see that not being nice if the system was expanded - coin (gold) is a crapy thing to see and I would hate to have 'Plate mail (dr' as much as I don't like 'Snake skin c'. Now it is interesting to hear the mention of deconstructing objects. This was my primary reason for bringing this up in the first place - a consistant material system would allow item creation and destruction with relative ease and with a bit of predicatbility, it would also make simpler such stuff as mining and logging and tanning. This is the main reason I thought that having material objects in the arches would be better than a list (aside from the fact that you wouldn't need to change the server code to add a new material, and this is the way other stuff is handled). It would also simplify mixing skills with materials (tanning, smithing, boyer...) if there were a more consistant (and I think object based) material system. Well - this has gone way beyond where I started. Now were talking about whether rings should have a material type and how things should stack and probably we'll get into identification issues next, then whether it is better to store information in arches or in lists and if magical items require magical materials... _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Thu Apr 3 15:03:50 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:59 2005 Subject: [CF-Devel] win32 gtk client Message-ID: <007501c2fa24$87cf9490$0201a8c0@cavancentral.net> Over the past couple of weeks, I have been working with Somebody's win32 source ( http://www.theperlguru.com/crossfire/gcfclient-src.zip ) and have a fairly stable client that supports: gtk, sdl, client-images and sound. binary: http://www.gazellevillage.com/download/gcfclient/gcfclient-install.exe source: http://www.gazellevillage.com/download/gcfclient/win32-crossfire-client-1.5. 0-src.zip In order to compile the source, you will need glib 2.2.1, gtk+ 2.2.1 and the other dependencies thereof ( atk, pango, etc ), sdl, sdl-image, sdl-mixer. I did all my compiling using Visual Studio, so I don't really have a make file. Sorry. :( There is a persistent bug that I am trying to figure out, mebbe you guys could help. When using the "download all information" config option, the client runs out of memory after downloading about 3500 or so images on my win2k dev machine. Somebody had informed me that his experience on his win9x box was around 200 or so images. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Apr 20 02:05:49 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:53:59 2005 Subject: [CF-Devel] more skill/spell musings Message-ID: <3EA246CD.101@sonic.net> Started coding the skill revamp. One of the ideas in that was to split the wizardry spells into a few skills. Reasons for doing so: 1) Wizardry is probably one of the best skills right now, as shown by polls. 2) As more and more spells are added, wizards get more an more powerful (more tools to kill monsters with). People tend to notice when new weapon artifacts are added that are over powering. But new spells with a different attacktype (or better more effecitve use of one that already exists) probably are less noticed. 3) different skills would mean a bit more difference in classes. That summoner will look different than the evoker for example. 4) Even if you don't really like this idea, it is much easier to merge such a split (via sed or the like) back into a skill than the reverse One can look at the archives on past discussions. The main point to remember is that in any split, one must be able to gain exp in the skill (at first level). So split just by spell path often won't work. Looking for inspiration, I looked at the starting wizardry spell classes (warlock, evoker, summoner, wizard, sorcerer, devotee, alchemist). Most of them are non specific about what spells they use. Note one thought I had is that given the split in skills, we can perhaps give exp for successful use of spells which we didn't before. Eg, if you paralyze a creature, you'd get some exp for that for example. Sure, this could be open to some abuses, but there are already otehr abuses out there (maps you go in and fire 20 fireballs or whatever). Other thought on this is when something is killed, we could look in the inventory for certain spell effects that made killing it easier, and give some exp to the owner of the spell effect (eg, if a paralyzed monster is killed, whoever cast the paralyzed should get some credit. Likewise, for slow, beserk, etc). Even things like identify or detect spells could get a little exp based on what they find (just as sense curse/magic do now) all that said, I see the following 'schools' of magic as a first pass: summoner - matches the class. This gets the summon spells, as well as most of the item creation spells (build xxx wall, create ..) Given directors are a very popular tactic, this category could be useful just for that. evoker - covers a wide range of damage spells. Since this is most useful, it gets split with: pyromaniac: Gets fire/lightning spells, as well as bomb. That leaves evoker with cold/acid/poison/bullet. Evoker could also get some of the pyro spells perhaps. discover: The alchemist class falls into this. Gets alchemy spell. Gets spells that let them find information out (identify). Gets spells that help survival, so that it can learn (study) things, eg, some number of protection spells. Also toss in things that perhaps change behaviour (slow, haste, paralyze). Toss in spells to help get away (dimension door). In a sense, this sort of gets the leftover that dont' fall into the ones above. As a note, the idea is that most of the spells would belong to only one school. However, some spells could certainly belong to more than one school. For example, detect magic is probably a fundamental ability that everyone should know. The pyromaniac should probably get pro fire/electricity so they don't kill themselves, but the discover might also have those. Note one of my thoughts would be that we perhaps limit characters to knowing only 3 of the 4 schools above - thus, higher lever characters are likely to look a bit more different and/or players have to make some actual decisions. The unresolved issues on this: 1) For spells that belong to more than one school, what school/skill is used to cast it. My thoughts would be 1) school you are best in, 2) have all spells be unique, so detect magic for discovers would have a different name than the evoker uses, 3) Player can specify a search order to use (eg, spell_search evoker pyro summoner) 4) use currently active skill, then a fallback of either 1 or 3 2) Starting skill for classes. It would be pretty clear that the summoner starts with that school, and same for alchemist (discover) and evoker. However, some of the other classes are less clear cut. One could certainly make a pyromaniac class to get that skill. But the devotee, which is sort of a cleric/wizard crossbread is more difficult - should it get pyro, or something else? This can obviously get 'fixed' by a more ala cart class system. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Apr 20 13:10:18 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:00 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <3EA0FB34.50200@sonic.net> References: <13861.1050656159@www23.gmx.net> <3EA050BD.8060500@sympatico.ca> <3EA0FB34.50200@sonic.net> Message-ID: <3EA2E28A.7070702@sympatico.ca> If this disjointed, well I wrote this in tiny bursts between diaper changes and yardwork. You were warned. > Well, my original thought was that 'materialname' should just be an > arbitrary string, and it would look at the material bitmask when it > comes to saving throws. ... I The material bitmask would be used for > saving throws - the map maker itself could adjust other values > accordingly (weight, value, saving throws, etc). That would bring me back to my original argument that it is not worth the effort to have these new materials then. > > That said, having detailed saving throws in the materials table for > different materials isn't bad. But it does mean that a map maker just > can't add a new material and have it work. Well if the materials were arch objects they could - but that is probably not too important anyway. You need server access for abilities, inventory, and other such things anyway. Plus if everyone with the map editor was adding materials it could get silly. > > Also, setting the 'materialname' for an object in the editor is not > going to do what you want it to do. When an object is first created, > it is assigned a materialname at that point, and the bonuses are done > then. If the object already has a materialname set, none of this > happens when it is loaded (there is no way to know if the bonuses have > already been taken into account). > > So if you make a sword, and give it 'materialname gold', it will be > the same as if the materialname was iron in terms of weight, value, > damage, etc. Really? This isn't how I presumed it worked. That won't do. When the object is created it should either apply the material or if the material isn't specific then assign a material from the generic material class. > Also, one thing I _still_ have not heard an explanation for is how it > is expected material types play into item creation. > > Is it just a matter that if I have a 'yew club', I could then make a > 'yew bow' from it? If I have a mithril chain, I can then make a > mithril shield, etc? Or something more? I think it is more a matter of material and weight having a relationship. If you break down a item weighing 1 kg you get 1 kg of that material, or if an item requires 1kg of a material to be created then ... I was assuming that if a 'recipe' required 3kg of gold you would need to have the equilivant weight in items made of gold (a couple gold goblets, some coins and a large nugget...) You could also possibly melt down or otherwise merge some materials together (like a bunch of silver nuggets into one ingot...) Of course some stuff isn't as workable, wood or bone or organics likely can't be reconstituted, only reduced. That bears some thinking. Also presumably you could have transmutation (ala the midas touch) where by spell or procedure you could convert an item from say lead to gold. Since it would be a nightmare to manage these type of things with the existing materials system (you'd need arches and code for everything)- I was projecting that the expanded system would (should?) make these things more palatable. Maybe other interesting things like spells that disolved certain materials (like wood or metal or gold) or caused metal items to get real hot or cold doing damage based on weight. > > As for 'granite' diamonds - in some sense, the fact that the material > name is now more specific means it is now wrong. If for example I > point over yonder and say 'that is a tree', I can be correct in that > statement whether it is an oak tree, redwood, pine, etc. If, however, > I point yonder and say 'that is a pine tree' when it is in fact an > oak, I am wrong in my statement. And that is similar with diamonds. > If you call them 'stone', it may not be very desriptive, but is > accurate. If you say they are 'granite', it is more specific, but > incorrect. Ya, but that is more of a general objection than I had. I was being much more literal. In fact diamond is a more desirable addition than granite is. Diamond has some game value while granite is just a hard stone (might as well be marble or even limestone for game play purposes.) Why would you substitute granite or make a crystal material class - diamonds are rocks, rubys are rocks. I have heard of (in games of course) a diamond throne, a diamond shield, diamond sword, ruby slippers... If you have a material system like this it is silly not to make basics like diamonds, rubies, emeralds... into materials. Even if some of them have similar saves, the values are different. You might think this screws with diamond as a monetary object, but you get instead a bit of gem variety (big diamond goblets, small ruby cufflinks, jewels of all sizes.) The 'diamond arch' is still there and stuff like inventory checkers shouldn't be impacted by this. > > However, I think rather than saying what is wrong with the current > system, it would probably be more useful to say what the ideal system > is. Here is my short list: > > 1) Ability to control what materials show up in a more specific > fashion (eg, only these weapons will show up as silver, and not every > weapon - basically artifact file level specificness) I don't get the artifact thing I think - that is how I though that Tim had implemented the materials (with lists of what items could be generated out of which materials) and I didn't particularily like the idea and thought it very unmanagable and somewhat backwards. That is primarily why I objected in the first place. If I add a Widgit arch, I would have to add it to the artifacts file. If I remove the Widgit, I have to remember to update the file. The way Tim actually did it (where you state the material in the arch) is more managable in my mind. I am not qualified to make these distinctions on the existing system however since I don't know the source code nearly as well as some of you folk. But if you want to give precise control without having a multitude of arches, you have a list of materials and you allow the map maker to put an arch on the map and set the material. Now you can either have parent materials from which their children inherit certain defaults, or just have something like race and material lists where there are groups of materials. You can even have a mix where there are types of materials and then other lists used to apply materials (like the treasures prehaps). So long as you have a fellow with the map editor able to say 'I'd like to put down a ruby headed axe right about here (ruby, wood) and chain mail shirt here (random metal) and a pair of dog-skin boots +1 here ' without having to edit any lists or files on the server and without having to memorize a 14 page instruction manual to figure out the codes (only a 7 page manual) - you've done alright. You have to trust that they will not choose unbalanced items or flood the market with super diamond shields (or let them and then you ditch their maps). > > 2) Some way to set a material in the map editor, and have the right > thing done when it is loaded by the server (eg, to actually apply the > various adjustments and so forth). Easiest way to do this is probably > to set a flag like 'FLAG_MATERIAL_ADJUSTED' - the editor would have it > unset, but whenever the server loads an object, it checks for that > flag - if it isn't set, it adjusts the item based on the material > set. If it is set, it doesn't do anything more. This allows map > maker to set the material of an object in the editor and have the > right thing happen. Wouldn't it be better if the default behaviour should be that when the server loads an object it applies the material set. There is a 'no material' option for items where you don't want material modifiers applied. This way when your mage casts iron to gold (or the monster casts gold to lead), when the iron item is destroyed and a gold item created it will have all the properties of gold (hopefully it will be too heavy for the greedy bugger to drag to the store...) > > 3) Removal of the material bitmask field - it is no longer needed with > the materialname field. Add special material keywords, eg, > random_paper, random_cloth. Alternative/better, allow a list of > materials 'material iron|mithril|bronze' - this sort of addresses > point #1 above. I would say thet there isn't a need for the special key words since if you enter a class of material (currently the bitmask, but hopefully an general name like stone, soft_metal, hide) it will assign a specific material based on chance. If you enter a specific material it will use that instead. I can see having the chance of assigning a material other than the 'normal' material be pretty low so if the item is 'metal' 75%-80% of the time it is iron anyway. The point is not material randomness but the ability to set the material - the randomness is a perk however as if saves you from having to 'naturalize' (like in 'naturalizing' bulbs so they come up looking like they grew at random) object composition when making maps. > > 4) From todd - name suffix for object names. Eg, yellow/gold objects > could have the suffix be 'gold'. This, if there is an image > 'chainmail.111.gold', and the current name is just 'chainmail.111', it > can update what it looks like. This could similarly be used for > animations. Eg, if for example you want to have wands made of > different materials, it could look for an animation 'wand_gold' if the > normal animation is jsut wand. The idea of having a colour and changing the image based on this colour comes form some old discussion of how this is done in other games. The client would actually modify the png to change the colour like in say Diablo where you have red skin beasties, green skin beasties, yellow skin beasties - all from the same graphic by fiddling the value for a colour or colours in the index (or at least that's how I understand it works). I wouldn't think it worthwhile to have an object suffix like chainmail.111.gold since i can do that now simply by making 'chainmail_g.111' and the problem still is you have to come up with a graphic for every combination. An intersting offshoot of colour fiddling this way for the materials is you can use it for lots of other stuff in the game (...like red skin beasties, green skin beasties, yellow skin beasties or having trees change colour in the fall, or doing cycling animation (like rain or snow) - all from the same graphic) That said - I have no idea if it is simple to do, it it is going to impact client performance (not using hardware for this) and if there would be a lot to do to fix up the existing images to make it work(there are currently some are 4 bit index, some 8 bit, some RGB images in there and all have different index numbers for transparencies...) That's why it was more a wishlist thing. > > 5) Some better way to display the materialname in inventory. This may > simply be moving the material to the end of the list. Eg, instead of > 'spruce longbow', it could be 'longbow, spruce'. Thus, if you have a > 'Bow of auriga +3' that is made of pine, it would be 'bow of auriga > +3, pine'. In this way, the details you are more likely to care abou > are presented first, and the material is presented later. The thing about this is I imagined almost every pickable object would have a material, so having the material name would get pretty unpleasant no matter where you put it. Having 'sword, steel', or 'steel sword' isn't real useful. It would be nice to have some way to do this without a whole pile of exceptions and such. Say if the item has a specific material (silver) then the name could be left alone since it can be assumed the map maker can work the name, and if the item has a material class (metal) and if the material is common (like steel or iron) then it won't get a name, but if it is more rare (silver) it would get a name. If you can follow that logic, I have a bridge you might like to purchase... > 6) this more a minor point, but I'd like the materials file to be more > humanly readable/easier to parse. Eg, instead of: > > saves 15,10,17,9,5,7,13,0,20,15,0,0,0,0,0,10,0,0,0,0,0,0,0,0,0 > > it would be something like > save_physical 15 > save_fire 10 > > (or whatever). Same for the 'mods' string. All values should > default to zero, so you only need to list values that actually are > differently. ya good idea. Even if they aren't in the archs, the materials should look like archs. other thoughts: Items with Multiple Materials- well items with multiple materials. how about allowing an item to have multiple items in equal proportions. So an item like a normal axe is say wood, metal (50-50) a stone axe wood, stone (50-50) a more complex item might be metal, wood, stone (33-33-33). If the materials are not of equal proportion (by weight I suppose) then they aren't factored in is all. Toughness would be the same as it works now (how does it work now with the saving throws?) with bitmask items or perhaps when you fireball or otherwise deconstruct that ruby axe you burn away the 50% weight (the wood) and get a ruby. What does not have material type- Well I don't want walls or buildings or other such landscape features to have material in general, nor forests or mountains or swamps (I can see having special tree or mountain arches that would, like a mine arch, also there is code already for random plant placement so mineral placement is simply a few lines to this.) This is along the lines of secret passages - Players shouldn't be expected to try every terrain square to see if it breaks burns or gives milk. Monsters or other living things should not have material types. Item checking - you could check materials, you could check materials by weight. Item stacking - Hey how about a universal system of weights and measures....hehehe _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Apr 20 16:39:14 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:00 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <3EA2E28A.7070702@sympatico.ca> References: <13861.1050656159@www23.gmx.net> <3EA050BD.8060500@sympatico.ca> <3EA0FB34.50200@sonic.net> <3EA2E28A.7070702@sympatico.ca> Message-ID: <3EA31382.4030808@sonic.net> Todd wrote: >> That said, having detailed saving throws in the materials table for >> different materials isn't bad. But it does mean that a map maker just >> can't add a new material and have it work. > > > Well if the materials were arch objects they could - but that is > probably not too important anyway. You need server access for > abilities, inventory, and other such things anyway. Plus if everyone > with the map editor was adding materials it could get silly. I imagine by having the materials be arch objects, the idea would be to have a 'silver sword', the object would be a sword, with the archetype 'silver' in its inventory? Or do you just mean convert the material file to archetypes (which wouldn't be hard), and have a special material type to denote this (sort of like skills are now). Thus, instead of having yet another file format, you could just have a 'materials' directory in the arch to customize/add new materials. >> So if you make a sword, and give it 'materialname gold', it will be >> the same as if the materialname was iron in terms of weight, value, >> damage, etc. > > > Really? This isn't how I presumed it worked. That won't do. When the > object is created it should either apply the material or if the material > isn't specific then assign a material from the generic material class. If an object has a generic material, then when it is loaded (created), the various adjustments happen. Thus, as the code stands now, if you don't set the materialname, a random material is chosen, and adjustments are made. However, if you set the materialname, the loader presumes that the adjustments have already been made, and thus does nothing. There is no simple solution to this other than adding a flag or the like saying that it has been adjusted. The reason being, if I make a sword with materialname gold, when it gets loaded, how would the program know this is the first time it has been loaded (and should thus get adjusted) vs it having already been adjusted? That is why setting the materialname in the editor won't do what you want - when the server goes to reload it later, it has no way of knowing that the object has or has not already been adjusted, so presumes it has been adjusted, and thus does nothing. > I think it is more a matter of material and weight having a > relationship. If you break down a item weighing 1 kg you get 1 kg of > that material, or if an item requires 1kg of a material to be created > then ... I was assuming that if a 'recipe' required 3kg of gold you > would need to have the equilivant weight in items made of gold (a couple > gold goblets, some coins and a large nugget...) > You could also possibly melt down or otherwise merge some materials > together (like a bunch of silver nuggets into one ingot...) Of course > some stuff isn't as workable, wood or bone or organics likely can't be > reconstituted, only reduced. That bears some thinking. Ok. That makes some more sense. The wood/non metal materials do pose some issues. OTOH, it also depends on how the creation is working - if magic is involved, not too hard to believe that you could turn 20 arrows into a spear or whatever. However, if your just working at a workbench, that isn't feasible - in that case, you'd have to determine if the donor item exceeds the material requirements for a new item (eg, a spear could be turned into some number of arrows, but not vice versa). But to do this, you'd need some tag in the material that says this is a material that can be reconstituted or not. > > Also presumably you could have transmutation (ala the midas touch) where > by spell or procedure you could convert an item from say lead to gold. > Since it would be a nightmare to manage these type of things with the > existing materials system (you'd need arches and code for everything)- I > was projecting that the expanded system would (should?) make these > things more palatable. And as coded now, this wouldn't be that hard. You'd basically find the material the item is currently made of, undo its benefits (cost/weight/protections/etc) and then apply the benefits/penalties of the new material. Problem more with this is balance. If you have a x-> gold translation, how do you do it? If the item weighs 9 kg, you get a 9 kg gold item (ignoring density)? Or more properly, would that 9 kg turn into 15 kg or whatever the weight adjustement for gold is? The problem here is then in a full material system, player turns that non magical plate armor to gold - 100 kg of gold now. With his skill, he then turns it into gold ingots (or coins) and gets a lot more money for that item than it is normally worth. Talk about messed up economics. > > Maybe other interesting things like spells that disolved certain > materials (like wood or metal or gold) or caused metal items to get real > hot or cold doing damage based on weight. One could certainly do something like that - to follow AD&D, warp wood - checks inventory of target, and warps some number of wood objects, making them unusuable. However, for this to really work, you then need to have some method of saying these are warped. Things like heat/cool metal are a lot trickier to track. > If you have a material system like this it is silly not to make basics > like diamonds, rubies, emeralds... into materials. Even if some of them > have similar saves, the values are different. You might think this > screws with diamond as a monetary object, but you get instead a bit of > gem variety (big diamond goblets, small ruby cufflinks, jewels of all > sizes.) The 'diamond arch' is still there and stuff like inventory > checkers shouldn't be impacted by this. I basically agree - there is no reason not to enumerate all the obvious material types. If you don't want to have material for ruby, diamond, emerald, pearl, etc, at least a more general 'gemstone' or 'crystal' category could be workable. > I don't get the artifact thing I think - that is how I though that Tim > had implemented the materials (with lists of what items could be > generated out of which materials) and I didn't particularily like the > idea and thought it very unmanagable and somewhat backwards. That is > primarily why I objected in the first place. If I add a Widgit arch, I > would have to add it to the artifacts file. If I remove the Widgit, I > have to remember to update the file. There is no harm listing artifact combinations in the file that can't possibly exist. For example, right now, I could add an entry to make special two handed swords. However, no two handed swords currently exist - the end result is that special entry would just never get used. It wouldn't cause any harm - it would just be like any number of archetypes that may not get used. As for additions, that may be true. However, there may be some number of more general rules. EG, you may still have a general matching for all weapons to have them made out a mithril. But only some smaller set of weapons might get made of silver for example. If you want your new item to go into that category, you'd need to update the artifacts file. OTOH, that isn't really new - if you say create a 'knife' archetype, presumably you'd want random artifacts for the same thing that can show up on daggers. There is already a bunch of artifacts listed as 'dagger', so you'd need to update the file anyways. And if you don't, all that really happens is that your object won't appear with these new special abilities/materials. Your item will still continue to work. > You can even have a mix where there are types of materials > and then other lists used to apply materials (like the treasures > prehaps). To be, that is completely the point of the artifacts file - a way to modify objects without needing to make new arches. In addition, usage of artifact files allows for more sensible material bonuses. For example, I can see that a yew bow might be suprerior, and hence why it has a damage bonus. But why would a yew club be any better? Given the current code, there is no way to seperate that (yew has bonuses which apply to whatever object type it gets applied to). However, with artifact code, I could do something like: Allow bow,crossbow materialname yew dam 2 value ... and so on And only have yew show up in bows and crossbows. If I want it to show up in clubs, I could make an appropriate entry, but not give it a 'dam 2' value. But given the current implementation, there is no way to do that, and I consider that wrong. > > > > Wouldn't it be better if the default behaviour should be that when the > server loads an object it applies the material set. There is a 'no > material' option for items where you don't want material modifiers > applied. This way when your mage casts iron to gold (or the monster > casts gold to lead), when the iron item is destroyed and a gold item > created it will have all the properties of gold (hopefully it will be > too heavy for the greedy bugger to drag to the store...) See note above - you need some way to know that this is the first time the server has seen that item, and thus is the time to apply the material benefits/penalties to the item. If you don't set the material, or ste it so that the server will randomly determine material, this works fine. But once the material has been set, you need some way for the server to know that it has set the material and applied material bonus, and don't do so again, vs the case where the mapmaker has set the material, and the bonuses haven't been applied. > >> >> 3) Removal of the material bitmask field - it is no longer needed with >> the materialname field. Add special material keywords, eg, >> random_paper, random_cloth. Alternative/better, allow a list of >> materials 'material iron|mithril|bronze' - this sort of addresses >> point #1 above. > > > I would say thet there isn't a need for the special key words since if > you enter a class of material (currently the bitmask, but hopefully an > general name like stone, soft_metal, hide) it will assign a specific > material based on chance. If you enter a specific material it will use > that instead. I can see having the chance of assigning a material other > than the 'normal' material be pretty low so if the item is 'metal' > 75%-80% of the time it is iron anyway. The point is not material > randomness but the ability to set the material - the randomness is a > perk however as if saves you from having to 'naturalize' (like in > 'naturalizing' bulbs so they come up looking like they grew at random) > object composition when making maps. I disagree a bit here. I think the general material terms should be the general material. EG, materialname stone could be valid if you want the item made of general non descript stone (ie, basically, always that general stone, and not a specific type of stone). There should be some way to say that is always the case. If you want a random material, I'd much rather that be noted in the name. You mention about difficulty of knowing what to do. IMO, it is much clearer from a design standpoint that if you see 'materialname random_stone', that you know it would choose a random stone type, comared to if you just say 'materialname stone'. Also, having a general name that may be valid that also matches and end product is a really bad idea. If you load a map and see 'materialname stone', how do you then know if that has already been processed, or if it will be randomized that next time by? Also, I see no disadvantage to having those special keywords - the only real disadvantage might be the extra 8 characters to type in the materialname. > The idea of having a colour and changing the image based on this colour > comes form some old discussion of how this is done in other games. The > client would actually modify the png to change the colour like in say > Diablo where you have red skin beasties, green skin beasties, yellow > skin beasties - all from the same graphic by fiddling the value for a > colour or colours in the index (or at least that's how I understand it > works). I wouldn't think it worthwhile to have an object suffix like > chainmail.111.gold since i can do that now simply by making > 'chainmail_g.111' and the problem still is you have to come up with a > graphic for every combination. > An intersting offshoot of colour fiddling this way for the materials is > you can use it for lots of other stuff in the game (...like red skin > beasties, green skin beasties, yellow skin beasties or having trees > change colour in the fall, or doing cycling animation (like rain or > snow) - all from the same graphic) > That said - I have no idea if it is simple to do, it it is going to > impact client performance (not using hardware for this) and if there > would be a lot to do to fix up the existing images to make it work(there > are currently some are 4 bit index, some 8 bit, some RGB images in there > and all have different index numbers for transparencies...) > That's why it was more a wishlist thing. this is a non trivial change. it is much eaiser to just have different images for the different colors. To do as described above, you'd need to have palletized images. So normal would be pallette 0, gold might be pallette 1, red pallette 2, etc. I have no idea how good the tools are for making such images. I also don't know if you can skip pallettes (you'd need to standardize accross all images that pallette 1 is gold, 2 is red, 3 is green, etc). If you don't want a gold, I don't know if you can skip that pallette. Transmitting what pallette to use to the client is the next issue. In terms of hte map, there is no easy way to tuck that information in (you now need to record in the object what palltte to use). Also, given how the unix client render images, it just won't work (it basically renders them once, using the default pallette). Using seperate images is much easier. The amount of code that needs to be changed is almost 0 (only to update the face when the object is created - everything else would work fine, becuase the server would use a different image number for that, and so the client would know to use a different image.). Copying the current image and recoloring it probably is going to be amount the same amount of work of making a pallettized image. Unique images also allow more flexibility - eg, you could have that gold chainmail have a sparkle or look slightly different than normal - doing that with pallettes if a bit more difficult I would thing. The only disadvantage to unique images is that you have more images, and thus more memory usage. There is no requirement that every combo would have to be done. As I said in my previous message, the material code would check to see if an image of the desired name exists - if not, it would just continue to use the default image. Only if that chainmail.111.gold exists would it change the face to use that image. > > The thing about this is I imagined almost every pickable object would > have a material, so having the material name would get pretty unpleasant > no matter where you put it. Having 'sword, steel', or 'steel sword' > isn't real useful. It would be nice to have some way to do this without > a whole pile of exceptions and such. Say if the item has a specific > material (silver) then the name could be left alone since it can be > assumed the map maker can work the name, and if the item has a material > class (metal) and if the material is common (like steel or iron) then it > won't get a name, but if it is more rare (silver) it would get a name. > If you can follow that logic, I have a bridge you might like to purchase... That might work. My only thought on this is you might see two sword entries, which are fully identified and appear mostly the same but don't merge. Maybe that isn't a big deal, or maybe it would be obvious why they don't merge (weight difference). So yea, noting in the material that this is a 'noteworthy' material and thus should get included in the name of the object, vs non noteworthy materials may work. > > Items with Multiple Materials- > well items with multiple materials. how about allowing an item to have > multiple items in equal proportions. So an item like a normal axe is > say wood, metal (50-50) a stone axe wood, stone (50-50) a more complex > item might be metal, wood, stone (33-33-33). If the materials are not > of equal proportion (by weight I suppose) then they aren't factored in > is all. Toughness would be the same as it works now (how does it work > now with the saving throws?) with bitmask items or perhaps when you > fireball or otherwise deconstruct that ruby axe you burn away the 50% > weight (the wood) and get a ruby. That works - presume if the material has multiple types, they are equal by weight. You could list multiple types even if not 100% equal, but close enough (eg, a 60/40 real life, you might still list it as two materials which would be 50/50, as its a close approximation). As for saves, probably be fairest way is to look at the material which has the worst saving throw for that object. Eg, if you have an iron/wood saving against fire, you'd use that wood saving throw. However, if you have that same object against acid, you'd use the iron. I'd try not to get too tricky on what happens when an object fails saves. That is another can of worms. > Well I don't want walls or buildings or other such landscape features to > have material in general, nor forests or mountains or swamps (I can see > having special tree or mountain arches that would, like a mine arch, > also there is code already for random plant placement so mineral > placement is simply a few lines to this.) This is along the lines of > secret passages - Players shouldn't be expected to try every terrain > square to see if it breaks burns or gives milk. > Monsters or other living things should not have material types. to an extent, I agree. However, if you allow random harvesting of materials, how do you do that? I should be able to go into a forest and chop down a tree and get wood, but what wood would I get? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Apr 20 18:48:40 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:00 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <3EA31382.4030808@sonic.net> References: <13861.1050656159@www23.gmx.net> <3EA050BD.8060500@sympatico.ca> <3EA0FB34.50200@sonic.net> <3EA2E28A.7070702@sympatico.ca> <3EA31382.4030808@sonic.net> Message-ID: <3EA331D8.6060904@sympatico.ca> > ... > Or do you just mean convert the material file to archetypes (which > wouldn't be hard), and have a special material type to denote this > (sort of like skills are now). Thus, instead of having yet another > file format, you could just have a 'materials' directory in the arch > to customize/add new materials. That was my thought, yes. Skills as archs, spell arches, ability arches, treasure lists arches (kind of like the random map styles are now...), material arches.... > ... > The wood/non metal materials do pose some issues. OTOH, it also > depends on how the creation is working - if magic is involved, not too > hard to believe that you could turn 20 arrows into a spear or > whatever. However, if your just working at a workbench, that isn't > feasible - in that case, you'd have to determine if the donor item > exceeds the material requirements for a new item (eg, a spear could be > turned into some number of arrows, but not vice versa). But to do > this, you'd need some tag in the material that says this is a material > that can be reconstituted or not. This is where I was imagining inheritance played a part. General class characteristics inherited by the specific materials so you don't need to configure every little setting (but you could...). Note imagine is the operative word since this was speculation on my part. > > Problem more with this is balance. If you have a x-> gold > translation, how do you do it? If the item weighs 9 kg, you get a 9 > kg gold item (ignoring density)? Or more properly, would that 9 kg > turn into 15 kg or whatever the weight adjustement for gold is? > > The problem here is then in a full material system, player turns that > non magical plate armor to gold - 100 kg of gold now. With his skill, > he then turns it into gold ingots (or coins) and gets a lot more money > for that item than it is normally worth. Talk about messed up economics. Ya, but you could also have monsters turning gold to lead or steel into tin. I knew steel to gold would be a provocative example, but it would work both ways. Plus you can make these things prohibitive - iron to gold abilities would be a heck of a lot less common than the steel to tin abilities. Remember the disenchanter beast? How about a little fellow that turns sangunite to lead? I know you can do this otherways but, it nice when it's as simple as twigging the material. > One could certainly do something like that - to follow AD&D, warp > wood - checks inventory of target, and warps some number of wood > objects, making them unusuable. However, for this to really work, you > then need to have some method of saying these are warped. Things like > heat/cool metal are a lot trickier to track. Not really you don't have to actually have heat or cold, just assign an amount of damage per measure of iron. Now you want to wear that plate armour when fighting fire elementals Pepe? >> I don't get the artifact thing I think - that is how I though that >> Tim had implemented the materials (with lists of what items could be >> generated out of which materials) and I didn't particularily like the >> idea and thought it very unmanagable and somewhat backwards. That is >> primarily why I objected in the first place. If I add a Widgit arch, >> I would have to add it to the artifacts file. If I remove the >> Widgit, I have to remember to update the file. > > > There is no harm listing artifact combinations in the file that can't > possibly exist. > And if you don't, all that really happens is that your object won't > appear with these new special abilities/materials. Your item will > still continue to work. no but it does get messy over time and you need to get into the server files to make maps. > >> You can even have a mix where there are types of materials and then >> other lists used to apply materials (like the treasures prehaps). > > To be, that is completely the point of the artifacts file - a way to > modify objects without needing to make new arches. > > In addition, usage of artifact files allows for more sensible > material bonuses. > > For example, I can see that a yew bow might be suprerior, and hence > why it has a damage bonus. But why would a yew club be any better? > Given the current code, there is no way to seperate that (yew has > bonuses which apply to whatever object type it gets applied to). That's interesting, material bonuses should be applicable for what ever object they constitute. I didn't think of an example like this. Either this type of bonus has to be taken out of the material code so it works universally or pseudo-logic can be applied to say that Yew is lighter but harder thus more the club weilder is more nimble, thus more damage (since damage can be seen as factoring in chance to hit as well as actual injury). > > However, with artifact code, I could do something like: > > Allow bow,crossbow > materialname yew > dam 2 > value ... > and so on > > And only have yew show up in bows and crossbows. If I want it to > show up in clubs, I could make an appropriate entry, but not give it a > 'dam 2' value. But given the current implementation, there is no way > to do that, and I consider that wrong. But if the artifact file randomly changes the items randomly after the map has been created (when somone enters it presumably) then you have no control over specific implementation. In this case if you wanted a ruby club particularly how would you do it without creating a new arch? Of course you could claw back some of those sort of bonuses from material type while leaving basic modifiers such as value, weight and saving throws. Really I haven't got an answer for this - there seems to be a particle/wave thing going on here. > >> I would say thet there isn't a need for the special key words[...] > > > I disagree a bit here. > > I think the general material terms should be the general material. > EG, materialname stone could be valid if you want the item made of > general non descript stone (ie, basically, always that general stone, > and not a specific type of stone). There should be some way to say > that is always the case. If you want a random material, I'd much > rather that be noted in the name. You mention about difficulty of > knowing what to do. IMO, it is much clearer from a design standpoint > that if you see 'materialname random_stone', that you know it would > choose a random stone type, comared to if you just say 'materialname > stone'. > > Also, having a general name that may be valid that also matches and > end product is a really bad idea. If you load a map and see > 'materialname stone', how do you then know if that has already been > processed, or if it will be randomized that next time by? > > Also, I see no disadvantage to having those special keywords - the > only real disadvantage might be the extra 8 characters to type in the > materialname. > See I would tend to never actually have a general material used in an object. This is why I suggested changing iron to metal and such. The material would always be specific. You could have an item with no material, but never an item of 'wood' (it would always resolve to be a type of wood) for example. >> The idea of having a colour and changing the image based on this >> colour comes form some old discussion of how this is done in other >> games. [...] >> That's why it was more a wishlist thing. > > > this is a non trivial change. it is much eaiser to just have > different images for the different colors. > Ya, it would be a lot of work for sure making a standard 8 bit palette and redoing most of the arches to use it - I didn't imagine I would live to see it. Then again if we implement a standard 8 bit pallete now for new graphics, some day our grandkids will thank us for it. >> Items with Multiple Materials- >> well items with multiple materials. how about allowing an item to >> have multiple items in equal proportions. So an item like a normal >> axe is say wood, metal (50-50) a stone axe wood, stone (50-50) a more >> complex item might be metal, wood, stone (33-33-33). If the >> materials are not of equal proportion (by weight I suppose) then they >> aren't factored in is all. Toughness would be the same as it works >> now (how does it work now with the saving throws?) with bitmask items >> or perhaps when you fireball or otherwise deconstruct that ruby axe >> you burn away the 50% weight (the wood) and get a ruby. > > > That works - presume if the material has multiple types, they are > equal by weight. > > You could list multiple types even if not 100% equal, but close > enough (eg, a 60/40 real life, you might still list it as two > materials which would be 50/50, as its a close approximation). > > As for saves, probably be fairest way is to look at the material > which has the worst saving throw for that object. Eg, if you have an > iron/wood saving against fire, you'd use that wood saving throw. > However, if you have that same object against acid, you'd use the iron. > > I'd try not to get too tricky on what happens when an object fails > saves. That is another can of worms. Ya lowest. The other can of worms would be related to item deconstruction of which I know only rumours... Wood ash is a prime ingrediant in some recipies, there are examples of other items which have partially survives massive trauma ( >> Well I don't want walls or buildings or other such landscape features >> to have material in general, nor forests or mountains or swamps (I >> can see having special tree or mountain arches that would, like a >> mine arch, also there is code already for random plant placement so >> mineral placement is simply a few lines to this.) This is along the >> lines of secret passages - Players shouldn't be expected to try every >> terrain square to see if it breaks burns or gives milk. >> Monsters or other living things should not have material types. > > > to an extent, I agree. However, if you allow random harvesting of > materials, how do you do that? I should be able to go into a forest > and chop down a tree and get wood, but what wood would I get? > Well this tree arch in question would have had a materialname set when it was placed (by man or machine). If it was set to 'wood', you would get a random wood, if it was set to 'oak' - you would get oak. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Apr 21 00:00:12 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:00 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <3EA331D8.6060904@sympatico.ca> References: <13861.1050656159@www23.gmx.net> <3EA050BD.8060500@sympatico.ca> <3EA0FB34.50200@sonic.net> <3EA2E28A.7070702@sympatico.ca> <3EA31382.4030808@sonic.net> <3EA331D8.6060904@sympatico.ca> Message-ID: <3EA37ADC.1050509@sonic.net> Todd wrote: Just a note, I think you are confused by what I mean when I say 'artifacts'. There are two types of artifacts in crossfire: 'true' artifacts are things like bonecrusher, darkblade, defender. Objects which have a specific archetype entry, and specific entries on the treasure list. 'random' artifacts. These are things like the 'of zormola' or 'of lythander' objects, and are controlled by the lib/artifacts file. These random artifacts may not in fact be suprerior items, as witnessed by the 'of mass' and 'of great mass' objects. In retrospect, calling this file artifacts was a terrible idea, but I didn't code it (I actually don't have a better name for it off the type of the head, but since the file is caleld artifacts, it only creates confusion when the word 'artifact' is used). In all my discussion in this thread about 'artifacts', I'm talking about random artifacts above. >> ... >> Or do you just mean convert the material file to archetypes (which >> wouldn't be hard), and have a special material type to denote this >> (sort of like skills are now). Thus, instead of having yet another >> file format, you could just have a 'materials' directory in the arch >> to customize/add new materials. > > > > That was my thought, yes. Skills as archs, spell arches, ability > arches, treasure lists arches (kind of like the random map styles are > now...), material arches.... I actually think this is a pretty good idea. The only thing currently in the 'materials' file that won't transfer is the saving throw values. So you'd now need to copy in saving throws into the object structure, or find some other clever way to handle that. As a note, if materials were done in this way, rather than the object containing the material, it'd probably just be easier to have an 'object *material' pointer. However, you'd actually need to use something like objectlink pointer if you plan to have more than one material in an object. > > This is where I was imagining inheritance played a part. General class > characteristics inherited by the specific materials so you don't need to > configure every little setting (but you could...). Note imagine is the > operative word since this was speculation on my part. I'm not sure how this work. At one level, I could see something like tree >> spear >> club >> arrow. IS that what your talking about? Even that, isn't a perfect method. A spear can't be converted to a club and vice versa (at least not in real life). This is sort of say I want to convert a 2"x4"x72" beam into a an 8.3" x 8.3" x 8.3" cube of wood. It just doesn't really work that way (ok, maybe with enough glue or whatever). but structurally, you see the point. I'd also think that such inheritence would just be even more confusing. > Ya, but you could also have monsters turning gold to lead or steel into > tin. I knew steel to gold would be a provocative example, but it would > work both ways. Plus you can make these things prohibitive - iron to > gold abilities would be a heck of a lot less common than the steel to > tin abilities. Remember the disenchanter beast? How about a little > fellow that turns sangunite to lead? > I know you can do this otherways but, it nice when it's as simple as > twigging the material. You could have some monsters do that I suppose. However, IMO, the ability to balance that is close to 0%. The real problem is how do these abilities work? If it is jus a matter that it is hard for a player to learn the lead to gold ability, that might sound good, but once he learns it, things are really screwed up. I suppose you could make this ability only appear in the scrolls. That might be interesting then.. Hmmm, I have a 'steel to mithril' scroll. Having this steel sword be mithril might be nice. And if the value/cost of these scrolls was more than the likely value you'd get from the item, no big issue there. I'm not sure to really put this as monster abilities. That rust monster should live up to its name, and really rust items (as of now, it just attacks with acid). Only material that really rusts being iron and steel. Thus, having the bronze armor/weapon in this case could be useful. However, you'd also need smarter monster logic - imagine that rust monstering wandering around, and if he steps onto a space with iron, he'd eat it (rust it out). So imagine a player coming into a dungeon, and seeing that there is no iron about, but plenty of bronze and tin and whatever else items. HE may get some clue. > >> One could certainly do something like that - to follow AD&D, warp >> wood - checks inventory of target, and warps some number of wood >> objects, making them unusuable. However, for this to really work, you >> then need to have some method of saying these are warped. Things like >> heat/cool metal are a lot trickier to track. > > > Not really you don't have to actually have heat or cold, just assign an > amount of damage per measure of iron. Now you want to wear that plate > armour when fighting fire elementals Pepe? But a little trickier - you somehow have to know that the fire elemental can heat that armor. Is this a spell like ability, or happens if you just stand next to it (does anything that attack with fire do this?) And how often do you make this check. It can certainly be done, but I'd not consider this an easy change. >> There is no harm listing artifact combinations in the file that can't >> possibly exist. > > >> And if you don't, all that really happens is that your object won't >> appear with these new special abilities/materials. Your item will >> still continue to work. > > > no but it does get messy over time and you need to get into the server > files to make maps No more than right now. (eg, if you want to add a new archetype, you need to get onto the server to make that entry). the random artifact code really only works for archetypes, so if you add one, add the artifacts entry for the other (if appropriate). This is no different than adding the image and treasure for your new archetype also. > > That's interesting, material bonuses should be applicable for what ever > object they constitute. I didn't think of an example like this. > Either this type of bonus has to be taken out of the material code so it > works universally or pseudo-logic can be applied to say that Yew is > lighter but harder thus more the club weilder is more nimble, thus more > damage (since damage can be seen as factoring in chance to hit as well > as actual injury). I think we're talking past each other right now. As the code stands now, the material bonus is universal. yew wood gives a +2 damage bonus for any weapon that gets made out of it, whether that weapon is a bow, club, spear, axe, etc. To me, that is wrong. Another case - lead has a -2 damage penalty. That is reasonable to see in the case of things like swords - lead can't keep a sharp edge. But for things like sling bullets (if they existed), or hammers, lead should probably cause more damage (heavier weight = more damage in those cases). As the code stands now, there is no way to make that distinction - it just says that anything made of lead has a -2 damage bonus. Just as a nit, I have no idea where Tim got his weight allowances for materials - they certainly don't match real life (platinum is more dense than lead for example) > > But if the artifact file randomly changes the items randomly after the > map has been created (when somone enters it presumably) then you have no > control over specific implementation. In this case if you wanted a ruby > club particularly how would you do it without creating a new arch? > Of course you could claw back some of those sort of bonuses from > material type while leaving basic modifiers such as value, weight and > saving throws. > Really I haven't got an answer for this - there seems to be a > particle/wave thing going on here. That is true. Of course, that ruby club example doesn't work right now either. Presuming we have some way to know if the item has been processed, or needs to be processed on this load, I'd suggest this (presuming we know the object needs to be processed): First, the code would look to see if there is a random artifact entry for ruby clubs. Presumably it doesn't find one. So it then falls back to the basic properties of ruby, and applies that. This may not be as perfect. OTOH, this case is less a concern to me. IF the mapmaker really wants it accurate, he can override the values appropriate and set the 'don't process me special' flag so the server ignores the material stuff. Since a ruby club would never show up randomly, how the user customizes this is not a big concern. I'm much more concerned about the cases like 'mithril sword' vs 'steel sword'. Since mithril swords may very well show up randomly, I'd want any that are specificly set that way in a map by a designer to get created just as if it was a random object, so it merges and otherwise behaves properly. > See I would tend to never actually have a general material used in an > object. This is why I suggested changing iron to metal and such. The > material would always be specific. You could have an item with no > material, but never an item of 'wood' (it would always resolve to be a > type of wood) for example. That's fine. But in that case, I don't see any harm in saying 'random_wood' or 'random_metal' vs just wood or metal. It is much clearer what is happening when you say 'random_wood'. Otherwise, you also get the confusion of something like 'is paper a specific material or not?' As of now, it is - there is only 'paper', and not things like velum or parchment. So if you had 'random_paper', as of now, you'd always just get it turned into paper. But suppose down the road you add 'velum' and 'parchment'. What used to be a specific meaning is now generic. Something of materialname 'paper' would now get turned into velum or parchment (and presumably, 'paper' is still a valid specific entry for things you write on). You don't have any of these problems if you prefix the materialname with random_ if you want it randomized. you also have cases right now where the generic name may also be the final result. Bone is an example. It is a generic name, but can also be the final name (there is only about a 30% chance of bone material not showing up as bone). So how do you differentiate that of 'I really mean this item should be made of bone and not randomized'. Prefixing the random_ once again fixes that. > Ya, it would be a lot of work for sure making a standard 8 bit palette > and redoing most of the arches to use it - I didn't imagine I would live > to see it. Then again if we implement a standard 8 bit pallete now for > new graphics, some day our grandkids will thank us for it. As said, I just can't see much advantage to that over just making unique images for the different colors. If we got to the point where enough of the images were done in enough different colors to say 'we really need a better method for this', then I might change my mind. But given the work needed to do palletized images (simply put, A LOT), I can't see doing this. And since seperate images give all the same benefits (it looks different) with almost none of the work, it is a sure term win. And I'd bet that down the road, if we did decide to go to palletized images, I'd expect that there could be tools which would take 5-6 images that are the same except for colorization and convert them into a palletized image. But even then, it is unclear why this is better. Most likely, even in this case, the client might still decide to render the image once and not at each draw. So in this case, it would just render 6 images (or whatever) - one image for each pallette. The only real advantage woudl be that palletized images would presumably take less space than a unique image. But as time passes, even that becomes less and less and image (bandwidth increases, disk space increases, etc.) > > Ya lowest. The other can of worms would be related to item > deconstruction of which I know only rumours... Wood ash is a prime > ingrediant in some recipies, there are examples of other items which > have partially survives massive trauma ( Well, it would be nice to somehow denote what happens to the object when destroyed. But this gets tricky. While wood ash makes sense if the object is incinerated, if the object is destroyed by acid, you shouldn't get that. However, to list all the combinations is probably not possible. But therefore denoting what this object turns into could be interesting. As well as perhaps what portion survives (eg, wood -> ash, you'd lose a lot of mass, presuming you can collect all that ash. metal -> melted metal, the mass would be near the same, its just now in a less useful form (that iron sword turned into a 'melted mass of iron'.) We'll ignore the issue that if you melt tin and copper, you should really get a pool of bronze - trying to figure out those mappings is another can of worms not worth dealing with. > Well this tree arch in question would have had a materialname set when > it was placed (by man or machine). If it was set to 'wood', you would > get a random wood, if it was set to 'oak' - you would get oak. Ok. Presumably, the random map/herb code could also make adjustments. Eg, growing conditions say this is good for oak, so let me set that material name. Over here, growing conditions are good for pine. This is trickier for the mountain spaces - presumably you should be able to mine some of the metals as well as some of the stones. However, weather doesn't really play into that - I guess some small number of mountains could get turned into quarries/mines. Ideally, over time, you might want thse to move around (eg, just don't always go to X to mine mithril).' > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Apr 21 02:47:29 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:00 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <3EA31382.4030808@sonic.net> Message-ID: On 20-Apr-03 Mark Wedel wrote: > Todd wrote: > If an object has a generic material, then when it is loaded (created), the > various adjustments happen. Thus, as the code stands now, if you don't set > the > materialname, a random material is chosen, and adjustments are made. > > However, if you set the materialname, the loader presumes that the > adjustments > have already been made, and thus does nothing. This was done because I presume if you are making a "gold sword" specifically, you have allready taken into account the effect of the gold on the sword. It would be silly to wieght adjust all the gold nuggests based on the iron->gold adjustment.. they were allready the right weight for gold. The simple solution is.. if it's made of mithril.. adjust for it when you make the object. > The wood/non metal materials do pose some issues. OTOH, it also depends on > how the creation is working - if magic is involved, not too hard to believe > that > you could turn 20 arrows into a spear or whatever. However, if your just > working at a workbench, that isn't feasible - in that case, you'd have to > determine if the donor item exceeds the material requirements for a new item > (eg, a spear could be turned into some number of arrows, but not vice versa). > But to do this, you'd need some tag in the material that says this is a > material > that can be reconstituted or not. My concept was to make a magical device.. like a big forge of some sort. You can only make objects from a raw material (type 73 INORGANIC). If you had collected a pile of oak spears.. you put them in the device, and pay your refinery fee, and poof, out pops a given amount of oak boards. The given amount could be fiddled with.. for example, you could pay extra to increase the accuracy of the refinery, or pay the minimum, and have it give you a normal amount. (that being, say you put 50kg of spears into the refinery, it would normally spit out between 1-25kg of raw oak. you could pay more to increase the odds, as an idea) So yes.. a player could dump a gold armour into the refinery, but it would cost him a bundle of money to convert it to raw gold. So there would be no monetary benefit. The workbench is just where you convert your raw oak into a spear. To make a spear, you might need a lathe (work area) and a carving tool. Certain carving tools are of higher quality than others, allowing you to make the more powerful spears. Special tools could cost a boatload of money, or be quest objects. (Bobs magical swordsmithing hammer) > I basically agree - there is no reason not to enumerate all the obvious > material types. If you don't want to have material for ruby, diamond, > emerald, > pearl, etc, at least a more general 'gemstone' or 'crystal' category could be > workable. I only didn't do it because I didn't want to flood the system with materials until I had time to fiddle. It's trivial to make a material that never comes up randomly with the current system, to prevent things like a diamond stoneaxe. > And only have yew show up in bows and crossbows. If I want it to show up > in > clubs, I could make an appropriate entry, but not give it a 'dam 2' value. > But > given the current implementation, there is no way to do that, and I consider > that wrong. Its not unreasonable to have yew clubs.. just that it gives the dam bonus is possibly wrong. This could be solved with the current system without alot of work, and without doing something ugly. The current materials file could easily be extended to have something similar to the only-for in archetypes. Whatever way you wanted to go with it.. > See note above - you need some way to know that this is the first time the > server has seen that item, and thus is the time to apply the material > benefits/penalties to the item. IMHO it is counter-intuitive to have the system apply bonuses to items I have manually set to being of a specific material. If I make a mithril magic sword.. I don't want the system auto-changing that on me. The mapmaker should know what he is doing. >> Well I don't want walls or buildings or other such landscape features to >> have material in general, nor forests or mountains or swamps (I can see >> having special tree or mountain arches that would, like a mine arch, >> also there is code already for random plant placement so mineral >> placement is simply a few lines to this.) This is along the lines of >> secret passages - Players shouldn't be expected to try every terrain >> square to see if it breaks burns or gives milk. >> Monsters or other living things should not have material types. > > to an extent, I agree. However, if you allow random harvesting of > materials, > how do you do that? I should be able to go into a forest and chop down a > tree > and get wood, but what wood would I get? > I disagree there. My idea for "mining" was that we set the materialtype for forests to "wood", so it randomizes wood types for the forests. You could go to an area of forest, and harvest it for awhile, and get out the type of wood that forest was made of. Obviously buildings shouldn't be harvestable.. but things like mountains could be minable, woods cuttable, etc. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Apr 21 02:57:08 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:00 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <3EA37ADC.1050509@sonic.net> Message-ID: On 21-Apr-03 Mark Wedel wrote: > Just as a nit, I have no idea where Tim got his weight allowances for > materials - they certainly don't match real life (platinum is more dense than > lead for example) I wung it. :) As for your idea on rustmonsters.. that is exactly why I added a material system in the first place. I wanted relationships like that to pop up. You could add a special rust attack and saving throws, or just use another save. The idea is that when materials are all damagable, you can make selections as a player based on what you will be fighting. hrmm, I'm fighting an acid blob, this gold sword should be immune to acid, yay. The gold sword may appear useless, but in reality, in specific instances it could be priceless. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Apr 21 02:59:48 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:00 2005 Subject: [CF-Devel] more skill/spell musings In-Reply-To: <3EA246CD.101@sonic.net> Message-ID: On 20-Apr-03 Mark Wedel wrote: > Given directors are a > very > popular tactic, this category could be useful just for that. As a thought, when an object's trajectory is changed by a director, it could change the op->owner as well, giving exp in essense for creative uses of directors. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Apr 21 22:58:59 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:01 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <3EA37ADC.1050509@sonic.net> References: <13861.1050656159@www23.gmx.net> <3EA050BD.8060500@sympatico.ca> <3EA0FB34.50200@sonic.net> <3EA2E28A.7070702@sympatico.ca> <3EA31382.4030808@sonic.net> <3EA331D8.6060904@sympatico.ca> <3EA37ADC.1050509@sonic.net> Message-ID: <3EA4BE03.50205@sympatico.ca> Mark Wedel wrote: > Just a note, I think you are confused by what I mean when I say > 'artifacts'. > > [..] > In all my discussion in this thread about 'artifacts', I'm talking > about random artifacts above. > Nope I got the random artifacts thing. The artifacts file will generate random variations (good and bad) of objects, but this occurs when the item is created and is well... random - if I wanted to place a dagger of Gnarg I couldn't. This isn't good for me if I want I do think I see the real issue here however... > I think we're talking past each other right now. As the code stands > now, the material bonus is universal. yew wood gives a +2 damage > bonus for any weapon that gets made out of it, whether that weapon is > a bow, club, spear, axe, etc. To me, that is wrong. > Another case - lead has a -2 damage penalty. That is reasonable to > see in the case of things like swords - lead can't keep a sharp edge. > But for things like sling bullets (if they existed), or hammers, lead > should probably cause more damage (heavier weight = more damage in > those cases). As the code stands now, there is no way to make that > distinction - it just says that anything made of lead has a -2 damage > bonus. > Yes, this is a problem. A better example still is a metal bow. This is perhaps the crux of the entire issue. Is this what you were speaking of all this time? You can't do these bonuses/penalties universally, you have to have arbirtary lists because the distinctions are arbitrary, so you *have* to use the artifact file for this. _But_ thinking on this point, I believe that it doesn't mean you should use the artifact file for assigning materials to objects, it means that materials shouldn't contain this type of information. Weight, value, saving throws and other universal modifiers should be assigned based on the material, but the artifact file should match materials to objects to produce bonuses or penalties (so for swords some materials would be benificial, but the same materials would be detrimental to bows.) This may make no sense to but consider this. No one is generally going to make a map and place a bow with material type 'metal' or 'iron', but a iron bow could exist, as a quest object (in which case the map maker placed it and perhaps magicked it right up), or as a byproduct of a spell or ability or alchemical transformation, or as an object (could be a model or a statue part?). You can see the problem with accounting for such things as a metal bow or ruby slippers using the artifacts file and how the way that Tim did it with mateial type is much more managable for item composition. This is why I first disliked the material changes, I thought It was similar to the artifact file where he had made lists of what item was made of what - too many limits and it overrides the map maker. This was already being done with the daggers of gnarg or cursed items. What he actually did however is expand the material system in the arches, and by adding saving throw, weight and value modifiers made it meaningful (more than a just a name) to put objects like a ruby crown (as opposed to a 'stone material crown' called ruby and manually modified to add value and other properties if you had the patience) or silver dagger or lead pipe into the game. Perhaps as a side effect to this because of the way it was implemented there is a random component as well so that there isn't a requirement to make an arch for each maiterial combination (which you would have to do to autogenerate items), but merely an arch for each material class (I can live with having a stone axe arch and a steel axe arch...) > I actually think this is a pretty good idea. The only thing currently > in the 'materials' file that won't transfer is the saving throw > values. So you'd now need to copy in saving throws into the object > structure, or find some other clever way to handle that. > > As a note, if materials were done in this way, rather than the object > containing the material, it'd probably just be easier to have an > 'object *material' pointer. However, you'd actually need to use > something like objectlink pointer if you plan to have more than one > material in an object. Well either in a list or as an arch it is the same, the difference being where and how it is stored- I dont' know about pointers. I wasn't thinking of using these particular arches on a map if that is what you are saying, just standardizing 'objects' in one place. If you wanted to actually see some gold on a map it would have to be put into a material field in an item (an ore arch, or a ingot arch, or a nugget arch...) Just like recipies and spells would be good in the arches too. Perhaps it would be a good way to fill out or otherwise work out other issues with the arch fields. I don't have see a real problem with hp meaning x coord in a exit type and hit point in a creature, so I don't mind if it is a property in a material as well, but I do get the idea that there are other issues with the arches that are causing some headaches. >> >> This is where I was imagining inheritance played a part. General >> class characteristics inherited by the specific materials so you >> don't need to configure every little setting (but you could...). >> Note imagine is the operative word since this was speculation on my >> part. > > > I'm not sure how this work. > > At one level, I could see something like tree >> spear >> club >> > arrow. IS that what your talking about? No, I meant wood>>pine or wood>>oak or metal>>iron where wood passes properties to pine which can be modified (like basic saving throw information, burnability) or where metal passes properties to iron (like basic saving throw info, malability, melting) Material would have no direct relation to the platonic spear, club or arrow until these objects are created. This came from an idea in the Crossfire TODO list. Realistically however, aside from some theoretical (and as yet coded) properties like burning, malability and melting (so you can add metals, but not wood, but you can burn wood and not metals...) it is probably just as effective to have a list as it is now. I realize that Tim was working within the existing material code, but I think that he hit upon a good model for material in general even if there weren't already metal, wood, glass... > But a little trickier - you somehow have to know that the fire > elemental can heat that armor. Is this a spell like ability, or > happens if you just stand next to it (does anything that attack with > fire do this?) And how often do you make this check. It can certainly > be done, but I'd not consider this an easy change. I was thinking it as an example of an ability or spell that could use material. Think of a spell/ability that worked like a fireball that did an amount of damage (dropping off each square removed from the caster/creature) for each 100g of metal worn. You could call it Nova or ColdWave - it would work the same. It would target more the armoured fellows (not a bad thing). There are probably enough material orientated spell ideas to make a class of magic out of (of course since these are all imaginary uncoded spells you could say the same thing about magic based on a catmotif as well - animated cat o nine tails, nine lives, claw of the magi, furball...) > Well, it would be nice to somehow denote what happens to the object > when destroyed. But this gets tricky. While wood ash makes sense if > the object is incinerated, if the object is destroyed by acid, you > shouldn't get that. However, to list all the combinations is probably > not possible. > > But therefore denoting what this object turns into could be > interesting. As well as perhaps what portion survives (eg, wood -> > ash, you'd lose a lot of mass, presuming you can collect all that > ash. metal -> melted metal, the mass would be near the same, its just > now in a less useful form (that iron sword turned into a 'melted mass > of iron'.)[..] > We'll ignore the issue that if you melt tin and copper, you should > really get a pool of bronze - trying to figure out those mappings is > another can of worms not worth dealing with. Yes. Another thing is that hopefully there will not be so many materials that you are talking about making alloys. There is no problem just *naming* something copper or bronze - they are close enough in game play that ther need be no physical distinction. For materials to be useful they should be different enough. That being said, there will be a greater representation of things such as precious metals and gem stones for atmospheric reasons, but I really don't even see the need for say iron _and_ steel, iron would be fine. > Ok. Presumably, the random map/herb code could also make > adjustments. Eg, growing conditions say this is good for oak, so let > me set that material name. Over here, growing conditions are good for > pine. > > This is trickier for the mountain spaces - presumably you should be > able to mine some of the metals as well as some of the stones. > However, weather doesn't really play into that - I guess some small > number of mountains could get turned into quarries/mines. Ideally, > over time, you might want thse to move around (eg, just don't always > go to X to mine mithril).' I'm pretty sure you can use the herb code to place mines in mountains as well. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Apr 21 23:57:02 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:01 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: References: Message-ID: <3EA4CB9E.7020207@sonic.net> Tim Rightnour wrote: > On 20-Apr-03 Mark Wedel wrote: > > This was done because I presume if you are making a "gold sword" specifically, > you have allready taken into account the effect of the gold on the sword. It > would be silly to wieght adjust all the gold nuggests based on the iron->gold > adjustment.. they were allready the right weight for gold. > > The simple solution is.. if it's made of mithril.. adjust for it when you make > the object. Yeah, but that is easier said than done. (well, OK, it isn't really hard, but requires a map maker to read the materials file, see the adjustments to make, calculate those adjustments, etc). OTOH, as Todd points out, this is no different than the random artifact code. If you want to make a dagger of Gnarg, you can, but you need to do the adjustments on your own. IMO, neither of these are actually good solutions - making maps should generally be easy, and not require map makers to read the materials and artifacts file. > > My concept was to make a magical device.. like a big forge of some sort. You > can only make objects from a raw material (type 73 INORGANIC). If you had > collected a pile of oak spears.. you put them in the device, and pay your > refinery fee, and poof, out pops a given amount of oak boards. The given > amount could be fiddled with.. for example, you could pay extra to increase the > accuracy of the refinery, or pay the minimum, and have it give you a normal > amount. (that being, say you put 50kg of spears into the refinery, it would > normally spit out between 1-25kg of raw oak. you could pay more to increase > the odds, as an idea) > > So yes.. a player could dump a gold armour into the refinery, but it would cost > him a bundle of money to convert it to raw gold. So there would be no monetary > benefit. This idea seems a little odd - in 'real life', it isn't all that difficult to convert gold chainmail to liquid gold. Well, more to the point of metals, most likely to do anything interesting with them, your 'tools' need to be able to melt them, so in practice, you'd break off enough pieces of that gold armor to melt down to do what you want. However, I don't have any big issue with the above method - presuming the converter methods are somehow appropriate. > > Its not unreasonable to have yew clubs.. just that it gives the dam bonus is > possibly wrong. This could be solved with the current system without alot of > work, and without doing something ugly. The current materials file could > easily be extended to have something similar to the only-for in archetypes. > Whatever way you wanted to go with it.. I agree that yew clubs isn't wrong, its just doing the extra damage is a bit odd. And I'm sure people could come up with other examples (would a steel hammer really be much better than a magic hammer, for example? Given the material has it lighter, it should probably do less damage in fact). These are minor issues, but just oddities which sort of bug me. > IMHO it is counter-intuitive to have the system apply bonuses to items I have > manually set to being of a specific material. If I make a mithril magic > sword.. I don't want the system auto-changing that on me. The mapmaker should > know what he is doing. Well, yes and no. If the map maker knows sufficiently what he is doing, he can then clear the flag which says 'adjust this items bonuses based on material at load time'. If, however, the hope is you have non developers making maps, it should be easy for them to make mithril shields and not need to read the materials file to see what the appropriate bonuses/penalties are (and in fact, since the server isn't a required part of making maps, very possible map makers won't even know what this is). Now I suppose if materials are turned into archetypes, the editor could be a little more clever about this and apply the template on its own. I'd personally consider it a low priority for the editor to be able to parse yet another file format (materials) > > I disagree there. My idea for "mining" was that we set the materialtype for > forests to "wood", so it randomizes wood types for the forests. You could go > to an area of forest, and harvest it for awhile, and get out the type of wood > that forest was made of. IMO, this might make things too easy. Given the big world map, even with the rare woods, you'd probably be able to find them with just a little bit of hunting (I mean there are forests out there with hundred of spaces of trees all together). I don't actually have a good solution to this, however. It makes some amount of sense that type of trees grow based on where they are. However, the counter is that if out of that 100 spaces, there is only 1 or 2 which are different, that doesn't become very interesting to play. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 22 00:41:04 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:01 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <3EA4BE03.50205@sympatico.ca> References: <13861.1050656159@www23.gmx.net> <3EA050BD.8060500@sympatico.ca> <3EA0FB34.50200@sonic.net> <3EA2E28A.7070702@sympatico.ca> <3EA31382.4030808@sonic.net> <3EA331D8.6060904@sympatico.ca> <3EA37ADC.1050509@sonic.net> <3EA4BE03.50205@sympatico.ca> Message-ID: <3EA4D5F0.8000603@sonic.net> Todd wrote: > Mark Wedel wrote: > >> Just a note, I think you are confused by what I mean when I say >> 'artifacts'. >> >> [..] >> In all my discussion in this thread about 'artifacts', I'm talking >> about random artifacts above. >> > Nope I got the random artifacts thing. The artifacts file will generate > random variations (good and bad) of objects, but this occurs when the > item is created and is well... random - if I wanted to place a dagger of > Gnarg I couldn't. This isn't good for me if I want I do think I see the > real issue here however... Well, as m message to Tim says, you could create a dagger of Gnarg. It just as it is right now, it is like th material - you'd have to make the adjustments manually. As said, I don't consider that a good thing. > Yes, this is a problem. A better example still is a metal bow. This is > perhaps the crux of the entire issue. Is this what you were speaking of > all this time? You can't do these bonuses/penalties universally, you > have to have arbirtary lists because the distinctions are arbitrary, so > you *have* to use the artifact file for this. Yes, this is what I'm saying. global adjustments for all weapons isn't a good thing. > _But_ thinking on this > point, I believe that it doesn't mean you should use the artifact file > for assigning materials to objects, it means that materials shouldn't > contain this type of information. Weight, value, saving throws and other > universal modifiers should be assigned based on the material, but the > artifact file should match materials to objects to produce bonuses or > penalties (so for swords some materials would be benificial, but the > same materials would be detrimental to bows.) This may make no sense to > but consider this. No one is generally going to make a map and place a > bow with material type 'metal' or 'iron', but a iron bow could exist, as > a quest object (in which case the map maker placed it and perhaps > magicked it right up), or as a byproduct of a spell or ability or > alchemical transformation, or as an object (could be a model or a statue > part?). You can see the problem with accounting for such things as a > metal bow or ruby slippers using the artifacts file and how the way that > Tim did it with mateial type is much more managable for item > composition. This is why I first disliked the material changes, I > thought It was similar to the artifact file where he had made lists of > what item was made of what - too many limits and it overrides the map > maker. This was already being done with the daggers of gnarg or cursed > items. What he actually did however is expand the material system in > the arches, and by adding saving throw, weight and value modifiers made > it meaningful (more than a just a name) to put objects like a ruby crown > (as opposed to a 'stone material crown' called ruby and manually > modified to add value and other properties if you had the patience) or > silver dagger or lead pipe into the game. Perhaps as a side effect to > this because of the way it was implemented there is a random component > as well so that there isn't a requirement to make an arch for each > maiterial combination (which you would have to do to autogenerate > items), but merely an arch for each material class (I can live with > having a stone axe arch and a steel axe arch...) Ehh, I'm not 100% sure I agree with that. IT can be seen that a yew bow, which does 2 points more damage than a normal value, is more valuable. But should a yew club, which realistic should behave the same as a normal club, be worth more? Probably not - if I can get an 'oak' club that is cheaper than the yew club but just a good, guess which one I'd buy? So in a true supply/demand situation, almost no one would ever make a yew club, and even those that are, wouldn't really be worth anything more. Thus, a global value for all object which says 'items made of yew are 50% more valuable'. The other reason I'd still like to see it in the artifacts file is one of the reasons I posted before - I'd really like to be able to control what material different items are made out of more than just a global 'if made out of metal, it may be any one of these metals'. The global nature of the current method is both a plus and minus - its a plus in that you get a whole bunch of different material objects showing up. It is a minus in that you get nonsensical combinations, or just too many combinations (there are 8 different metals as of this writing. Imagine if this gets expanded down the road to 15 materials, and how much clutter you'd have in your inventory. If I could at least say someting like 'lets limit swords to the 4 materials. Lets have shields be these 4, armor these 4, etc'. Don't have those 4 all be the same to get some variation. That can still be made to allow all your different materials, but keep the number of material + object combinations to some sane level. > > Well either in a list or as an arch it is the same, the difference being > where and how it is stored- I dont' know about pointers. I wasn't > thinking of using these particular arches on a map if that is what you > are saying, just standardizing 'objects' in one place. If you wanted to > actually see some gold on a map it would have to be put into a material > field in an item (an ore arch, or a ingot arch, or a nugget arch...) > Just like recipies and spells would be good in the arches too. Perhaps > it would be a good way to fill out or otherwise work out other issues > with the arch fields. I don't have see a real problem with hp meaning x > coord in a exit type and hit point in a creature, so I don't mind if it > is a property in a material as well, but I do get the idea that there > are other issues with the arches that are causing some headaches. Well, to some extent, I think having materials be archs wouldn't be a bad idea. The more things that use the standard archetype format, the better - this simplifies the number of special loaders needed, makes it easier to integrate these things into the editor, etc. > > > Yes. Another thing is that hopefully there will not be so many > materials that you are talking about making alloys. There is no problem > just *naming* something copper or bronze - they are close enough in game > play that ther need be no physical distinction. For materials to be > useful they should be different enough. That being said, there will be > a greater representation of things such as precious metals and gem > stones for atmospheric reasons, but I really don't even see the need for > say iron _and_ steel, iron would be fine. well, I agree that different materials for objects to get randomly created from should be sufficiently different to be interesting. This is basically the same issue with races and classes - if the races are too similar, they are not all that interesting. However, the problem is at some level, I think having a whole list of materials will happen - just look at the discussion about gem types. Now the gem types is a more specific case. But suppose we remove 'bronze' from the materials. I could certainly see at some point someone way 'I want to add a bronze statue to the game', so bronze is back in . And then the question comes, if that material is there, why wouldn't it get used? > > I'm pretty sure you can use the herb code to place mines in mountains as > well. I'm sure you could. But a lot harder to know 'we should place a copper mine here, and a mithril mine here, etc' simply because if you have temparture and rainful, you can figure out what plants will grow. Those two bits don't make too much difference for what minerals would show up. Could be more interesting to somehow modify the random map code - have mines show up, and in the mine itself, you find the appropriate type of ore for that mine (gold nuggets, iron ore, mithril crystals, etc). Ideally, a new material theme would get chosen each time the map resets. So at one time, that mine might be copper, next time iron, next time lead. Of course, the curent material stuff doesn't work great for that either - all the alloys are never really mined - you'd never actually mine 'steel ore' for example, but rather mine iron and turn it into steel in your blast furnace. But thats yet another can of worms. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 22 03:07:04 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:01 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <3EA4D5F0.8000603@sonic.net> Message-ID: On 22-Apr-03 Mark Wedel wrote: > Of course, the curent material stuff doesn't work great for that either - > all > the alloys are never really mined - you'd never actually mine 'steel ore' for > example, but rather mine iron and turn it into steel in your blast furnace. > > But thats yet another can of worms. Not really.. think alchemy. Perhaps certain metals cannot be mined at all. You simply mine the components and alchemy them together. It's no different from making true lead or mercury. I assume bronze and steel would work like this. That much is trivial to implement. It also leaves the option open to have certain materials that never show up randomly. Say for an example we make a new alloy, umm.. lets call it markurite. :) The metal has special properties which make it desireable for certain uses, say it makes nice boots, or whatever. We have a formulae for it, and if people want to make a pair of boots, they have to go mine/gather some iron, gather some ash, and mine some obsidian. Combine in some alchemical ratio, and then they can craft a pair of boots with it. The player has then created an item that is completely unavailable in the game by collection means. IMHO that is what the alchemy system is really missing.. the ability to make something truly unique and special to the player. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 22 03:14:16 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:01 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <3EA4CB9E.7020207@sonic.net> Message-ID: On 22-Apr-03 Mark Wedel wrote: >> The simple solution is.. if it's made of mithril.. adjust for it when you >> make >> the object. > > Yeah, but that is easier said than done. (well, OK, it isn't really hard, > but > requires a map maker to read the materials file, see the adjustments to make, > calculate those adjustments, etc). > > OTOH, as Todd points out, this is no different than the random artifact > code. > If you want to make a dagger of Gnarg, you can, but you need to do the > adjustments on your own. > > IMO, neither of these are actually good solutions - making maps should > generally be easy, and not require map makers to read the materials and > artifacts file. Ahh.. but that wasn't really my point. A mapmaker creating a specific object shouldn't have to think about that sort of thing. He shouldn't have to consider that when he sets a sword to damage 10, and mithril, it might end up being dam 12. He *meant* for the sword to be damage 10, and he *meant* for it to be made of mithril. Therefore, in his creation, he has allready taken into account the effect of the mithril. He should not be forced to follow the details I have laid out for the general materials. The idea behind them is that the modifiers show the difference between that metal, and the "base" normal metal (iron), and apply it to everyday objects. It is not a hard and fast set of rules that all objects need to conform to. It follows the principal of least surprise. If I make an object, and specifically tell the game it is mithril, the game assumes I have taken that into account when creating the object. In this way, it is no different to the mapmaker than it was before. Think of the mithril armour in the game. Would you have me change that mithril armour to have additional AC and whatnot effects because I've added the new system? Of course not. it's allways been mithril, it's allways had the "special" impact of being mithril. My material code wasn't needed to make that mithril chainmail better than normal chainmail, it has allready been taken into account. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 22 03:50:31 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:01 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) References: Message-ID: <22586.1051001431@www48.gmx.net> When I read all this about materials, item-deconstruction and harvesting skills I started to wonder: What is this really going to add to the gameplay? We already have item-creation. We already have "raw materials" in respect to alchemy: Dread eyes and lich dust are raw materials, diamonds are raw material... Now if we had item-deconstruction and maybe transmutation, that opens a big can of unbalancing-worms and economy loopholes - and for what? There was the suggestion to balance it by charging money. So I have to pay to convert my armour into gold? Well, fine - but how about dropping the old armour and bying a new gold armour from the shop? Same outcome, easier to understand, and already implemented since ten years. I could deconstruct my gold armour into nuggets? So what about selling the gold armour and bying nuggets from the bank? And what about the harvesting skills? To me they sound like skills which are primarily focused around pressing a single keyboard button. Tell me if I'm wrong. Is the big deal the gain of "realism" like when rust monsters can decompose my iron armour into rust? First, IMO realism is less important than simplicity and gameplay. Second, most CF features got abandoned before it ever came to detail-work like the rust monster thing. I also read the following argument: > what the alchemy system is really missing... > the ability to make something truly unique and special > to the player. > I don't understand this at all. The alchemy system *can* be used to make any kind of unique and special item. In fact, we explicity decided we do not want this because it is spoiling our quests when the best items can be composed of random ingredients. After all, this smells like the "big deal" are going to be the great items you get out of item-de/construction. This is not gameplay value. This is like placing a big unbalanced super-sword in a badly designed map to make it interesting. AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 23 01:10:35 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:01 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: References: Message-ID: <3EA62E5B.9040804@sonic.net> Tim Rightnour wrote: > On 22-Apr-03 Mark Wedel wrote: ts file. > > > Ahh.. but that wasn't really my point. A mapmaker creating a specific object > shouldn't have to think about that sort of thing. He shouldn't have to > consider that when he sets a sword to damage 10, and mithril, it might end up > being dam 12. He *meant* for the sword to be damage 10, and he *meant* for it > to be made of mithril. Therefore, in his creation, he has allready taken into > account the effect of the mithril. But what I'm saying (and what I think Todd has said) is that a map maker may take a normal sword, assign it material type mithril, and expect that it will be 'improved' as mithril would do so. That mapmaker probably isn't expecting he needs to adjust value and other bits. More likely, he's found a random mithril sword while playing, and said 'that's cool - I'll put one on my leader giant', and not expect that that doesn't work as expected. This is actually a tricky issue. On the one hand, you should presume that the mapmaker knows what he is doing. OTOH, that may be an overly generous presumption on what the map makers skills are, or what the map maker expects. The ideal situation of course would be for the editor itself to make the adjustment - this lets the player see exactly what a mithril item does. But at some level, the question comes in how smart should the editor be (the 'smarter' it is, the more likely that a change in the server could result in the editor doing improper things). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 23 08:06:55 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:01 2005 Subject: [CF-Devel] bug in update_object() In-Reply-To: <3EA62E5B.9040804@sonic.net> Message-ID: update_object() in common/object.c is the main update function for map flags. There is a variable called "update_now". This variable is not initialized at function start! it must be int update_now=0, flags; instead of int update_now, flags; Funny is, that i missed this bug for ages - but all the times i wonder about "flags don't match with old flags" warning in some compile settings from update_position(). If this is fixed, better you do some test runs because this is a long staying bug and update_object() seems calling update_position() sometimes with wrong flags, invoking some protests from it. I really hate this kind of bugs... Sometimes the compilers drop a "used before initilized" warnings, but here nothing - not from VC and not from GNU C. And i had looked over it alot of times and always missed this and wonder about the strange unexpected warnings (i thought all the times we have a memory leak here or a stack overflow...). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 23 11:11:18 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:01 2005 Subject: [CF-Devel] Map summaries Message-ID: <20030423161117.GA13725@crystal> Hi All, Just wondering, what is the email address for sending in map summaries to the CF webpage? All email addresses seem to have been removed from the webpage. BT -- GEEK = Gatherer of Extremely Enlightening Knowledge _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 23 11:21:37 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:01 2005 Subject: [CF-Devel] Map summaries In-Reply-To: <20030423161117.GA13725@crystal> Message-ID: Hello, The Contact Info: is in the lower right hand corner of each page. ;) If you are looking for the submit page - that was taken down during the recent site overhaul. Let me know if you have any questions.. - Rick On Wed, 23 Apr 2003, H. S. Teoh wrote: > Hi All, > > Just wondering, what is the email address for sending in map summaries to > the CF webpage? All email addresses seem to have been removed from the > webpage. > > > BT > > -- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 23 12:59:41 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:01 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <3EA62E5B.9040804@sonic.net> Message-ID: On 23-Apr-03 Mark Wedel wrote: > But what I'm saying (and what I think Todd has said) is that a map maker > may > take a normal sword, assign it material type mithril, and expect that it will > be > 'improved' as mithril would do so. That mapmaker probably isn't expecting he > needs to adjust value and other bits. > > More likely, he's found a random mithril sword while playing, and said > 'that's > cool - I'll put one on my leader giant', and not expect that that doesn't > work > as expected. Then it would be trivial to make a spcial flag that says "process this item with the material change code, and then remove the falg and save the object" If anything however, I think this flag should be per-request.. not the standard behavior. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 23 13:38:03 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:01 2005 Subject: [CF-Devel] Map summaries In-Reply-To: References: <20030423161117.GA13725@crystal> Message-ID: <20030423183803.GA14988@crystal> On Wed, Apr 23, 2003 at 11:21:37AM -0500, Rick Tanner wrote: > > Hello, > > The Contact Info: is in the lower right hand corner of each page. ;) Ahhh, I see it now. See, that's what happens when you play CF too much. :-P > If you are looking for the submit page - that was taken down during the > recent site overhaul. [snip] OK. T -- "A man's wife has more power over him than the state has." -- Ralph Emerson _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 23 20:31:19 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:01 2005 Subject: [CF-Devel] more skill/spell musings In-Reply-To: <3EA246CD.101@sonic.net> References: <3EA246CD.101@sonic.net> Message-ID: <20030424013119.GA3642@hawthorn.csse.monash.edu.au> > Note one thought I had is that given the split in skills, we can perhaps > give exp for successful use of spells which we didn't before. Eg, if you > paralyze a creature, you'd get some exp for that for example. Sure, this > could be open to some abuses, but there are already otehr abuses out there > (maps you go in and fire 20 fireballs or whatever). Would not a better solution be, if you kill a monster while it was paralyzed you get exp to the skill for kill, and same amount of exp to the skill for paralyze? > > summoner - matches the class. This gets the summon spells, as well as most > of the item creation spells (build xxx wall, create ..) Given directors > are a very popular tactic, this category could be useful just for that. > > evoker - covers a wide range of damage spells. Since this is most useful, > it gets split with: Pyromancer? > pyromaniac: Gets fire/lightning spells, as well as bomb. That leaves > evoker with cold/acid/poison/bullet. Evoker could also get some of the > pyro spells perhaps. > > discover: The alchemist class falls into this. Gets alchemy spell. Gets > spells that let them find information out (identify). Gets spells that > help survival, so that it can learn (study) things, eg, some number of > protection spells. Also toss in things that perhaps change behaviour > (slow, haste, paralyze). Toss in spells to help get away (dimension door). > In a sense, this sort of gets the leftover that dont' fall into the ones > above. I thought evokers were mainly direct damage? Or are evokers a seperate class and unrelated to the things below it? > As a note, the idea is that most of the spells would belong to only one > school. However, some spells could certainly belong to more than one > school. For example, detect magic is probably a fundamental ability that > everyone should know. The pyromaniac should probably get pro > fire/electricity so they don't kill themselves, but the discover might also > have those. Just have a "shared skills" group. > Note one of my thoughts would be that we perhaps limit characters to > knowing only 3 of the 4 schools above - thus, higher lever characters are > likely to look a bit more different and/or players have to make some actual > decisions. The diablo II system would work wonders in regards to this. (level dependant and skill dependant, you need to fulfill the requirements of level and of having the 3 (or more or less) skills below it before you can learn the skill.) > The unresolved issues on this: > > 1) For spells that belong to more than one school, what school/skill is > used to cast it. My thoughts would be 1) school you are best in, 2) have > all spells be unique, so detect magic for discovers would have a different > name than the evoker uses, 3) Player can specify a search order to use (eg, > spell_search evoker pyro summoner) 4) use currently active skill, then a > fallback of either 1 or 3 I don't like the sound of a a different name for the same spell, a small difference can justify a different name but having many different names for one skill is just going to be confusing. I'm abit unsure as to what various classes do to get skills from other classes? Currently I would imagine the game would be nigh on impossible without being able to use both ICE spells and FIRE spells. dnh _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 23 20:35:41 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:02 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <3EA4CB9E.7020207@sonic.net> References: <3EA4CB9E.7020207@sonic.net> Message-ID: <3EA73F6D.7050909@sympatico.ca> Ok two more, then I'm done... One: Mark said: > This idea seems a little odd - in 'real life', it isn't all that difficult to > convert gold chainmail to liquid gold. Well, more to the point of metals, most > likely to do anything interesting with them, your 'tools' need to be able to > melt them, so in practice, you'd break off enough pieces of that gold armor to > melt down to do what you want. > > However, I don't have any big issue with the above method - presuming the > converter methods are somehow appropriate. I would hope that gold chainmail is not so common that people are lining up outside the 'gold refinery' and that it would upset the economy. The problem with using extreame cases is the images it brings to mind. I think gold as a material is much more likely to turn up in couns and tiny nuggets and the *vast* majority of refining would be to turn these little bits into big bits than vise-versa. It might even take some metals out of commission if you made enough big items like statues (impress your friends and neighbours - drop 1000lb of gold for a statue of yourself) > > > > Its not unreasonable to have yew clubs.. just that it gives the dam bonus is > > possibly wrong. This could be solved with the current system without alot of > > work, and without doing something ugly. The current materials file could > > easily be extended to have something similar to the only-for in archetypes. > > Whatever way you wanted to go with it.. > > I agree that yew clubs isn't wrong, its just doing the extra damage is a bit > odd. And I'm sure people could come up with other examples (would a steel > hammer really be much better than a magic hammer, for example? Given the > material has it lighter, it should probably do less damage in fact). These are > minor issues, but just oddities which sort of bug me. > Not so minor, combat modifiers come about as a result of a material being applied to an item (not from material alone.) There should be lists similar to the artifacts file where items are given bonuses or penalties based on material. You could even have certain material - This shouldn't be used in place of the material field in the arch however. > > IMHO it is counter-intuitive to have the system apply bonuses to items I have > > manually set to being of a specific material. If I make a mithril magic > > sword.. I don't want the system auto-changing that on me. The mapmaker should > > know what he is doing. > > Well, yes and no. If the map maker knows sufficiently what he is doing, he > can then clear the flag which says 'adjust this items bonuses based on material > at load time'. If, however, the hope is you have non developers making maps, it > should be easy for them to make mithril shields and not need to read the > materials file to see what the appropriate bonuses/penalties are (and in fact, > since the server isn't a required part of making maps, very possible map makers > won't even know what this is). This is it exactly. Placing a golden hammer on the map shouldn't be as hard as it is where you have to guess the value, guess the weight and set the bitmask for soft_metal. Certainly you can call something a golden hammer, but the 'gold' carries no intrinsic game information to work with. If you take the hammer arch (not a golden hammer arch, but a hammer arch' and set the material to gold and it adjusts the value (based on material, not utility), the weight, then you have a benefit. The fact that it reacts more uniquely by virtue of it being gold and not just a 'soft_metal' (by having different saving throws than say tin) is even better IMHO. The fact that you could use this material value to do other things is even better. Certainly you can write code to manipulate objects based on finding the word 'gold' in the name or some such, but if 'gold' is a material you can use/compare/modify you can write better and more flexable code to do it. This is how it works already, with item saving throws, - this is an expansion of the same idea which would likely make it easier to add say magnetism or decomposition or prevent players with iron objects from entering the elven city, fight a lycanthrope with a silver candlestick, make golems out of straw or out of mithril. The fact that a silver bow makes a real lousy weapon, but silver arrows are useful is apparent to you and me, but not something you can predict so you have to apply *those* type of modifiers using some sort of list however. Really I could give a tinkers damn about a gold sword being -3 to hit but +3 damage - I mean that is adding realism and all and is a great idea too, but in my mind is almost a seperate discussion. Also certainly a well crafted bow of yew will fetch more than a shoddy bow of pine, but come on, a gold bow that is unusable will still fetch so much more that the difference between the others good bow and the crappy one. I realize that in the game usefullness is more of a cost consideration than in the real world, but we still have coinage based on precious metals and therefore the gold bow is worth more by weight. That being said I am not proposing adding randomly generated gold bows to the game thus throwing off the economy... I am proposing that the material system be made more flexable and slightly more responsive. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 23 20:37:08 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:02 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <3EA4CB9E.7020207@sonic.net> References: <3EA4CB9E.7020207@sonic.net> Message-ID: <3EA73FC4.60503@sympatico.ca> And Two: Why working over the materials system is good for game play: Cast aside all preconceptions (including the material code which was recently committed which is being discussed) and consider: 1) There are no diamonds, there is stone(64). There is no silver, there is iron(2). There is no lead, there is soft_metal(1024). 2) Materials are found in all pickable objects, not just weapons and armour ('No material' is considered a material). 3) Part of creating an object on a map consists of picking a material, assigning an arbirtary value, assigning an arbirtary weight and putting in a name. There is no consistancy between map makers so for example if I were to make a gold bar: I would make it material 1024, guess it has a value of 600 (?), say it has a weight of 5000 and call it 'gold bar' You would make a silver bar, assign it material 2 (it holds an edge?), assign a value of 900 (?) say it has a weight of 300 and call it silver ingot. The map maker is expected to understand the values of these fields even though the values are heavily modified in the game (well value anyway). Further to this weapon and armour items have more arbitrary fields to modify their effectiveness and many standard weapon and armour items are subject to further modification when called into existance (artifact code). 4) Most of the inventory checkers and other item handling code, with the exception of parts dealing with the material type bitmask (primarily used for item saving throws against destruction...) when chacking for material has to work by item name, As far as I can tell, determining the difference between silver and gold or ruby and emerald is based on pattern matching on the name. So what would a good material system look like? 1) The material field would be expanded to support a larger array of materials. Further, these would be referenced by name, not by a bit number. This by itself would justify the change since it would be possible to use this value in code (the server code or a scripting language) and it would make things much cleaner. All discussion of recipies, construction and deconstruction, harvesting, or transmutation are merely a *wee* slice of this. It could also be used for item checking, for spells, for weapon bonuses or penalties... what ever someone can think of coding. It would make the designer's life much easier and help to standardize such things as value and weight modifiers without limiting design (You can still change the fields after all, but you don't have to guess how much additional value or weight would be reasonable for golden underpants unless you want to). 2) The materials would be modular, not loaded from a header file. It would be nice if they were actually carried in the archs and not a server side file for the convienence of designers (so you'd only need to run 'make collect'), but not necessary. They should be in a very readable format like the arches in any case. 3) Material properties shouldn't contain combat modifiers or other values which are not universally applicable to pickable items. The system should work equally for a gold or ruby figurine as a gold or ruby helmet helmet. Combat modifiers arising from applying 'oak' to a club would not apply to applying 'oak' to a bow or a spear and thus have material bonuses to combat must be maintained manually based on human judgement. Yes there is also a component of value that is based on the 'quality' of an object and not on the material alone, but this is in addition to the material value modifiers and thus there is no reason value couldn't also modified at this point in an external system (artifacts file or similar set of lists or whatever) as well. So material properties would be primarily saving throws, weight and value modifiers and other non-item specific values (perhaps things like: is_magnetic, is_maleable, is_burnable...) 4) There should be an effort to make arches more material generic to streamline the system. Following that there should be a method of assinging a random type of material from a range to avoid need for the creation of a large number of arches. Something like the treasure file or artifacts system should allow for 'random' material type in an object'. 5) Although it should be simple to add new materials, it should be done with the same reservation of adding other metatypes (spells, abilities...). Materials which have very similar game properties (pine and spruce, granite and marble) can still be handled by changing the item name. If there is a reason to actually add the material. This should be handled in the same way as everything else dealing with arches. 6) There should be a simple way to manage items composed of multiple materials (multiple entries in the materials field to replace the bit addition mechanism). There is little here that goes against the material changes made for 1.5 specifically, but there is a component of reworking some things (especially uniting the material and materialname fields and seperating action bonuses from material properties). It is almost what existed with the originally with the bit field but expanded and moved out of the header files. How will this improve game play without considering the contraversial topics of transmutation or item construction and deconstruction or unbalancing an already unbalanced economy? -The elven city of Nimora will not allow entry to characters carrying any iron. -I've already mentioned spells or abilities which target specific materials. This is a lot of ground to cover. Arch lightning, burst wood -To create a golden statue of youself please drop 1000lb of gold. -"I believe I will place a ruby helmet in the chest." ...... -CFPython.SetMaterial(), CFPython.IsMaterial(), CFPythonGetMaterial() -The undead and their worshippers can be identified as they cannot bear the touch of silver. All these would center on writing code that *checked* the material field, of course I made no mention of things you could do writing code that *changed* the material field. You can probably do some of these things now, but could you do it as cleanly? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 23 21:02:26 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:02 2005 Subject: [CF-Devel] Map lore redux Message-ID: <3EA745B2.4060904@sympatico.ca> Ok one more try: How about this: An arch called maplore Object maplore name type 98(?) face lore.111 -->sample png attached lore @yadda yadda. endlore invisible 1 no_pick 1 editable 128 end Pop these in you maps while designing when you think of some tidbits you'd like to have show up in the general lore population, such as: @The banks of the river Frontinac are said to be the home of a fierce tribe of lizardmen. @The river Frontinac is only passable near the Plains of Azzar or in the northern jungles. or @The city of Scorn is said to be as vile a cesspool as can be found west of Navar. Every so often, run a tidied up version of this script (or perhaps a PERL version mhhh?) to collect the map lore so you can do something with it. With some modifications you could also probably run this against the arches too generating a single lore file to play with. #!/usr/bin/python #lorecollect.py #To collect 'lore object' lore - endlore contents from Crossfire maps # Python 2.1 or so import sys import os import string import fileinput def lorecollect(lfile, dir, files): for file in files: file = os.path.join(dir,file) try: f = open(file,'r') contents = f.read().split('\n') match = 0 for line in contents: if line == 'arch maplore': print 'Found one' lfile.write(file) match = 1 elif match == 1 and line[:3] == 'name': lfile.write('%s\n' %(line)) elif match == 1 and line == 'lore': match = 2 elif match == 2 and line == 'endlore': match = 0 elif match == 2: lfile.write('%s\n' %(line)) else: pass f.close() except (OSError, IOError): pass if __name__ == '__main__': import sys if len(sys.argv) < 3: sys.stderr.write ('Collects lore from maps into a single file\nUsage: lorecollect.py ') sys.exit() else: lfile = open(sys.argv[2],'w') os.path.walk(sys.argv[1],lorecollect,lfile) lfile.close() -------------- next part -------------- A non-text attachment was scrubbed... Name: lore1.png Type: image/png Size: 398 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030423/20d4a30d/lore1.png From crossfire-devel-admin at archives.real-time.com Thu Apr 24 02:04:13 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:02 2005 Subject: [CF-Devel] more skill/spell musings In-Reply-To: <20030424013119.GA3642@hawthorn.csse.monash.edu.au> References: <3EA246CD.101@sonic.net> <20030424013119.GA3642@hawthorn.csse.monash.edu.au> Message-ID: <3EA78C6D.7010001@sonic.net> David Hurst wrote: >> Note one thought I had is that given the split in skills, we can perhaps >> give exp for successful use of spells which we didn't before. Eg, if you >>paralyze a creature, you'd get some exp for that for example. Sure, this >>could be open to some abuses, but there are already otehr abuses out there >>(maps you go in and fire 20 fireballs or whatever). > > > Would not a better solution be, if you kill a monster while it was paralyzed > you get exp to the skill for kill, and same amount of exp to the skill for > paralyze? It is probably better that the exp gets split somehow. I think doubling it probably isn't the right. The main point is that to try and give some credit to the skill that helps out. > >>summoner - matches the class. This gets the summon spells, as well as most >>of the item creation spells (build xxx wall, create ..) Given directors >>are a very popular tactic, this category could be useful just for that. >> >>evoker - covers a wide range of damage spells. Since this is most useful, >>it gets split with: > > > Pyromancer? Well, really it is skill names: evocation summoning pyromancy abjuration/divination/transmutation (this follows AD&D - its a bit long - any idea of a nice simple name? - the basic idea is this covers the knowledge, exploration, and knowledge spells). The background would be if one could only choose one skill, these would be people that could go out and find things out and remain safe. So really any name would be OK, and just write some lore into the game about this skill and why people know it. > > I thought evokers were mainly direct damage? Or are evokers a seperate > class and unrelated to the things below it? evokers and pyros basically split the damage spells. The basic idea is to try and spread out the damage spells a bit more, but since there are so many that fall into the direct damage, some form of split is necessary IMO. If you split evocation, getting the cold and some other spells, with the pyromancy, which gets fire and some other, both of those are large 'arenas' of useful spells. > > The diablo II system would work wonders in regards to this. (level > dependant and skill dependant, you need to fulfill the requirements of > level and of having the 3 (or more or less) skills below it before you can learn the skill.) Not familiar with diablo 2. Note that this system does _nothing_ on how skills are learned - it is really more about how skills work within the game. IT just seems to me that if you allow players to easily learn all 4 magic skills, it sort of removes some of the interest. OTOH, unless other skills are limited, same arguement can be made (learning priest spells or whatever). So as a first pass, other than finding necessary bits to learn the skill (skillscroll), there wouldn't be any real limites. > > I don't like the sound of a a different name for the same spell, a small > difference can justify a different name but having many different names > for one skill is just going to be confusing. There'd be no more than 4 spells of the same/similiar name, as that is how many different magic using skills there are. Although, interesting enough, as I think about this, you could probably associate 'spells' to these non spell casting skills (or maybe more accurately, a skill is only defined as a spell casting skill because there are spells associated with it. > > I'm abit unsure as to what various classes do to get skills from other > classes? Currently I would imagine the game would be nigh on impossible > without being able to use both ICE spells and FIRE spells. Skills and classes are pretty much unrelated. Your class will determine your starting skills, just as now. But beyond that, other than being able to get the bits to learn the skill, there is nothing preventing you from learning it. Note that the idea I proposed was to limit poeple to 3 of the 4 mana spellcasting skills. So someone could learn evocation, pyro, and summoner. He'd just be prevented from the knowledge/protection arena. Someone else could decide to do pyrom, summoner, discover, and thus not be able to get evocation. Of course, he can still use rods/wands for the spells he doesn't have. I know it won't be possible to completely balance the usefulness of these skills. OTOH, I think it is possible to come up with something that there is reason to have the skills. Eg, you'd never say 'never get XXX skill - it has no use'. It also creates potentially some more interesting scenarios - might be more converstation between players - eg, hey, do you have the divination skill and can you make some scrolls for me? In exchange, I'll make you some evocation scrolls' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Fri Apr 25 18:18:04 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:02 2005 Subject: [CF-Devel] Adding New Stuff (again) - Requests and suggestions Message-ID: <200304251718.04237.mail-lists+cfdev@dogphilosophy.net> Finally had a chance to start playing with Crossfire again... Looking at the "what new stuff do you want to see in Crossfire" poll at the website, it looks like there is quite a bit of interest in seeing new spells, skills, races, and monsters. One problem I run into trying to add new things is the fact that MOST of them require recompiling from scratch - and getting anyone else to try them out requires generating a diff and talking someone else into also recompiling from scratch (and hoping CVS hasn't changed in the relevant areas in the meantime...). Realistically, this means only the person who created the new "thing" would ever try it out, and nobody on a dial-up line would ever be able to contribute effectively at all (as running a server on a dial-up line is not as simple to keep up long enough for anyone else to try it out...) While this is unavoidable in some cases, I think it'd be helpful to have support for reading "external update" files for any of the data files that are read on startup (such as the treasures file, the archetypes file, etc.). This way, if someone generated a new race (requiring nothing more than new arch's, barring any completely-new abilities that can't be defined there), anyone who wanted to try it out would need only drop the generated "add-on" files containing the extra archetypes-file info and extra treasures-file info into the appropriate place and restart the server. Similarly, it would be helpful if more of the "generic" functionality were to be split out of the source code and into configuration files/arches (such as hand-to-hand attacks, the "generic" bullet/bolt/ball/cone spells, creatures summoned by different summon-type spells, etc.) would make it easier to contribute new variations for testing and evaluation for inclusion in the "real" source. As I recall, all of those categories in the game are really defined by external config files, but it is currently still necessary to edit header and source files to add the names (and recompile), which cuts out a lot of potential testing of new spells. I don't know how difficult this would be do do in practice, so I assume it's incredibly easy for any of the official developers and therefore I demand that it be done immediately. :-) (I'm still surprised that there's no "biting" HtH attack, given the number of biting monsters [mice, snakes, wolves, etc.] wandering around...) Finally, some published semi-official guidelines as to what's required for "acceptable" submissions of new races, spells, foods, materials, etc. would be helpful, similar to the existing documentation regarding new skills, e.g. something along the lines of: "For a new race, one must have graphics for a minimum of 4 directions and an arch file. The race's attribute modifiers should not normally got beyond about +10 or -5 in total, and no individual modification should be more than +15 or -15. If the race has any abilities beyond variations of existing abilities, the submission must include a patch against current CVS which supplies the necessary code." or "A new hand-to-hand attack must include the appropriate arch, treasure-file entry, and appropriate attack messages. Base damage should not exceed (whatever) and speed should range from (x) to (y)." and so on. Thoughts? Or is this just another gigantic can of metaphorical worms on top of the ongoing "materials" discussion? (Incidentally, I LIKE the new materials system, though obviously some quirks [naming, etc.] still stand to be worked out...) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 26 00:06:05 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:02 2005 Subject: [CF-Devel] Adding New Stuff (again) - Requests and suggestions In-Reply-To: <200304251718.04237.mail-lists+cfdev@dogphilosophy.net> References: <200304251718.04237.mail-lists+cfdev@dogphilosophy.net> Message-ID: <3EAA13BD.4070404@sonic.net> Flying Pedestrian wrote: > Finally had a chance to start playing with Crossfire again... > > One problem I run into trying to add new things is the fact that MOST > of them require recompiling from scratch - and getting anyone else > to try them out requires generating a diff and talking someone else > into also recompiling from scratch (and hoping CVS hasn't changed in > the relevant areas in the meantime...). Realistically, this means > only the person who created the new "thing" would ever try it out, and > nobody on a dial-up line would ever be able to contribute effectively at > all (as running a server on a dial-up line is not as simple to keep up long > enough for anyone else to try it out...) The compiling issue is one that can't be avoided - if you make code changes, the code has to be compiled. I'd note that one issue is that there just aren't a lot of servers, so you have a relatively small audience of peopel to try to run any changes, whether a compilation is needed or not. And of those, some number may want to stick to stable code, just CVS code, etc. > This way, if someone generated a new race (requiring nothing more than > new arch's, barring any completely-new abilities that can't be > defined there), anyone who wanted to try it out would need only drop > the generated "add-on" files containing the extra archetypes-file info and > extra treasures-file info into the appropriate place and restart the server. The archetypes and treasure files are text only, order is not important. so right now, something like 'cat arch_new >> archetypes; cat treasure_new >> treasures' would do as you describe. I don't really see the point of having seperate external files from those. > > Similarly, it would be helpful if more of the "generic" functionality were > to be split out of the source code and into configuration files/arches (such > as hand-to-hand attacks, the "generic" bullet/bolt/ball/cone spells, creatures > summoned by different summon-type spells, etc.) would make it easier to > contribute new variations for testing and evaluation for inclusion in the > "real" source. As I recall, all of those categories in the game are really > defined by external config files, but it is currently still necessary to > edit header and source files to add the names (and recompile), which cuts > out a lot of potential testing of new spells. I don't know how difficult > this would be do do in practice, so I assume it's incredibly easy for any of > the official developers and therefore I demand that it be done immediately. It depends. I personally don't want a bunch of config files each with a unique format. However, I do plan to move more of the functionality to arch's (spell archs as per a mail a few weeks ago). > (I'm still surprised that there's no "biting" HtH attack, given the number > of biting monsters [mice, snakes, wolves, etc.] wandering around...) monsters don't use skill attacks. So for example, while right now there is a clawing skill, monsters don't use it - they just use the values in their arch which defines to hit, damage, etc. However, at some point, one has to examine how many 'unarmed' attacks there really should be. In real life, given a choice, almost no one would go unarmed - even a master of karate would probably be more effective with katana in hand. So the unarmed attacks more add color, and not effective attack methods (although the code may be generous with some). And crossfire doesn't follow other game system model where a claw/claw/bite attack would mean 3 attacks a round. So if a player has claw and bite, he doesn't get extra attack, he just gets more choices. But almost certainly, one will be better than the other. So the question is why add all these skills in? I'm also tempted to just roll all of these into an 'unarmed combat' skill. One can think of this as kicking, punching, clawing, biting, etc. > > Finally, some published semi-official guidelines as to what's required > for "acceptable" submissions of new races, spells, foods, materials, etc. > would be helpful, similar to the existing documentation regarding new > skills, e.g. something along the lines of: This is much more variable. My personal thoughts on this: 1) It must be sufficiently different to be added. This is probably why the northman lost out in the competition - not sufficiently different to really care about. similiar to the spruce/pine material discussion. 2) It must be balanced. Balance is a trickier issue. Look at some of the races - a lot of stat bonuses, but some other penalty to offset for it (lack of ability to use some item, etc). There are probably some things to say, like more than a 10 modifier to a stat would be questionable. 3) It must be complete, eg, have the arch, image if appropriate, treasure file if appropriate, etc. I'd also note that discussion on this can happen on the mailing list. For example, you can make a post like 'here is a new class - I show the bonuses, skills,etc, What do people think?' This is a bit harder if there are code changes - one can envision what they want to do, but may run into problems when it comes to writing the code. Same issue shouldn't be true for archs. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 26 02:10:35 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:02 2005 Subject: [CF-Devel] Adding New Stuff (again) - Requests and suggestions In-Reply-To: <3EAA13BD.4070404@sonic.net> References: <200304251718.04237.mail-lists+cfdev@dogphilosophy.net> <3EAA13BD.4070404@sonic.net> Message-ID: <200304260110.35514.mail-lists+cfdev@dogphilosophy.net> On Friday 25 April 2003 11:06 pm, Mark Wedel wrote: > The compiling issue is one that can't be avoided - if you make code > changes, the code has to be compiled. > > I'd note that one issue is that there just aren't a lot of servers, so > you have a relatively small audience of peopel to try to run any changes, > whether a compilation is needed or not. And of those, some number may want > to stick to stable code, just CVS code, etc. Well, again, that's why I think it'd be nice to have more of the configuration (particularly, e.g. names of spells and HtH attacks, order of preference of HtH attacks, 'definitions' of extensions of standard spells, etc., which currently are "hard-coded" into the source...) I think people'd be more likely to try out new things if it just required adding a bit to a couple of files instead of going through the whole patch, recompile, reinstall routine. > The archetypes and treasure files are text only, order is not important. > so right now, something like 'cat arch_new >> archetypes; cat treasure_new > >> treasures' would do as you describe. I don't really see the point of > having seperate external files from those. Ah, okay, wasn't sure you could just tack on extra text to the end of those files - that takes care of that problem then... Is it also easy to add graphics to the crossfire.0/crossfire.1 files "on the fly" as well? Also, is it possible to skip adding a new spell name to the headers and instead just add it to the spell_params file? (I imagine not, from what I remember of the code...I think it'd be ideal to be able to add a spell for testing with just an addition to spell_params, an entry in the archetypes file, and new graphics...) > It depends. I personally don't want a bunch of config files each with a > unique format. However, I do plan to move more of the functionality to > arch's (spell archs as per a mail a few weeks ago). Okay, I missed that message - I did go back and read up on some of the messages I missed while I was off of the mailing list, but I hadn't gotten through ALL of them yet...I wouldn't want a bunch of different configuration types either - the handful that exist already ought to be plenty. Basically, any spell (for example) that doesn't require new BEHAVIOR (just different attack types, settings for range, duration, radius, list of possible creatures summoned, etc.) seemed like it ought to be moved out to the arch's and spell_params files instead of hard-coded as they are now. > monsters don't use skill attacks. So for example, while right now there > is a clawing skill, monsters don't use it - they just use the values in > their arch which defines to hit, damage, etc. > However, at some point, one has to examine how many 'unarmed' attacks > there really should be. In real life, given a choice, almost no one would > go unarmed - even a master of karate would probably be more effective with > katana in hand. So the unarmed attacks more add color, and not effective > attack methods (although the code may be generous with some). That's not NECESSARILY true - although I must admit the MAIN reason for my interest in the "biting" attack would indeed be for the appropriate messages. Similarly, this would affect e.g. pets (as summoning spells improve in variety, this may become and issue - although again it's more for "color". ["Your air para-elemental jolts zombie. Your air para-elemental zaps zombie..."...] it would make sense that a character with a pet wolf or giant purple vampire frog would see "biting" type messages...or for that matter a character who gets polymorphed into something else, or when someone starts adding Were(whatever) races to the game, might end up seeing that for his own attacks.) On the other hand - Karate, for example, doesn't do as much damage as many melee weapons, but it has a higher "fire" rate. "Biting" would be slower than "Clawing" but have a substantially (though still reasonable) higher base damage. Properly constructed, the tradeoffs make for a bit of potential strategy (Karate is actually pretty handy when you're being mobbed by large numbers of fast but relatively weak creatures), and another bit of potential "uniqueness" for characters, without danger of serious imbalance being added or having the high "barrier to entry" of needing to understand the crossfire source well enough to code a complex new set of behaviors into the game. > And crossfire doesn't follow other game system model where a > claw/claw/bite attack would mean 3 attacks a round. So if a player has > claw and bite, he doesn't get extra attack, he just gets more choices. But > almost certainly, one will be better than the other. So the question is > why add all these skills in? Actually, I'm glad for that - one "style" of attack at a time is plenty. For HtH attacks, specifically, the only real purpose would be do add a bit more color and strategy, and add another potential "uniqueness" to a character without having to add anything really bizarre or complex. > I'm also tempted to just roll all of these into an 'unarmed combat' > skill. One can think of this as kicking, punching, clawing, biting, etc. The SKILL being rolled into one actually doesn't seem unreasonable to me, though you then still have to deal with the messages (or just change them all to "hit", which is boring...) Of course, while we're at it, someone could do something about all that silly redundancy of having daggers, shortswords, longswords, broadswords, sabers, scimitars, cutlasses, falchions, katanas, and rapiers. After all, they're all basically just "big knives"... (kidding, obviously...I LIKE the "color" and minor differences that having all of those adds to the game...I think the same can apply to a certain extent to different "unarmed" attacks as well, though probably not THAT many.) On the other hand, having them separate gives some potential to later add items to the game that enhance a particular attack type ("boots of kicking", "brass knuckles", "Amulet of the Weapons Master" (boosts Melee Weapons attacks), "MithrilWhite(tm) Toothpaste" (bite-enhancing "potion"), etc...), though what little I understand of the existing code makes me think new code would have to be added to be able to modify the effects (damage, wc, etc.) of only one type of attack skill at a time... > My personal thoughts on this: > 1) It must be sufficiently different to be added. This is probably why the > northman lost out in the competition - not sufficiently different to really > care about. similiar to the spruce/pine material discussion. "Sufficiently different" is the part that I understand the least - not that I don't know why there needs to be differences, but that I'm not quite certain what constitutes something that would be considered a worthy "difference". Different looking? (Graphic "sufficiently" different to make it stand out from other [races|spells|monsters|whatever])? Different "numbers"? (be really fast, really damaging, really slow, really long-lasting, etc. compared to other [races|spells|monsters|whatever])? Does it mean that to be "different" there must be a new set of functions in the source code to handle it?...(Is it, for example, "just another bolt spell" regardless of other novelty unless it has its own new function? Personally, I think there's a lot of untapped "uniqueness" potential sitting in the existing "damage spells" and, perhaps, summoning spells code, waiting for only novel spell names, graphics, and arches to bring it out...) > 2) It must be balanced. Balance is a trickier issue. Look at some of the > races - a lot of stat bonuses, but some other penalty to offset for it > (lack of ability to use some item, etc). There are probably some things to > say, like more than a 10 modifier to a stat would be questionable. I figure what's going to constitute "balance" is going to be something that discussion will have to hash out enough to get viable new submissions into playtesting (where we find out if the discussions were right...) I tend to be pretty conservative about what I guess is balanced, so it shouldn't be an issue for me personally. I hope. > 3) It must be complete, eg, have the arch, image if appropriate, treasure > file if appropriate, etc. Well, I was thinking in terms of what specifically is needed to make a (whatever) "complete". It's obvious in a lot of cases, but might be helpful to have noted down explicitly somewhere, e.g. for a new race: Either 4 or 8 "facing" graphics (with rare exceptions, e.g. fireborn) arch for the new race treasure entry for new race Anyway, just thinking about trying to offer new things for the game again, particularly the spells, skills, races, and monsters at the top of the poll results... (I think the new materials and item-creation systems are very promising) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 26 00:48:54 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:02 2005 Subject: [CF-Devel] Navar map bug Message-ID: <20030426054853.GA10228@crystal> Don't know if this is fixed in CVS; on metalforge, the cathedral in Navar cannot be entered. Did somebody mess around with the no_pass flag in the arch recently? :-) T -- For every argument for something, there is always an equal and opposite argument against it. Debates don't give answers, only wounded or inflated egos. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 26 03:09:38 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:02 2005 Subject: [CF-Devel] Adding New Stuff (again) - Requests and suggestions References: <3EAA13BD.4070404@sonic.net> Message-ID: <19340.1051344578@www60.gmx.net> Mark W. wrote: > > [...] > > Looking at the "what new stuff do you want to see in Crossfire" poll > > at the website, it looks like there is quite a bit of interest in > > seeing new spells, skills, races, and monsters. When I saw that poll I was about to vote for new maps and quests, but that point turned out to be missing somehow. :-) > > [...] it would be helpful if more of the "generic" functionality > > were to be split out of the source code and into configuration files/arches > > [...] > > It depends. I personally don't want a bunch of config files each with a > unique format. However, I do plan to move more of the functionality > to arch's (spell archs as per a mail a few weeks ago). We already have a lot of different file formats. What about including a C XML parser to crossfire? That would allow to have one file format and one parser for all the extra datafiles like for materials, races, skills, or even treasurelists. It would make the movement of data from config- to data-files quite a lot easier, and serves portability. Well, I'm saying this because I actually just done it for the CFJavaEditor as I couldn't stand the growing number of small datafiles, each with different syntax and parser. Especially the big file for type definitions is now Xml (formerly types.txt is now types.xml). That makes it not only better readable, the parser is also validating which means it can tell exact line numbers in case of an error. And it's so easy to add or change things. I know Xml is sort of trendy at the moment and sometimes it gets overrated. In our case though, I believe it's quite ideal: As an open project our data should be consistent, readable, portable and error handling is important - That's exactly what Xml provides. AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 26 03:26:58 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:02 2005 Subject: [CF-Devel] Adding New Stuff (again) - Requests and suggestions In-Reply-To: <200304260110.35514.mail-lists+cfdev@dogphilosophy.net> References: <200304251718.04237.mail-lists+cfdev@dogphilosophy.net> <3EAA13BD.4070404@sonic.net> <200304260110.35514.mail-lists+cfdev@dogphilosophy.net> Message-ID: <3EAA42D2.50807@sonic.net> Flying Pedestrian wrote: > Well, again, that's why I think it'd be nice to have more of the configuration > (particularly, e.g. names of spells and HtH attacks, order of preference > of HtH attacks, 'definitions' of extensions of standard spells, etc., which > currently are "hard-coded" into the source...) Well, that is coming - more of that stuff is moving to archs. However, some bits won't change. Eg, while it may be nice for the search order of the hth attacks to be setable, that seems sort of pointless to me. The player should select the appropriate one. This sort of falls back to request of 'I want to be able to set what food I eat when my food reaches 0'. the code to do that for such a minor convenience makes it a very low priority. > > I think people'd be more likely to try out new things if it just required > adding a bit to a couple of files instead of going through the whole patch, > recompile, reinstall routine. Maybe. It wouldn't hurt - but there has been a lot of customizable stuff there already, and a lot of it doesn't seem to get played with. > Is it also easy to add graphics to the crossfire.0/crossfire.1 files "on the > fly" as well? Also, is it possible to skip adding a new spell name to > the headers and instead just add it to the spell_params file? (I imagine > not, from what I remember of the code...I think it'd be ideal to be > able to add a spell for testing with just an addition to spell_params, an > entry in the archetypes file, and new graphics...) In terms of the image stuff, there is no way to do that right now. The trickier bit here is that images are assigned numbers - I'm pretty sure those numbers have to be contigous. I'm not sure if they have to be in alphabetical order However, at the same time, to rebuild that data is really easy. I can't see that as being much a point to server admins - if they are willing to patch a bunch of files for some change, I can't see it being much a stretch that they couldn't have an arch distribution and do a 'make collect'. > Basically, any spell (for example) that doesn't require new BEHAVIOR (just > different attack types, settings for range, duration, radius, list of possible > creatures summoned, etc.) seemed like it ought to be moved out to the > arch's and spell_params files instead of hard-coded as they are now. See the discussion a few weeks back about spell objects. It didn't addressed summon creatures, but that is probably something that could be included. Note that right now, I think some of the summoning stuff looks at the races to determine what to summon, so for some, just modifying the races file might be enough. > > Similarly, this would affect e.g. pets (as summoning spells improve in > variety, this may become and issue - although again it's more for "color". > ["Your air para-elemental jolts zombie. Your air para-elemental zaps > zombie..."...] it would make sense that a character with a pet wolf or > giant purple vampire frog would see "biting" type messages...or for that > matter a character who gets polymorphed into something else, or when someone > starts adding Were(whatever) races to the game, might end up > seeing that for his own attacks.) Well, for monsters, as said, it doesn't come from attacks. It comes from attack messages. I'd think the code is there to just make up some more messages and assign the appropriate attack message type to the monster arch. > > On the other hand - Karate, for example, doesn't do as much damage as many > melee weapons, but it has a higher "fire" rate. "Biting" would be slower > than "Clawing" but have a substantially (though still reasonable) higher base > damage. Properly constructed, the tradeoffs make for a bit of potential > strategy (Karate is actually pretty handy when you're being mobbed by > large numbers of fast but relatively weak creatures), and another bit of > potential "uniqueness" for characters, without danger of serious imbalance > being added or having the high "barrier to entry" of needing to understand the > crossfire source well enough to code a complex new set of behaviors into the > game. Thats true - if you are fighting a whole bunch of wimpy creatures, faster attacks for less damage would be of some advantage. But otherwise, it is simple math to say 'attacktime * damage = attackfactor'. Eg, if you have something that has an attacktime of 1.0 but does 20 damage, and something that has an attacktime of 2.0 but does 5 damage, still pretty clear that the slower attack that does more damage is better. Unless you are fighting mobs of monsters with low hit points. But I still wonder how many different unarmed attack types you can come up with which are really that different. When do we add kicking and so on? Thus may not seem like a big deal, but right now there are 30+ skills out there. Imagine if it got to the point there was 100. It'd be like the northman now - it wouldn't so much to get rid of it because it was bad, but more because it is redundant. > Actually, I'm glad for that - one "style" of attack at a time is plenty. For > HtH attacks, specifically, the only real purpose would be do add a bit more > color and strategy, and add another potential "uniqueness" to a character > without having to add anything really bizarre or complex. fair enough. But as said, one has to be careful with uniqueness. Otherwise people may just be like 'oh biting. Its basically the same as biting with a different name'. At some level this gets annoying because of your keyboard bindings and what not. > The SKILL being rolled into one actually doesn't seem unreasonable to me, > though you then still have to deal with the messages (or just change them all > to "hit", which is boring...) unarmed combat could have a mixture of messages. kicks, claws, bites, knees, etc. It could actually be a little more colorful because you'd get higher variety. > > Of course, while we're at it, someone could do something about all that silly > redundancy of having daggers, shortswords, longswords, broadswords, sabers, > scimitars, cutlasses, falchions, katanas, and rapiers. After all, they're all > basically just "big knives"... > > (kidding, obviously...I LIKE the "color" and minor differences that having > all of those adds to the game...I think the same can apply to a certain > extent to different "unarmed" attacks as well, though probably not THAT many.) The other difference is that dealing with a bunch of objects is a bit easier than dealing with a bunch of skills. Thats basically just how the game is - this is perhaps largely an interfact issue and may get improved upon (with the change in skill system, each skill will have its own exp bucket, which then means this gets communicated to the client. If the client displays it, might not be unreasonable to switch to that skill if the player clicks on it). Perhaps the bigger issue with skills is that there are some proposals to make learning skills difficult or limiting the number of skills one can learn. In some of these cases, the more marginal skills lose out (if karate and boxing are pretty much the same, why'd you bother to learn both for example, especially if it might cost you to learn something more useful like jeweler (still not one of hte major skills, but still something you might use a bit and not redundant with one of your existing skills) > > On the other hand, having them separate gives some potential to later add > items to the game that enhance a particular attack type ("boots of kicking", > "brass knuckles", "Amulet of the Weapons Master" (boosts Melee Weapons > attacks), "MithrilWhite(tm) Toothpaste" (bite-enhancing "potion"), etc...), > though what little I understand of the existing code makes me think > new code would have to be added to be able to modify the effects (damage, wc, > etc.) of only one type of attack skill at a time... It is somewhat an issue of fluff vs actual usefulness. I can certainly see possibilty to add all sorts of stuff (spiked kneepads, etc). With the new skill system, this may be more possible - it should be possible to have different skills (by name) that do the same functions. So thus, bite, claw, head butt, kicking, etc, could all go into an 'unarmed' skill subtype. > "Sufficiently different" is the part that I understand the least - not that > I don't know why there needs to be differences, but that I'm not quite certain > what constitutes something that would be considered a worthy "difference". It depends on what you are doing. In the case of players, I'd say difference means different in play (eg, human northman issue again - if the only thing different is face and maybe a stat by 1 point of something, that isn't all that different in play). For monsters, this is much more open - IMO, there is a lot of room to add more monsters, because in that case, difference can just be in race. And these can be used as ways for the priests of certain religions to gain exp. I'd say some of it depends on thought process. If you come up with a new monster/class/spell/skill, ask yourself, what does this add to the game? Why are you adding it? > Does it mean that to be "different" there must be a new set of functions in > the source code to handle it?...(Is it, for example, "just another bolt spell" > regardless of other novelty unless it has its own new function? Personally, I > think there's a lot of untapped "uniqueness" potential sitting in the existing > "damage spells" and, perhaps, summoning spells code, waiting for only novel > spell names, graphics, and arches to bring it out...) Certainly not - I think a lot more can be done without code changes. However, at some level, an 'extra large fireball' isn't all that different than what exists now. However, something like 'balls of fire' (like ball lightning) could be different enough. The problem is the question is difficult enough to answer that I can't just provide a 'these are a set of rules, and if you follow them, things will be OK'. My personal thought is that best to drop a mail to the list asking about the conceptual bases. Eg, I have an idea for a new spells that does a, b, c. The enumeration of a, b, c doesnt' have to be in specific at this point, eg, for a new class, you might say 'it would have a bonus to strength, penalty to con, ..' and you wouldn't have to come up with all those details at that point. The other tricky part of this is that adding such things can reduce the uniqueness of others. If you fall by balls of fire example, that sort of reducesthe uniqueness that ball lightning currently has. Maybe that is OK, maybe not. > > Well, I was thinking in terms of what specifically is needed to make a > (whatever) "complete". It's obvious in a lot of cases, but might be helpful > to have noted down explicitly somewhere, e.g. for a new race: > > Either 4 or 8 "facing" graphics (with rare exceptions, e.g. fireborn) > arch for the new race > treasure entry for new race Unfortunately, I don't think all that info has been recorded. However, one can certainly ask 'if I added a new spell, what would have to be done'. and an answer detailing the steps may be forthcoming. But since it may be from peopel's memory, who knows how accurate. > > Anyway, just thinking about trying to offer new things for the game again, > particularly the spells, skills, races, and monsters at the top > of the poll results... Well, as said above, the first step would be a conceptual level (a spell that does X, a class like Z, etc) - post those out and see what people think. If the idea is generally positive, then starting working out details, eg, bonus, damage, starting equipment, etc. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 26 03:59:48 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:03 2005 Subject: [CF-Devel] Map lore redux References: <3EA745B2.4060904@sympatico.ca> Message-ID: <18117.1051347588@www60.gmx.net> I like the lore thing. If I may suggest something: Since these lores are going to appear in books and maybe other places, it might be beneficial to specify which lore relates to which place and is relevant to which player level. I would suggest a syntax like this: (The messages don't really fit together, it's just an example) lore @level 1: Orcs are small greenish monsters. @level 40, lake_country: Deep underground the mountains of lake country dwells a terrible wyrm of chaos. @level 3, scorn: Rumors tell there is a secret passage to port joseph from the prison of scorn. Maybe it's just a drunkard's story... endlore In this way, there could be libraries for example which have books containing information only relevant to players of levels 1-15. A library in lake country could have information about the surrounding areas, but not about pupland for instance. This could help improving the well-known problem about players who don't find suitable maps to play. About map lores: I would put them into the map header. That way, it is clear where to find it and we don't need to have exceptional cases in the object parser. But that's just my opinion. Andreas -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 26 05:02:15 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:03 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) References: <3EA73FC4.60503@sympatico.ca> Message-ID: <17711.1051351335@www60.gmx.net> Todd M. wrote: > > Why working over the materials system is good for game play: > > Cast aside all preconceptions (including the material code which > was recently committed which is being discussed) and consider: > [...] Yes, I can agree with what you said. I didn't mean to argue against the new material system actually - that's quite fine and I do see the benefits. Maybe I'm not fully satisfied with the current implementation, but that's not a big issue so let's cast it aside. What I am primarily concerned about are the effects caused by item deconstruction and especially transmutation (e.g. lead -> gold). Now, you got me with one particular argument pro item-deconstruction: > 3) Part of creating an object on a map consists of picking a > material, assigning an arbirtary value, assigning an arbirtary > weight and putting in a name. There is no consistancy between map > makers so for example if I were to make a gold bar: > I would make it material 1024, guess it has a value of 600 (?), say > it has a weight of 5000 and call it 'gold bar' > You would make a silver bar, assign it material 2 (it holds an edge?), > assign a value of 900 (?) say it has a weight of 300 and call it > silver ingot. > The map maker is expected to understand the values of these fields even > though the values are heavily modified in the game (well value anyway). > Further to this weapon and armour items have more arbitrary fields to > modify their effectiveness and many standard weapon and armour items are > subject to further modification when called into existance (artifact > code). If I understand it correctly, you mainly say the current "value"- system is bad and item value should better be based on materials? That's a good point IMO. Of course it's hard to balance, but maybe easier to balance than the current value system. With item-deconstruction, any item has two values: 1. The item value (= value for selling the item "as is"). 2. The material value (= value after de-constructing the item). > Yes there is also a component of value that is based on the > 'quality' of an object and not on the material alone, but this > is in addition to the material value modifiers and thus there is > no reason value couldn't also modified at this point in an > external system (artifacts file or similar set of lists or > whatever) as well. The item value should always be higher than the material value, except for raw materials and coins/gems for which both values are identical. Assuming that mapmakers are also playing crossfire, it is likely that they will get a feel for material values. They might have an idea what 1 kg of gold is worth, much rather than knowing what "value 1500" means. I'm not sure what you envisioned exactly, but I can see two ways to go which seem interesting: a) Dump "value" fields in the arches, and auto-calculate the item value in the server by summing up bonuses like resistances/damage etc. Item value is then material value + sum of bonuses. b) Leave "value" fields in the arches, calculate: Item value = material value + "value" from the arch So, after all, I can see benefits in item-deconstruction too. However, I think it is very important to plan and implement it carefully. If done wrong it could just as well mess up our economy worse than it is now. To talk about material transmutation: I still think we should not do it. If there are ways to convert lead into gold - no matter what or how - that is definitly going to screw economy. AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 26 11:03:26 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:03 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <17711.1051351335@www60.gmx.net> Message-ID: On 26-Apr-03 Andreas Vogl wrote: > a) Dump "value" fields in the arches, and auto-calculate > the item value in the server by summing up bonuses > like resistances/damage etc. > Item value is then material value + sum of bonuses. I've considered this on occasion. My thought was to assign a value per kg for various materials. Say gold, which we allready know has a value:weight ratio of 1:1 (from the coin). You start there and add or subtract based on craftsmanship, bonuses, etc. Interestingly however.. gold nuggets don't share this same ratio. Large nuggets are 100:180, small are 10:20. Perhaps this means that the value multiplier for a gold item is just too small, and should be increased.. But that too has an effect, namely when you sell a gold plate mail. However.. I know that the concept of taking a gold platemail and breaking it down into raw gold, that may have a value of say 100 times that of the platemail is intimidating to people, but I think you are missing a matter of scale here. Lets say I go to the titan's quest, and I clear out one of the lower levels, and get bored. In my boredom, I decide to pile everything I find up, and cast alchemy, turning it into nuggets. Generally, if I do this, I can get about 5000 large nuggets (sometimes many many more) by doing the first few levels. It doesn't even take very long. Heck.. I can just summon lots of vampires and issue killpets if I really am bored. Compared to this, deconstructing the occasional gold platemail is pretty tame. I'm saying.. the economy is such a joke.. that even if we charged nothing for deconstruction, and performed it at a 1:1 weight ratio, it would still have zero impact on the raw currency flow. The currency flow is so rediculous that it doesn't even show up on the radar. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 26 11:24:40 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:03 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <17711.1051351335@www60.gmx.net> References: <3EA73FC4.60503@sympatico.ca> <17711.1051351335@www60.gmx.net> Message-ID: <3EAAB2C8.9060301@sympatico.ca> >Yes, I can agree with what you said. I didn't mean to argue against >the new material system actually - that's quite fine and I do see >the benefits. >Maybe I'm not fully satisfied with the current implementation, >but that's not a big issue so let's cast it aside. > No explanation necessary. It's a proper question to ask what this would do for the game. Since I brought it up, it is my duty to attempt to argue why something should be done differently rather than your duty to justify not doing it. > >What I am primarily concerned about are the effects caused by item >deconstruction and especially transmutation (e.g. lead -> gold). > >Now, you got me with one particular argument >pro item-deconstruction: > > > >>3) Part of creating an object on a map consists of picking a >>material, assigning an arbirtary value, assigning an arbirtary >>weight and putting in a name. There is no consistancy between map >>makers so for example if I were to make a gold bar: >>I would make it material 1024, guess it has a value of 600 (?), say >>it has a weight of 5000 and call it 'gold bar' >>You would make a silver bar, assign it material 2 (it holds an edge?), >>assign a value of 900 (?) say it has a weight of 300 and call it >>silver ingot. >>The map maker is expected to understand the values of these fields even >>though the values are heavily modified in the game (well value anyway). >>Further to this weapon and armour items have more arbitrary fields to >>modify their effectiveness and many standard weapon and armour items are >>subject to further modification when called into existance (artifact >>code). >> >> > >If I understand it correctly, you mainly say the current "value"- >system is bad and item value should better be based on materials? > Not exactly, what I am saying is that if the material component of an item is tied to material + weight, there is *less* to mess up when assigning values. It also speaks to standardizing arches a little bit (especially if there is a way to specify a random list of materials as a material or otherwise invoke variations on an arch on a map without requiring a arch as a template) since you could make more use of generic arches (chainmail rather than mithril mail, iron mail - or nugget rather than gold nugget, iron nugget, silver nugget.) It's more Platonic. This doesn't really change how value works however, I don't think there is a need to mess with the value system itself. >That's a good point IMO. Of course it's hard to balance, but maybe >easier to balance than the current value system. > >With item-deconstruction, any item has two values: >1. The item value (= value for selling the item "as is"). >2. The material value (= value after de-constructing the item). > > > >>Yes there is also a component of value that is based on the >>'quality' of an object and not on the material alone, but this >>is in addition to the material value modifiers and thus there is >>no reason value couldn't also modified at this point in an >>external system (artifacts file or similar set of lists or >>whatever) as well. >> >> > >The item value should always be higher than the >material value, except for raw materials and coins/gems for >which both values are identical. > Yes, but actually the intrinsic value should be stated while the material and weight would comprise the rest of the value. I am not going to speak to coinage at this time since that is a special case and there is special code for money, but otherwise yes, an arch like an ingot would have a low or zero value prior to applying the material value while an arch like flawless diamond or worked metal object would have a high value prior to the material value. >Assuming that mapmakers are also playing crossfire, it is >likely that they will get a feel for material values. >They might have an idea what 1 kg of gold is worth, >much rather than knowing what "value 1500" means. > >I'm not sure what you envisioned exactly, but I can >see two ways to go which seem interesting: > >a) Dump "value" fields in the arches, and auto-calculate > the item value in the server by summing up bonuses > like resistances/damage etc. > Item value is then material value + sum of bonuses. > >b) Leave "value" fields in the arches, calculate: > Item value = material value + "value" from the arch > > I thought that I was being clearer than that... The second one is the idea I was intending to portray and I believe the way it works in Tim's code. (or should work if the thing Mark mentioned about why it doesn't is ironed out). Mapmakers can of course change the value field and will do so based on experience, but the portion of value that comes from a material's intrinsic value (if the item was broken down) can be applied automatically. You would still have a base value in the arch, but it would save the fiddling required when you sub class the arch on a map to make a ruby dagger as opposed to a iron one. Also it will standardize values somewhat since the modification to the value I would have made in the above case is not likely the same as the one you would have made on a different map. This would not prevent you at all from also modifying the value field further however if you felt it should be a particularily nice ruby dagger. As for adding value by other things like bonuses and such - I never thought much about it. I mentioned the materials since it is already mostly implemented. > >So, after all, I can see benefits in item-deconstruction >too. However, I think it is very important to plan and >implement it carefully. >If done wrong it could just as well mess up our economy >worse than it is now. > >To talk about material transmutation: I still think >we should not do it. If there are ways to convert >lead into gold - no matter what or how - that is definitly >going to screw economy. > > Well if there is a marerials field to be manipulated I think you will see transmutation occuring and I believe this is a good thing. Now as to transmuting lead to gold specifically - yes this sort of thing can't be let loose without great care, but transmutation equally applies to changing between all the other materials too, most of which would not impact economy or even some that would improve it. I never had the idea that lead to gold should be a street corner thing, (it could perhaps be assigned as possible only with a unique item called the 'philosopher's stone', or perhaps not at all). But since this covers such things as turning iron to tin and diamonds to glass, I think it is like throwing the baby out with the bath water to say no transmutation unilaterally. Again I'm not speaking of 'transmutation' the spell or any such powerful skill, just a term for when the material field is changed using code and an object gains a new set of modifiers (maybe properties?) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 26 11:52:31 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:03 2005 Subject: [CF-Devel] Map lore redux In-Reply-To: <18117.1051347588@www60.gmx.net> References: <3EA745B2.4060904@sympatico.ca> <18117.1051347588@www60.gmx.net> Message-ID: <3EAAB94F.6030007@sympatico.ca> Andreas Vogl wrote: >I like the lore thing. > >If I may suggest something: >Since these lores are going to appear in books and maybe >other places, it might be beneficial to specify >which lore relates to which place and is relevant to which >player level. > >I would suggest a syntax like this: >(The messages don't really fit together, it's just an example) > > lore > @level 1: > Orcs are small greenish monsters. > @level 40, lake_country: > Deep underground the mountains of lake country > dwells a terrible wyrm of chaos. > @level 3, scorn: > Rumors tell there is a secret passage to port joseph > from the prison of scorn. Maybe it's just a drunkard's > story... > endlore > >In this way, there could be libraries for example which have >books containing information only relevant to players of >levels 1-15. >A library in lake country could have information about >the surrounding areas, but not about pupland for instance. > The name field in the arch is captured too, so if you wanted to put some lore on you map containing the 'terrible chaos wyrn' you would slap the lore arch on the map, change the name field to a key phrase such as 'deep under lake county'. As you describe, it would be nice to possibly have more than one level of key word and use some other fields too. I would like to keep the lore standard across map and arch but no reason not to have extra fields available for map lore- like area or level (but did you read the talk about weighting lore?) which is why I am still pondering and not really doing anything yet. > >This could help improving the well-known problem about >players who don't find suitable maps to play. > That's the idea, the other main point is to make the information modular so that if a map is removed - so is the lore. This is why I am pushing to store it in the maps (and the arches for item lore) and not in a message file even though it gets collected anyway. > > >About map lores: I would put them into the map header. >That way, it is clear where to find it and we don't need >to have exceptional cases in the object parser. >But that's just my opinion. > > >Andreas > > > I can see Mark's point of not wanting to add more fields into the map header, and actually now like the idea of using an arch so that you can put as many 'lore points' as you need in a single map. As for collecting this - I do think it would be better done by reading through the map files and generating a repository file like in the script I posted than by reading iit in from a map header with a parser in the server when the maps are loaded. That being said however, I was thinking I should do this collection script as either a DM command or triggered event using the Python plugin. It is real easy to do this sort of thing in Python so I don't really worry about collection process. Now having a solid lore data type is a good idea however and worth hammering out. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 26 14:54:27 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:03 2005 Subject: [CF-Devel] Issues I'de like to bring up Message-ID: <1051386869.8388.229.camel@localhost.localdomain> Introduction ------------ Hello all, some notes about my system before I go on. I use Linux and the GTK client under GNOME. I'de like to break this email into 3 parts game design, map design and client design. Game design in this email is in regard to the game itself, the features, monsters, spells, etc. the map design is in regard to the world we play in, the cities, the individual maps, etc. and the client design is the gtk client itself. Game Design ----------- Overall its a fun game to play. There are a lot of things to learn and do, feature wise there are a ton. my biggest concern with this is the XP you loose when you die compared to the XP you gain when you kill a monster. From what I understand you loose 20% or 3 levels when you die, which ever is less. So if a small piddly monster kills me say I loose 3 levels, but if I kill it I get maybe 1000 XP. Not quite even. If I kill a dragon I get so 100K XP but if it kills me I loose 3 level, not quite even as well. Now when I loose the 3 levels, it might no sound so bad, 3 overall levels isn't *that* big a deal, but in the process I also loose (most times more than 3) specific levels. Regaining the levels lost can take days, just to be able to retry and kill the monster that killed me in the first place. I understand that there should be a bigger penalty for dieing than for killing the monster, its a reason to just die all the time. I think there is a fairer way to do this though that is more proportional to each monsters strength - if killing a monster gives you N XP points, then being killed by the monster takes N*5 XP away from you. That being said, if I was using a magic skill when I die, they should all come out of magic, etc. just like when I kill it they would all goto magic. Map Design ---------- Generally speaking the game allows for a lot of unique things to be done in the maps, most of which have been done already, I'm sure. My issue is with the current maps I've seen. There is no real progression threw "easy" "medium" and "hard" types of maps. By this I mean: I'm a level 19 overall player, most in magic. I can complete most maps in Scorn rather easily, I can also defeat raffle 1, but once I venture out most of the other maps I die in about 30 sec. of entering. An idea I've been tossing around in my head that I think would solve the problem requires a complete world re-design. Its basically as follows: 1) Have 4 major cities a) levels 0-10 b) levels 11-20 c) levels 20-50 d) levels 51+ 2) City one (the city all players start in - like Scorn) you can leave this city, just like now, when you buy a pass, but to enter any of the other 3 major cities you would need the pass + be within or above the level range for that city. 3) Any levels (caves, mountains, forest, towers, runes, other cities, etc.) outside the 4 major cities should have a sign explaining what level the map/area is. This could be a sign saying "Levels 10+" or "Powerful beings only" etc. but as they are out of the 4 major cities, any level player should be aloud to go into then regardless. 4) Anytime that there is a quest, riddle, etc. to solve, PLEASE make sure that any idiot can figure it out. A prefect example of what not to do is Red Islands (or what ever it is called). Myself and 2 other players were there for 4 days - in real life - trying to figure it out. The only reason we got threw is someone else told us the passwords. I think with this design, you get a nice progression of things do to as you gain in levels. It also gives new areas to explore that you would never have seen before. And it still leaves surprise areas (outside of the 4 major cities) for very difficult or mix and match levels. The last thing I want to mention is a very specific point. Every now and again one player just pisses you off, beyond all. It would be nice if players had the option to turn off the safeties in the arena. Client Design ------------- I use the GTK client - and like its functionality. There really isn't anything wrong with it. Though I think look and feel wise you may get more players if it was a fully graphical, full screen, client. This would be a major coding project and probably not be something a single person could do. Closing ------- Thanks for reading all this, I'll be waiting for replies and the conversation this email will hopefully bring. Justin Zaun metalforge server (jgz) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 26 15:35:28 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:03 2005 Subject: [CF-Devel] Adding New Stuff (again) - Requests and suggestions In-Reply-To: <3EAA42D2.50807@sonic.net> References: <200304251718.04237.mail-lists+cfdev@dogphilosophy.net> <200304260110.35514.mail-lists+cfdev@dogphilosophy.net> <3EAA42D2.50807@sonic.net> Message-ID: <200304261435.28116.mail-lists+cfdev@dogphilosophy.net> On Saturday 26 April 2003 02:26 am, Mark Wedel wrote: > However, some bits won't change. Eg, while it may be nice for the search > order of the hth attacks to be setable, that seems sort of pointless to me. > The player should select the appropriate one. This sort of falls back to > request of 'I want to be able to set what food I eat when my food reaches > 0'. the code to do that for such a minor convenience makes it a very low > priority. Really the only reason "order of attacks" comes into it at all for me is that it's something that MUST be there(?) and MUST be edited in the source code (and recompiled) - if it just automatically got added to the bottom of the list if it wasn't hard-coded, that'd work too...but see below... > Maybe. It wouldn't hurt - but there has been a lot of customizable stuff > there already, and a lot of it doesn't seem to get played with. Smells like a new poll topic - "Which customizable feature are you least likely to play with? 1)(whatever) 2)(whatever) 3)What customizable features? (etc.)...." > In terms of the image stuff, there is no way to do that right now. The > trickier bit here is that images are assigned numbers - I'm pretty sure > those numbers have to be contigous. I'm not sure if they have to be in > alphabetical order > > However, at the same time, to rebuild that data is really easy. I can't > see that as being much a point to server admins - if they are willing to > patch a bunch of files for some change, I can't see it being much a stretch > that they couldn't have an arch distribution and do a 'make collect'. Okay - that's not much more complex than "cat newtreasures >> treasures" so that takes care of my concern there, too, since it doesn't actually require a complete recompile. > See the discussion a few weeks back about spell objects. It didn't > addressed summon creatures, but that is probably something that could be > included. Okay, went back and found it...and the short discussion hits pretty much EVERYTHING that I was wanting, (including supporting "negative damage" to cause healing effects.) Two additional minor suggestions there - support for a "resistance" allowing a character to be healed by a damagetype (only if the >100% resistance comes from ONE object) - e.g. Fireborns might have a 105% resistance to fire, thus being healed at a rate of 1/20th of the damage that would have been done by fire (might be possible to extend this to allow characters/monsters to recharge mana/grace from particular types of attacks as well.) > Note that right now, I think some of the summoning stuff looks at the > races to determine what to summon, so for some, just modifying the races > file might be enough. That would be ideal, in my opinion. Making a new summoning spell would then just mean adding the pointer to the appropriate race/caster's level entry in the file. > Thats true - if you are fighting a whole bunch of wimpy creatures, faster > attacks for less damage would be of some advantage. > > But otherwise, it is simple math to say 'attacktime * damage = > attackfactor'. Eg, if you have something that has an attacktime of 1.0 but > does 20 damage, and something that has an attacktime of 2.0 but does 5 > damage, still pretty clear that the slower attack that does more damage is > better. Unless you are fighting mobs of monsters with low hit points. If I wanted to play with a calculator instead of playing the game I'd be playing on a MUD or something :-) > But I still wonder how many different unarmed attack types you can come > up with which are really that different. When do we add kicking and so on? > > Thus may not seem like a big deal, but right now there are 30+ skills out > there. Imagine if it got to the point there was 100. It'd be like the > northman now - it wouldn't so much to get rid of it because it was bad, but > more because it is redundant. [...] > unarmed combat could have a mixture of messages. kicks, claws, bites, > knees, etc. It could actually be a little more colorful because you'd get > higher variety. This is true, and actually I could see re-simplifying and reorganizing unarmed combat into a smaller subset - "humanoid unarmed" (punching, wrestling, karate) and "animal unarmed" (biting and clawing and trampling). Point both the skills and abilities at the same two attackmessages tables and you're done...cuts down the redundant message tables and "non-weapon attacks" while keeping a rational division between the types. Rough difference would be humanoid combat = faster but lower damage, animal combat=slower but higher damage ("base" values). [...] > Perhaps the bigger issue with skills is that there are some proposals to > make learning skills difficult or limiting the number of skills one can > learn. In some of these cases, the more marginal skills lose out (if > karate and boxing are pretty much the same, why'd you bother to learn both > for example, especially if it might cost you to learn something more useful > like jeweler (still not one of hte major skills, but still something you > might use a bit and not redundant with one of your existing skills) I can see the point there. "Collapsing" the unarmed combat into 2 or 3, more rationally-delineated categories (rather than the 5? 6? that currently exist or "would make sense to exist given the current breakdown") would solve that. > > On the other hand, having them separate gives some potential to later add > > items to the game that enhance a particular attack type ("boots of > > kicking", "brass knuckles", "Amulet of the Weapons Master" (boosts Melee > > Weapons attacks), "MithrilWhite(tm) Toothpaste" (bite-enhancing > > "potion"), etc...), though what little I understand of the existing code > > makes me think new code would have to be added to be able to modify the > > effects (damage, wc, etc.) of only one type of attack skill at a time... > > It is somewhat an issue of fluff vs actual usefulness. I can certainly > see possibilty to add all sorts of stuff (spiked kneepads, etc). It it any more "fluff vs actual usefulness" than having amulets (ac+1), rings(ac+1), and bracers(ac+1) all existing at the same time?... I wouldn't want to go TOO overboard - do we really need to add a "knee" or leg bodypart (in addition to the existing "feet")? But, a BIT more potential variety here doesn't seem any more redudant than having 10 different versions of "big knives" in melee weapons (or, really, more like 80, factoring the new materials code [which, as I mentioned before, I actually DO like]), or 6-8 different versions of "spell-casting guy" classes... > In the case of players, I'd say difference means different in play (eg, > human northman issue again - if the only thing different is face and maybe > a stat by 1 point of something, that isn't all that different in play). [...] > I'd say some of it depends on thought process. If you come up with a new > monster/class/spell/skill, ask yourself, what does this add to the game? > Why are you adding it? THIS I completely understand and agree with. I'm more wondering, for example, where the line for "many smaller differences" or "a few larger differences" crosses the point where someone else might find it worth trying out... I tend to want to design new things as ideas strike me and on those occasions where I have a small amount of spare time to work on them...rather than having an idea and waiting for an email committee to re-design it for me (and then waiting for the NEXT batch of spare time to arise) before I actually try to implement it :-) so it would be helpful to be able to at least make a reasonable guess as to whether or not a new race/item/spell/whatever is "different enough" before spending much time on it (either in implementation or waiting on the aforementioned email committee...) > Certainly not - I think a lot more can be done without code changes. > However, at some level, an 'extra large fireball' isn't all that different > than what exists now. However, something like 'balls of fire' (like ball > lightning) could be different enough. > > The problem is the question is difficult enough to answer that I can't > just provide a 'these are a set of rules, and if you follow them, things > will be OK'. My personal thought is that best to drop a mail to the list > asking about the conceptual bases. Eg, I have an idea for a new spells > that does a, b, c. The enumeration of a, b, c doesnt' have to be in > specific at this point, eg, for a new class, you might say 'it would have a > bonus to strength, penalty to con, ..' and you wouldn't have to come up > with all those details at that point. Well, actually I WOULD, since what I'm thinking of is actually doing the work of putting the ideas into practice, rather than "Hey, I have this great idea, why don't you developers get to work implementing it for me" :-) (I actually think there are more than enough classes already, so that's not specifically an issue. Races and spells (and cults and quests which can be built with and around them...if/when I finally get time to figure out map-making) are where I'm thinking at the moment. > The other tricky part of this is that adding such things can reduce the > uniqueness of others. If you fall by balls of fire example, that sort of > reducesthe uniqueness that ball lightning currently has. Maybe that is OK, > maybe not. This make sense if the only thing different about the new spell is damage type and the color of the graphic. On the other hand, one might use exactly (? haven't looked to see if this would work yet) the "ball lightning" routine with a different arch and graphic (as examples off the top of my overstressed head): attacktype - confusion and depletion damage - low arch - slow-moving, medium duration Voila' - the "Phantasmal Molester" spell... (or something of the sort). Change to medium speed arch, physical and magic attacktype and an animated graphic of a hyperactive kitten and you have "Summon Playful Annihilator"... Looking at the "technical" descriptions - "It's just ball lightning with different speeds, graphics, and attacktypes. That's not very different.".... In PLAY they probably wouldn't SEEM anything like ball lightning at all, though. (AND, if I am correct that the existing ball-lightning code needs only a little easy modification (or better still, none at all) to be adapted for this, I am capable of putting out the finished "products" myself without pestering official developers to stop what they're doing and get them working for me...) > Unfortunately, I don't think all that info has been recorded. > > However, one can certainly ask 'if I added a new spell, what would have > to be done'. and an answer detailing the steps may be forthcoming. But > since it may be from people's memory, who knows how accurate. Ah, got it - the information's not written down because nobody's completely sure what it is :-) Fortunately, it looks like in MOST cases it's not too tough to work out. I'm hoping other people will jump into the discussion here, too, so it doesn't look so much like I'm pestering you personally... Where DO all of you tend to draw the line at what makes something "different enough" to be worth possibly including?... _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 26 15:35:50 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:03 2005 Subject: [CF-Devel] Adding New Stuff (again) - Requests and suggestions In-Reply-To: <19340.1051344578@www60.gmx.net> References: <3EAA13BD.4070404@sonic.net> <19340.1051344578@www60.gmx.net> Message-ID: <200304261435.50406.mail-lists+cfdev@dogphilosophy.net> On Saturday 26 April 2003 02:09 am, Andreas Vogl wrote: > Mark W. wrote: > > > [...] > > > Looking at the "what new stuff do you want to see in Crossfire" poll > > > at the website, it looks like there is quite a bit of interest in > > > seeing new spells, skills, races, and monsters. > > When I saw that poll I was about to vote for new maps and > quests, but that point turned out to be missing somehow. :-) Good point - I noticed "completing the quests" was a big hit on the "what do you like to do" poll. It's one of the factors I'm taking into account as well - new spells, races, monsters, cults, and items are all useful "building blocks" for later constructing new quests. Similarly, small new components can contribute directly to the other two favorite things - "Building a unique character" and "finding neat and powerful items"... A could imagine a whole collection of "college(s) of magic" (akin to the existing "tower of demonology" quest), each of which involves a series of "prerequisite" tasks to go through (and fees to pay :-)) which lead through learning a series of the particular college's rare and/or unique (i.e. not available in random books) spells...but in order for someone to work on the quests, the spells will have to be available to use... Similarly, a "City Of The [new race]" would require the new race to exist first... MY problem is that I don't have the "chunks" of time available to try to plan out and implement maps and characters and quests to go with all of the smaller components (that I DO have time to work on), but I'd like to contribute nonetheless... _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 26 16:05:32 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:03 2005 Subject: [CF-Devel] Translation request Message-ID: <3EAAF49C.7040404@sympatico.ca> Does any one know what *brefjell* actually means? I would like to fix the image in the classic set since it looks odd in the hall of selection. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 26 16:58:20 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:03 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <3EAAB2C8.9060301@sympatico.ca> References: <3EA73FC4.60503@sympatico.ca> <17711.1051351335@www60.gmx.net> <3EAAB2C8.9060301@sympatico.ca> Message-ID: <3EAB00FC.3070500@sonic.net> A few quick notes: The idea of the material having a value/gram field is interesting. My personal thought is that while automating pieces is good, having base or some other value in the arch is also good. I think my item_power calculation code shows that having the program try to figure 'values' is tricky. I note you also get an odd case. For example, plate mail normally weights 100 kg. Plate mail that weights 60 kg, under the above system, would arguably be worth less if made of the same material. But the fact it is lighter means it is actually more valuable to the player. So if we suppose we have mithril which is half the weight of iron, its value has to be more than twice the value of iron just to stay even when you sell it - really, its value would have to like 4 or 6 times iron, or maybe more. This is just a note, not any big issue in I see doing it. That said, for value calculations, I wonder if a simple addition of 'value of crafted plate armor' + 'value of 50 kg of mithril' is the right approach. In reality, it is the combination of these two that would make mithril plate really valuable. This might just be an issue of proper tuning. As for transmutation - I agree that some automatic transmutation should be allowed (eg, program decids to make this set of plate out of bronze). I just think the number of items made of the non default material should be quite small in most cases (5%?) This could also be more an issue of balance. For example, if steel is lighter and doesn't cost much more than iron, then everyone that could in the would make their objects from steel and not iron. Maybe the exact percentages depends on the material - maybe iron is available in some part of the world, so they use bronze instead (best available material that is readily available). In this case, 90+% of the objects of that class would be of iron or bronze. Mostly, I'd like to make stuff appearing of alternative materials rare enough to be somewhat noteworthy - this IMO adds more interest (wow, a bamboo arrow - haven't seen those before). If after you clear out the newbie tower you have already seen most of the different material types in the game, it just isn't that interesting. Also, by doing this, you reduce the clutter in the inventory. For example, if an object is amde of the 'default' material we don't change the name, and only include the material in the name of the object is non default, inventory is a lot cleaner and you won't have 15 different types of clubs in your inventory. as for player controlled transmutation (via spells or objects), this probably isn't that great an idea. Alchemy ws added quite a while ago and predates this new code of course. But the reason I say that transmutation is generally bad is that it would sort of seem to defeat the purpose. If I need bronze for an object I'm making, but I can just convert that copper armor to bronze via some spell, one sort of has to ask what is the point? Why not just have the shops sell blocks of bronze, gold, brass, iron, etc in that case? If the idea is that players are supposed to hunt/find the materials, just allowing them to convert from one to another doesn't seem to be much a point. OTOH, I am a bit concerned about the need for different materials and how they show up. Eg, suppose I need bronze for soemthing I want to build, but don't have any, and no shop has any. Well, I should go to a map where a lot of items show up, knowing some might be bronze. And if what I'm really focusing on right now is making that item, I might as well choose an easy dungeon where I can get a lot more stuf quickly, eg, newbie tower, goblin quest, etc. This probably isn't good if I'm high level - clearing out low level dungeons so that others can't play them (or worse than that - killing everything, but leaving most of the treasure behind). But I don't actually have a good solution to that. As far as the economy - making the argument that it is fundamentally broken so that if I break it more doesn't seem like a good arguement to me - it just means it is even harder to fix it down the road, if so desired. That said, I don't expect the over economy problem to get fixed by this code, but I don't think we should break it even more - we should at least try to improve it some. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 26 17:13:09 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:03 2005 Subject: [CF-Devel] Map lore redux In-Reply-To: <3EAAB94F.6030007@sympatico.ca> References: <3EA745B2.4060904@sympatico.ca> <18117.1051347588@www60.gmx.net> <3EAAB94F.6030007@sympatico.ca> Message-ID: <3EAB0475.8080400@sonic.net> Adding it to the map header may not be terrible. My one concern about adding it as an object within the map is for people down the road that might edit that map - how are they supposed to find where that lore object is? that also said, it wouldn't be hard to write/modify a script that looks for a lore/endlore field in the map header, and if it finds out, formulates the lore object around it. I agree that have location tags for the lore isn't a bad idea. It has long since been mentioned that there should be different regions in crossfire - this would at least be a start. for this to work, the different region names would have to be agreed upon - otherwise, map makers and others could use different names that don't match up in their lore fields. As for level info or lore: I'm still undecided if level is best, or if a weighted value is best. Eg, that info about a wyrm under a mountain, may appear 1% of the time in most any library, but 'better' libraries are more likely to have that piece of info. Eg, if you have something like: lore @chance 40: Orcs are small greenish monsters. @chance 30, scorn: Rumors tell there is a secret passage to port joseph from the prison of scorn. Maybe it's just a drunkard's story... @chance 2, lake_country: Deep underground the mountains of lake country dwells a terrible wyrm of chaos. endlore The total probability is 72. 40/72 woudl be the first entry, 30/72 would be the second, 2/72 would be the third. However, the 'level' of the library gets added. So if the library is level 10 lets say, we roll the d72, add 10, and if val > 72, val=72. Thus, the first entry is less likely to show up, and the last one is more likely show up. But this may not be really good - so including absolute level could also work. As said, I'm undecided. But in the above method, a gem of knowledge could occasionally show up in a low level library. This might add some interest/intrigue (oh, I remember seeing something about a wyrm in lake country a long time ago in some library). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 26 17:31:00 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:03 2005 Subject: [CF-Devel] Adding New Stuff (again) - Requests and suggestions In-Reply-To: <200304261435.28116.mail-lists+cfdev@dogphilosophy.net> References: <200304251718.04237.mail-lists+cfdev@dogphilosophy.net> <200304260110.35514.mail-lists+cfdev@dogphilosophy.net> <3EAA42D2.50807@sonic.net> <200304261435.28116.mail-lists+cfdev@dogphilosophy.net> Message-ID: <3EAB08A4.4000008@sonic.net> Flying Pedestrian wrote: > On Saturday 26 April 2003 02:26 am, Mark Wedel wrote: > Okay - that's not much more complex than "cat newtreasures >> treasures" so > that takes care of my concern there, too, since it doesn't actually require > a complete recompile. Even a recompile isn't that big a deal. The big deal with source code changes is it is much more likely to not patch correctly or whatnot - you are requiring that the server have roughly the same version as you patched against. That is not always true. > > Two additional minor suggestions there - support for a "resistance" allowing > a character to be healed by a damagetype (only if the >100% resistance comes > from ONE object) - e.g. Fireborns might have a 105% resistance to fire, thus > being healed at a rate of 1/20th of the damage that would have been done by > fire (might be possible to extend this to allow characters/monsters to > recharge mana/grace from particular types of attacks as well.) resistance above 100 isn't really supported. Its a nice idea, but I also wonder about balance issue (fireborn now less dependent on a cleric for example - he fireballs himeself - not only does he kill the monsters around him, but he gets healed). > If I wanted to play with a calculator instead of playing the game I'd be > playing on a MUD or something :-) > But at some level, everyone still does comparision (this armor gives me more protection, but I move slower, etc). And for most, one can compare weapons pretty easily and figure out what is best. I'd note that under the new skill system I am working on, this will likely be more an issue - each skill has its own level - no more categories. So if you started with punching, and got to level 5 in it, and then learned karate, most likely that punching is going to be a lot better than that karate because of the extra levels you have. So it is more likely you'd stick with what you learned first. Now if 1st level karate is better than 5th level punching, that has soem other issues. > This is true, and actually I could see re-simplifying and reorganizing unarmed > combat into a smaller subset - "humanoid unarmed" (punching, wrestling, > karate) and "animal unarmed" (biting and clawing and trampling). Point both > the skills and abilities at the same two attackmessages tables and you're > done...cuts down the redundant message tables and "non-weapon attacks" while > keeping a rational division between the types. Rough difference would be > humanoid combat = faster but lower damage, animal combat=slower but higher > damage ("base" values). Probably the only people that really use the unarmed attacks at all are those with no choice (weapon prohibition). >> I'd say some of it depends on thought process. If you come up with a new >>monster/class/spell/skill, ask yourself, what does this add to the game? >>Why are you adding it? > > > THIS I completely understand and agree with. I'm more wondering, for example, > where the line for "many smaller differences" or "a few larger differences" > crosses the point where someone else might find it worth trying out... I can't really answer that point. I know when peterm added beholder to his server (as a race) it was fairly popular. I'd think that most new features will at least get tried out, because the players are curious. However, it is certainly possible that they try out a new feature, say 'this sucks', and then never use it again. OTOH, one has to be careful - if each new feature is better than what is there before, you get power migration. > > I tend to want to design new things as ideas strike me and on those occasions > where I have a small amount of spare time to work on them...rather than > having an idea and waiting for an email committee to re-design it for me (and > then waiting for the NEXT batch of spare time to arise) before I actually try > to implement it :-) so it would be helpful to be able to at least make a > reasonable guess as to whether or not a new race/item/spell/whatever is > "different enough" before spending much time on it (either in implementation > or waiting on the aforementioned email committee...) I can understand that - people want to do whatever now, and not wait. My solution to that is to post out my ideas long before I'm likely to have time to work on them. But that said, I don't think the information is out there right now to really say 'that would be a good feature' or 'that would be a bad feature' based simply on stat/damage/whatever. The other thought is to try to talk to people on irc - that at least might give some immediate feedback if people think it is a reasonable idea or not. > > (I actually think there are more than enough classes already, so that's > not specifically an issue. Races and spells (and cults and quests which > can be built with and around them...if/when I finally get time to figure out > map-making) are where I'm thinking at the moment. IMO, more maps would probably be one of the higher priority items. There isn't a lot missing in terms of 'wouldn't it be nice if this skill/spell/race' existed. And likewise, there are tons of items. OTOH, if you have a new idea like 'heres a neat new skill', that'd be cool. Just because I can't envision them doesn't mean there aren't things to be done there. Its just that I don't see anything that is really lacking. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sat Apr 26 17:55:20 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:04 2005 Subject: [CF-Devel] Issues I'de like to bring up In-Reply-To: <1051386869.8388.229.camel@localhost.localdomain> References: <1051386869.8388.229.camel@localhost.localdomain> Message-ID: <3EAB0E58.2030108@sonic.net> Justin Zaun wrote: > Game Design > ----------- > Overall its a fun game to play. There are a lot of things to learn and > do, feature wise there are a ton. my biggest concern with this is the XP > you loose when you die compared to the XP you gain when you kill a > monster. From what I understand you loose 20% or 3 levels when you die, > which ever is less. So if a small piddly monster kills me say I loose 3 > levels, but if I kill it I get maybe 1000 XP. Not quite even. If I kill > a dragon I get so 100K XP but if it kills me I loose 3 level, not quite > even as well. Now when I loose the 3 levels, it might no sound so bad, 3 > overall levels isn't *that* big a deal, but in the process I also loose > (most times more than 3) specific levels. Regaining the levels lost can > take days, just to be able to retry and kill the monster that killed me > in the first place. > > I understand that there should be a bigger penalty for dieing than for > killing the monster, its a reason to just die all the time. I think > there is a fairer way to do this though that is more proportional to > each monsters strength - if killing a monster gives you N XP points, > then being killed by the monster takes N*5 XP away from you. That being > said, if I was using a magic skill when I die, they should all come out > of magic, etc. just like when I kill it they would all goto magic. In practice, you should never lose more than 3 specific levels of skill, but that might be broken. It should hopefully get fixed up in the new skill code I'm working on (one big difference is skill exp no longer has to match your total exp like it does now). That said, I think trying to tie death penalty to what killed you is difficult. If you kill yourself with a fireball, what should you lose? Suppose for an example, you wander into a room, the titan there lighting bolt zaps you, so you quickly get out of that room, but due to being weakened, get killed by some other monster? In a sense, it is the titan that killed you. Also, in an even simpler case, maybe you get killed by something you had no chance defeating. One could make the case that your exp loss being at all related to that is excessive. Note that I'm not saying the players here will somehow manipulate how they die (as if you can do that, you can probably save yourself). Its just basing exp loss on what actually killed you may not be a lot better. the problem is that the experience table is not consistent. At low levels, it is exponential - if your level 8 and have 250,000 exp, you need 500,000 (total) for next level. Worse case is you lose 20%, or about half a level. However, the gap from level 20->21 is 8400000 to 9300000 (900,000 gap, but 20% of 930,000 is 1.86 mil, so about 2 levels). And as more levels pass, the higher ratio, which is why there is a 3 level cap. At level 60, that 3 level cap means you only really lose 6% of your exp. One thought I immediately have to to extend the logic some, like least of the three: 20% of your exp 3 levels 10% of your levels (round down, min of 1). Thus at level 19, you'd lose at most one level (really, 1.99999 if your 1 exp from your next level - maybe this should also be fixed). In the low 20's level range, your caught in that portion of 3 levels and 20% is about the same thing, and both are quite harsh. OTOH, death is meant to be somewhat harsh. If it became 'oh I died. Lost 15 minutes of play', that is also sort of pointless. > > > Map Design > ---------- > Generally speaking the game allows for a lot of unique things to be done > in the maps, most of which have been done already, I'm sure. My issue is > with the current maps I've seen. There is no real progression threw > "easy" "medium" and "hard" types of maps. By this I mean: I'm a level 19 > overall player, most in magic. I can complete most maps in Scorn rather > easily, I can also defeat raffle 1, but once I venture out most of the > other maps I die in about 30 sec. of entering. An idea I've been tossing > around in my head that I think would solve the problem requires a > complete world re-design. Its basically as follows: > 1) Have 4 major cities > a) levels 0-10 > b) levels 11-20 > c) levels 20-50 > d) levels 51+ The bigworld stuff sort of does this, and to some extent even the small world stuff. My personal gripe would perhaps be that in the 15-25 range, the number of maps that are challenging yet not really deadly are few and far beween. This is why death is so painful - you can go backto killing the easier stuff, or your can fight the really tough stuff and perhaps die again. IMO, this might be more a problem with the monsters - there isn't a lot of monsters in that range. > > 2) City one (the city all players start in - like Scorn) you can leave > this city, just like now, when you buy a pass, but to enter any of the > other 3 major cities you would need the pass + be within or above the > level range for that city. I think out and out level checks are a bad thing. You can do some things like the tower of demonology, which requires a hefty entrance fee, which will obviously keep out low level players. You can also post signs. But a 'you have to be level 30 to enter this town' seems a bit odd to me. > 3) Any levels (caves, mountains, forest, towers, runes, other cities, > etc.) outside the 4 major cities should have a sign explaining what > level the map/area is. This could be a sign saying "Levels 10+" or > "Powerful beings only" etc. but as they are out of the 4 major cities, > any level player should be aloud to go into then regardless. Well, one of the map guidelines is to have some clue as to the level of a dungeon. presuming the entrance space is safe, I'd rather have it there than signs all over the world. > > 4) Anytime that there is a quest, riddle, etc. to solve, PLEASE make > sure that any idiot can figure it out. A prefect example of what not to > do is Red Islands (or what ever it is called). Myself and 2 other > players were there for 4 days - in real life - trying to figure it out. > The only reason we got threw is someone else told us the passwords. One 'problem' is that so few of the maps actually require much in the way of NPC play, and the npc communication interface isn't that great. But at the same time, I really don't want things to be too obvious - if allthe answers are just presented to you, that doesn't seem that interesting either. > The last thing I want to mention is a very specific point. Every now and > again one player just pisses you off, beyond all. It would be nice if > players had the option to turn off the safeties in the arena. What's the point of that? If you really want to kill them, do it in the town square our someplace. The arena is purely meant as a place to safely combat someone else - if you can end up luring other people in there, turning off the safeties, and then killing them, who would ever enter the arena again? > > Client Design > ------------- > I use the GTK client - and like its functionality. There really isn't > anything wrong with it. Though I think look and feel wise you may get > more players if it was a fully graphical, full screen, client. This > would be a major coding project and probably not be something a single > person could do. Can you clarify what you mean by 'fully graphical, full screen'? One can maximize the window right now, but that probably isn't what you mean. there is a finite number of tiles the client can show to the player - 25x25 is the max size right now. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Apr 27 01:10:11 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:04 2005 Subject: [CF-Devel] Issues I'de like to bring up In-Reply-To: <3EAB0E58.2030108@sonic.net> References: <1051386869.8388.229.camel@localhost.localdomain> <3EAB0E58.2030108@sonic.net> Message-ID: <1051423813.8388.277.camel@localhost.localdomain> On Sat, 2003-04-26 at 18:55, Mark Wedel wrote: > Justin Zaun wrote: > > > Game Design > > ----------- > > Overall its a fun game to play. There are a lot of things to learn and > > do, feature wise there are a ton. my biggest concern with this is the XP > > you loose when you die compared to the XP you gain when you kill a > > monster. From what I understand you loose 20% or 3 levels when you die, > > which ever is less. So if a small piddly monster kills me say I loose 3 > > levels, but if I kill it I get maybe 1000 XP. Not quite even. If I kill > > a dragon I get so 100K XP but if it kills me I loose 3 level, not quite > > even as well. Now when I loose the 3 levels, it might no sound so bad, 3 > > overall levels isn't *that* big a deal, but in the process I also loose > > (most times more than 3) specific levels. Regaining the levels lost can > > take days, just to be able to retry and kill the monster that killed me > > in the first place. > > > > I understand that there should be a bigger penalty for dieing than for > > killing the monster, its a reason to just die all the time. I think > > there is a fairer way to do this though that is more proportional to > > each monsters strength - if killing a monster gives you N XP points, > > then being killed by the monster takes N*5 XP away from you. That being > > said, if I was using a magic skill when I die, they should all come out > > of magic, etc. just like when I kill it they would all goto magic. > > In practice, you should never lose more than 3 specific levels of skill, but > that might be broken. It should hopefully get fixed up in the new skill code > I'm working on (one big difference is skill exp no longer has to match your > total exp like it does now). > Overall levels, yes only 3 max, but 3 overall levels might be 2 Magic and 3 Agility levels so I really lost 5 not 3. > That said, I think trying to tie death penalty to what killed you is > difficult. That might be the case, but it might also be the best way to handle things too. > If you kill yourself with a fireball, what should you lose? it would be based on your current XP, same as I imagine it is for monsters. > Suppose > for an example, you wander into a room, the titan there lighting bolt zaps you, > so you quickly get out of that room, but due to being weakened, get killed by > some other monster? In a sense, it is the titan that killed you. > Technically it the other monster that makes the killing blow, but it might be wise to keep track of what monsters did what damage to what % of your HP and base the loss on that information. > Also, in an even simpler case, maybe you get killed by something you had no > chance defeating. One could make the case that your exp loss being at all > related to that is excessive. If I walk into a room with 4 dragons and one kills me, I would expect my xp loss to be based on that :-) it was the monster that killed me. > > Note that I'm not saying the players here will somehow manipulate how they die > (as if you can do that, you can probably save yourself). Its just basing exp > loss on what actually killed you may not be a lot better. > > the problem is that the experience table is not consistent. At low levels, it > is exponential - if your level 8 and have 250,000 exp, you need 500,000 (total) > for next level. Worse case is you lose 20%, or about half a level. > > However, the gap from level 20->21 is 8400000 to 9300000 (900,000 gap, but 20% > of 930,000 is 1.86 mil, so about 2 levels). And as more levels pass, the higher > ratio, which is why there is a 3 level cap. At level 60, that 3 level cap means > you only really lose 6% of your exp. I'm not saying the exp table should be consistent, but if its not then flat rules for the lost XP should be in place, but rather rules that take into account (IMO what killed you and) your current level. > > One thought I immediately have to to extend the logic some, like least of the > three: > > 20% of your exp > 3 levels > 10% of your levels (round down, min of 1). > > Thus at level 19, you'd lose at most one level (really, 1.99999 if your 1 exp > from your next level - maybe this should also be fixed). In the low 20's level > range, your caught in that portion of 3 levels and 20% is about the same thing, > and both are quite harsh. > One way to do this would be to remove the % idea as a whole, and deal with it on a per level/group of levels basis. ie if your a level 1 player loose 50% of your XP, level 2-3 loose 55%, level 4-5 loose 45% ect. so you loose approperate amounts based on what level you currently are, ading in a random 1 or 2%. > OTOH, death is meant to be somewhat harsh. If it became 'oh I died. Lost 15 > minutes of play', that is also sort of pointless. > I agree that there should be a deterrence to death, so its not seen as a "oh well, no big deal" type of thing, I guess its just the levels I'm hovering in right now there is no monsters to match skill wise. Big monsters kill me easily, easy monsters arn't worth the time. > > > > > > Map Design > > ---------- > > Generally speaking the game allows for a lot of unique things to be done > > in the maps, most of which have been done already, I'm sure. My issue is > > with the current maps I've seen. There is no real progression threw > > "easy" "medium" and "hard" types of maps. By this I mean: I'm a level 19 > > overall player, most in magic. I can complete most maps in Scorn rather > > easily, I can also defeat raffle 1, but once I venture out most of the > > other maps I die in about 30 sec. of entering. An idea I've been tossing > > around in my head that I think would solve the problem requires a > > complete world re-design. Its basically as follows: > > 1) Have 4 major cities > > a) levels 0-10 > > b) levels 11-20 > > c) levels 20-50 > > d) levels 51+ > > The bigworld stuff sort of does this, and to some extent even the small world > stuff. My personal gripe would perhaps be that in the 15-25 range, the number > of maps that are challenging yet not really deadly are few and far beween. This > is why death is so painful - you can go backto killing the easier stuff, or your > can fight the really tough stuff and perhaps die again. > > IMO, this might be more a problem with the monsters - there isn't a lot of > monsters in that range. How hard is it to add mew monsters, data files or source code changes? > > > > > 2) City one (the city all players start in - like Scorn) you can leave > > this city, just like now, when you buy a pass, but to enter any of the > > other 3 major cities you would need the pass + be within or above the > > level range for that city. > > I think out and out level checks are a bad thing. You can do some things like > the tower of demonology, which requires a hefty entrance fee, which will > obviously keep out low level players. You can also post signs. But a 'you have > to be level 30 to enter this town' seems a bit odd to me. I think if a person really wants into a high level area when they are at a low level, they should be able to get in, but at the same time you want to protect them from stepping into a situation they have no chance of winning. One solution - what I mentioned above would work for an outright blocking, but a more lenient way might be something like this: A level 10 player tries to enter a 20+ city, the guard says somthing along the lines "Only the strong and very strong should enter here. If you really want to die I've been know to take bribes of 20 plat". the player drops 20 plat and the gate opens. Saves the city for the higher level players but if a lower level player really wants in he can get in. > > > > 3) Any levels (caves, mountains, forest, towers, runes, other cities, > > etc.) outside the 4 major cities should have a sign explaining what > > level the map/area is. This could be a sign saying "Levels 10+" or > > "Powerful beings only" etc. but as they are out of the 4 major cities, > > any level player should be aloud to go into then regardless. > > Well, one of the map guidelines is to have some clue as to the level of a > dungeon. presuming the entrance space is safe, I'd rather have it there than > signs all over the world. I agree and this is what I ment :-) I guess the guidelines arn't being followed everywhere. Though if a city is for level 20+ players any maps withing that city wouldn't need a sign at all. > > > > > 4) Anytime that there is a quest, riddle, etc. to solve, PLEASE make > > sure that any idiot can figure it out. A prefect example of what not to > > do is Red Islands (or what ever it is called). Myself and 2 other > > players were there for 4 days - in real life - trying to figure it out. > > The only reason we got threw is someone else told us the passwords. > > One 'problem' is that so few of the maps actually require much in the way of > NPC play, and the npc communication interface isn't that great. But at the same > time, I really don't want things to be too obvious - if allthe answers are just > presented to you, that doesn't seem that interesting either. I guess my point was that making a player have to guess the correct answer isn't the best idea in the world. Not everyone has seen the same movies or have the same cultural information. IMHO quests, riddles, etc. would be better if they were "go here do this come back", "talk to John to get information that I need and I'll tell you what you want to know". > > > > The last thing I want to mention is a very specific point. Every now and > > again one player just pisses you off, beyond all. It would be nice if > > players had the option to turn off the safeties in the arena. > > What's the point of that? If you really want to kill them, do it in the town > square our someplace. The arena is purely meant as a place to safely combat > someone else - if you can end up luring other people in there, turning off the > safeties, and then killing them, who would ever enter the arena again? heh, didn't mean that one person could turn off the safeties without the other knowing. Just meant to have a place to duke it out that others could watch safely and I would gain/he would loose XP. > > > > > Client Design > > ------------- > > I use the GTK client - and like its functionality. There really isn't > > anything wrong with it. Though I think look and feel wise you may get > > more players if it was a fully graphical, full screen, client. This > > would be a major coding project and probably not be something a single > > person could do. > > Can you clarify what you mean by 'fully graphical, full screen'? One can > maximize the window right now, but that probably isn't what you mean. there is > a finite number of tiles the client can show to the player - 25x25 is the max > size right now. > well the best design I could think of off hand would be like Diablo. I understand they had a different perspective of graphics, but the UI design was very slick and very clean, fully graphical and full screen. > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Apr 27 05:37:00 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:04 2005 Subject: [CF-Devel] Issues I'de like to bring up References: <3EAB0E58.2030108@sonic.net> Message-ID: <5508.1051439820@www56.gmx.net> > > [...] > > My issue is with the current maps I've seen. > > There is no real progression threw "easy" "medium" > > and "hard" types of maps. [...] This is a good point really. In most all commercial RPGs you find difficulty levels grouped in areas. That's no coincidence. In Crossfire this is widely not the case, and that's why players often don't find the right maps while in fact there are many. > My personal gripe would perhaps be that in the 15-25 range, > the number of maps that are challenging yet not really > deadly are few and far beween. > [...] > IMO, this might be more a problem with the monsters - > there isn't a lot of monsters in that range. I believe there are enough monsters and there are enough mid level maps. The problem is these maps are sprinkled all over the world, and there is no "mid level area". We have especially many map sets with an "internal" level progression all the way from kobolds to big demons and dragons. This can be found in wizard tower, volcanoe, 9 gates of hell, and many more. While this concept has it's merits, the mid level players are really the losers in that case: They first need to go through the "boring" low level stages - and then exit out before it gets too dangerous, which means they have to leave with little or no reward. I'm not suggesting we should start to rewrite all maps or something. What could be done though is adding an advice about this to the official CF mapguide. Just in case there is a common agreement to this new "guideline", I would suggest something along the lines of this: Avoid mixing difficulty levels all over the place. When newbie maps, mid level- and high level areas stay seperated, players have a much easier time to find what is suitable for them. It is okay to place a harder map into a low level area, as long as it requires something to enter which keeps out too weak players. Feel free to extend, modify or criticize it. :-) AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Sun Apr 27 23:23:47 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:04 2005 Subject: [CF-Devel] Issues I'de like to bring up In-Reply-To: <1051423813.8388.277.camel@localhost.localdomain> References: <1051386869.8388.229.camel@localhost.localdomain> <3EAB0E58.2030108@sonic.net> <1051423813.8388.277.camel@localhost.localdomain> Message-ID: <3EACACD3.80806@sonic.net> Justin Zaun wrote: >> > > Overall levels, yes only 3 max, but 3 overall levels might be 2 Magic > and 3 Agility levels so I really lost 5 not 3. Matter of semantics. The 'problem' is that if you count skill levels, this will only get worse. what I'm working on now will have each skill have its own exp total, and thus you will have a level in 30 different things. Suppose with that, you die and happen to lose a level if half of the skills you know. Do you now say you've lost 10 levels, even though your over all level might have only gone down by one? I'm willing to look for a solution for this. Maybe under the revised skill system, we only ding your over all level (which gives you your hp and ability to use enchanted weapons?) Or maybe 20% (or some other mechanism) on your your overall exp, but 5% for skills? I don't think loss should be based on number of skills - then you'd get people saying 'I should learn more skills just so I don't lose as much exp' - somehow, that doesn't seem right. One problem is that some skills are harder to advance than others. wizardry, combat, eg, the skills that kill thing, are pretty easy to get exp in. Things like literacy, sense magic, etc, are a lot harder. OTOH, I've not heard of any characters being killed by reading a book (although the idea of cursed books/scrolls is interesting). but for that matter, the identification skills are quite safe, and I can't really envision a way to make that dangerous. > > Technically it the other monster that makes the killing blow, but it > might be wise to keep track of what monsters did what damage to what % > of your HP and base the loss on that information. well, that isn't really feasible to do, and get very complicated. You now have to track when people did damage - so you know that 'player has healed 20 points, so that 20 points done back ... is no longer relevant'. Arguably, getting killed by something wimpy should cost you more. Eg, an orc killed you? You deserve to lose a lot of exp. In any case, I'm really not sold on adjust penalty on death based on how you die. I'm certainly willing to come up with a fairer system however. > One way to do this would be to remove the % idea as a whole, and deal > with it on a per level/group of levels basis. ie if your a level 1 > player loose 50% of your XP, level 2-3 loose 55%, level 4-5 loose 45% > ect. so you loose approperate amounts based on what level you currently > are, ading in a random 1 or 2%. Yeah, I was thinking about it. The 'problem' is that the exp table is a modifiable settings, it just seems having people that may want to modify it also adjust loss percentages makes things relatively unfriendly. However, I'd personally like more input. Low level exp loss seems fine (doesn't take too long to get it back'). The 15-25 range seems tought for various reasons. I'd be curious what people who are level 40+ think about the current loss. IS it too much, too weak, just right? > > > How hard is it to add mew monsters, data files or source code changes? Tyically not very. new monsters are easy. source code is a little trickier more in the sense that as a new developer, one needs to submit a few things before they would be given write access to CVS (someone else would review the submissions and apply them into CVS, if appropriate, on the submitters behalf). > > I think if a person really wants into a high level area when they are at > a low level, they should be able to get in, but at the same time you > want to protect them from stepping into a situation they have no chance > of winning. One solution - what I mentioned above would work for an > outright blocking, but a more lenient way might be something like this: > A level 10 player tries to enter a 20+ city, the guard says somthing > along the lines "Only the strong and very strong should enter here. If > you really want to die I've been know to take bribes of 20 plat". the > player drops 20 plat and the gate opens. I guess I disagree. I don't see a reason to protect people from their own stupidity. If there are signs saying this map is a high level area, and every other bit of info poitns to that, yet some new player wanders in and gets killed, I have no sympathy for them. That said, those various clues should be present. For example, there is a sign on the road to brest which says it is a high level area. If people ignore it, wander in, and get killed, that is there problem. But more to the point, the town itself is not dangerous - the shops are safe, the inn is safe, etc. Only if they go into a dungeon are they at risk of being killed. >> Well, one of the map guidelines is to have some clue as to the level of a >>dungeon. presuming the entrance space is safe, I'd rather have it there than >>signs all over the world. > > > I agree and this is what I ment :-) I guess the guidelines arn't being > followed everywhere. Though if a city is for level 20+ players any maps > withing that city wouldn't need a sign at all. there are lots of maps that predate the creation of the guidelines. And no one has really gone and bothered to update everything - its a lot of work, and not especially interesting work. > I guess my point was that making a player have to guess the correct > answer isn't the best idea in the world. Not everyone has seen the same > movies or have the same cultural information. IMHO quests, riddles, etc. > would be better if they were "go here do this come back", "talk to John > to get information that I need and I'll tell you what you want to know". I agree that not everyone has the same cultural references. The problem is it gets tricky to know what people do and do not know. The dialogues do make the presumption that the players have at least some English comprehension. But what level of comprehension do you presume? I also agree the the answers should be available in the game. I disagree that we should always point to where the answers are. Take the scorn town gate. You can get a password to get out. However, if the guards told you where the password was, it would be pretty pointless (and from a role playing perspective, not make a lot of sense). However, this is also an example of another good point - more than one way to get the info that is needed. Meaning, if the information is rare, but not unique, sprinkle it in a few places. Maybe even unrelated to where the information is needed - I personally think this adds to the game - it makes it appear less linear and larger. For example, if you foudn some useful piece of info in navar city related to some question in santo dominion, you might tuck it away, not knowing what it is for. But later in the game, maybe you remember that point. Maybe you don't, and find the same piece of info in santo dominion, and you now remember you found that a while ago. Either way, it makes it seem that the game is more 'global'. But there are certainly some issues with NPC's. In some maps, you need to talk to most everyone to get information. But at the same time, the converstation model isn't very good (hard to know what to say to continue the conversation), and in some other cases, there are loads of people around with nothing to say. I'd not like to remove all the boring poeple - then it really comes to 'this person is here - he must have something important to say'. I would like to see the npc converstation code improved. > > heh, didn't mean that one person could turn off the safeties without the > other knowing. Just meant to have a place to duke it out that others > could watch safely and I would gain/he would loose XP. Ok. I imagine someone could design that pretty easily - it is basically the same as the existing arena, but with no battleground tiles. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Apr 28 00:34:26 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:04 2005 Subject: [CF-Devel] Issues I'de like to bring up In-Reply-To: <3EACACD3.80806@sonic.net> References: <1051386869.8388.229.camel@localhost.localdomain> <3EAB0E58.2030108@sonic.net> <1051423813.8388.277.camel@localhost.localdomain> <3EACACD3.80806@sonic.net> Message-ID: <1051508067.8390.344.camel@localhost.localdomain> On Mon, 2003-04-28 at 00:23, Mark Wedel wrote: > Justin Zaun wrote: > One problem is that some skills are harder to advance than others. wizardry, > combat, eg, the skills that kill thing, are pretty easy to get exp in. Things > like literacy, sense magic, etc, are a lot harder. > Very true, loosing 1 level in personality or Wisdom is like loosing 5 in magic or phyis :-) > OTOH, I've not heard of any characters being killed by reading a book > (although the idea of cursed books/scrolls is interesting). but for that > matter, the identification skills are quite safe, and I can't really envision a > way to make that dangerous. > Would make for a better way to loose XP rather that just by death. though the ideas should be well thoughtout in the grand skeem of XP gain and loss. Takin in account of all ways to gain XP in or loose XP threout the entire game. > > > > > Technically it the other monster that makes the killing blow, but it > > might be wise to keep track of what monsters did what damage to what % > > of your HP and base the loss on that information. > > well, that isn't really feasible to do, and get very complicated. You now > have to track when people did damage - so you know that 'player has healed 20 > points, so that 20 points done back ... is no longer relevant'. > Would it really, just an array of percentages. > Arguably, getting killed by something wimpy should cost you more. Eg, an orc > killed you? You deserve to lose a lot of exp. > a) I'm walking down the street, get mugged and shot. After which I stumble into the street and get killed by a car. I'de want the mugger to get blamed. b) I'm walking down the street get mugged and shot. After which I stumble into the middle of a robbery and get shot a second time, killing me. I would want both to get blamed. I think the game should follow B, not A. > In any case, I'm really not sold on adjust penalty on death based on how you > die. I'm certainly willing to come up with a fairer system however. > Its hard for a non-programmer (of crossfire) to come up with a fair way because I don't know all the ways XP can be gained or lost. > > > One way to do this would be to remove the % idea as a whole, and deal > > with it on a per level/group of levels basis. ie if your a level 1 > > player loose 50% of your XP, level 2-3 loose 55%, level 4-5 loose 45% > > ect. so you loose approperate amounts based on what level you currently > > are, ading in a random 1 or 2%. > > Yeah, I was thinking about it. The 'problem' is that the exp table is a > modifiable settings, it just seems having people that may want to modify it also > adjust loss percentages makes things relatively unfriendly. > % are always messy, but a fairer (if thats a word) way might be: say 20% of (current level max XP - previous level max XP) * current level > However, I'd personally like more input. Low level exp loss seems fine > (doesn't take too long to get it back'). The 15-25 range seems tought for > various reasons. I'd be curious what people who are level 40+ think about the > current loss. IS it too much, too weak, just right? > > > > > > > > > How hard is it to add mew monsters, data files or source code changes? > > Tyically not very. new monsters are easy. source code is a little trickier > more in the sense that as a new developer, one needs to submit a few things > before they would be given write access to CVS (someone else would review the > submissions and apply them into CVS, if appropriate, on the submitters behalf). > Is there a HOWTO with an example of how to add a monster, even an existing on, say a Hill Giant or a Dragon, new graphics an all? > > > > > I think if a person really wants into a high level area when they are at > > a low level, they should be able to get in, but at the same time you > > want to protect them from stepping into a situation they have no chance > > of winning. One solution - what I mentioned above would work for an > > outright blocking, but a more lenient way might be something like this: > > A level 10 player tries to enter a 20+ city, the guard says somthing > > along the lines "Only the strong and very strong should enter here. If > > you really want to die I've been know to take bribes of 20 plat". the > > player drops 20 plat and the gate opens. > > I guess I disagree. I don't see a reason to protect people from their own > stupidity. If there are signs saying this map is a high level area, and every > other bit of info poitns to that, yet some new player wanders in and gets > killed, I have no sympathy for them. > > That said, those various clues should be present. For example, there is a > sign on the road to brest which says it is a high level area. First time I went there I didn't go by way of road... missed the sign all together. the sing would have been better placed right outside the city wall, after you press 'a' on the city in the world map > If people ignore > it, wander in, and get killed, that is there problem. But more to the point, > the town itself is not dangerous - the shops are safe, the inn is safe, etc. > Only if they go into a dungeon are they at risk of being killed. > True, if they ignore it, but what if they never saw it? > >> Well, one of the map guidelines is to have some clue as to the level of a > >>dungeon. presuming the entrance space is safe, I'd rather have it there than > >>signs all over the world. > > > > > > I agree and this is what I ment :-) I guess the guidelines arn't being > > followed everywhere. Though if a city is for level 20+ players any maps > > withing that city wouldn't need a sign at all. > > there are lots of maps that predate the creation of the guidelines. And no > one has really gone and bothered to update everything - its a lot of work, and > not especially interesting work. > well I figured a bit out about map editors, I could add the signs/information needed, but I think it goes beyond just that... how is a map determend to be "easy" "medium" "difficult"? and are those the word that should be used? > > > > I guess my point was that making a player have to guess the correct > > answer isn't the best idea in the world. Not everyone has seen the same > > movies or have the same cultural information. IMHO quests, riddles, etc. > > would be better if they were "go here do this come back", "talk to John > > to get information that I need and I'll tell you what you want to know". > > I agree that not everyone has the same cultural references. The problem is it > gets tricky to know what people do and do not know. The dialogues do make the > presumption that the players have at least some English comprehension. But what > level of comprehension do you presume? speaking English yes, but there should be no presumption that anyone has any cultural information, unless it come directly out of the game and not real life. using Monty Python phrases for a password is bad using what special gift Sorig gives you after praying is good. (protection form electricity) > > I also agree the the answers should be available in the game. I disagree that > we should always point to where the answers are. Take the scorn town gate. You > can get a password to get out. However, if the guards told you where the > password was, it would be pretty pointless (and from a role playing perspective, > not make a lot of sense). However, this is also an example of another good > point - more than one way to get the info that is needed. > Agreed. I'm not saying give them step by step how to get the information, but a pointer in the right direction helps. > Meaning, if the information is rare, but not unique, sprinkle it in a few > places. Maybe even unrelated to where the information is needed - I personally > think this adds to the game - it makes it appear less linear and larger. For > example, if you foudn some useful piece of info in navar city related to some > question in santo dominion, you might tuck it away, not knowing what it is for. > But later in the game, maybe you remember that point. Maybe you don't, and > find the same piece of info in santo dominion, and you now remember you found > that a while ago. Either way, it makes it seem that the game is more 'global'. > This is one big way to make the game more 'global', but there are others too. give information in one city that is needed in another location that is not avalible there. Have traviling NPCs that can give out information. One thing that would be VERY nice is if playes could write their own books. the books themselves would be one of a kind, and would be worth pidilly when sold, but the information in them would be very valuble. Carying that idea further, you could make a library (like an apartment in that things wont disapeer, different in that its global to everyone in the game). > But there are certainly some issues with NPC's. In some maps, you need to > talk to most everyone to get information. But at the same time, the > converstation model isn't very good (hard to know what to say to continue the > conversation), and in some other cases, there are loads of people around with > nothing to say. > The bit with loads around with nothing to say has caused me to not bother with them any more... looking at the map editor, the interface for them is VERY VERY basic, might want to add a perl, php, python type scripting behind them. > I'd not like to remove all the boring poeple - then it really comes to 'this > person is here - he must have something important to say'. I would like to see > the npc converstation code improved. > Agreed. but the boring people should have some built-in AI. hold some kind of converation that really don't give up any info at all. > > > > > heh, didn't mean that one person could turn off the safeties without the > > other knowing. Just meant to have a place to duke it out that others > > could watch safely and I would gain/he would loose XP. > > Ok. I imagine someone could design that pretty easily - it is basically the > same as the existing arena, but with no battleground tiles. > modify the current area with 2 portals from within the betting room, 1 for safe combat, one for non-safe combat. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Apr 28 01:40:03 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:04 2005 Subject: [CF-Devel] More random skill musings. Message-ID: <3EACCCC3.4060704@sonic.net> A few weeks back, I posted my notes file about the new skill system I'm working on (and I'm actually really working on it now). As I've done work, there are some more refinements to be said: 6. Other Objects ---------------- Many other objects will use the 'skill' field in their object to denote what skill is needed to use this object. Thus, for examples, readable objects have 'skill literacy' to denote that the literacy skill is needed to read them. Weapons have 'skill' values to denote what skill is needed to use the weapon. Same for spells. ?s I go and update the archs, some things perhaps strike me as odd - should perhaps the ability to learn a new spell be based more on the skill you use it on and not literacy (eg, cleric using their praying ability?) This may reduce the usefulness of literacy, but could make more sense. But related to that change above (skill in archetypes of skill to use) - this does allow the potential of skills to wear armor. Eg, heavy armor skill, medium armor skill, etc. I'm not saying this should necessary be done, but is an example of what could be done with the new skill system - you could really expand the number of proficiencies available. Another question - currently, whenever you use a skill, it changes your range to that skill even if the use may be temporary. For example, if you read a book, it will make literacy your active skill, and update your range. The side effect of this code is that a message like 'you switch to skill literacy' is also printed out. In the new code, this is no longer necessary - we don't rely on what the players chosen_skill is to figure out where to put exp. Thus, if you read a book, none of your range stuff changes, and no message about now using the skill literacy is generated. In some sense, I think this is probably better. As one does things, one never thinks about 'readying' skills, one just does it, and the new way follows that. Players can skill explicity ready skills, and that will change the range and what not - just indirect use will not. I thought I'd post this out here and see what peoples thought on this behaviour is. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Apr 28 08:33:32 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:04 2005 Subject: [CF-Devel] Issues I'de like to bring up In-Reply-To: <1051508067.8390.344.camel@localhost.localdomain> Message-ID: On 28-Apr-03 Justin Zaun wrote: > Agreed. but the boring people should have some built-in AI. hold some > kind of converation that really don't give up any info at all. Heh.. how fun/annoying would it be to put an eliza engine on all the speechless NPC's... :) Of course you would have to seed it with game relevant information, like possibly lore. Could do things like look for basic words like "hello hi help" and have it just spit out a random peice of lore, and if you say something more complex, have it just generate an eliza response. Of course.. to make it interesting, much like rumors in nethack, we would have to preload some false ones. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Apr 28 23:03:29 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:05 2005 Subject: [CF-Devel] More random skill musings. In-Reply-To: <3EACCCC3.4060704@sonic.net> Message-ID: <5.1.0.14.0.20030428222830.00a6dec0@postoffice.worldnet.att.net> At 01:40 AM 4/28/03, you wrote: > ?s I go and update the archs, some things perhaps strike me as odd - should perhaps the ability to learn a new spell be based more on the skill you use it on and not literacy (eg, cleric using their praying ability?) This may reduce the usefulness of literacy, but could make more sense. Makes a lot of sense, but I don't think I'd remove the idea that high level spells may use "hard to read runes" or studies in "complex magic theory" in the same way that high level books are only readable by high-level characters. It seems that one might not want to totally get away from using literacy for spell learning. I think most disciplines are enhanced by knowledge that is passed on in writing. While its not hard to think of progressions like magic bullet, large bullet, and bullet swarm/storm all being easier to learn by skill XP, it is a bigger stretch to think that bullet has anything at all to do with say snowball, fireball, etc. But even then, is not mastering a swarm/storm something quite different than being able to conjure a single object. I can be really good at swinging a one-handed axe, but that doesn't mean I'm going to have an easy way of it when I try to excel at two handed axes. While some skill applies, I think it also takes some study to understand how one might translate ones current skill into one that is similar but significantly different. > But related to that change above (skill in archetypes of skill to use) - this does allow the potential of skills to wear armor. Eg, heavy armor skill, medium armor skill, etc. I'm not saying this should necessary be done, but is an example of what could be done with the new skill system - you could really expand the number of proficiencies available. > > Another question - currently, whenever you use a skill, it changes your range to that skill even if the use may be temporary. For example, if you read a book, it will make literacy your active skill, and update your range. The side effect of this code is that a message like 'you switch to skill literacy' is also printed out. > > In the new code, this is no longer necessary - we don't rely on what the players chosen_skill is to figure out where to put exp. Thus, if you read a book, none of your range stuff changes, and no message about now using the skill literacy is generated. > > In some sense, I think this is probably better. As one does things, one never thinks about 'readying' skills, one just does it, and the new way follows that. Players can skill explicity ready skills, and that will change the range and what not - just indirect use will not. > > I thought I'd post this out here and see what peoples thought on this behaviour is. Excellent idea. The whole "readying" thing is what keeps me from using a more broad set of skills. Instead, I kind of concentrate on one at a time, especially when you can die in the moment you pause to ready something new. Oh, and on the idea of limiting the number of skill categories... 1) Good idea in that it forces one to try to guide one's development path as long as it is not ridiculously limiting. Through life we all garner more and more expertise in more and more disciplines, but we will tend to not be able to master all of them. 2) My vote is "not so good idea" if an early choice prevents one from choosing to let that skill rot back to general knowledge. I am skeptical of hard limits that aren't reversible - heck, make the reversibility very costly if necessary, but allow it. I'd like not to realize I made an awful mistake at level 10 that can't be undone when I am level 100, and therefore my possibilities are forevermore restricted in some way. I remember playing one game once that required an Xth level thief to be able to finish the game in a satisfactory manner (save the life of the main protagonist). Thing was, I got by without thief skills of significance throughout the whole game. By the time I figured it out, I was hosed. There wasn't any real practical way to practice up thievery, and I had to ditch the game and start over. This was not something I liked. While its not quite the same issue, I think that it illustrates a point that it would be better to be able to learn that last category if I knew that it meant I'd be ditching one of my other categories. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Mon Apr 28 23:25:42 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:05 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <3EAB00FC.3070500@sonic.net> References: <3EAAB2C8.9060301@sympatico.ca> <3EA73FC4.60503@sympatico.ca> <17711.1051351335@www60.gmx.net> <3EAAB2C8.9060301@sympatico.ca> Message-ID: <5.1.0.14.0.20030428230349.00a6c460@postoffice.worldnet.att.net> I have yet to see compelling argument for transmutation. I vote against it. It smells like a big cheat. Oh, can't be bothered to find diamonds, who cares, I'll make my own out of these stones (that aren't made out of carbon). Alchemy at least requires that you find ingredients, but even then, I don't like (and don't use) what I hear is the ability to turn any pile of treasure into gold. I think that is severely bogus. I'd rather see people abuse the titan's tower to get rich than to abuse the newbie tower because I can change worthless things into more valuable items. The cool factor for transmutation is not compelling. It is related to the past discussion about dimension door. Unrestricted dimension door pretty much hoses the challenge to most any map. Transmutation sounds like it hoses other things in a similar way. IMO, conjuring energy is not that big of a deal (transmuting light, magnetism, or what not to make spells we currently use). Heck, even magic bullet isn't bad if you consider that maybe you are taking elements (atoms/dust) from the air and are simply condensing them to form bullets, but transmuting solid matter from one material to totally another seems a bit of a stretch. Also, IMO, if it is even allowed, it should be even more lossy than alchemical formulae. (Most of the time you vaporize the stuff away instead of getting anything useful out of it.) In fact, I'd think the premise of transmutation would be atomic de/reconstruction, and I think that you should have to have many times greater quantity of source material than end-result. No way would 1 lb of lead give you 1lb of gold, but rather 1000 lb of lead gives you maybe 1 lb of gold. While I vote no, in a pinch I would say make it very expensive so if you really want to do cool things, you still have to work to do cool stuff. It is no fun to be able to make things just because you can't be bothered to adventure for them. If you have to do that, go play another game... _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 29 00:20:58 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:05 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <5.1.0.14.0.20030428230349.00a6c460@postoffice.worldnet.att.net> References: <3EAAB2C8.9060301@sympatico.ca> <3EA73FC4.60503@sympatico.ca> <17711.1051351335@www60.gmx.net> <3EAAB2C8.9060301@sympatico.ca> <5.1.0.14.0.20030428230349.00a6c460@postoffice.worldnet.att.net> Message-ID: <3EAE0BBA.7040305@sonic.net> Kevin R. Bulgrien wrote: > Alchemy at least requires that you find ingredients, but even then, > I don't like (and don't use) what I hear is the ability to turn > any pile of treasure into gold. I think that is severely bogus. > I'd rather see people abuse the titan's tower to get rich than > to abuse the newbie tower because I can change worthless things > into more valuable items. the current implementation of alchemy doesn't let you make it more valuable. All alchemy really does is convert something heavy into a more convenient carrying form (gold nuggets). In fact, you'll get more money from not using alchemy - the alchemy is lossy - some items will be destroyed and not converted to gold. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 29 00:38:54 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:05 2005 Subject: [CF-Devel] Issues I'de like to bring up In-Reply-To: References: Message-ID: <3EAE0FEE.20308@sonic.net> Tim Rightnour wrote: > On 28-Apr-03 Justin Zaun wrote: > >>Agreed. but the boring people should have some built-in AI. hold some >>kind of converation that really don't give up any info at all. > > > Heh.. how fun/annoying would it be to put an eliza engine on all the speechless > NPC's... :) Of course you would have to seed it with game relevant > information, like possibly lore. > > Could do things like look for basic words like "hello hi help" and have it just > spit out a random peice of lore, and if you say something more complex, have it > just generate an eliza response. Of course.. to make it interesting, much like > rumors in nethack, we would have to preload some false ones. I don't know if this would be better or worse. In some sense, at least most of the 'boring' npcs that lack any information don't say anything when you say 'hi' to them. If you had the npc's now going into various conversation, this could make it even harder to find the npc's with real information. OTOH, if the information was available in common lore, and thus any random npc might have it, that might be OK. Note however that what knowledge each NPC has (From lore) has to be generated once (at reset time). Eg, if each time you said 'hi', the script went through and grabbed a random piece of lore, that could basically mean you could talk to that same pc for a long time and it would tell you most everything. Isntead, it should have some number of knowledge pieces, and just repeat those. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 29 00:48:07 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:05 2005 Subject: [CF-Devel] Adding New Stuff (again) - Requests and suggestions In-Reply-To: <3EAB08A4.4000008@sonic.net> References: <200304261435.28116.mail-lists+cfdev@dogphilosophy.net> <200304251718.04237.mail-lists+cfdev@dogphilosophy.net> <200304260110.35514.mail-lists+cfdev@dogphilosophy.net> <3EAA42D2.50807@sonic.net> <200304261435.28116.mail-lists+cfdev@dogphilosophy.net> Message-ID: <5.1.0.14.0.20030428232633.00a6cec0@postoffice.worldnet.att.net> I see both sides of the compile vs. resource file thing, and also have the impression that a lot of talk is going around about adding new spells, etc., without considering the relative merit of adding such things as opposed to the adding of less glamorous stuff. Just to get it out of the way, I think the old-code people are pooh-poohing legitimate ideas about how well designed resource files can be used. In my experience, huge reductions in code and increases in functionality are generated through the design of robust data structures. Been there, done that. Code is not the ultimate answer. The game content (data) is where it is at. Make a good engine, and the data drives it. But, this is an old and evolving project, and it is probably awfully late to make the kinds of changes that would yield maximal results. So, perhaps the pooh-poohing is not as bad as if it were a young project. More significantly, though, I think that the data file people are overly concerned about compiling and adding features without being willing to invest something significant into the project. As for compiling, all I have is a dial up. Sometimes pulling latest CVS is a pain in the butt. Indeed, sometimes it is more than that. But compiling is just not that big of a deal. I am not a C programmer, but I am a multi-disciplined technical person, and I can whittle this or that out if I am motivated enough. There are enough experts out there that will mangle what I do into something that they think is acceptable - but only if I give them the raw material. BTW, I think that the most significant contribution to Crossfire just might not be the addition of this or that cool spell or item, but indeed might be the documentation that one could write while adding just one cool thing. Either that, or a map that uses existing stuff in creative ways - taking care to do the design in player friendly ways, and filling in the need for medium difficulty areas. If I were a project developer, I think I'd be skeptical of "contributions" that don't really take much more effort than a brain fart. I mean, all of us can dream up a spell or artifact. Does that really mean we all should be mucking around in just adding cool stuff without having to pay dues? There is already more magic than one can practically use. Do we REALLY need more? Sure more might be nice, but Crossfire sure has other greater needs. So, while I see the flexi-data file proposal as being meritorious, I can't say that I am that excited about unleashing a bunch of mithril-toothpaste-like ideas into the game. If I can't or don't want to have to do the foot work to think through, communicate, and decide via committee, whether something is a good idea or not, probably I ought not be messing with an open source game. I really don't think it is the project's goal to cater to the any-joe-can-add-a-feature ability. On the other hand, if the whole thing about committee work being drudgery is legit, perhaps I do the work on my own, figure out how to deal with the existing system, and sell it after the fact - without going into a fit if it doesn't fly. (I still think a lot of hogwash got sprayed around over that food beep thing. The current code was presented as being less code (touted good thing), when, in fact, it is far more code (touted bad thing) than the patch that was submitted to the list... but bygones are bygones, and working with committees of mostly one or few seasoned experts can be a bear. But, the end point is that the gumption factor ended up making the sale - in spite of the hoopla. One can only really prove how valuable something is by showing what you are willing to contribute to it, and not just talk about it voluminously.) I redid one graphic animation - hours of work. Was it fun? Hmm. Not so sure about that. Interesting, yes. Hopefully it counts as an incremental contribution, you know, one of the 10,000 diamonds that it takes to expand the old apartment. But it may be a bit of a stretch for me to expect to be able to dramatically affect game play without an effort, even if it is as small as taking something to committee... or a bit bigger thing like gathering info from the experts and writing up docs about how to do what is already there. I would guess that it is only fair of me to think that I have a ways to go before I should expect to be demanding painless ways to do things that could potentially unbalance game play, and I guess I think that the same is true of others. In the end, let's see some more of the "boring" contributions before we feel we need to be able to make the more glorious ones... I can show you more graphics that could be redone... and in fact, have a few more half-way done, but not yet ready for publication. I'd much rather see work in new or improved types of doors, walls, and other basic building blocks, than in additional spells, skills, materials, etc. We've seen a lot of comments about how map making is one of the game's choke points... Hmm... now where is that trapdoor code? Maybe I need to do some more digging... My new map is stuck because my concept from games past didn't translate over... and I haven't adapted to the Crossfire model. See, I have no room to fuss about how hard it is until I am ready to commit to doing something that costs me. Cheap advice is just that... cheap advice. What projects really need is some of the expensive stuff. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 29 01:36:50 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:05 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <5.1.0.14.0.20030428230349.00a6c460@postoffice.worldnet.att.net> References: <3EAAB2C8.9060301@sympatico.ca> <3EA73FC4.60503@sympatico.ca> <17711.1051351335@www60.gmx.net> <3EAAB2C8.9060301@sympatico.ca> <5.1.0.14.0.20030428230349.00a6c460@postoffice.worldnet.att.net> Message-ID: <3EAE1D82.3080404@sympatico.ca> Kevin R. Bulgrien wrote: >I have yet to see compelling argument for transmutation. I vote >against it. It smells like a big cheat. Oh, can't be bothered >to find diamonds, who cares, I'll make my own out of these stones >(that aren't made out of carbon). > >Alchemy at least requires that you find ingredients, but even then, >I don't like (and don't use) what I hear is the ability to turn >any pile of treasure into gold. I think that is severely bogus. >I'd rather see people abuse the titan's tower to get rich than >to abuse the newbie tower because I can change worthless things >into more valuable items. > >The cool factor for transmutation is not compelling. > >It is related to the past discussion about dimension door. Unrestricted >dimension door pretty much hoses the challenge to most any map. >Transmutation sounds like it hoses other things in a similar way. > >IMO, conjuring energy is not that big of a deal (transmuting light, magnetism, >or what not to make spells we currently use). Heck, even magic bullet isn't >bad if you consider that maybe you are taking elements (atoms/dust) from the >air and are simply condensing them to form bullets, but transmuting solid >matter from one material to totally another seems a bit of a stretch. Also, >IMO, if it is even allowed, it should be even more lossy than alchemical >formulae. (Most of the time you vaporize the stuff away instead of getting >anything useful out of it.) In fact, I'd think the premise of transmutation >would be atomic de/reconstruction, and I think that you should have to have >many times greater quantity of source material than end-result. No way would >1 lb of lead give you 1lb of gold, but rather 1000 lb of lead gives you maybe >1 lb of gold. While I vote no, in a pinch I would say make it very expensive >so if you really want to do cool things, you still have to work to do cool >stuff. It is no fun to be able to make things just because you can't be >bothered to adventure for them. If you have to do that, go play another >game... > > > Transmutation is the changing of one material to another - I stress that when I brought it up it was not to propose a 'transmutation power for players', it is not an ability or a spell or in anyway related to alchemy but a term I was using for changing the material field in an arch to a different material without otherwise changing the arch (and thus applying properties like weight or saving throws of the new material to the arch). It is something you would write code for to acomplish a range of things from converter tables, to monster abilities, to scripted events. In itself it is not something that you could do in the game except by way of the application of such code. I unfortunatly used a classic example of transforming a substance to gold, when I should have perhaps used something more neutral like transforming iron to oak. There is nothing stopping the transmutation of objects now, it is just nicer to work with if there is more formal material system. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 29 00:58:58 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:05 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <3EAE0BBA.7040305@sonic.net> References: <5.1.0.14.0.20030428230349.00a6c460@postoffice.worldnet.att.net> <3EAAB2C8.9060301@sympatico.ca> <3EA73FC4.60503@sympatico.ca> <17711.1051351335@www60.gmx.net> <3EAAB2C8.9060301@sympatico.ca> <5.1.0.14.0.20030428230349.00a6c460@postoffice.worldnet.att.net> Message-ID: <5.1.0.14.0.20030429005114.01d1c6d0@postoffice.worldnet.att.net> At 12:20 AM 4/29/03, you wrote: >Kevin R. Bulgrien wrote: > >>Alchemy at least requires that you find ingredients, but even then, >>I don't like (and don't use) what I hear is the ability to turn >>any pile of treasure into gold. I think that is severely bogus. >>I'd rather see people abuse the titan's tower to get rich than >>to abuse the newbie tower because I can change worthless things >>into more valuable items. > > the current implementation of alchemy doesn't let you make it more valuable. All alchemy really does is convert something heavy into a more convenient carrying form (gold nuggets). In fact, you'll get more money from not using alchemy - the alchemy is lossy - some items will be destroyed and not converted to gold. That is good to know. I still think it is kind of bogus to condense things directly into gold when spells and scrolls like town portal and word of recall and bargaining can be used to make "work" for the conversion a bit easier. I'm not arguing to take that out, but I do think that behavior encompasses my idea about how any transmutation implementation should be done, if it is done at all. (And I've not seen the arguments that convince me it should be done.) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 29 01:52:52 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:05 2005 Subject: [CF-Devel] Issues I'de like to bring up In-Reply-To: <1051508067.8390.344.camel@localhost.localdomain> References: <1051386869.8388.229.camel@localhost.localdomain> <3EAB0E58.2030108@sonic.net> <1051423813.8388.277.camel@localhost.localdomain> <3EACACD3.80806@sonic.net> <1051508067.8390.344.camel@localhost.localdomain> Message-ID: <3EAE2144.6080007@sonic.net> Justin Zaun wrote: > On Mon, 2003-04-28 at 00:23, Mark Wedel wrote: > > Would it really, just an array of percentages. You also have to track the power of each monster, when the damage was done, etc. And you have to copy the relevant information aobut the monster into that array -after all, you could be fighting 3 monsters, and kill two of them before the third one kills you - the information of the first two (in terms of stats) is no longer around unless that is copied. But this also opens a can of worms. If I've taken damage, and then heal it, how do we deal with it? Presumably, the damage done a while back should go away first. So now you also need to record when the damage was done. I just don't think there is any way to sensibly do this without having just as many problems or oddities as the current system. So it is much simpler to try and refine that vs implement a complicate system that probably still won't work properly. And as said, I don't think it should really matter what killed you/how you died. If anything, losing less exp from wimpier monsters will encourage players to just be more conservative (fight wimpier monsters mean you lose less exp if you die, and also reduces the odds of you dying). In some sense, the death penalty is self regulating - don't die. If for example the penalty for death was even more severe, you'd get people just playing a lot more conservatively. If the death penalty was really minor, you'd get people dying all the time - nothing to lose, so just try things (and in some cases, you could get strategies - I know I'm going to die, but I can get more exp/whatever before I die to still make it worth it. > Its hard for a non-programmer (of crossfire) to come up with a fair way > because I don't know all the ways XP can be gained or lost. 95+% of exp probably comes from killing things. Ways to lose exp is to get hit by drain attacks or die. > > % are always messy, but a fairer (if thats a word) way might be: > > say 20% of (current level max XP - previous level max XP) * current > level Not sure if I follow what that formula is supposed to be. > > Is there a HOWTO with an example of how to add a monster, even an > existing on, say a Hill Giant or a Dragon, new graphics an all? doc/Developers/objects > > True, if they ignore it, but what if they never saw it? That's a problem. One can only do ones best to try and make the information available. > well I figured a bit out about map editors, I could add the > signs/information needed, but I think it goes beyond just that... how is > a map determend to be "easy" "medium" "difficult"? and are those the > word that should be used? I'd probbly just put a level estimate - that is more accurate. And no more out of 'game' than a sign saying it is for medium or high level characters. > speaking English yes, but there should be no presumption that anyone has > any cultural information, unless it come directly out of the game and > not real life. > > using Monty Python phrases for a password is bad > using what special gift Sorig gives you after praying is good. > (protection form electricity) I agree with both of those points. > This is one big way to make the game more 'global', but there are others > too. give information in one city that is needed in another location > that is not avalible there. Have traviling NPCs that can give out > information. One thing that would be VERY nice is if playes could write > their own books. the books themselves would be one of a kind, and would > be worth pidilly when sold, but the information in them would be very > valuble. Carying that idea further, you could make a library (like an > apartment in that things wont disapeer, different in that its global to > everyone in the game). NPC's don't travel, so that idea doesn't really work. Players can inscribe their own notes, so that already applies. Players can actually put those in various places I guess. Of course, the value of the book depends on who the person rights in it - there is no way to know what the player rights is worth any data (I could just write 'aaaaaaaaa', which contains no useful information of course). The value of that book, in terms of knowledge, is basically nothing. > > The bit with loads around with nothing to say has caused me to not > bother with them any more... looking at the map editor, the interface > for them is VERY VERY basic, might want to add a perl, php, python type > scripting behind them. python scripting can be connected to them. The biggest issue is to probably give names to npc's proper. Thus, you can get something like 'Jeff at the tavern has some info', and just by clicking on the different people, you can see who Jeff is without having to start conversations with them. > > modify the current area with 2 portals from within the betting room, 1 > for safe combat, one for non-safe combat. That won't work - it is the floor of the arena that determines how people die - having a different portal won't make any difference unless you have two different arena areas with different floors. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 29 02:06:21 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:05 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <3EAE1D82.3080404@sympatico.ca> References: <5.1.0.14.0.20030428230349.00a6c460@postoffice.worldnet.att.net> <3EAAB2C8.9060301@sympatico.ca> <3EA73FC4.60503@sympatico.ca> <17711.1051351335@www60.gmx.net> <3EAAB2C8.9060301@sympatico.ca> <5.1.0.14.0.20030428230349.00a6c460@postoffice.worldnet.att.net> Message-ID: <5.1.0.14.0.20030429012056.00a58e50@postoffice.worldnet.att.net> >Transmutation is the changing of one material to another - I stress that when I brought it up it was not to propose a 'transmutation power for players', it is not an ability or a spell or in anyway related to alchemy but a term I was using for changing the material field in an arch to a different material without otherwise changing the arch (and thus applying properties like weight or saving throws of the new material to the arch). It is something you would write code for to acomplish a range of things from converter tables, to monster abilities, to scripted events. In itself it is not something that you could do in the game except by way of the application of such code. I unfortunatly used a classic example of transforming a substance to gold, when I should have perhaps used something more neutral like transforming iron to oak. There is nothing stopping the transmutation of objects now, it is just nicer to work with if there is more formal material system. Glad that this came out in the clear. It didn't come across to me in the prior thread. I still don't quite see exactly what you mean though. It sounds like something that might support, say a Gorgon turning stuff to stone and a Midas turning stuff to gold. Now if these were non-player things in the game, maybe that is not so abusive as a general player-invoked spell of transmutation, but have you really outlined what is so fundamentally different about a player spell and a table that a player can coax into "casting" transmutation? Have you got some game play examples instead of pure theory? Why would you want to argue for tables that convert material anyway. To me that is not much different than having a player spell, but more to the point is what it brings to the game. Go find a silver arrow, or make one from ingredients... don't convert a gold one or an oak one... I still think that unlimited player invoked conversion doesn't help game play. (Oh, and with the economy, charging money isn't necessarily enough of a control to make limit something that is abusive.) I am thinking that, a la snakeskin, the material system already does some of that fancy work with stats, but maybe you are saying that it is limited and that you'd like the system to be able to take a map maker placed iron arrow and convert it to silver, calculate the stats, all before the player ever saw the object? Why wouldn't the map designer just say something like random_material arrow? Then again, maybe you're not going for conversion tables per se, but rather something that could be like a trap that turns your fine leather boots into granite boots when you step on it. The fact that it could be a conversion table does not mean that you'd intend for people to add a store full of such. And just because it is conceptually possible, probably no one would make a trap like that that indiscriminately turned boots into valuable substances even though this would be made possible by a transmutation engine. Or maybe another example of what you envision might be a system that allows a castable defensive magical aura that converts incoming bullets into rubber bullets that don't do much harm... but not necessarily also planning a spell that turns them into more valuable items that are heavier and more damaging because there isn't really a good gaming scenario that makes that worthy of consideration. Well, enough said... I'm thinking that I'm not the only one that doesn't see what you envision and how it would not turn into yet another way to avoid puzzle solving, material hunting, or earning wealth in more conventional ways. Bottom line? I can see merit to a developer controlled transmutation system that might allow stuff as shown above - even though I remain opposed to gratuitous, player-invokable conversions of arbitrary materials to other arbitrary materials. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 29 02:19:07 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:05 2005 Subject: [CF-Devel] More Lore In-Reply-To: <000801c1ee6d$1f48df80$0802a8c0@KAMERIA> References: <000801c1ee6d$1f48df80$0802a8c0@KAMERIA> Message-ID: <3EAE276B.1020101@sonic.net> Todd Mitchell wrote: > Ok, more thoughts on lore: > > For generic lore in the arches I believe it is established that it is > sufficient to populate the lore <> endlore field with weighted values, e.g. > > arch orc > <..> > lore > @5 Orcs are the foul brethern to goblins. > @4 Dwarves and Orcs have a strong hatred of one another. > ... > endlore The @5 (or whatever) must be on its own line, followed by various lines of lore, and then perhaps another @whatever, etc. Reason for this: 1) it means you can have long lore descriptions without needing to have several hundred character long lines. 2) The meaning of the @ can get expanded more easily in the future, eg, @5 could become '@5 santo_dominion 3', or whatever else. If the lore it describes is on the same line, it makes expansion more difficult, and parsing also more difficult. > > Whereby the object name, level and other information could be grabbed > from the arch if necessary too. I don't get that point. Are you talking about embedding control sequences in the lore for this information? I otherwise don't see what that info would be used for. In any case, all the information the lore needs should be in the lore area. Don't presume that grabbing information from the arch will be easy or even possible in the code. And I'd add that don't presume that the information in the arch is at all meaningful - for many monsters, the level of the monster may not be especially meaningful. > If you customize a creature you need to > grab this out of the maps however, e.g. if you make a special dragon, > you can put in special lore, it is stored on the map. This has to be > picked up during the map lore collection however. This would capture > the arch name and name if the object had one (have to remember to check > for no name...) but I don't know how stuff like level and such can be > easily snagged with a script if it has not been changed (look up the > arch?- yuck) I note you are going beyond how you had originally described the lore stuff. The original idea of lore was to more easily connect information about arches with the arch itself. You're now talking about expanding this more and more beyond the original idea. And as said above, I fail to see why you need to care about level or object name information. If relevant, it should be included in the lore information itself. > For map and quest type information this is not going to work, some maps > have nothing of interest, and some like the city maps have many > many points of interest. If you were to go with a header file, you > would need to account for different topics. Also this information can > be more tricky to manage since it is more specific. This is why I think > a specific maplore arch object would be good in addition to the lore > field. I disagree on that point - if all the information is in the 'lore' field, as it should be, there is no reason you need multiple objects. And I still have the concern that if you have a bunch of objects with lore on a map, that it will be very difficult to manage this information (need to figure what objects have lore, where they are on the map, and so on). > The only thing is that both types of lore should follow the same data > format, style guidelines (including truth and falsehood, weighting and > level and key word information) and be accessable through the same 'lore > engine', although not perhaps in the same way... And I think the @ with sufficient fields is more than sufficient to do that, eg: @ I'm concerned about the keyword stuff however. I'm presuming that this is supposed to mean that if I say 'orc' to an NPC, if it has any lore that has that as a keyword, it would respond. But this seems very random - that npc now needs to provide some clue as to what it knows about - if it is just a matter of randomly guessing what the npc knows about, that is completely useless. And at that level, why not just design proper NPC's with bits of information. No matter what you do, properly designed NPC's will still be better than random lore. I will also note that in the original discussion of lore that the idea was for it to show up in things like books or other static sources, and not dynamic things like NPC's. Having lore show up in NPC's also requires the need to have some flag to say 'generate random messages from lore for this NPC'. You don't want to do this by default - first because it won't work well, but second, because you really don't want to this for every monster that could be generated - a fairly costly operation to do for something that is likely to be killed. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 29 11:34:10 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:05 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <5.1.0.14.0.20030428230349.00a6c460@postoffice.worldnet.att.net> Message-ID: On 29-Apr-03 Kevin R. Bulgrien wrote: > I have yet to see compelling argument for transmutation. I vote > against it. It smells like a big cheat. Well.. It is worth noting.. that the folks at AD&D were smart about transmutation as well. You could turn wood into metal, and vice-versa, and you could turn various metals into slag and tin. They knew better than to provide a general spell that does anything to anything, or a set of spells that was all encompassing. IIRC one use for them was that druids couldn't wear/wield metal. So you could transmute metal objects into wood. Of course.. it's been awhile, I could be mistaken. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 29 11:38:40 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:05 2005 Subject: [CF-Devel] Issues I'de like to bring up In-Reply-To: <3EAE0FEE.20308@sonic.net> Message-ID: On 29-Apr-03 Mark Wedel wrote: > Note however that what knowledge each NPC has (From lore) has to be > generated > once (at reset time). Eg, if each time you said 'hi', the script went > through > and grabbed a random piece of lore, that could basically mean you could talk > to > that same pc for a long time and it would tell you most everything. Isntead, > it > should have some number of knowledge pieces, and just repeat those. Well.. rather than that.. they should just clam up. An NPC could track who it has spoken to to some degree. Say for example a randomtalking NPC will only say 5 things to a player per reset. If you walked up to a stranger on the street and said "hello" 500 times, he would probably either hit you or shut up eventually. Also.. with something like an eliza engine, the NPC's could listen to player conversation, and generate useless little tidbits. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 29 23:41:40 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:06 2005 Subject: [CF-Devel] More Lore In-Reply-To: <001b01c1ef65$9c4fdee0$0802a8c0@KAMERIA> References: <000801c1ee6d$1f48df80$0802a8c0@KAMERIA> <3EAE276B.1020101@sonic.net> <001b01c1ef65$9c4fdee0$0802a8c0@KAMERIA> Message-ID: <3EAF5404.8060502@sonic.net> Just as aside, I've realized I'm spending a lot of time going in depth on responses, and then finding I don't have time to do anything else. So expect less detailed responses from me, but hopefully still with useful information. I understand your idea to have a lore system that covers everything we may want it to do. Better to design it once than multiple times. But at some level, I wonder if it really makes sense to try and grap information from maps instead of just having something like a 'scorn.lore' or a 'dungeon.lore' or whatever else - that lore file just being a freestanding file in the proper lore syntax. A lot easier to collect those. A lot easier for anyone else dealing with those maps in the future to find the lore information. As for collection, I'd prefer that the scripts be in perl and not python, largely because I know the former, and not the later. Which is probably related to why all the existing scripts are also in perl. However, that isn't a major point. server changes - I'd think something needs to be done to read in the lore file and process all the meanings (area, weighting, etc). As for file format, probably doesn't make a big difference - but do keep in mind that the server has to be able to parse it. And since we are taking raw data, I don't know if it makes a lot of sense to convert it to xml - one could certainly have an option in the collect script to also spew out xml if desired. AT some level, I'd prefer not to require yet more libraries to compile the server. It is not legal to have multiple arches with the same name, so the point of using the name to combine data doesn't really apply. But I otherwise think that idea is fine - the probability of lore information about an orc is only relative to the orc itself. However, in the broader picture, it seems we need some information about the probabilty of the lore for the archetype itself showing up. Eg, information about holy avengers should be less likely to show up than orcs. OTOH, maybe just keep it all even, so useful lore information is bound to show up - if we generate lore for all the archetypes, that is a lot of lore entries - enough that everything would be seemingly rare. map lore: As you mention, this is a trickier problem. Having it in the map header requires something like a maplore lore thurgond @chance 5 ... @chance 8 ... endlor lore scorn @chance 12 ... @chance 3 ... endlor endmaplore Which is still easy enough to to do - it all works as long as the containing names for it in the map header don't aren't the same as the lore delimiters. Or a seperate file could be used. I do agree it is a good idea to try and make collecting map lore automatic. At some level, however, that is different/unrelated to arch lore (eg, the same format for the lore in maps can be used in archetypes and vice versa. IT may just being it isn't meaningful in the archs, so that data is left blank). One addition I'd suggest to the lore header - a tag indicating the type of lore, eg, spell, monsters, person, place, item. Thus, books like 'Marks Tome of Rare Items' can show up and only contain lore about with the 'items' type. Perhaps that takes the place/is used as the location tag also, eg, instead of '@chance 5 place' it could be '@chance 5 "place:santo dominion"' can be made. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Tue Apr 29 23:58:48 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:06 2005 Subject: [CF-Devel] Adding New Stuff (again) - Requests and suggestions In-Reply-To: <5.1.0.14.0.20030428232633.00a6cec0@postoffice.worldnet.att.net> References: <200304261435.28116.mail-lists+cfdev@dogphilosophy.net> <200304251718.04237.mail-lists+cfdev@dogphilosophy.net> <200304260110.35514.mail-lists+cfdev@dogphilosophy.net> <3EAA42D2.50807@sonic.net> <200304261435.28116.mail-lists+cfdev@dogphilosophy.net> <5.1.0.14.0.20030428232633.00a6cec0@postoffice.worldnet.att.net> Message-ID: <3EAF5808.5040108@sonic.net> You make a lot of good points. Documentation is sorely lacking. IMO, one good design method is to write the doc for what you want to do before you do it. Post it out - this not only describes what you are doing, but can then act as the doc when done, with perhaps some updates as things move along. Giving some thought to what you right will probably make the code better also. That what to contribute is a tough one. It it hard to turn down code that will do something new and cool. However, at the same time, it is interesting to note how many new maps there are relative to new features. And arguably, maps requires less technical knowhow than coding something new into the game. However, I think trying to force people to do something may not be good. Eg, I'm required to make some maps before I can add some new feature, and it is the later that I'm more interested in doing. How good do you think the maps I create will really be? that said, there are certainly some issues. People seem much more inclined to work on new features than fix bugs, yet arguably this second point is more important. As far as date files at load time: There is already a lot more stuff that can be set at load time than in the past - settings, exp, etc. However, at the same time I look at some of the files that are there (spell_params, skill_params) and really wonder how often people actually touch them, and if they had to re-compile the server to make the change, would that be a show stopper? Arguable, the spell_params and skill_params are the worst examples - compiled in defaults + files that get loaded at run time. It seems to me the right thing is basically one or the other - compile in or load at run time. There is also the 'races' file, which IMO is probably even worse - it jsut takes archetype information and changes it at load time. Better solution would be to just update the archs with the right information than using that file. Perhaps to me the bigger issue of making everything setable in load time files is where does it end? There is a lot of data that could generated at load time, but there is an issue of return on investment, so to speak. Computer speed has incrreased a lot faster than code growth in crossfire, to the extent that a full compile of crossfire probably takes just a minute or two on a fast computer. That said, I could certainly see pulling some data into more central include files. In the example of order of skills being searched for, having that in the skills.h file probably makes more sense than embedding it in some .c file. And .h files tend to change less, so any patches that may be necessary ahve better odds of applying. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 30 00:05:16 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:06 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: References: Message-ID: <3EAF598C.6070401@sonic.net> Tim Rightnour wrote: > On 29-Apr-03 Kevin R. Bulgrien wrote: > >>I have yet to see compelling argument for transmutation. I vote >>against it. It smells like a big cheat. > > > Well.. It is worth noting.. that the folks at AD&D were smart about > transmutation as well. You could turn wood into metal, and vice-versa, and you > could turn various metals into slag and tin. > > They knew better than to provide a general spell that does anything to > anything, or a set of spells that was all encompassing. > > IIRC one use for them was that druids couldn't wear/wield metal. So you could > transmute metal objects into wood. Of course.. it's been awhile, I could be > mistaken. Note that live action/human moderated games have the big advantage that a human does moderate them. A good GM can mitigate most any issue. The iron to gold spell? Well, that now gold shield sure looks like gold and acts like gold, but for some reason, when you try to melt it down, it reverts to brass. And the GM can also adjust the economy - there really just aren't that many people that will pay for gold armor. that said, you do raise an interesting point in the current code - the code right now has logic for adjusting within the same material type (iron -> brass for example), but nothing for going between radically different materials (iron -> wood). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 30 03:10:04 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:06 2005 Subject: [CF-Devel] Materials (was FW: DIAMONDS) In-Reply-To: <3EAF598C.6070401@sonic.net> Message-ID: On 30-Apr-03 Mark Wedel wrote: > Note that live action/human moderated games have the big advantage that a > human does moderate them. Well.. Mostly my point was.. the people at TSR were smart enough to know if you let people change bronze -> gold, you'd have a mess on your hands. Such a spell/ability/whatever is absurd. But is there anything wrong with changing iron to bronze? I think transmutation is a fine thing, it's just that you have to be selective about what you let people transmute something into. Platinum->gold seems fine to me.. lead->gold seems absurd. If we do it.. we have to think about the results of each transmutation, thats all. A fine thing IMHO would be to have a druid class that could only wear wood/hide. Such a class might benefit from turning rings/amulets into wood. Just an example of course.. > that said, you do raise an interesting point in the current code - the code > right now has logic for adjusting within the same material type (iron -> > brass > for example), but nothing for going between radically different materials > (iron > -> wood). I think it would be trivial to implement. All you need is a little chart with some base values. Say we take iron as the "base" material.. we say iron has a value and weight of 100. Now we just set "pine" to say, 80, 80. Now if you wanted to transmute mithril->oak you do: mithril->iron->pine->oak. Easier that way as we only have to have one set of transmutation values between types.. and we don't have to caluclate iron->oak, iron->spruce, iron->balsa. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 30 09:48:28 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:06 2005 Subject: [CF-Devel] More Lore References: <001b01c1ef65$9c4fdee0$0802a8c0@KAMERIA> Message-ID: <8446.1051714108@www37.gmx.net> Todd Mitchell wrote: > [...] I am primarily concerned with establishing a good and useful > repository of lore. How this is used in the game is of interest at > the moment only in that it is properly supported by the data format. > [...] I agree with the proposals concerning lore from you and from Mark. > [...] > I did suggest a lore field in the map header but this > was not well regarded at first [...] I recommend to put map lore into the map header. This makes it clear where the data is, and appears much easier "to handle". When I think about supporting it in the JavaEditor for example, if the lore was stored in objects, I'd need to implement a fairly big and complicated logic to generate and manage these very special objects. That seems wrong to me because the map header is the perfect place to store any amount of "special data" easily. The other thing with (map)lore objects is that future developers will be tempted to start using the object/attribute datafields of the maplore *object* (For example using "level" or "other_arch" to store some information). This kind of functionality is then not available for lore in arches, so the system gets incompatible. In the map header, the lore data is limited to the space between "lore ... endlore", which is exactly how it works in the arches. Mark has proposed the following: maplore lore thurgond @chance 5 ... @chance 8 ... endlor lore scorn @chance 12 ... @chance 3 ... endlor endmaplore I just wanted to ask: Is it really neccessary to have more then one lore field in the map header? Wouldn't it be easier to add the keywords per lore entry (like "@chance 5, scorn") rather than creating kind of different sections? Assuming that map lore contains information only related to that one particular map, it seems like one single keyword could do for the entire maplore block anyways. However, I'm just making suggestions here. I don't mind if you do it different, as long as the maplore is in the map header. ;-) AndreasV -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 30 18:27:51 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:06 2005 Subject: [CF-Devel] skills and classes Message-ID: As of now, a player's class has little impact on the game beyond level 10 or so. exeption : monk (-weapon,+meditation) Idea: Give skill boni/mali similar to spellpath attunements with each class. Eg.: alchemist : +7 alchemy, -1 melee ... Effect: alchemist would be 7 levels higher in alchemy then their exp. in that skill category would indicate. We don't have to implement negative levels. For mali like -1 we then just add -1 if level > 1. exp. 0* 2000 4000 8000 skill +0 1 2 3 4 alch. +7 8 9 10 11 melee -1 1 1 2 3 * if one has this skill of course. This would also mean, an alchemist might reach level 117 in alchemy, but only level 109 in melee. Especially with the new skill system, we could make the class influence the whole players life without just denying skills. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel-admin at archives.real-time.com Wed Apr 30 19:50:28 2003 From: crossfire-devel-admin at archives.real-time.com (crossfire-devel-admin@archives.real-time.com) Date: Thu Jan 13 17:54:06 2005 Subject: [CF-Devel] More Lore In-Reply-To: <001c01c1f028$feddee80$0802a8c0@KAMERIA> References: <000801c1ee6d$1f48df80$0802a8c0@KAMERIA> <3EAE276B.1020101@sonic.net> <001b01c1ef65$9c4fdee0$0802a8c0@KAMERIA> <3EAF5404.8060502@sonic.net> <001c01c1f028$feddee80$0802a8c0@KAMERIA> Message-ID: <3EB06F54.5080909@sympatico.ca> > > >...You know the more I think about it (and I didn't plan on writing this >till just now...), a maplore arch with only a name and a lore field wouldn't >be that bad, it wouldn't require any changes to server or editor at all (add >a lore field to a marker perhaps?--what the heck is the marker for anyway) >would work in both map editors by default, and they would show up in the map >editor as a big bright letter L icons just waiting to be clicked on by map >makers much like the creators or no_magic arches or other system arches >do... It would automatically add lore to the maps in a usable format and >use the same collection routines as the arch lore, and It wouldn't be any >more of a hassle than managing a handful of connectors really... > >arch >Object >face maplore.111 >name >lore >endlore >invisible 1 >no_pick 1 >end > > > Jeez, the marker arch was the wrong arch to pick as an example wasn't it? Ok, how hard would it be to make a attribute page for an invisible arch with a name field, and a lore tab for the java editor (yes I forgot you'd still have to add the lore field to most of the attribute forms in the java editor Andreas, hopefully that is pretty simple - same as mesg field right?). I think this will work pretty good, it's still easier than any other way I can think of since all the mechanisms are there to make it work already (except for a pretty attribute page to fill in the lore in the java editor, but you can still enter it ). I'll even include a screen shot. Every thing else can be managed inside the lore field anyway. -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-3.png Type: image/png Size: 56596 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030430/7e2e354d/Screenshot-3.png From temitchell at sympatico.ca Tue Apr 1 10:11:30 2003 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:03:10 2005 Subject: [CF-Devel] Fw: unique-map recycling Message-ID: <000601c26646$8c9ae320$0802a8c0@ott.ca.dmr> This I sent a few days ago, but it never arrived, here it is again: I have an question about trying to clean up unique maps. I added a function that will delete the relevant map files in unique items when someone sells a lot (or recycle the maps when they quit) and that works well, the proper files are deleted and the lots file updates correctly but since these maps could be in memory or temp map or something, when they are swapped out the files are recreated in unique-items (this is also a pain when testing maps with unique floors, I find I have to stop the server, then delete the unique item maps). Is there a way to flush the maps or otherwise refresh the map so that a new version is taken from the maps directory on the next load? For example if I could flush the map then delete it and ready an new one? I could overwrite the map in unique-items but wouldn't it still be overwritten again by the server with the old information when it leaves memory?\ Also what if someone else is on the map when it is sold (could check for this when selling I guess, but what about when a player quits since I can't stop them from quiting can I?). Since these are regular maps with some unique floors, it is possible someone could be on the map (although not in the 'house' part of the map). Geez, it all seemed so simple at the outset... From temitchell at sympatico.ca Tue Apr 1 10:11:33 2003 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:03:10 2005 Subject: [CF-Devel] CVS References: <000501c265be$54f18060$0a02a8c0@kameria> <20020926195444.G11476@real-time.com> <000c01c265c2$be613e60$0a02a8c0@kameria> <3D93FC2D.2070204@sonic.net> Message-ID: <000601c26680$18f74320$0a02a8c0@kameria> Must have been a glitch I tried what you suggested, then I tried after installing Flex and Bison - nada. Anyway I ended up checking out the whole CVS again and doing a clean build and it works now. Anyway was good, since I also noticed the Python plugin Makefile is built properly now too. From andi.vogl at gmx.net Wed Apr 2 09:35:05 2003 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:03:10 2005 Subject: [CF-Devel] improved Aljwaf for Bigworld In-Reply-To: <000501c27812$0542bf00$0a02a8c0@kameria> Message-ID: <000001c27866$a62539d0$c86ebb81@gizmo> Todd Mitchell wrote: > I bulked up the Aljwaf quest for the Bigworld maps - this > includes a good chunk of desert and a bigger ruin with more > buildings. You can check it out at > http://abraxis.sytes.net/CF/finished/bigworld These maps are very cool. I especially like the mystical touch about Aljwaf's tomb, and the "special effects" like duststorms in the desert. I'm sure Mark will include them into the bigworld set when he has time. > I must say there are a lot of nice features in the > CFJavaEditor these days. This was the first time I have spent > a bit of time with it and I really noticed the improvements. > Especially like the help tips which are really helpful > (don't do this - this works like this...) Thank you, makes me happy to read that. :-) > Two minor requests however - I would like to see the > attack_movement codes done the same way as damage and > material (so I don't have to look them up). Yes, I would like to do that. The problem with attack_movement is that it's not just a bitmask - It's basically a value (attack movement) summed together with a bitmask (unagressive movement). IMO that's one of the really good examples how arch attributes should *not* be used. Anyways, I'll try to come up with some kind of easy-to-use interface. Might take me a while though. > The other thing is if more info for stuff like speed, ac, > weapon damage and the like could be added to the tool tips > (like ranges - say ac the lower the better, speed high - low > (negative sign is for...). This is a bunch of different things. I'll comment on the various attributes you mentioned: ac: Armour class is currently (briefly) explained in the help text (the '?'-buttons in the attribute dialogs). I got it wrong for monsters though: It should state there lower is better, I'll correct that. weapon damage: This is explained pretty detailed, but example ranges are missing. The reason is there are no clear ranges AFAIK, and the value gets influenced by so many factors too. I expressed that in the statement: "Look at existing weapons to get a feel for the range of weapon damage values." I know that is sort of shady, but it was my best shot. :) speed: Most of the time, speed is used for animation speed. As you know, the CFJavaEditor does not support animations yet. I plan to add that at some point, and by that time I'll also decide how to best explain animation speed. So far I explained speed only where it is used for different purposes, like movement speed. Generally, extending the help-texts is quite easy. You, or anyone, is welcomed to send me propositions for better help-texts in the JavaEditor. AndreasV From root at garbled.net Thu Apr 3 17:13:01 2003 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:03:10 2005 Subject: [CF-Devel] Monsters sleeping Message-ID: So I've noticed recently there was a change to make monsters far away from you sleep. I'm wondering if this is having the intended effect. What I see, is that areas that used to be packed end-to-end with monsters, are now containing one or two, and a generator at the back of the room. Someone on IRC mentioned that this is due to the monsters sleeping, and blocking the generators. It doesn't really have the old "gauntlet" feel when everything is just a big empty room. But thats just my opinion. I've also found that my spells are a lot less useful, as I can't area-blast a horde anymore, I have to run around picking them off singly. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From root at garbled.net Thu Apr 3 19:27:50 2003 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:03:10 2005 Subject: [CF-Devel] Money issues Message-ID: So, through my own playing, and listening to my friends at work who I've hooked on the game.. I've noticed a few problems with the money system. (umm duh) Basically, one problem is, that other than for the most basic of goods, shops are completely useless. 1) When you are low level, you could *really* use the stuff you find in shops. Unfortunately, it's all so high priced, you can't afford it. 2) When you finally can afford it, you don't need it anymore. 3) Now that you have all this dough.. you just end up either collecting piles of gems, or wandering about looking for various niche items, like a ring of elrond. 4) eventually, money becomes wholly useless. I think I can solve the first three of these. #4 is more complex, because it deals with the issue of what does a super-high-level player really need to buy anyhow? So I think we should leave that one for later. Anyhow, here is my three part solution: 1) Greatly reduce the selling price and value of most common goods. Scrolls, wands, staves, potions, armor, weapons. This allows low level charactrers and newbies, which are arguably the only people who use this stuff, to actually buy them from shops. 2) Increase the frequency things like books scrolls and whatnot appear on the low level maps. 3) Make high level stores. The third point is the most important. What we should do, is make a list of the towns, and crank the level of the shops in those towns. That way, more high-level goodies will appear there. It gives mid-level players somehwere to spend thier money. Especially given that high level shops will start to have things like random-artifacts pop up, with much greater frequency. Ideally, the highest level shops, should pretty much be completely stocked by random-artifacts. For example, and just off the top of my head: Scorn: leave it alone Wolfsburg: level 3-4 Navar: level 5-6 Santo Dominon: level 7-8 Brest: level 9-10 --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From tanner at real-time.com Wed Apr 16 22:34:04 2003 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:10 2005 Subject: [CF List] Testing Message-ID: <20030416222055.A12476@real-time.com> Testing From tanner at real-time.com Wed Apr 16 22:34:05 2003 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:11 2005 Subject: [CF List] Testing Message-ID: <20030416221222.A12173@real-time.com> Testing From tanner at real-time.com Wed Apr 16 22:34:06 2003 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:11 2005 Subject: [CF List] Testing Message-ID: <20030416221159.A11867@real-time.com> Testing From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:40:43 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:11 2005 Subject: [CF List] What to do after Beginner phase? References: <86heampn4z.fsf_-_@cail.esc.pike.il.us> Message-ID: <3E62BBE4.5090808@sonic.net> Aaron Baugher wrote: > Does anyone have any suggestions where I should go for a decent, > not-totally-lethal challenge as a 6-8 level summoner? I have no > trouble starting a new character and going through the beginner areas > in Scorn, getting my character up to level 6 or so. But then it seems > like I stall; every area I enter either has critters too low-level to > be worth any experience, or I get wasted right away by something way > out of my league. So I bounce around between levels 5-9 or so, > gradually losing attribute points with each death. > > So, any places I should explore that'll have a decent number of > monsters in the pirate/ghost/viking range of competition? The smuggler quest in navar city has a bunch of pirates/ghosts. However, there are some other tough monsters tossed in their (fairy dragons I think), but perhaps doing the first couple levels could give you something. The crossfire website (http://crossfire.real-time.com/) does have a map listing by level. Unfortunately, some of them are pretty small/short maps, so don't get a lot of a reward. _______________________________________________ crossfire-list mailing list crossfire-list@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-list From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:40:48 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:11 2005 Subject: [CF List] 1 crossfire-list admin request(s) waiting Message-ID: <20030316230003.7255.98094.Mailman@pirate.real-time.com> The crossfire-list@lists.real-time.com mailing list has 1 request(s) waiting for your consideration at: https://mailman.real-time.com/mailman/admindb/crossfire-list Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: dstuart@rogers.com on Fri Mar 14 22:25:01 2003 Cause: Post by non-member to a members-only list From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:40:50 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:11 2005 Subject: [CF List] Undeliverable Mail Message-ID: <10303050601.AA02188@theperlguru.com> Delivery failed 20 attempts: phil@micronetix.com Original message follows. Received: from SMTP32-FWD by theperlguru.com (SMTP32) id A00000858; Tue, 4 Mar 2003 20:46:35 -0500 Received: from pirate.real-time.com [208.20.202.13] by theperlguru.com with ESMTP (SMTPD32-5.05) id A6FB2CDE0140; Tue, 04 Mar 2003 20:46:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=pirate.real-time.com) by pirate.real-time.com with esmtp (Exim 4.11 #5 (Red Hat Linux)) id 18qOGI-0000ac-00; Tue, 04 Mar 2003 20:04:02 -0600 Received: from enchanter.real-time.com ([208.20.202.11] ident=[JqQg7VEcrr/pONUGdvBTEIXT7828IdBj]) by pirate.real-time.com with esmtp (Exim 4.11 #5 (Red Hat Linux)) id 18qOFw-0000aM-00 for ; Tue, 04 Mar 2003 20:03:40 -0600 Received: from enchanter.real-time.com (IDENT:nNITOjr4rlFy4tWe/EMC7xFqgBXqvVaF@localhost [127.0.0.1]) by enchanter.real-time.com (8.12.8/8.12.8) with ESMTP id h251gmul027247 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 4 Mar 2003 19:42:48 -0600 Received: from localhost (leaf@localhost) by enchanter.real-time.com (8.12.8/8.12.8/Submit) with ESMTP id h251gl8F027243 for ; Tue, 4 Mar 2003 19:42:47 -0600 X-Authentication-Warning: enchanter.real-time.com: leaf owned process doing -bs Date: Tue, 4 Mar 2003 19:42:47 -0600 (CST) From: Rick Tanner To: "crossfire-list@lists.real-time.com" Subject: Re: [CF List] Enchanting Weapons In-Reply-To: <86r89ngva6.fsf@cail.esc.pike.il.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -3.2 (---) X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *18qOFw-0000aM-00*kMbsuHo5grw* Sender: crossfire-list-admin@lists.real-time.com Errors-To: crossfire-list-admin@lists.real-time.com X-BeenThere: crossfire-list@lists.real-time.com X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: crossfire-list@lists.real-time.com [message truncated] From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:40:53 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:11 2005 Subject: [CF List] 1 crossfire-list admin request(s) waiting Message-ID: <20030317230002.32332.64299.Mailman@pirate.real-time.com> The crossfire-list@lists.real-time.com mailing list has 1 request(s) waiting for your consideration at: https://mailman.real-time.com/mailman/admindb/crossfire-list Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: dstuart@rogers.com on Fri Mar 14 22:25:01 2003 Cause: Post by non-member to a members-only list From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:40:56 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:11 2005 Subject: [CF List] crossfire-list post from print15zxtprint2002@terra.com requires approval Message-ID: <20030401204559.23581.71634.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-list@lists.real-time.com From: print15zxtprint2002@terra.com Subject: Dont miss Print Supplies! Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-list to approve or deny the request. From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:40:58 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:11 2005 Subject: [CF List] What to do after Beginner phase? In-Reply-To: <3E62BBE4.5090808@sonic.net> References: <86heampn4z.fsf_-_@cail.esc.pike.il.us> <3E62BBE4.5090808@sonic.net> Message-ID: <86d6l8j5jv.fsf@cail.esc.pike.il.us> Mark Wedel writes: > The smuggler quest in navar city has a bunch of pirates/ghosts. > However, there are some other tough monsters tossed in their (fairy > dragons I think), but perhaps doing the first couple levels could > give you something. Thanks; I'll go check that out. Haven't been to Navar City yet. -- Aaron abaugher@esc.pike.il.us _______________________________________________ crossfire-list mailing list crossfire-list@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-list From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:41:02 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:12 2005 Subject: [CF List] Enchanting Weapons In-Reply-To: References: Message-ID: <3E6705B8.3030508@terra.es> There is an important point to know when enchanting weapons which in my opinion can be quite terrible. Usually, when you have many objects of the same kind but you need just a few of them, the system automatically gets only the required amount. For example, when dropping all your gold coins on a desk which only needs 20 of them. However, that's NOT the case with the potions used to improve weapon stats. It is not funny when you need 2 potions of str and, expecting only to use these 2, use your, say 30 potions of str, collected during all the time you have played, and find that all of them dissapear without any additional effect. -- Juan Segarra _______________________________________________ crossfire-list mailing list crossfire-list@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-list From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:41:05 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:12 2005 Subject: [CF List] crossfire-list post from cflist@gmx.li requires approval Message-ID: <20030331101906.7528.72995.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-list@lists.real-time.com From: cflist@gmx.li Subject: Re: [CF List] The 'dis'economy of crossfire] Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-list to approve or deny the request. From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:41:08 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:12 2005 Subject: [CF List] What to do after Beginner phase? In-Reply-To: <200303011624.25049.tanner@real-time.com> Message-ID: <86heampn4z.fsf_-_@cail.esc.pike.il.us> Does anyone have any suggestions where I should go for a decent, not-totally-lethal challenge as a 6-8 level summoner? I have no trouble starting a new character and going through the beginner areas in Scorn, getting my character up to level 6 or so. But then it seems like I stall; every area I enter either has critters too low-level to be worth any experience, or I get wasted right away by something way out of my league. So I bounce around between levels 5-9 or so, gradually losing attribute points with each death. So, any places I should explore that'll have a decent number of monsters in the pirate/ghost/viking range of competition? -- Aaron abaugher@esc.pike.il.us _______________________________________________ crossfire-list mailing list crossfire-list@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-list From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:41:09 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:12 2005 Subject: [CF List] crossfire-list post from abaugher@esc.pike.il.us requires approval Message-ID: <20030304024301.2499.42081.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-list@lists.real-time.com From: abaugher@esc.pike.il.us Subject: Re: [CF List] What to do after Beginner phase? Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-list to approve or deny the request. From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:41:11 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:12 2005 Subject: [CF List] Enchanting Weapons In-Reply-To: References: Message-ID: <86r89ngva6.fsf@cail.esc.pike.il.us> Rick Tanner writes: > You are correct - that's how you create weapons with attribute > bonuses. For instance, Longsword (Str +1). What if the weapon is already enchanted? I have a shortsword +2. Is it possible to use a 'Increase Strength Bonus' scroll on it? If so, do I have to use a 'prepare weapon' scroll first, or is it already prepared? > The prepare weapon scrolls can be hard to find. Like most things, > they are never around when you need them. ;) Guess I'll keep looking. Thanks, -- Aaron abaugher@esc.pike.il.us _______________________________________________ crossfire-list mailing list crossfire-list@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-list From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:41:12 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:12 2005 Subject: [CF List] What to do after Beginner phase? In-Reply-To: References: Message-ID: <86llzvj2fy.fsf@cail.esc.pike.il.us> Rick Tanner writes: > > Are you trying to gain experience (levels) in magic or physique? Both, I suppose. I've been advancing pretty evenly in magic and physique so far, with wisdom a level or two behind. > If it's magic experience - the golem spells is what you want. Such > as summon golem, summon air/earth/fire/water elemental, summon pet > monster, etc. Use them to do all your fighting for you. With the > spell (or helm of) xray, you can safely hide on the other side of > the wall and use the shift- keys to send your summoned > monster all over the map (within viewing site, of course..) Hmm, good idea. I'll have to run down that spell. I've been using the 'summon water elemental' spell quite a bit. > Great maps for using the golem spells are: > High Tower in Wolfsburg (top level) > Twin Towers in Wolfsburg I got 3/4 through this one, but the top level was just too tough. > Something else you could do is a hybrid warrior/mage. A balance > between protective armour and + Spell Point regneration gear. That's sort of what I'm trying to do. I managed to find a Robe +4, so I've got my AC pretty low without hurting my speed too much. Thanks for all the good suggestions. -- Aaron abaugher@esc.pike.il.us _______________________________________________ crossfire-list mailing list crossfire-list@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-list From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:41:14 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:12 2005 Subject: [CF List] 1 crossfire-list admin request(s) waiting Message-ID: <200209292200.g8TM0IK27140@sprite.real-time.com> The crossfire-list@lists.real-time.com mailing list has 1 request(s) waiting for your consideration at: https://mailman.real-time.com/mailman/admindb/crossfire-list Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: keggtumbleson@bolt.com on Sat Sep 28 17:37:46 2002 Cause: Post by non-member to a members-only list From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:41:15 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:12 2005 Subject: [CF List] cannot save In-Reply-To: References: Message-ID: <200303011624.25049.tanner@real-time.com> On Friday 28 February 2003 06:57 pm, Nep Arz wrote: > hi there, > > i cant save my character during the play, although it will create a > folder of the player's name, but still it wont save the character. > > > could you help me, please? Also check if you have enough disk space. We ran into this problem where disk was full and no one could save their characters. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 02E0 2734 A1A1 DBA1 0E15 623D 0036 7327 93D9 7DA3 _______________________________________________ crossfire-list mailing list crossfire-list@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-list From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:41:17 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:13 2005 Subject: [CF List] crossfire-list member wildman@md.prestige.net bouncing - disabled Message-ID: <20030301224101.21051.45672.Mailman@pirate.real-time.com> Content-type: text/plain; charset=us-ascii This is a Mailman mailing list bounce action notice: List: crossfire-list Member: wildman@md.prestige.net Action: Subscription disabled. Reason: Excessive or fatal bounces. You can reenable their subscription by visiting the membership management page at https://mailman.real-time.com/mailman/admin/crossfire-list/members and setting their options accordingly The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman-owner@lists.real-time.com. -------------- next part -------------- This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: wildman@md.prestige.net all relevant MX records point to non-existent hosts ------ This is a copy of the message, including all the headers. ------ Return-path: Received: from localhost.localdomain ([127.0.0.1] helo=pirate.real-time.com) by pirate.real-time.com with esmtp (Exim 4.11 #5 (Red Hat Linux)) id 18pFeD-0005S9-00; Sat, 01 Mar 2003 16:40:01 -0600 Received: from gatekeeper.real-time.com ([65.193.16.100]) by pirate.real-time.com with smtp (Exim 4.11 #5 (Red Hat Linux)) id 18pFdn-0005Ry-00 for ; Sat, 01 Mar 2003 16:39:35 -0600 Received: from guardian.castle.real-time.com by gatekeeper.real-time.com via smtpd (for pirate.real-time.com [208.20.202.13]) with SMTP; 1 Mar 2003 22:06:17 UT Received: from samurai.castle.real-time.com ([192.168.252.7]) by mail.castle.real-time.com with esmtp (Exim 4.11 #5 (Red Hat Linux)) id 18pFKN-00065u-00 for ; Sat, 01 Mar 2003 16:19:31 -0600 Received: from tanner by samurai.castle.real-time.com with local (Exim 4.11) id 18pFP7-0000Za-00 for crossfire-list@lists.real-time.com; Sat, 01 Mar 2003 16:24:25 -0600 Content-Type: text/plain; charset="iso-8859-1" From: Bob Tanner Organization: Real Time Enterprises, Inc. To: crossfire-list@lists.real-time.com Subject: Re: [CF List] cannot save Date: Sat, 1 Mar 2003 16:24:24 -0600 User-Agent: KMail/1.4.3 References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200303011624.25049.tanner@real-time.com> X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *18pFKN-00065u-00*52cy9TDNGSM* X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *18pFdn-0005Ry-00*i3vu32e7kPU* Sender: crossfire-list-admin@lists.real-time.com Errors-To: crossfire-list-admin@lists.real-time.com X-BeenThere: crossfire-list@lists.real-time.com X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: crossfire-list@lists.real-time.com X-Reply-To: tanner@real-time.com List-Help: List-Post: List-Subscribe: , List-Id: Crossfire Discussion Mailing List List-Unsubscribe: , X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *18pFeD-0005S9-00*E7cFJkIPFao* On Friday 28 February 2003 06:57 pm, Nep Arz wrote: > hi there, > > i cant save my character during the play, although it will create a > folder of the player's name, but still it wont save the character. > > > could you help me, please? Also check if you have enough disk space. We ran into this problem where = disk=20 was full and no one could save their characters. --=20 Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint =3D 02E0 2734 A1A1 DBA1 0E15 623D 0036 7327 93D9 7DA3 _______________________________________________ crossfire-list mailing list crossfire-list@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-list From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:41:18 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:13 2005 Subject: [CF List] crossfire-list post from abaugher@esc.pike.il.us requires approval Message-ID: <20030304013600.1106.67933.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-list@lists.real-time.com From: abaugher@esc.pike.il.us Subject: Re: [CF List] What to do after Beginner phase? Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-list to approve or deny the request. From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:41:20 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:13 2005 Subject: [CF List] Enchanting Weapons In-Reply-To: References: Message-ID: <993100000.1046748991@[192.168.200.4]> -- Rick Tanner > > You are correct - that's how you create weapons with attribute bonuses. > For instance, Longsword (Str +1). > > The prepare weapon scrolls can be hard to find. Like most things, they > are never around when you need them. ;) Frequently, you can get a significant bonus from using weapons of your god. For example, weapons blessed by the Devourers are quite functional (won't improve your stats). Until you can find the prepare scroll take a nearby +2 or +3 item and pray with it for a while. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 888 359 3508 _______________________________________________ crossfire-list mailing list crossfire-list@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-list From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:41:21 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:13 2005 Subject: [CF List] Enchanting Weapons In-Reply-To: <86fzq3j2as.fsf@cail.esc.pike.il.us> Message-ID: You are correct - that's how you create weapons with attribute bonuses. For instance, Longsword (Str +1). The prepare weapon scrolls can be hard to find. Like most things, they are never around when you need them. ;) - Rick On 3 Mar 2003, Aaron Baugher wrote: > I've found a few "Increase Bonus" scrolls, and the potions > to go with them. I'd like to use them, but if I'm reading the > handbook correctly, first I have to prepare the weapon by reading a > 'prepare weapon' scroll while standing on diamonds. But I can't find > such a scroll anywhere. Am I misunderstanding something here, or are > these scrolls just very rare? _______________________________________________ crossfire-list mailing list crossfire-list@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-list From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:41:23 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:13 2005 Subject: [CF List] crossfire-list post from abaugher@esc.pike.il.us requires approval Message-ID: <20030304130101.16598.16687.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-list@lists.real-time.com From: abaugher@esc.pike.il.us Subject: Re: [CF List] Enchanting Weapons Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-list to approve or deny the request. From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:41:25 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:13 2005 Subject: [CF List] crossfire-list post from abaugher@esc.pike.il.us requires approval Message-ID: <20030302015501.32464.28569.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-list@lists.real-time.com From: abaugher@esc.pike.il.us Subject: What to do after Beginner phase? Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-list to approve or deny the request. From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:41:26 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:13 2005 Subject: [CF List] 1 crossfire-list admin request(s) waiting Message-ID: <20030401230004.24541.40927.Mailman@sprite.real-time.com> The crossfire-list@lists.real-time.com mailing list has 1 request(s) waiting for your consideration at: https://mailman.real-time.com/mailman/admindb/crossfire-list Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: print15zxtprint2002@terra.com on Tue Apr 1 14:45:59 2003 Cause: Post by non-member to a members-only list From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:41:28 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:13 2005 Subject: [CF List] Crossfire Polls In-Reply-To: <000901c2ff4d$e7d732c0$0802a8c0@ott.ca.dmr> References: <000901c2ff4d$e7d732c0$0802a8c0@ott.ca.dmr> Message-ID: <3E9B95B0.7020003@sonic.net> Most polls should be taken with a grain of salt - especially those that don't have a none of the above type of answer (in which case people may still vote for something, like removing the swashbuckler, just because they have to vote for something. The reason some classses/races probably are popular vote getters for removal is because they aren't all that interesting. while theif may be one of the main 'areas' in traditional RPG's, it probably loses out in crossfire because it doesn't have any really great skills that make it more playable in some games. Mostrai as a god? Probably because it has the best low level enemies, and thus one of the best ways to get exp. animations: Would be really hard to provide a list of animations the player could choose from. Even easier now in that the players use the same animation logic as everything else, so you could even include non players (eg, pirate lass, etc). But there should probably be some limits - in some cases, like dragons, the race is the major factor. But for humanoid type races, there could be a large choice of images. As for the max hp/sp/grace thing, always nice to see confirmation - I'll see about coding it in. _______________________________________________ crossfire-list mailing list crossfire-list@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-list From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:41:30 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:13 2005 Subject: [CF List] failure notice Message-ID: <20030407194918.4625.qmail@kaazh.pair.com> Hi. This is the mail program processing your message. I'm afraid I wasn't able to deliver your message to the following address. This is a permanent error. : HTML email not accepted at this address --- Below this line is a copy of the message. >From crossfire-list-admin@lists.real-time.com Mon Apr 07 19:49:18 2003 Return-Path: Delivered-To: crowbert-crowcastle:net-pc-crossfire@crowcastle.net X-Envelope-To: pc-crossfire@crowcastle.net Received: (qmail 4618 invoked from network); 7 Apr 2003 19:49:18 -0000 Received: from pirate.real-time.com (208.20.202.13) by kaazh.pair.com with SMTP; 7 Apr 2003 19:49:18 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=pirate.real-time.com) by pirate.real-time.com with esmtp (Exim 4.12 #5 (Red Hat Linux)) id 192d37-0008Km-00; Mon, 07 Apr 2003 15:17:01 -0500 Received: from oe64.law8.hotmail.com ([216.33.240.199] helo=hotmail.com) by pirate.real-time.com with esmtp (Exim 4.12 #5 (Red Hat Linux)) id 192d2M-0008KZ-00 for ; Mon, 07 Apr 2003 15:16:14 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 7 Apr 2003 12:47:42 -0700 Received: from 68.118.224.17 by OE64.law8.internal.hotmail.com with DAV; Mon, 07 Apr 2003 19:47:41 +0000 X-Originating-IP: [68.118.224.17] X-Originating-Email: [sszretter@hotmail.com] From: To: Date: Mon, 7 Apr 2003 15:47:17 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01C2FD1C.F7B06780" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: X-OriginalArrivalTime: 07 Apr 2003 19:47:42.0156 (UTC) FILETIME=[8D6150C0:01C2FD3E] X-Spam-Score: 1.0 (+) X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *192d2M-0008KZ-00*3SZcJPhVVf6* Subject: [CF List] java client Sender: crossfire-list-admin@lists.real-time.com Errors-To: crossfire-list-admin@lists.real-time.com X-BeenThere: crossfire-list@lists.real-time.com X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: crossfire-list@lists.real-time.com List-Help: List-Post: List-Subscribe: , List-Id: Crossfire Discussion Mailing List List-Unsubscribe: , X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *192d37-0008Km-00*QxVKuAQfN1s* This is a multi-part message in MIME format. ------=_NextPart_000_002C_01C2FD1C.F7B06780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is anyone still working on / supporting a java based client? Just wondering, as I have been toying with it... ------=_NextPart_000_002C_01C2FD1C.F7B06780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Is anyone still working on / supporting = a java=20 based client?
Just wondering, as I have been toying = with=20 it...
 
------=_NextPart_000_002C_01C2FD1C.F7B06780-- _______________________________________________ crossfire-list mailing list crossfire-list@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-list From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:41:31 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:13 2005 Subject: [CF List] crossfire-list post from trhyne@mit.edu requires approval Message-ID: <20030401190029.22737.52002.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-list@lists.real-time.com From: trhyne@mit.edu Subject: Re: [CF List] New New Experience Scheme... Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-list to approve or deny the request. From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:41:33 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:13 2005 Subject: [CF List] crossfire-list post from tanner@real-time.com requires approval Message-ID: <20030417032813.1637.7520.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-list@lists.real-time.com From: tanner@real-time.com Subject: Testing Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-list to approve or deny the request. From crossfire-list-admin at archives.real-time.com Fri Apr 18 23:41:35 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:13 2005 Subject: [CF List] crossfire-list post from tanner@real-time.com requires approval Message-ID: <20030417032221.1637.55163.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-list@lists.real-time.com From: tanner@real-time.com Subject: Testing Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-list to approve or deny the request. From crossfire-list-admin at archives.real-time.com Sat Apr 19 00:08:59 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:13 2005 Subject: [CF List] 1 crossfire-list admin request(s) waiting Message-ID: <20030315230003.17221.58058.Mailman@pirate.real-time.com> The crossfire-list@lists.real-time.com mailing list has 1 request(s) waiting for your consideration at: https://mailman.real-time.com/mailman/admindb/crossfire-list Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: dstuart@rogers.com on Fri Mar 14 22:25:01 2003 Cause: Post by non-member to a members-only list From crossfire-list-admin at archives.real-time.com Sat Apr 19 00:09:12 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:13 2005 Subject: [CF List] crossfire-list post from prds1/centennialc@centennialcollege.ca requires approval Message-ID: <20030403063629.5211.92836.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-list@lists.real-time.com From: prds1/centennialc@centennialcollege.ca Subject: NAV detected a virus in a document you authored. Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-list to approve or deny the request. From crossfire-list-admin at archives.real-time.com Sat Apr 19 00:10:30 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:13 2005 Subject: [CF List] 1 crossfire-list admin request(s) waiting Message-ID: <20030418220002.629.2554.Mailman@sprite.real-time.com> The crossfire-list@lists.real-time.com mailing list has 1 request(s) waiting for your consideration at: https://mailman.real-time.com/mailman/admindb/crossfire-list Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: tanner@castle.real-time.com on Fri Apr 18 00:21:02 2003 Cause: Posting to a restricted list by sender requires approval From crossfire-list-admin at archives.real-time.com Sat Apr 19 00:11:05 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:13 2005 Subject: [CF List] crossfire-list post from tanner@castle.real-time.com requires approval Message-ID: <20030418052102.22162.67195.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-list@lists.real-time.com From: tanner@castle.real-time.com Subject: (no subject) Reason: Posting to a restricted list by sender requires approval At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-list to approve or deny the request. From crossfire-list-admin at archives.real-time.com Sat Apr 19 00:11:12 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:14 2005 Subject: [CF List] crossfire-list post from tanner@real-time.com requires approval Message-ID: <20030417031328.1427.61594.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-list@lists.real-time.com From: tanner@real-time.com Subject: Testing Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-list to approve or deny the request. From crossfire-list-admin at archives.real-time.com Sat Apr 19 00:11:39 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:14 2005 Subject: [CF List] 1 crossfire-list admin request(s) waiting Message-ID: <200210232200.g9NM02v13940@sprite.real-time.com> The crossfire-list@lists.real-time.com mailing list has 1 request(s) waiting for your consideration at: https://mailman.real-time.com/mailman/admindb/crossfire-list Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: mo2003_20021018_3606@2mbb.com on Tue Oct 22 07:04:04 2002 Cause: Post by non-member to a members-only list From crossfire-list-admin at archives.real-time.com Sat Apr 19 00:11:41 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:14 2005 Subject: [CF List] crossfire-list post from rockhiren@hotmail.com requires approval Message-ID: <20030403164248.9867.35729.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-list@lists.real-time.com From: rockhiren@hotmail.com Subject: Worm Klez.E immunity Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-list to approve or deny the request. From crossfire-list-admin at archives.real-time.com Sat Apr 19 11:08:21 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:14 2005 Subject: [CF List] Crossfire Polls In-Reply-To: <003101c3036e$72c67340$0802a8c0@ott.ca.dmr> References: <000901c2ff4d$e7d732c0$0802a8c0@ott.ca.dmr> <3E9B95B0.7020003@sonic.net> <003101c3036e$72c67340$0802a8c0@ott.ca.dmr> Message-ID: <3E9CF0EC.1050500@sonic.net> > Oh yes, I am personally against having say gnome players choose a huge > barbarian animation type of thing, and would prefer to use race specific > animations (a gnome is a gnome is a gnome!), but it seems I am in the > minority here. I am currently working on animating the player faces so once > I get the basics done (still lots of 'classic' animations to do here) it is > likely I will start adding a few filler animations like halflings in heavy > armor or gnome wizards. It shouldn't be too hard to make face changing > booths or whatever. I am esthetically against using just any old animation > for a player face - they should all be four direction at least... I would > like to add an option in the hall of selection however where you can pick no > class but get a wack of money and entrance to a little shop to buy a few > skills or other useful items. This might be a backdoor way to encourage > people to use the racial player animations... The animation stuff is a more a matter of opinion. As long as it is a valid image, I wouldn't have a problem if a player chose a non animated or other than fully animated figure. It is up to the players to figure out what looks best. The animation stuff is also tricky. My wizard may not really look like that image - I may very well equip some real armor, and thus should look more like a fighter. To some extent, race would play a major role - halfling, dwarf, dragon, etc. However, there are several large human races - northman, half orc, viking, etc, which as far as a race would look would be pretty similar. For these races, class (or more precisly, equipment) is what would really determine what someone looks like. The tricky part is knowing what animations a particular race could choose from. As far as skill selection - not positive on that. A player that buys melee weapon and other combat type skills may still consider themselves a fighter, even if they don't have the name proper. I'm also concerned about the balance of any such system. If you don't give enough, no one takes that option. If you give too much, everyone takes it (why shoudl I take wizard class when I can buy it for cheaper if I don't choose a class). Many classes are balanced by giving stat bonus, equipment bonuses, or minor skills. OTOH, allowing players to buy everything does allow for more customization then you get now. > > > > > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list _______________________________________________ crossfire-list mailing list crossfire-list@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-list From crossfire-list-admin at archives.real-time.com Sat Apr 19 11:08:23 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:14 2005 Subject: [CF List] Crossfire Polls Message-ID: <20030416133208.QEHH26395.tomts22-srv.bellnexxia.net@[209.226.175.18]> > I'm also concerned about the balance of any such system. If you don't give > enough, no one takes that option. If you give too much, everyone takes it (why > shoudl I take wizard class when I can buy it for cheaper if I don't choose a class). > > Many classes are balanced by giving stat bonus, equipment bonuses, or minor > skills. OTOH, allowing players to buy everything does allow for more > customization then you get now. > What I was thinking was a significantly lower amount than you would get by choosing a class, but not so low that it is stupid to choose a race only. The only issue I see is failing to learn the skills you bought. I think that people would do it enough that it would be worth doing. Then again, maybe no one would do it. _______________________________________________ crossfire-list mailing list crossfire-list@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-list From crossfire-list-admin at archives.real-time.com Sat Apr 19 11:10:02 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:14 2005 Subject: [CF List] java client Message-ID: Is anyone still working on / supporting a java based client? Just wondering, as I have been toying with it... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030419/4ea58426/attachment.htm From crossfire-list-admin at archives.real-time.com Sat Apr 19 11:10:04 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:14 2005 Subject: [CF List] Crossfire Polls Message-ID: <000901c2ff4d$e7d732c0$0802a8c0@ott.ca.dmr> There are a bunch of Polls on the official Crossfire website. They have been around for a while so I thought I would give a rundown on the results so far. I only looked at the polls with more than 20 votes and which weren't totally stupid* (just a bit stupid was ok however). I couldn't resist adding in witty and not so witty commentary. *************************** What are you most interested in seeing more of in Crossfire? *************************** New spells 26.87 % (18) New skills 28.36 % (19) New races 13.43 % (9) New monsters 11.94 % (8) New potions 1.49 % (1) New weapons 5.97 % (4) New foods 2.99 % (2) New armour 4.48 % (3) New rings 2.99 % (2) New amulets 1.49 % (1) Total votes: 67 --well this is clear enough, people want to see new skills and spells. Is this an indication of the desire for character development, or is it a reflection of everyone who voted being level 110 and having infinite wealth? *************************** If you had the unpleasant task of dropping one player race from Crossfire, which one would it be? *************************** Dwarf 2.44 % (1) Dragon 0.00 % (0) Elf 0.00 % (0) Fireborn 7.32 % (3) Gnome 2.44 % (1) Half-Orc 14.63 % (6) Halfling 7.32 % (3) Human 4.88 % (2) Northman 21.95 % (9) Quetzalcoatl 24.39 % (10) Troll 7.32 % (3) Wraith 7.32 % (3) Total votes: 41 -- People don't like the Q... Is it because the dragon is so much better? The Northman and the Half-orc are also unpopular, probably because of the simularity to the human. Of course every one likes an elf and dragons are truly different which can account for their popularity (or perhaps I shouldn't imply votes against as votes for) Now what is really surprising is that there were two votes to ditch humans...good old standard baseline humans. *************************** If a character class in Crossfire was to be removed, which would you choose? *************************** Alchemist 2.63 % (1) Barbarian 5.26 % (2) Devotee 10.53 % (4) Evoker 5.26 % (2) Monk 2.63 % (1) Ninja 23.68 % (9) Paladin 0.00 % (0) Priest 0.00 % (0) Sorcerer 0.00 % (0) Summoner 5.26 % (2) Swashbuckler 34.21 % (13) Thief 5.26 % (2) Warlock 5.26 % (2) Warrior 0.00 % (0) Wizard 0.00 % (0) Total votes: 38 -Oooh the Swashbuckler takes it on the chin. Did he sleep with *everyone's* daughter or what? *************************** Boy, I like Crossfire. My favorite part of the game is: *************************** Killin' things 8.33 % (4) Solving the quests 33.33 % (16) Knocking around town meeting people, goofing off 4.17 % (2) Collecting neat and powerful items 22.92 % (11) Fighting other players 2.08 % (1) Building a unique character 29.17 % (14) Total votes: 48 --Player vs Player isn't very popular despite the effort given to accommodate this (arenas and proposed deathmatches and such). *************************** Which class do you like to play the most? *************************** Alchemist 2.94 % (1) Barbarian 2.94 % (1) Devotee 0.00 % (0) Evoker 0.00 % (0) Monk 11.76 % (4) Ninja 2.94 % (1) Paladin 8.82 % (3) Priest 5.88 % (2) Sorcerer 5.88 % (2) Summoner 2.94 % (1) Swashbuckler 0.00 % (0) Thief 0.00 % (0) Warlock2 0.59 % (7) Warrior 14.71 % (5) Wizard 20.59 % (7) Total votes: 34 -Wizards and Warlocks and Warriors. Surprising that the Thief did so poorly considering he is one of the Big Four in the genre. Maybe those new skills will shake this up a bit. *************************** What is your favorite Crossfire player race? *************************** Dwarf 5.88 % (2) Dragon 20.59 % (7) Elf 11.76 % (4) Fireborn 14.71 % (5) Gnome 0.00 % (0) Half-Orc 0.00 % (0) Halfling 2.94 % (1) Human 23.53 % (8) Northman 14.71 % (5) Quetzalcoatl 5.88 % (2) Troll 0.00 % (0) Wraith 0.00 % (0) Total votes: 34 --Humans beat out the dragons and the northmen are more popular than the elves? I wonder what this says about how people voted in the previous poll about dropping a race? *************************** Which Crossfire cult do you find most fun to worship? *************************** Gnarg 3.03 % (1) Lythander 3.03 % (1) Mostrai 36.36 % (12) Gaea 15.15 % (5) Devourers 12.12 % (4) Ruggilli 0.00 % (0) Gorokh 3.03 % (1) Valriel 15.15 % (5) Sorig 12.12 % (4) Total votes: 33 --Mostrai wins by a landslide. I hope that the faithful were not stuffing the ballot box here. *************************** Which Crossfire cult is your least favorite? *************************** Gnarg 20.00 % (4) Lythander 5.00 % (1) Mostrai 0.00 % (0) Gaea 20.00 % (4) Devourers 10.00 % (2) Ruggilli 10.00 % (2) Gorokh 5.00 % (1) Valriel 10.00 % (2) Sorg 20.00 % (4) Total votes: 20 --The next question I guess is why. *************************** If Crossfire was a desert item, which desert item would it be? *************************** Jello 10.71 % (3) Ice Cream 25.00 % (7) A Nice Cakey Treat 17.86 % (5) A Slice of Pie 14.29 % (4) Jam Tart 10.71 % (3) Ichor 21.43 % (6) Total votes: 28 - Is it safe to say Crossfire is like an Ichor flavoured Ice Cream? *************************** Do you like maps that have darkness set? *************************** I like the darkness, it is spooky. 66.67 % (18) I turn darkness off in the client - it's a pain. 33.33 % (9) Total votes: 27 - Pretty much what you'd expect. *************************** How would you like to see all characters represented? *************************** The race (troll, elf, dwarf, etc.) 22.73 % (5) The class (wizard, thief, ninja, etc.) 13.64 % (3) I think you should to be able to pick either one. 63.64 % (14) Total votes: 22 --People want to pick out their character face. *************************** Is a Crossfire client for Windows important? *************************** Yes! 74.36 % (29) Yes, but I'm not sweating it. 17.95 % (7) I don't care really 0.00 % (0) No 2.56 % (1) Burn in hell! 5.13 % (2) Total votes: 39 --Silly question I guess. I am surprised there isn't more I don't care really votes. *************************** Is a Crossfire client for MacOS important? *************************** Yes! 54.17 % (13) Yes, but I'm not sweating it. 16.67 % (4) I don't care really. 20.83 % (5) No. 4.17 % (1) Who's this Mac fellow? 4.17 % (1) Total votes: 24 --Again, not surprising. I am sure that people would vote for a Amiga version of Crossfire as well. *************************** Should characters start with max HP/SP/Grace at first level? *************************** Yes 72.73 % (24) No 27.27 % (9) Total votes: 33 - Looks like a popular idea. Well that's it for now. I am sure there will now be a flood of voting as people try to sway opinion. Thanks to Rick Tanner for putting up the polls in the first place. * before you gasp in shock at my rudeness - I wrote the totally stupid ones and somehow tricked Rick into putting them up. _______________________________________________ crossfire-list mailing list crossfire-list@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-list From crossfire-list-admin at archives.real-time.com Sat Apr 19 11:10:16 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:14 2005 Subject: [CF List] 1 crossfire-list admin request(s) waiting Message-ID: <200210242200.g9OM05v24569@sprite.real-time.com> The crossfire-list@lists.real-time.com mailing list has 1 request(s) waiting for your consideration at: https://mailman.real-time.com/mailman/admindb/crossfire-list Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: mo2003_20021018_3606@2mbb.com on Tue Oct 22 07:04:04 2002 Cause: Post by non-member to a members-only list From crossfire-list-admin at archives.real-time.com Sat Apr 19 11:10:22 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:14 2005 Subject: [CF List] Warning: could not send message for past 1 hour Message-ID: <200303221826.h2MGQFgA023584@blake.timetraveller.org> ********************************************** ** THIS IS A WARNING MESSAGE ONLY ** ** YOU DO NOT NEED TO RESEND YOUR MESSAGE ** ********************************************** The original message was received at Sun, 23 Mar 2003 02:26:15 +1000 from [202.83.74.222] ----- Transcript of session follows ----- <<< DATA 451 4.4.1 collect: I/O error on connection from [202.83.74.222], from= Warning: message still undelivered after 1 hour Will keep trying until message is 2 days old -------------- next part -------------- Skipped content of type message/delivery-status-------------- next part -------------- An embedded message was scrubbed... From: crossfire-list-admin@lists.real-time.com Subject: no subject Date: Sun, 23 Mar 2003 02:26:15 +1000 Size: 1358 Url: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030419/7f9b60e2/attachment.mht From crossfire-list-admin at archives.real-time.com Sat Apr 19 11:10:29 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:14 2005 Subject: [CF List] crossfire-list post from phil@theperlguru.com requires approval Message-ID: <20030318023101.4836.10154.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-list@lists.real-time.com From: phil@theperlguru.com Subject: Re: [CF List] Dragon Race Question v. 1.4.0 Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-list to approve or deny the request. From crossfire-list-admin at archives.real-time.com Sat Apr 19 11:10:31 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:14 2005 Subject: [CF List] Dragon Race Question v. 1.4.0 Message-ID: <3E72A568.1090208@rogers.com> Hi All, I'm not subscribed to the list, so please cc me directly in any reply.. My question is related to the Dragon race. The character guide on the website says that it might be a good idea to change the attunement of a dragon after a certain number of levels. It further says that this is accomplished by purchasing an ancient elemental residue in Scorn, at the Guild of Dragons.. Problem is, in my version of crossfire (1.4.0), I cannot seem to find this guild for the life of me! I think it's supposed to be the guild just above the library, but I cannot enter this structure. Is there something I need to do first, or am I looking in the right place? I think I'm a "Dragon" race, not a "Q", if there is a difference? Dave -- Cynic, n.: Experienced. _______________________________________________ crossfire-list mailing list crossfire-list@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-list From crossfire-list-admin at archives.real-time.com Sat Apr 19 11:10:34 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:15 2005 Subject: [CF List] Enchanting Weapons In-Reply-To: <86r89ngva6.fsf@cail.esc.pike.il.us> Message-ID: With enchanted weapons (+1, +2, etc.), you still need the Prepare Weapon scroll (applied first..) in order to use the Increase Strength Bonus scroll to make it a shortsword +2 (Str +1) weapon. By starting with an enchanted weapon, it just saves you from having to use the Enchant Weapon scroll later on to increase the pluses (and counts against the number of enchantments available - which is defined when you use the Prepare Weapon scroll) - Rick Tanner leaf@real-time.com On 4 Mar 2003, Aaron Baugher wrote: > What if the weapon is already enchanted? I have a shortsword +2. Is > it possible to use a 'Increase Strength Bonus' scroll on it? If so, > do I have to use a 'prepare weapon' scroll first, or is it already > prepared? _______________________________________________ crossfire-list mailing list crossfire-list@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-list From crossfire-list-admin at archives.real-time.com Sat Apr 19 11:10:37 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:15 2005 Subject: [CF List] Enchanting Weapons In-Reply-To: Message-ID: <86fzq3j2as.fsf@cail.esc.pike.il.us> I've found a few "Increase Bonus" scrolls, and the potions to go with them. I'd like to use them, but if I'm reading the handbook correctly, first I have to prepare the weapon by reading a 'prepare weapon' scroll while standing on diamonds. But I can't find such a scroll anywhere. Am I misunderstanding something here, or are these scrolls just very rare? -- Aaron abaugher@esc.pike.il.us _______________________________________________ crossfire-list mailing list crossfire-list@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-list From crossfire-list-admin at archives.real-time.com Sat Apr 19 11:10:39 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:15 2005 Subject: [CF List] Crossfire Polls References: <000901c2ff4d$e7d732c0$0802a8c0@ott.ca.dmr> <3E9B95B0.7020003@sonic.net> Message-ID: <003101c3036e$72c67340$0802a8c0@ott.ca.dmr> > Most polls should be taken with a grain of salt - especially those that don't > have a none of the above type of answer (in which case people may still vote for > something, like removing the swashbuckler, just because they have to vote for > something. certainly and doubly so for polls with such a low number of participants (20-40 people is pretty small poll). I just wanted to send up the results for interest. Now one thing I saw that was really interesting was the web work done on Mids server where there seems to be a lot of logging happening (player race/classes picked, killed by statistics, most used maps...) I always liked the feedback (and polls) on the old Mids server and am glad to see it continuing and improved. Feedback is good. > > The reason some classses/races probably are popular vote getters for removal > is because they aren't all that interesting. > > while theif may be one of the main 'areas' in traditional RPG's, it probably > loses out in crossfire because it doesn't have any really great skills that make > it more playable in some games. > for sure. As with all statistics it is important to undertstand what the message really is. I think that is the messge I was trying to get across. There is a good reason that warriors and wizards are the top picks - this is where the rewards are and how the game plays... > Mostrai as a god? Probably because it has the best low level enemies, and > thus one of the best ways to get exp. Most likely, as in real life players have shown that they will find and exploit any imbalance - in fact the questions should have probably been 'In you opinion, which is the most interesting or best Cult'. Not that this fact is unimportant - it may point to the fact that a overwhelmingly popular cult may need to be adjusted... > > animations: Would be really hard to provide a list of animations the player > could choose from. Even easier now in that the players use the same animation > logic as everything else, so you could even include non players (eg, pirate > lass, etc). But there should probably be some limits - in some cases, like > dragons, the race is the major factor. But for humanoid type races, there could > be a large choice of images. > Oh yes, I am personally against having say gnome players choose a huge barbarian animation type of thing, and would prefer to use race specific animations (a gnome is a gnome is a gnome!), but it seems I am in the minority here. I am currently working on animating the player faces so once I get the basics done (still lots of 'classic' animations to do here) it is likely I will start adding a few filler animations like halflings in heavy armor or gnome wizards. It shouldn't be too hard to make face changing booths or whatever. I am esthetically against using just any old animation for a player face - they should all be four direction at least... I would like to add an option in the hall of selection however where you can pick no class but get a wack of money and entrance to a little shop to buy a few skills or other useful items. This might be a backdoor way to encourage people to use the racial player animations... _______________________________________________ crossfire-list mailing list crossfire-list@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-list From crossfire-list-admin at archives.real-time.com Sat Apr 19 11:10:42 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:15 2005 Subject: [CF List] crossfire-list post from rbl@berthou.com requires approval Message-ID: <20030403181840.10690.83498.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-list@lists.real-time.com From: rbl@berthou.com Subject: Have a new Allhallowmas Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-list to approve or deny the request. From crossfire-list-admin at archives.real-time.com Sat Apr 19 11:12:13 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:15 2005 Subject: [CF List] What to do after Beginner phase? In-Reply-To: <86heampn4z.fsf_-_@cail.esc.pike.il.us> Message-ID: Are you trying to gain experience (levels) in magic or physique? Here are my suggestions. Keep in mind the success of my suggested techniques will vary from player to player. Results may vary.. -=-=-SPOILER WARNING-=-=- If it's physique, then go with an all "warrior mode" eq set. For instance, the most protective armour and shield your strength allows (without sacrificing to much attack and movement speed..), the fastest and most damaging weapon you can find or afford (artifact weapon or usually a katana of some sort), the best jack boots you can find or afford, cloak of protection, rings that are + strength and so on. I realize this is more "roll plaing" then "role playing" - but it works. As far as maps go, here's a few: Raffle 1 in pupland Slave Pit 1, Slave Pit 2, Slave Pit 3 in Wolfsburg High Tower in Wolfsburg Twin Towers in Wolfsburg Warehouse in Wolfsburg Pirate's Arena in port area of Scorn If it's magic experience - the golem spells is what you want. Such as summon golem, summon air/earth/fire/water elemental, summon pet monster, etc. Use them to do all your fighting for you. With the spell (or helm of) xray, you can safely hide on the other side of the wall and use the shift- keys to send your summoned monster all over the map (within viewing site, of course..) Great maps for using the golem spells are: High Tower in Wolfsburg (top level) Twin Towers in Wolfsburg Tower of Brest in Brest (second level, 1 hallway in particular) Something else you could do is a hybrid warrior/mage. A balance between protective armour and + Spell Point regneration gear. Remember, you gain the experience for the monster you kill with your current set skill. So, hack on the hill giant with your sword until he's almost dead, hit him with burning hands and kill him - wizardry experience. Blast the evil treant with 4 or 5 burning hands and then hack on them with your sword until the tree is vanquished - physique experience. HTH, - Rick Tanner leaf@real-time.com _______________________________________________ crossfire-list mailing list crossfire-list@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-list From crossfire-list-admin at archives.real-time.com Sat Apr 19 11:12:16 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:15 2005 Subject: [CF List] crossfire-list post from abaugher@esc.pike.il.us requires approval Message-ID: <20030304024600.2550.28381.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-list@lists.real-time.com From: abaugher@esc.pike.il.us Subject: Enchanting Weapons Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-list to approve or deny the request. From crossfire-list-admin at archives.real-time.com Sat Apr 19 11:14:54 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:15 2005 Subject: [CF List] Dragon Race Question v. 1.4.0 In-Reply-To: <3E72A568.1090208@rogers.com> References: <3E72A568.1090208@rogers.com> Message-ID: <200303172110163.SM01492@adsl-68-22-198-25.dsl.chcgil.ameritech.net> On Fri, 14 Mar 2003 23:00:40 -0500, Dave wrote: >Hi All, > >I'm not subscribed to the list, so please cc me directly in any reply.. > >My question is related to the Dragon race. The character guide on the >website says that it might be a good idea to change the attunement of a >dragon after a certain number of levels. It further says that this is >accomplished by purchasing an ancient elemental residue in Scorn, at the >Guild of Dragons.. > >Problem is, in my version of crossfire (1.4.0), I cannot seem to find >this guild for the life of me! I think it's supposed to be the guild >just above the library, but I cannot enter this structure. > >Is there something I need to do first, or am I looking in the right >place? I think I'm a "Dragon" race, not a "Q", if there is a difference? > >Dave We debugged this in IRC. The problem was that he had the wrong version of the maps. -Philip _______________________________________________ crossfire-list mailing list crossfire-list@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-list From crossfire-list-admin at archives.real-time.com Sat Apr 19 11:15:03 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:15 2005 Subject: [CF List] Enchanting Weapons References: <3E6705B8.3030508@terra.es> Message-ID: <3E797376.6090008@sonic.net> Juan Segarra wrote: > There is an important point to know when enchanting weapons which in my > opinion can be quite terrible. > Usually, when you have many objects of the same kind but you need just a > few of them, the system automatically gets only the required amount. For > example, when dropping all your gold coins on a desk which only needs 20 > of them. However, that's NOT the case with the potions used to improve > weapon stats. It is not funny when you need 2 potions of str and, > expecting only to use these 2, use your, say 30 potions of str, > collected during all the time you have played, and find that all of them > dissapear without any additional effect. > Fixed in CVS: server/apply.c: Change weapon improving code to only use up the number of potions that it needs, and not all on the ground. Required adding another arg to eat_item() which is the number of items to consume. include/sproto.h: Rebuilt for new eat_item() (actually, a static, so no longer shows up in this file) MSW 2003-03-19 _______________________________________________ crossfire-list mailing list crossfire-list@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-list From crossfire-list-admin at archives.real-time.com Sat Apr 19 11:16:01 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:15 2005 Subject: [CF List] crossfire-list post from dstuart@rogers.com requires approval Message-ID: <20030315042501.30460.65445.Mailman@pirate.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-list@lists.real-time.com From: dstuart@rogers.com Subject: Dragon Race Question v. 1.4.0 Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-list to approve or deny the request. From crossfire-list-admin at archives.real-time.com Sat Apr 19 11:19:38 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:15 2005 Subject: [CF List] 1 crossfire-list admin request(s) waiting Message-ID: <200210222200.g9MM04s31163@sprite.real-time.com> The crossfire-list@lists.real-time.com mailing list has 1 request(s) waiting for your consideration at: https://mailman.real-time.com/mailman/admindb/crossfire-list Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: mo2003_20021018_3606@2mbb.com on Tue Oct 22 07:04:04 2002 Cause: Post by non-member to a members-only list From crossfire-list-admin at archives.real-time.com Sat Apr 19 11:19:41 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:15 2005 Subject: [CF List] crossfire-list post from stamhankar@hotmail.com requires approval Message-ID: <20030403063629.5211.81405.Mailman@sprite.real-time.com> As list administrator, your authorization is requested for the following mailing list posting: List: crossfire-list@lists.real-time.com From: stamhankar@hotmail.com Subject: Hi,so cool a flash,enjoy it Reason: Post by non-member to a members-only list At your convenience, visit: https://mailman.real-time.com/mailman/admindb/crossfire-list to approve or deny the request. From crossfire-list-admin at archives.real-time.com Sat Apr 19 11:19:45 2003 From: crossfire-list-admin at archives.real-time.com (crossfire-list-admin@archives.real-time.com) Date: Thu Jan 13 18:03:15 2005 Subject: [CF List] Warning: could not send message for past 1 hour Message-ID: <200303221820.h2MGK1gA023561@blake.timetraveller.org> ********************************************** ** THIS IS A WARNING MESSAGE ONLY ** ** YOU DO NOT NEED TO RESEND YOUR MESSAGE ** ********************************************** The original message was received at Sun, 23 Mar 2003 02:20:01 +1000 from [202.83.74.222] ----- Transcript of session follows ----- <<< DATA 451 4.4.1 collect: I/O error on connection from [202.83.74.222], from= Warning: message still undelivered after 1 hour Will keep trying until message is 2 days old -------------- next part -------------- Skipped content of type message/delivery-status-------------- next part -------------- An embedded message was scrubbed... From: crossfire-list-admin@lists.real-time.com Subject: no subject Date: Sun, 23 Mar 2003 02:20:01 +1000 Size: 1356 Url: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20030419/1560d844/attachment.mht From trhyne at MIT.EDU Tue Apr 1 13:23:27 2003 From: trhyne at MIT.EDU (Vernon T Rhyne) Date: Thu Jan 13 18:04:34 2005 Subject: [CF List] New New Experience Scheme... In-Reply-To: Your message of "Wed, 16 Oct 2002 18:05:19 +0200." <3922.1034784319@www39.gmx.net> Message-ID: <200210161730.NAA29576@department-of-alchemy.mit.edu> I'd like to propose a couple points, rehashing much of Andreas's: 1) Going down one experience path shouldn't prevent you from going down others later, or prevent you from going as far. Honestly, I'd say that it shouldn't make it harder or easier... 2) Overall experience gained from an act should be determined by overall level, rather than the level of the skill governing the act that is generating it. A level 105 character shouldn't receive full exp for singing to a kobold, etc... (already been proposed a bit...) 3) Experience within a path is determined by level in that skill. A level 105 character who has no personality xp gets full PERSONALITY exp for singing to a kobold. As such, having a "max score" doesn't force your character to stagnation, and you can add skills and spheres without giving easy exp.