From b.t.lally at warwick.ac.uk Sun May 1 18:11:50 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Sun May 1 17:52:57 2005 Subject: [crossfire] channels In-Reply-To: <42732328.8020504@sonic.net> References: <200504240152.09906.b.t.lally@warwick.ac.uk> <200504281425.32061.b.t.lally@warwick.ac.uk> <42732328.8020504@sonic.net> Message-ID: <200505020011.50896.b.t.lally@warwick.ac.uk> On Saturday 30 Apr 2005 07:18, Mark Wedel wrote: > Just because the preference is stored on the client doesn't mean the > client can't tell the server what its preference is. ok, sure, that just means sending the data rather than using the save file. However I am unsure how older clients would work then? > So for channels, same thing could be done - as part of setting up the > connection, the client can get the channel listing from the server, and for > ones it knows about, send back whether it wants to subscribe to those > channels or not. What about the channels created after the client has logged on? From lalo at laranja.org Mon May 2 17:03:58 2005 From: lalo at laranja.org (lalo@laranja.org) Date: Mon May 2 17:07:12 2005 Subject: [crossfire] new pickup In-Reply-To: <3bec7e305031118476cd0a3eb@mail.gmail.com> References: <3bec7e305031118476cd0a3eb@mail.gmail.com> Message-ID: <2064.220.207.82.7.1115071438.squirrel@webmail.laranja.org> > While I'm doing this, are there any other categories of items > that should be in new pickup? sorry to be almost 2 months late :-P I'm just now catching up with my CF mail. Yes, I have a request from the dragon camp! I'd like a category to pick up flesh. Even better would be if it only picks flesh with some nutritious value (eg stuff with a non-zero chance of giving me a resistance) - but that would probably be too complex, so never mind. In fact it would probably be very dragonlike to auto-eat :-P a thought for the future... From tchize at myrealbox.com Sun May 8 04:38:50 2005 From: tchize at myrealbox.com (tchize) Date: Sun May 8 04:40:32 2005 Subject: [crossfire] statues and monuments Message-ID: <200505081138.55324.tchize@myrealbox.com> Hello some monuments and statues in misc/ may contain a message but are of type 0 (no type). Is there a particulare reason or is it just lazyness? Does someone mind if i switch them to type SIGN? This way they would benefit from the new protocol messages currently used by books which allows client to get a better grasp on where a message comes from (they could display a picture of a big statue in a window with a text at the bottom when player apply the statue). -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- 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/20050508/244d7651/attachment.pgp From mikeeusaaa at yahoo.com Sun May 8 08:42:03 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sun May 8 08:42:34 2005 Subject: [crossfire] statues and monuments In-Reply-To: <200505081138.55324.tchize@myrealbox.com> Message-ID: <20050508134203.30981.qmail@web61011.mail.yahoo.com> The razor says lazyness. Death To women's Rights. --- tchize wrote: > Hello some monuments and statues in misc/ may > contain a message but are of > type 0 (no type). > Is there a particulare reason or is it just > lazyness? > > Does someone mind if i switch them to type SIGN? > This way they would benefit > from the new protocol messages currently used by > books which allows client to > get a better grasp on where a message comes from > (they could display a > picture of a big statue in a window with a text at > the bottom when player > apply the statue). > -- > -- > Tchize (David Delbecq) > tchize@myrealbox.com > Public PGP KEY FINGERPRINT: > F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 > C17C > Public PGP KEY location: > http://wwwkeys.pgp.net/pgpnet/wwwkeys.html > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > Discover Yahoo! Stay in touch with email, IM, photo sharing and more. Check it out! http://discover.yahoo.com/stayintouch.html From fuchs.andy at gmail.com Mon May 9 19:48:55 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Mon May 9 19:50:55 2005 Subject: [crossfire] Buildable savebeds Message-ID: I would like to discuss the addition of buildable savebeds. Mainly If they should exist and what their price should be. -- -- Andrew Fuchs From leaf at real-time.com Mon May 9 20:08:34 2005 From: leaf at real-time.com (Rick Tanner) Date: Mon May 9 20:08:55 2005 Subject: [crossfire] Buildable savebeds In-Reply-To: References: Message-ID: On Mon, 9 May 2005, Andrew Fuchs wrote: > I would like to discuss the addition of buildable savebeds. Mainly If > they should exist and what their price should be. They do no exist now, and IMNSHO it should continue to be that way. Here's a reason why: What is to stop players from using their newly created bed of reality in a treasure room and logging in every two hours to loot the map? That is rather frustrating for other players who go through all portions of the map only to discover the treasure has already been collected. This is a good part of the reason why a change was made with town portal - for them to disappear with map resets. Am I confusing "buildable" save bed, as in an add-on for a personal apartment or guild hall, with a "portable" save bed in this case? From eracclists at bellsouth.net Mon May 9 20:27:08 2005 From: eracclists at bellsouth.net (ERACC) Date: Mon May 9 20:28:56 2005 Subject: [crossfire] Buildable savebeds In-Reply-To: References: Message-ID: <200505092027.08481.eracclists@bellsouth.net> On Monday 09 May 2005 08:08 pm Rick Tanner wrote: [...] > Am I confusing "buildable" save bed, as in an add-on for a personal > apartment or guild hall, with a "portable" save bed in this case? [...] Yes, you are confused. :-) This is follow-up from a discussion started on IRC #crossfire about apartments and buildable things. Gene -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 20:26:00 up 12 days, 3:14, 9 users, load average: 0.05, 0.11, 0.08 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandriva Linux, OpenServer & UnixWare resellers From cerzeo at gmail.com Tue May 10 06:33:29 2005 From: cerzeo at gmail.com (=?ISO-8859-1?Q?Alberto_S=E1ez_Lodeiros?=) Date: Tue May 10 06:37:03 2005 Subject: [crossfire] Guilds and Houses Message-ID: <3fa5094505051004338800f1d@mail.gmail.com> Hi ! I have my own LAN server where some of my friens play crossfire. And my first question is: Can they build a guild? How? (Something like a clan, ex: The guild of the "Paper Sword") And the second question, Is it possibel that players can build a house, not to get the permanent apartemnts? Thnkx for hlp :) -- -- Powered by Linux Knoppix -- From trhyne at MIT.EDU Tue May 10 12:57:05 2005 From: trhyne at MIT.EDU (Vernon T Rhyne) Date: Tue May 10 12:59:06 2005 Subject: [crossfire] Crossfire: Images In-Reply-To: <20050508134203.30981.qmail@web61011.mail.yahoo.com> References: <20050508134203.30981.qmail@web61011.mail.yahoo.com> Message-ID: <1115747825.4280f5f106d28@webmail.mit.edu> First as a research project, then as a company presentation, I created an MFC application to demonstrate a process I'd developed at my job. As part of this process, I borrowed some of the 32x32 images used in crossfire to form a quilted-together picture and as bitmaps on push-buttons. The success of the internal demonstration has lead to the distinct possibility that it will be shown to other companies and publishers in the MMORPG community. What is the crossfire policy on image reuse, reproduction and permission? From mikeeusaaa at yahoo.com Tue May 10 13:23:41 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Tue May 10 13:25:06 2005 Subject: [crossfire] Crossfire: Images In-Reply-To: 6667 Message-ID: <20050510182341.22930.qmail@web61015.mail.yahoo.com> GPL to my knowledge. --- Vernon T Rhyne wrote: > First as a research project, then as a company > presentation, I created an MFC > application to demonstrate a process I'd developed > at my job. As part of this > process, I borrowed some of the 32x32 images used in > crossfire to form a > quilted-together picture and as bitmaps on > push-buttons. > > The success of the internal demonstration has lead > to the distinct possibility > that it will be shown to other companies and > publishers in the MMORPG > community. What is the crossfire policy on image > reuse, reproduction and > permission? > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From eracclists at bellsouth.net Tue May 10 14:06:43 2005 From: eracclists at bellsouth.net (ERACC) Date: Tue May 10 14:07:07 2005 Subject: [crossfire] Buildable savebeds In-Reply-To: References: Message-ID: <200505101406.43242.eracclists@bellsouth.net> On Monday 09 May 2005 08:08 pm Rick Tanner wrote: > On Mon, 9 May 2005, Andrew Fuchs wrote: > > > I would like to discuss the addition of buildable savebeds. Mainly If > > they should exist and what their price should be. > > They do no exist now, and IMNSHO it should continue to be that way. There could (and IMO should) be a "tent of reality" that can be purchased and used in maps with regions marked "wilderness". If it is not marked wilderness then one cannot use the tent. Since it is a tent it wears out over time (based on in-game time) and either has to be repaired by some method or another has to be purchased. If one is not used for a long time in-game then it is "eaten by moths" or some such and becomes a useless tatter of rags. Voil?, another way to spend platinum. :-) > Here's a reason why: > > What is to stop players from using their newly created bed of reality in a > treasure room and logging in every two hours to loot the map? Use regions to stop that. The move to regions in maps has opened up other possibilities for save. Gene -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 13:51:39 up 12 days, 20:40, 9 users, load average: 0.09, 0.04, 0.01 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandriva Linux, OpenServer & UnixWare resellers From tchize at myrealbox.com Tue May 10 15:21:57 2005 From: tchize at myrealbox.com (tchize) Date: Tue May 10 15:23:07 2005 Subject: [crossfire] Crossfire: Images In-Reply-To: <1115747825.4280f5f106d28@webmail.mit.edu> References: <20050508134203.30981.qmail@web61011.mail.yahoo.com> <1115747825.4280f5f106d28@webmail.mit.edu> Message-ID: <200505102222.01812.tchize@myrealbox.com> 1) any link to this presentation? 2) crossfire project is under GPL, this includes pictures. Read http://www.gnu.org/licenses/licenses.html#GPL for details Le Mardi 10 Mai 2005 19:57, Vernon T Rhyne a ?crit : >First as a research project, then as a company presentation, I created an > MFC application to demonstrate a process I'd developed at my job. As part > of this process, I borrowed some of the 32x32 images used in crossfire to > form a quilted-together picture and as bitmaps on push-buttons. > >The success of the internal demonstration has lead to the distinct > possibility that it will be shown to other companies and publishers in the > MMORPG community. What is the crossfire policy on image reuse, > reproduction and permission? > >_______________________________________________ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- 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/20050510/5c0f0d9f/attachment.pgp From lalo at laranja.org Tue May 10 17:48:49 2005 From: lalo at laranja.org (lalo@laranja.org) Date: Tue May 10 17:51:08 2005 Subject: [crossfire] Buildable savebeds In-Reply-To: <200505101406.43242.eracclists@bellsouth.net> References: <200505101406.43242.eracclists@bellsouth.net> Message-ID: <1048.61.135.11.194.1115765329.squirrel@webmail.laranja.org> ERACC wrote: >On Monday 09 May 2005 08:08 pm Rick Tanner wrote: > >>On Mon, 9 May 2005, Andrew Fuchs wrote: >> >>>I would like to discuss the addition of buildable savebeds. Mainly If >>>they should exist and what their price should be. > IMHO they should; on the other hand they should be *really* expensive. (re "portable" savebeds) >There could (and IMO should) be a "tent of reality" that can be >purchased and used in maps with regions marked "wilderness". If it is >not marked wilderness then one cannot use the tent. Since it is a >tent it wears out over time (based on in-game time) and either has to >be repaired by some method or another has to be purchased. If one is >not used for a long time in-game then it is "eaten by moths" or some >such and becomes a useless tatter of rags. > +1... I think there has been discussion of this for ages, but now with regions it's actually feasible :-) which also opens the ground for a completely new type of character, the traveler who doesn't have an apartment anywhere. (I suppose bank accounts are also necessary for that to work.) >>Am I confusing "buildable" save bed, as in an add-on for a personal >>apartment or guild hall, with a "portable" save bed in this case? > Yes. "Buildable" things can only be placed in "buildable" tiles, and once placed, they become normal, permanent (but "unique") objects. -- best, Lalo From lalo at laranja.org Tue May 10 17:53:32 2005 From: lalo at laranja.org (lalo@laranja.org) Date: Tue May 10 17:55:09 2005 Subject: [crossfire] Guilds and Houses In-Reply-To: <3fa5094505051004338800f1d@mail.gmail.com> References: <3fa5094505051004338800f1d@mail.gmail.com> Message-ID: <1079.61.135.11.194.1115765612.squirrel@webmail.laranja.org> There are two different things that might help you: parties and guilds. A party is just a group of players; they can message each other easily, and they can share experience. Use the built-in help to learn about the many party commands (IIRC typing "help party" will tell you about it). A guild is, well, there are houses in all major BigWorld towns and cities called Guild Houses. You need at least 3 players and a LOT of money to buy one; so this is probably going to be a medium-term goal for them ;-) A guild house is a shared house, with space to store things, and also has one big buildable annex where you can use "buildable" things to customize it to your own taste. It's the closer you can come to building your own house. -- best, Lalo From nicolas.weeger at laposte.net Wed May 11 04:49:43 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed May 11 04:51:16 2005 Subject: [crossfire] Guilds and Houses Message-ID: > A guild house is a shared house, with space to store things, and also has > one big buildable annex where you can use "buildable" things to customize > it to your own taste. It's the closer you can come to building your own > house. I think some people were working on new apartments with buildable space, but I don't know what's the status of that. In any case, you can change anything to be buildable (in the sense of putting material), just a matter of setting the right flag on the map squares. > best, > Lalo Regards Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From mikeeusaaa at yahoo.com Wed May 11 07:36:32 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Wed May 11 07:37:17 2005 Subject: [crossfire] Guilds and Houses In-Reply-To: 6667 Message-ID: <20050511123632.55055.qmail@web61022.mail.yahoo.com> The far east has a buildable apartment and I finished putting on the gates to the cities so it is ripe for uploading https://cat2.dynu.ca/cat2/fareastpatch.tar.gz --- Nicolas Weeger wrote: > > A guild house is a shared house, with space to > store things, and also has > > one big buildable annex where you can use > "buildable" things to customize > > it to your own taste. It's the closer you can > come to building your own > > house. > > I think some people were working on new apartments > with buildable space, but I don't know what's the > status of that. > In any case, you can change anything to be buildable > (in the sense of putting material), just a matter of > setting the right flag on the map squares. > > > best, > > Lalo > > Regards > Ryo > > Accédez au courrier électronique de La Poste : > www.laposte.net ; > 3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 > (0,34€/mn) > > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mikeeusaaa at yahoo.com Wed May 11 10:38:09 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Wed May 11 10:39:19 2005 Subject: [crossfire] Guilds and Houses In-Reply-To: 6667 Message-ID: <20050511153809.91423.qmail@web61025.mail.yahoo.com> Also note that in MLAB there are buildable lots outside of CityDeClouds you can buy and build on. Mlab is on cat2.dynu.ca (also dlable from website https://cat2.dynu.ca and hopefully will be in CVS some time...) --- lalo@laranja.org wrote: > There are two different things that might help you: > parties and guilds. > > A party is just a group of players; they can message > each other easily, > and they can share experience. Use the built-in > help to learn about the > many party commands (IIRC typing "help party" will > tell you about it). > > A guild is, well, there are houses in all major > BigWorld towns and cities > called Guild Houses. You need at least 3 players > and a LOT of money to > buy one; so this is probably going to be a > medium-term goal for them ;-) > > A guild house is a shared house, with space to store > things, and also has > one big buildable annex where you can use > "buildable" things to customize > it to your own taste. It's the closer you can come > to building your own > house. > > -- > best, > Lalo > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From fuchs.andy at gmail.com Wed May 11 13:55:28 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Wed May 11 13:57:22 2005 Subject: [crossfire] Guilds and Houses In-Reply-To: <20050511153809.91423.qmail@web61025.mail.yahoo.com> References: <20050511153809.91423.qmail@web61025.mail.yahoo.com> Message-ID: The permenant apartment in Navar is 'buildable'. In addition to that, there are some hoses in Stoneville that have unique floors. The actual 'building' of the entire house is not implimented yet, but will probaly happen in the future (building code needs some way to track players posessions, and prevent someone from building stuff that should only appear inside a house). -- -- Andrew Fuchs From mwedel at sonic.net Thu May 12 05:23:19 2005 From: mwedel at sonic.net (mwedel@sonic.net) Date: Thu May 12 05:23:32 2005 Subject: [crossfire] statues and monuments In-Reply-To: <200505081138.55324.tchize@myrealbox.com> References: <200505081138.55324.tchize@myrealbox.com> Message-ID: <8245.213.202.66.213.1115893399.squirrel@webmail.sonic.net> > Hello some monuments and statues in misc/ may contain a message but are of > type 0 (no type). > Is there a particulare reason or is it just lazyness? > > Does someone mind if i switch them to type SIGN? This way they would > benefit > from the new protocol messages currently used by books which allows client > to > get a better grasp on where a message comes from (they could display a > picture of a big statue in a window with a text at the bottom when player > apply the statue). I don?t see a problem with making that change. From nicolas.weeger at laposte.net Thu May 12 13:22:38 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu May 12 13:25:36 2005 Subject: [crossfire] Windows client & server release soon Message-ID: <42839EEE.2050101@laposte.net> Hello. I plan to do a 'snapshot' release for Windows, client & server, sometime next week. As Windows users can't easily compile, it's only fair to give'em some improvements from time to time :) Or we could do an official release at some point, too. Ryo From cerzeo at gmail.com Thu May 12 16:09:19 2005 From: cerzeo at gmail.com (=?ISO-8859-1?Q?Alberto_S=E1ez_Lodeiros?=) Date: Thu May 12 16:09:37 2005 Subject: [CROSSFIRE] The Forge Message-ID: <3fa50945050512140915bf97b6@mail.gmail.com> Hi again crossfire friends. How can i forge an armor? I have 4 mithrill crystals, and i do not how to use them. Can i also forge weapons? Tnkx -- -- Powered by Linux Knoppix -- From tchize at myrealbox.com Sat May 14 03:53:03 2005 From: tchize at myrealbox.com (tchize) Date: Sat May 14 03:54:02 2005 Subject: Now the gravestones [Was: [crossfire] statues and monuments] In-Reply-To: <200505081138.55324.tchize@myrealbox.com> References: <200505081138.55324.tchize@myrealbox.com> Message-ID: <200505141053.10010.tchize@myrealbox.com> In the same philosophy, I will also switch the GRAVESTONE type to SIGN type, The #define GRAVESTONE 38 is used nowhere in code. And behavior of a GRAVESTONE is identical to the SIGN (aka: just apply and read) Le Dimanche 08 Mai 2005 11:38, tchize a ?crit : >Hello some monuments and statues in misc/ may contain a message but are of >type 0 (no type). >Is there a particulare reason or is it just lazyness? > >Does someone mind if i switch them to type SIGN? This way they would benefit >from the new protocol messages currently used by books which allows client > to get a better grasp on where a message comes from (they could display a > picture of a big statue in a window with a text at the bottom when player > apply the statue). -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- 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/20050514/ff05392d/attachment.pgp From fuchs.andy at gmail.com Sat May 14 12:39:51 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sat May 14 12:40:06 2005 Subject: [crossfire] Request for ui bindings for scripts. Message-ID: It would be nice if a script can intergrate more fully with the client's ui. Namly, add enteries to the menubar, and otherwise maniuplate the ui of the client. -- -- Andrew Fuchs From pc-crossfire04 at crowcastle.net Sat May 14 12:54:50 2005 From: pc-crossfire04 at crowcastle.net (Preston Crow) Date: Sat May 14 12:56:06 2005 Subject: [crossfire] Request for ui bindings for scripts. In-Reply-To: References: Message-ID: <1116093290.6945.12.camel@hawk> On Sat, 2005-05-14 at 13:39, Andrew Fuchs wrote: > It would be nice if a script can intergrate more fully with the > client's ui. Namly, add enteries to the menubar, and otherwise > maniuplate the ui of the client. That would be nice. One thing nice about the current interface is it requires very little modification of the non-common client code. It can be used with the old cfclient, gtkclient, and pretty much anything else. If someone wrote a generic "add button" interface to the various clients, then it would be fairly easy to hook the scripting in to it. I'm not familiar enough with the various toolkits to do something like that. But I could imagine a number of uses: A button that equips your fighting gear, another that equips your magic gear, another to pray until you hit max grace, etc. I have scripts like those, but I just use 'scripttell' to activate them (often bound to a key). --PC From alex_sch at telus.net Wed May 18 23:49:55 2005 From: alex_sch at telus.net (Alex Schultz) Date: Wed May 18 23:51:12 2005 Subject: [crossfire] Spellcasting Swords & Python Troubles Message-ID: <428C1AF3.90500@telus.net> Hi, I'm working on a server-side python script to allow weapons (or arrows/bolts after making a small fix the the direction) to cast a spell upon hitting an enemy. I think that the easiest way to store the data on the sword for the spell is by putting a rod (set to invisible and no_drop) with the desired spell attributes (which spell, and to adjust how fast the spell can be used etc.) in the sword's inventory. So far, I've made a python script that mostly works, except I just have two issues. First issue, is that the current python bindings can get the name of a spell as the player sees it and can get a pointer to the spell object, but can't seem to get the archetype of the spell object, which is need to cast it. This is not a big problem, as adding a binding for that should not be difficult and I plan to do that soon. For the moment, I'm just hardcoding the spell archetype for testing the other parts. Second issue, which is somewhat more trickery. For some reason, the testing server keeps segfaulting when the script casts the spell with CastAbility. Anybody have an idea of whats happening or how to find that out? I'm attaching the small script here. Thanks, Alex Schultz (aka Rednaxela) -------------- next part -------------- A non-text attachment was scrubbed... Name: swordcast.py Type: application/x-python Size: 745 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050518/1bba8162/swordcast.bin From nicolas.weeger at laposte.net Thu May 19 16:17:33 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu May 19 16:21:22 2005 Subject: [crossfire] Spellcasting Swords & Python Troubles In-Reply-To: <428C1AF3.90500@telus.net> References: <428C1AF3.90500@telus.net> Message-ID: <428D026D.9070607@laposte.net> > Hi, Hi. Nice idea to have spells :) Imagine a sword casting a fireball, something like that :) > Second issue, which is somewhat more trickery. For some reason, the > testing server keeps segfaulting when the script casts the spell with > CastAbility. Anybody have an idea of whats happening or how to find > that out? I'm attaching the small script here. After checking, the issue is that your rod doesn't have the "map" field correctly set. So when cast_spell calls get_map_flags (spell_util.c:1041), op being said rod, its map is NULL, which is a Bad Thing (tm). The solution seems to do: CFPython.CastAbility(activator, spellrod, spellname, direction, "") ie swap activator & spellrod. That seems to work, as far as i can tell (even though i wonder why i get a lightning when the spell is chaos spray...) > Thanks, > Alex Schultz (aka Rednaxela) Hope this helps. Ryo From alex_sch at telus.net Thu May 19 19:30:28 2005 From: alex_sch at telus.net (Alex Schultz) Date: Thu May 19 19:31:23 2005 Subject: [crossfire] Spellcasting Swords & Python Troubles In-Reply-To: <428D026D.9070607@laposte.net> References: <428C1AF3.90500@telus.net> <428D026D.9070607@laposte.net> Message-ID: <428D2FA4.5070407@telus.net> Nicolas Weeger wrote: > Nice idea to have spells :) > Imagine a sword casting a fireball, something like that :) Yeah. Thanks :-) > > After checking, the issue is that your rod doesn't have the "map" > field correctly set. So when cast_spell calls get_map_flags > (spell_util.c:1041), op being said rod, its map is NULL, which is a > Bad Thing (tm). > The solution seems to do: > CFPython.CastAbility(activator, spellrod, spellname, direction, "") > > ie swap activator & spellrod. > That seems to work, as far as i can tell Thanks! It looks like I was silly and got the two mixed up there. That part is fixed now. > (even though i wonder why i get a lightning when the spell is chaos > spray...) Due to the first issue I mentioned in my first e-mail, I hardcoded it to "spell_sm_lightning" for testing. I'm going to add the needed functionality (getting the archetype name from an object) to the python plugin later tonight. I just encountered another problem. For the direction to cast the spell, I'm using "GetDirection(activator)" which does properly get the direction that the player is going if the player is running, but it returns 0 (i.e. casting a cone spell around you or bolt under you) when the player is not running. Any ideas? Thanks, Alex Schultz (aka Rednaxela) From alex_sch at telus.net Thu May 19 23:28:18 2005 From: alex_sch at telus.net (Alex Schultz) Date: Thu May 19 23:27:49 2005 Subject: [crossfire] Spellcasting Swords & Python Troubles In-Reply-To: <428D2FA4.5070407@telus.net> References: <428C1AF3.90500@telus.net> <428D026D.9070607@laposte.net> <428D2FA4.5070407@telus.net> Message-ID: <428D6762.50901@telus.net> Alex Schultz wrote: > Due to the first issue I mentioned in my first e-mail, I hardcoded it > to "spell_sm_lightning" for testing. I'm going to add the needed > functionality (getting the archetype name from an object) to the > python plugin later tonight. Coded and in the SF tracker. > > I just encountered another problem. For the direction to cast the > spell, I'm using "GetDirection(activator)" which does properly get the > direction that the player is going if the player is running, but it > returns 0 (i.e. casting a cone spell around you or bolt under you) > when the player is not running. Any ideas? Sorry for posting this issue so hastily. I found the solution and it also required added python bindings. These additions to the bindings are on the SF tracker with the others here: http://sourceforge.net/tracker/index.php?func=detail&aid=1205421&group_id=13833&atid=313833 I would appreciate it if somebody who knows that area of the code reviews it and if it's good, then commit it. Thanks, Alex Schultz (aka Rednaxela) From alex_sch at telus.net Fri May 20 09:05:39 2005 From: alex_sch at telus.net (Alex Schultz) Date: Fri May 20 09:05:31 2005 Subject: [crossfire] Spellcasting Swords & Python Troubles In-Reply-To: <428D6762.50901@telus.net> References: <428C1AF3.90500@telus.net> <428D026D.9070607@laposte.net> <428D2FA4.5070407@telus.net> <428D6762.50901@telus.net> Message-ID: <428DEEB3.90205@telus.net> Hi again, The python code for the spellcasting swords is now working perfectly now except for one issue. If the spell casted kills the monster before the monster gets hit by the sword normally, then the server crashes with this message: PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/swordcast.py< PYTHON - HandleEvent:: script loaded (/python/swordcast.py)! Object (null) is freed but has speed. Aborted Which would seem to be the case because the spell already killed the monster and it was freed from memory, and then when the sword tries to hit it, after the spell is cast it fails because the monster died so quickly. Cone spells to not appear to be effected (probably only damages after 1 tick or so), bolt spells like small lightning and steambolt are affected, and I haven't tested it yet, but finger of death and bullet spells might be affected too. If anybody has any ideas on how to get around this, I would appreciate it. Thanks, Alex Schultz (aka Rednaxela) From alex_sch at telus.net Fri May 20 23:56:12 2005 From: alex_sch at telus.net (Alex Schultz) Date: Fri May 20 23:55:41 2005 Subject: [crossfire] Spellcasting Swords & Python Troubles In-Reply-To: <428DEEB3.90205@telus.net> References: <428C1AF3.90500@telus.net> <428D026D.9070607@laposte.net> <428D2FA4.5070407@telus.net> <428D6762.50901@telus.net> <428DEEB3.90205@telus.net> Message-ID: <428EBF6C.5010909@telus.net> Alex Schultz wrote: > The python code for the spellcasting swords is now working perfectly > now except for one issue. If the spell casted kills the monster before > the monster gets hit by the sword normally, then the server crashes > with this message: > > PYTHON - triggerEvent:: eventcode 2 > PYTHON - HandleEvent:: got script file >/python/swordcast.py< > PYTHON - HandleEvent:: script loaded (/python/swordcast.py)! > Object (null) is freed but has speed. > Aborted > > Which would seem to be the case because the spell already killed the > monster and it was freed from memory, and then when the sword tries to > hit it, after the spell is cast it fails because the monster died so > quickly. Cone spells to not appear to be effected (probably only > damages after 1 tick or so), bolt spells like small lightning and > steambolt are affected, and I haven't tested it yet, but finger of > death and bullet spells might be affected too. If anybody has any > ideas on how to get around this, I would appreciate it. Very sorry to be putting so many posts here in a row, but that previous analysis of mine of the the problem was incorrect. From further analysis, I found that it is happening somewhere inside this call "(PlugList[findPlugin(evt->plugin)].eventfunc) (&CFP);" (server/attack.c line 693) but after the spell gets a chance to activate. From temitchell at sympatico.ca Sat May 21 09:07:02 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Sat May 21 09:07:48 2005 Subject: [crossfire] multipart images Message-ID: <1116684422.3413.4.camel@oberon.kameria> I know it was discussed informally a while ago but can we suggest all multipart images use an "x" as the first digit in the name convention? (e.g. x11 and x12) I like the x since large images don't require the first digit to specify the tiling order and it is something that can be used to indicate a image larger than a single tile (to both people and programs). If this passes in the house, I can update the naming document. -- Todd Mitchell From fuchs.andy at gmail.com Sat May 21 10:57:08 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sat May 21 10:57:25 2005 Subject: [crossfire] multipart images In-Reply-To: <1116684422.3413.4.camel@oberon.kameria> References: <1116684422.3413.4.camel@oberon.kameria> Message-ID: On 5/21/05, Todd Mitchell wrote: > I know it was discussed informally a while ago but can we suggest all > multipart images use an "x" as the first digit in the name convention? > (e.g. x11 and x12) I like the x since large images don't require the > first digit to specify the tiling order and it is something that can be > used to indicate a image larger than a single tile (to both people and > programs). > > If this passes in the house, I can update the naming document. This is how commits to cvs have been doing recently. -- -- Andrew Fuchs From temitchell at sympatico.ca Sat May 21 11:37:41 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Sat May 21 11:37:48 2005 Subject: [crossfire] multipart images In-Reply-To: References: <1116684422.3413.4.camel@oberon.kameria> Message-ID: <1116693461.3413.7.camel@oberon.kameria> Actually they haven't - there was a whole lot of buildings added recently which did not use this convention. This is why I bring it up. On Sat, 2005-21-05 at 11:57 -0400, Andrew Fuchs wrote: > On 5/21/05, Todd Mitchell wrote: > > I know it was discussed informally a while ago but can we suggest all > > multipart images use an "x" as the first digit in the name convention? > > (e.g. x11 and x12) I like the x since large images don't require the > > first digit to specify the tiling order and it is something that can be > > used to indicate a image larger than a single tile (to both people and > > programs). > > > > If this passes in the house, I can update the naming document. > > This is how commits to cvs have been doing recently. > -- Todd Mitchell From mikeeusaaa at yahoo.com Sat May 21 12:47:02 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat May 21 12:49:49 2005 Subject: [crossfire] multipart images In-Reply-To: 6667 Message-ID: <20050521174702.66102.qmail@web61021.mail.yahoo.com> Please don't rename the buildings. If you want ill use x from now on? --- Todd Mitchell wrote: > Actually they haven't - there was a whole lot of > buildings added > recently which did not use this convention. This is > why I bring it up. > > On Sat, 2005-21-05 at 11:57 -0400, Andrew Fuchs > wrote: > > On 5/21/05, Todd Mitchell > wrote: > > > I know it was discussed informally a while ago > but can we suggest all > > > multipart images use an "x" as the first digit > in the name convention? > > > (e.g. x11 and x12) I like the x since large > images don't require the > > > first digit to specify the tiling order and it > is something that can be > > > used to indicate a image larger than a single > tile (to both people and > > > programs). > > > > > > If this passes in the house, I can update the > naming document. > > > > This is how commits to cvs have been doing > recently. > > > -- > Todd Mitchell > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From temitchell at sympatico.ca Sat May 21 13:18:27 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Sat May 21 13:20:58 2005 Subject: [crossfire] multipart images In-Reply-To: <20050521174702.66102.qmail@web61021.mail.yahoo.com> References: <20050521174702.66102.qmail@web61021.mail.yahoo.com> Message-ID: <1116699507.3413.11.camel@oberon.kameria> Changing the image names will have no impact on your maps, the arches will refrence the proper images if updated properly, it's just mostly a pain to remove and add the image files back into CVS. It wouldn't be much of a standard if we didn't rename the images however... On Sat, 2005-21-05 at 10:47 -0700, Mitch Obrian wrote: > Please don't rename the buildings. > If you want ill use x from now on? > From kirschbaum at myrealbox.com Tue May 24 13:30:31 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Tue May 24 13:31:59 2005 Subject: [crossfire] Spellcasting Swords & Python Troubles In-Reply-To: <428EBF6C.5010909@telus.net> References: <428C1AF3.90500@telus.net> <428D026D.9070607@laposte.net> <428D2FA4.5070407@telus.net> <428D6762.50901@telus.net> <428DEEB3.90205@telus.net> <428EBF6C.5010909@telus.net> Message-ID: <20050524183031.GA30106@kirschbaum.myrealbox.com> Alex Schultz wrote: > From further analysis, I found that it is happening somewhere inside > this call "(PlugList[findPlugin(evt->plugin)].eventfunc) (&CFP);" > (server/attack.c line 693) but after the spell gets a chance to > activate. You were right: the crash here happens because the called function accesses an already freed object. The attached patch (fix-crash.diff) fixes that problem for me but I'm not yet sure if it handles all possible cases. The other two attached files (test and swordcast.py) implement a few spell casting swords. You should use the current CVS server because it uses your new Python functions. Note that I do not put a rod into the sword's inventory -- I just use the spell itself. But this version still has a few problems left: - It uses CastAbility() but not CastSpell(). CastAbility() creates the spell object from the archetype name. Therefore it uses default values (level 0) for the spell. I cannot use CastSpell() (which takes a spell object) because it does not include a "caster" parameter. Any objections to add that parameter so that both functions (CastAbility and CastSpell) basically have the same parameter list? (Btw: no script in /maps-bigworld/python currently calls that function.) - With some spells (for example firebolt) you gain only one handed experience (both for direct kills from the sword and for kills from the spell). -------------- next part -------------- Index: plugin/plugin_python.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/plugin/plugin_python.c,v retrieving revision 1.62 diff -w -c -5 -r1.62 plugin_python.c *** plugin/plugin_python.c 20 May 2005 19:28:02 -0000 1.62 --- plugin/plugin_python.c 24 May 2005 17:55:24 -0000 *************** *** 72,81 **** --- 72,85 ---- /* wrapper for fix_player */ static void PyFixPlayer( object* pl ) { CFParm lCFR; + + if(QUERY_FLAG(pl, FLAG_FREED)) + return; + lCFR.Value[ 0 ] = pl; PlugHooks[ HOOK_FIXPLAYER ]( &lCFR ); } /* Set up an Python exception object. Index: server/attack.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/attack.c,v retrieving revision 1.106 diff -w -c -5 -r1.106 attack.c *** server/attack.c 15 Apr 2005 00:41:34 -0000 1.106 --- server/attack.c 24 May 2005 17:55:26 -0000 *************** *** 639,648 **** --- 639,651 ---- event *evt; if (get_attack_mode (&op, &hitter, &simple_attack)) goto error; + op_tag = op->count; + hitter_tag = hitter->count; + /* GROS: Handle for plugin attack event */ if ((evt = find_event(op, EVENT_ATTACK)) != NULL) { CFParm CFP; int k, l; *************** *** 659,670 **** CFP.Value[6] = &base_dam; CFP.Value[7] = &base_wc; CFP.Value[8] = &l; CFP.Value[9] = evt->hook; CFP.Value[10]= evt->options; ! if (findPlugin(evt->plugin)>=0) ((PlugList[findPlugin(evt->plugin)].eventfunc) (&CFP)); } /* GROS: This is used to handle script_weapons with weapons. Only used for players */ if (hitter->type==PLAYER) { if (hitter->current_weapon != NULL) --- 662,678 ---- CFP.Value[6] = &base_dam; CFP.Value[7] = &base_wc; CFP.Value[8] = &l; CFP.Value[9] = evt->hook; CFP.Value[10]= evt->options; ! if (findPlugin(evt->plugin)>=0) { ((PlugList[findPlugin(evt->plugin)].eventfunc) (&CFP)); + if (was_destroyed(op, op_tag)) + goto error; + if (was_destroyed(hitter, hitter_tag)) + goto error; + } } /* GROS: This is used to handle script_weapons with weapons. Only used for players */ if (hitter->type==PLAYER) { if (hitter->current_weapon != NULL) *************** *** 687,703 **** CFP.Value[6] = &base_dam; CFP.Value[7] = &base_wc; CFP.Value[8] = &l; CFP.Value[9] = evt->hook; CFP.Value[10]= evt->options; ! if (findPlugin(evt->plugin)>=0) (PlugList[findPlugin(evt->plugin)].eventfunc) (&CFP); } }; }; - op_tag = op->count; - hitter_tag = hitter->count; /* * A little check to make it more difficult to dance forward and back * to avoid ever being hit by monsters. */ --- 695,714 ---- CFP.Value[6] = &base_dam; CFP.Value[7] = &base_wc; CFP.Value[8] = &l; CFP.Value[9] = evt->hook; CFP.Value[10]= evt->options; ! if (findPlugin(evt->plugin)>=0) { (PlugList[findPlugin(evt->plugin)].eventfunc) (&CFP); + if (was_destroyed(op, op_tag)) + goto error; + if (was_destroyed(hitter, hitter_tag)) + goto error; + } } }; }; /* * A little check to make it more difficult to dance forward and back * to avoid ever being hit by monsters. */ -------------- next part -------------- arch map name test msg Creator: CF Java Map Editor Date: 5/24/2005 endmsg width 16 height 16 end arch cobblestones end arch cobblestones y 1 end arch cobblestones y 2 end arch cobblestones y 3 end arch cobblestones y 4 end arch cobblestones y 5 end arch cobblestones y 6 end arch cobblestones y 7 end arch cobblestones y 8 end arch cobblestones y 9 end arch cobblestones y 10 end arch cobblestones y 11 end arch cobblestones y 12 end arch cobblestones y 13 end arch cobblestones y 14 end arch cobblestones y 15 end arch cobblestones x 1 end arch cobblestones x 1 y 1 end arch sword name spellcaster (firebolt) name_pl spellcasters (firebolt) event_attack_plugin Python event_attack /swordcast.py x 1 y 1 arch spell_firebolt end end arch sword name swordcast (banishment) name_pl swordcasts (banishment) event_attack_plugin Python event_attack /swordcast.py x 1 y 1 arch spell_banishment end end arch sword name swordcast (windstorm) name_pl swordcasts (windstorm) event_attack_plugin Python event_attack /swordcast.py x 1 y 1 arch spell_windstorm end end arch sword name swordcast (faery fire) name_pl swordcasts (faery fire) event_attack_plugin Python event_attack /swordcast.py x 1 y 1 arch spell_faery_fire end end arch sword name swordcast (bullet swarm) name_pl swordcasts (bullet swarm) event_attack_plugin Python event_attack /swordcast.py x 1 y 1 arch spell_bullet_swarm end end arch cobblestones x 1 y 2 end arch cobblestones x 1 y 3 end arch cobblestones x 1 y 4 end arch cobblestones x 1 y 5 end arch cobblestones x 1 y 6 end arch cobblestones x 1 y 7 end arch cobblestones x 1 y 8 end arch cobblestones x 1 y 9 end arch cobblestones x 1 y 10 end arch cobblestones x 1 y 11 end arch cobblestones x 1 y 12 end arch cobblestones x 1 y 13 end arch cobblestones x 1 y 14 end arch generate_mouse x 1 y 14 end arch cobblestones x 1 y 15 end arch cobblestones x 2 end arch cobblestones x 2 y 1 end arch cobblestones x 2 y 2 end arch cobblestones x 2 y 3 end arch cobblestones x 2 y 4 end arch cobblestones x 2 y 5 end arch cobblestones x 2 y 6 end arch cobblestones x 2 y 7 end arch cobblestones x 2 y 8 end arch cobblestones x 2 y 9 end arch cobblestones x 2 y 10 end arch cobblestones x 2 y 11 end arch cobblestones x 2 y 12 end arch cobblestones x 2 y 13 end arch cobblestones x 2 y 14 end arch cobblestones x 2 y 15 end arch cobblestones x 3 end arch cobblestones x 3 y 1 end arch cobblestones x 3 y 2 end arch cobblestones x 3 y 3 end arch cobblestones x 3 y 4 end arch cobblestones x 3 y 5 end arch cobblestones x 3 y 6 end arch cobblestones x 3 y 7 end arch cobblestones x 3 y 8 end arch cobblestones x 3 y 9 end arch cobblestones x 3 y 10 end arch cobblestones x 3 y 11 end arch cobblestones x 3 y 12 end arch cobblestones x 3 y 13 end arch cobblestones x 3 y 14 end arch cobblestones x 3 y 15 end arch cobblestones x 4 end arch cobblestones x 4 y 1 end arch cobblestones x 4 y 2 end arch cobblestones x 4 y 3 end arch cobblestones x 4 y 4 end arch cobblestones x 4 y 5 end arch cobblestones x 4 y 6 end arch cobblestones x 4 y 7 end arch cobblestones x 4 y 8 end arch cobblestones x 4 y 9 end arch cobblestones x 4 y 10 end arch cobblestones x 4 y 11 end arch cobblestones x 4 y 12 end arch cobblestones x 4 y 13 end arch cobblestones x 4 y 14 end arch cobblestones x 4 y 15 end arch cobblestones x 5 end arch cobblestones x 5 y 1 end arch cobblestones x 5 y 2 end arch cobblestones x 5 y 3 end arch cobblestones x 5 y 4 end arch cobblestones x 5 y 5 end arch cobblestones x 5 y 6 end arch cobblestones x 5 y 7 end arch cobblestones x 5 y 8 end arch cobblestones x 5 y 9 end arch cobblestones x 5 y 10 end arch cobblestones x 5 y 11 end arch cobblestones x 5 y 12 end arch cobblestones x 5 y 13 end arch cobblestones x 5 y 14 end arch cobblestones x 5 y 15 end arch cobblestones x 6 end arch cobblestones x 6 y 1 end arch cobblestones x 6 y 2 end arch cobblestones x 6 y 3 end arch cobblestones x 6 y 4 end arch cobblestones x 6 y 5 end arch cobblestones x 6 y 6 end arch cobblestones x 6 y 7 end arch cobblestones x 6 y 8 end arch cobblestones x 6 y 9 end arch cobblestones x 6 y 10 end arch cobblestones x 6 y 11 end arch cobblestones x 6 y 12 end arch cobblestones x 6 y 13 end arch cobblestones x 6 y 14 end arch cobblestones x 6 y 15 end arch cobblestones x 7 end arch cobblestones x 7 y 1 end arch cobblestones x 7 y 2 end arch cobblestones x 7 y 3 end arch cobblestones x 7 y 4 end arch cobblestones x 7 y 5 end arch cobblestones x 7 y 6 end arch cobblestones x 7 y 7 end arch cobblestones x 7 y 8 end arch cobblestones x 7 y 9 end arch cobblestones x 7 y 10 end arch cobblestones x 7 y 11 end arch cobblestones x 7 y 12 end arch cobblestones x 7 y 13 end arch cobblestones x 7 y 14 end arch cobblestones x 7 y 15 end arch cobblestones x 8 end arch cobblestones x 8 y 1 end arch cobblestones x 8 y 2 end arch cobblestones x 8 y 3 end arch cobblestones x 8 y 4 end arch cobblestones x 8 y 5 end arch cobblestones x 8 y 6 end arch cobblestones x 8 y 7 end arch cobblestones x 8 y 8 end arch cobblestones x 8 y 9 end arch cobblestones x 8 y 10 end arch cobblestones x 8 y 11 end arch cobblestones x 8 y 12 end arch cobblestones x 8 y 13 end arch cobblestones x 8 y 14 end arch cobblestones x 8 y 15 end arch cobblestones x 9 end arch cobblestones x 9 y 1 end arch cobblestones x 9 y 2 end arch cobblestones x 9 y 3 end arch cobblestones x 9 y 4 end arch cobblestones x 9 y 5 end arch cobblestones x 9 y 6 end arch cobblestones x 9 y 7 end arch cobblestones x 9 y 8 end arch cobblestones x 9 y 9 end arch cobblestones x 9 y 10 end arch cobblestones x 9 y 11 end arch cobblestones x 9 y 12 end arch cobblestones x 9 y 13 end arch cobblestones x 9 y 14 end arch cobblestones x 9 y 15 end arch cobblestones x 10 end arch cobblestones x 10 y 1 end arch cobblestones x 10 y 2 end arch cobblestones x 10 y 3 end arch cobblestones x 10 y 4 end arch cobblestones x 10 y 5 end arch cobblestones x 10 y 6 end arch cobblestones x 10 y 7 end arch cobblestones x 10 y 8 end arch cobblestones x 10 y 9 end arch cobblestones x 10 y 10 end arch cobblestones x 10 y 11 end arch cobblestones x 10 y 12 end arch cobblestones x 10 y 13 end arch cobblestones x 10 y 14 end arch cobblestones x 10 y 15 end arch cobblestones x 11 end arch cobblestones x 11 y 1 end arch cobblestones x 11 y 2 end arch cobblestones x 11 y 3 end arch cobblestones x 11 y 4 end arch cobblestones x 11 y 5 end arch cobblestones x 11 y 6 end arch cobblestones x 11 y 7 end arch cobblestones x 11 y 8 end arch cobblestones x 11 y 9 end arch cobblestones x 11 y 10 end arch cobblestones x 11 y 11 end arch cobblestones x 11 y 12 end arch cobblestones x 11 y 13 end arch cobblestones x 11 y 14 end arch cobblestones x 11 y 15 end arch cobblestones x 12 end arch cobblestones x 12 y 1 end arch cobblestones x 12 y 2 end arch cobblestones x 12 y 3 end arch cobblestones x 12 y 4 end arch cobblestones x 12 y 5 end arch cobblestones x 12 y 6 end arch cobblestones x 12 y 7 end arch cobblestones x 12 y 8 end arch cobblestones x 12 y 9 end arch cobblestones x 12 y 10 end arch cobblestones x 12 y 11 end arch cobblestones x 12 y 12 end arch cobblestones x 12 y 13 end arch cobblestones x 12 y 14 end arch cobblestones x 12 y 15 end arch cobblestones x 13 end arch cobblestones x 13 y 1 end arch cobblestones x 13 y 2 end arch cobblestones x 13 y 3 end arch cobblestones x 13 y 4 end arch cobblestones x 13 y 5 end arch cobblestones x 13 y 6 end arch cobblestones x 13 y 7 end arch cobblestones x 13 y 8 end arch cobblestones x 13 y 9 end arch cobblestones x 13 y 10 end arch cobblestones x 13 y 11 end arch cobblestones x 13 y 12 end arch cobblestones x 13 y 13 end arch cobblestones x 13 y 14 end arch cobblestones x 13 y 15 end arch cobblestones x 14 end arch cobblestones x 14 y 1 end arch cobblestones x 14 y 2 end arch cobblestones x 14 y 3 end arch cobblestones x 14 y 4 end arch cobblestones x 14 y 5 end arch cobblestones x 14 y 6 end arch cobblestones x 14 y 7 end arch cobblestones x 14 y 8 end arch cobblestones x 14 y 9 end arch cobblestones x 14 y 10 end arch cobblestones x 14 y 11 end arch cobblestones x 14 y 12 end arch cobblestones x 14 y 13 end arch cobblestones x 14 y 14 end arch cobblestones x 14 y 15 end arch cobblestones x 15 end arch cobblestones x 15 y 1 end arch cobblestones x 15 y 2 end arch cobblestones x 15 y 3 end arch cobblestones x 15 y 4 end arch cobblestones x 15 y 5 end arch cobblestones x 15 y 6 end arch cobblestones x 15 y 7 end arch cobblestones x 15 y 8 end arch cobblestones x 15 y 9 end arch cobblestones x 15 y 10 end arch cobblestones x 15 y 11 end arch cobblestones x 15 y 12 end arch cobblestones x 15 y 13 end arch cobblestones x 15 y 14 end arch cobblestones x 15 y 15 end -------------- next part -------------- A non-text attachment was scrubbed... Name: swordcast.py Type: text/x-python Size: 258 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050524/2192ab9e/swordcast.py From alex_sch at telus.net Wed May 25 00:49:06 2005 From: alex_sch at telus.net (Alex Schultz) Date: Wed May 25 00:50:38 2005 Subject: [crossfire] Spellcasting Swords & Python Troubles In-Reply-To: <20050524183031.GA30106@kirschbaum.myrealbox.com> References: <428C1AF3.90500@telus.net> <428D026D.9070607@laposte.net> <428D2FA4.5070407@telus.net> <428D6762.50901@telus.net> <428DEEB3.90205@telus.net> <428EBF6C.5010909@telus.net> <20050524183031.GA30106@kirschbaum.myrealbox.com> Message-ID: <429411D2.6010505@telus.net> Andreas Kirschbaum wrote: >Alex Schultz wrote: > >>From further analysis, I found that it is happening somewhere inside >>this call "(PlugList[findPlugin(evt->plugin)].eventfunc) (&CFP);" >>(server/attack.c line 693) but after the spell gets a chance to >>activate. >> > >You were right: the crash here happens because the called function >accesses an already freed object. The attached patch (fix-crash.diff) >fixes that problem for me but I'm not yet sure if it handles all >possible cases. > That appears to fix the problem I was having perfectly :-) > > >The other two attached files (test and swordcast.py) implement a few >spell casting swords. You should use the current CVS server because it >uses your new Python functions. > Here's the current state of my version of swordcast.py that's working perfectly with it. It uses a rod instead of a spell inside to store both the casting level and I'm attempting to make it so that can also be used to limit how rapidly the spell can cast (as in slower than you hits) by using the spellpoint storage of rods. I'm attaching it here, and when using it one also has to remember to set the rod to "no_drop 1". This version also supports arrows and bolts properly by checking the direction of the weapon of the arrow instead of the player when it's a arrow being shot. > >Note that I do not put a rod into the sword's inventory -- I just use >the spell itself. But this version still has a few problems left: > > - It uses CastAbility() but not CastSpell(). CastAbility() creates the > spell object from the archetype name. Therefore it uses default > values (level 0) for the spell. > > I cannot use CastSpell() (which takes a spell object) because it does > not include a "caster" parameter. Any objections to add that > parameter so that both functions (CastAbility and CastSpell) > basically have the same parameter list? (Btw: no script in > /maps-bigworld/python currently calls that function.) > I don't have any objections, though for this script I prefer using a approach that allows one to set the casting level to something other than the default spell level. > > - With some spells (for example firebolt) you gain only one handed > experience (both for direct kills from the sword and for kills from > the spell). > I don't encounter that with my version of it. Probably because the sword is casting it and it looks at the sword's default skill with direct hits, whereas with mine, spellcasting goes through the rod, whose default skill is use_magic_item. Alex Schultz (aka Rednaxela) -------------- next part -------------- A non-text attachment was scrubbed... Name: swordcast.py Type: application/x-python Size: 756 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050524/04134e76/swordcast.bin From kirschbaum at myrealbox.com Wed May 25 02:48:30 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Wed May 25 02:50:40 2005 Subject: [crossfire] Spellcasting Swords & Python Troubles In-Reply-To: <429411D2.6010505@telus.net> References: <428C1AF3.90500@telus.net> <428D026D.9070607@laposte.net> <428D2FA4.5070407@telus.net> <428D6762.50901@telus.net> <428DEEB3.90205@telus.net> <428EBF6C.5010909@telus.net> <20050524183031.GA30106@kirschbaum.myrealbox.com> <429411D2.6010505@telus.net> Message-ID: <20050525074828.GA14039@kirschbaum.myrealbox.com> Alex Schultz wrote: > Andreas Kirschbaum wrote: > >- It uses CastAbility() but not CastSpell(). CastAbility() creates > > the spell object from the archetype name. Therefore it uses default > > values (level 0) for the spell. > > > > I cannot use CastSpell() (which takes a spell object) because it > > does not include a "caster" parameter. Any objections to add that > > parameter so that both functions (CastAbility and CastSpell) > > basically have the same parameter list? (Btw: no script in > > /maps-bigworld/python currently calls that function.) > > > I don't have any objections, though for this script I prefer using a > approach that allows one to set the casting level to something other > than the default spell level. That is the reason why I want to add the parameter "caster" to CastSpell(): this function casts the spell from the passed in spell object (including all customized parameters). But currently you cannot use it for your script because it re-uses the parameter "who" (the rod) as the "caster". This crashes the server because the rod is not on the map but in an inventory. From antonoussik at gmail.com Wed May 25 04:27:22 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Wed May 25 04:28:42 2005 Subject: [crossfire] Buildable savebeds In-Reply-To: <1048.61.135.11.194.1115765329.squirrel@webmail.laranja.org> References: <200505101406.43242.eracclists@bellsouth.net> <1048.61.135.11.194.1115765329.squirrel@webmail.laranja.org> Message-ID: On 5/10/05, lalo@laranja.org wrote: > ERACC wrote: > > >On Monday 09 May 2005 08:08 pm Rick Tanner wrote: > > > >>On Mon, 9 May 2005, Andrew Fuchs wrote: > >> > >>>I would like to discuss the addition of buildable savebeds. Mainly If > >>>they should exist and what their price should be. A good idea. Then the pre-built BOR (Beds Of Reality) can be removed from the apartments, and they will be an optional extra. > >There could (and IMO should) be a "tent of reality" that can be > >purchased and used in maps with regions marked "wilderness". Since there are wild animals in the wilderness sleeping out in the open poses aditional dangers. There could be a random probability of you getting attacked by wild animals (expressed in-game by sumoning hostile monsters to the player when he/she log in). > +1... I think there has been discussion of this for ages, but now with > regions it's actually feasible :-) which also opens the ground for a > completely new type of character, the traveler who doesn't have an > apartment anywhere. Would they then have a pocket dimension? (in CF if a pocket dimension did exist, it would allow permanent storage of infinite items, as there is no limit to how high stacks can go. Perhaps a way of limiting that would be to make high stacks fall over and scatter. On open areas this would work quite well, but in a closed area, where it is impossible to spill any higher, and therefore the items will stack regardless, there could be a hard limit, after which "the stack is up to the cieling", and no more can be placed on it. Therefore the drop code could go like [check stack size < 100], and spill code could go like [for (every tile i && heightof i > spill_limit) for (tile in every direction j) if (height of i > (height of j)+1) spill top item from i to top of j;]) From lalo at laranja.org Wed May 25 06:19:19 2005 From: lalo at laranja.org (Lalo Martins) Date: Wed May 25 06:22:58 2005 Subject: [crossfire] Buildable savebeds In-Reply-To: References: <200505101406.43242.eracclists@bellsouth.net> <1048.61.135.11.194.1115765329.squirrel@webmail.laranja.org> Message-ID: <50604.221.122.43.98.1117019959.squirrel@webmail.laranja.org> > On 5/10/05, lalo@laranja.org wrote: >> which also opens the ground for a >> completely new type of character, the traveler who doesn't have an >> apartment anywhere. > > Would they then have a pocket dimension? (in CF if a pocket dimension > did exist, it would allow permanent storage of infinite items, as > there is no limit to how high stacks can go. Perhaps a way of limiting > that would be... I think it's a dangerous idea :-) IF it existed, it would have to be horribly costly, and anyone who has one could probably have a castle or at least storage space somewhere. No, I was thinking more along the lines of never carrying too much stuff. Bank accounts now work, I've heard; so this kind of char would need to learn to only carry the essential. Which sounds challenging enough to be fun. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.laranja.org/ mailto:lalo@laranja.org pgp key: http://garfield.laranja.org/~lalo/gpgkey-signed.asc GNU: never give up freedom http://www.gnu.org/ From alex_sch at telus.net Wed May 25 07:23:35 2005 From: alex_sch at telus.net (Alex Schultz) Date: Wed May 25 07:24:43 2005 Subject: [crossfire] Spellcasting Swords & Python Troubles In-Reply-To: <20050525074828.GA14039@kirschbaum.myrealbox.com> References: <428C1AF3.90500@telus.net> <428D026D.9070607@laposte.net> <428D2FA4.5070407@telus.net> <428D6762.50901@telus.net> <428DEEB3.90205@telus.net> <428EBF6C.5010909@telus.net> <20050524183031.GA30106@kirschbaum.myrealbox.com> <429411D2.6010505@telus.net> <20050525074828.GA14039@kirschbaum.myrealbox.com> Message-ID: <42946E47.8090300@telus.net> Andreas Kirschbaum wrote: >Alex Schultz wrote: > >>Andreas Kirschbaum wrote: >> >>>- It uses CastAbility() but not CastSpell(). CastAbility() creates >>> the spell object from the archetype name. Therefore it uses default >>> values (level 0) for the spell. >>> >>> I cannot use CastSpell() (which takes a spell object) because it >>> does not include a "caster" parameter. Any objections to add that >>> parameter so that both functions (CastAbility and CastSpell) >>> basically have the same parameter list? (Btw: no script in >>> /maps-bigworld/python currently calls that function.) >>> >>> >>I don't have any objections, though for this script I prefer using a >>approach that allows one to set the casting level to something other >>than the default spell level. >> > >That is the reason why I want to add the parameter "caster" to >CastSpell(): this function casts the spell from the passed in spell >object (including all customized parameters). But currently you cannot >use it for your script because it re-uses the parameter "who" (the rod) >as the "caster". This crashes the server because the rod is not on the >map but in an inventory. > Ok, but I am currently somewhat unclear on the advantage of switching from CastAbility to a modified CastSpell would be. The script I sent in the last e-mail seems to work perfectly with the fix-crash.diff applied to the server. From mikeeusaaa at yahoo.com Wed May 25 13:09:01 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Wed May 25 13:10:47 2005 Subject: [crossfire] Buildable savebeds In-Reply-To: 6667 Message-ID: <20050525180901.81019.qmail@web61015.mail.yahoo.com> I agree. No pocket reality please. Maby you should make the tent wear out in the weather so they have to buy a new one every so often. Also there should be possibility of being attacked while asleep. --- Lalo Martins wrote: > > > On 5/10/05, lalo@laranja.org > wrote: > >> which also opens the ground for a > >> completely new type of character, the traveler > who doesn't have an > >> apartment anywhere. > > > > Would they then have a pocket dimension? (in CF if > a pocket dimension > > did exist, it would allow permanent storage of > infinite items, as > > there is no limit to how high stacks can go. > Perhaps a way of limiting > > that would be... > > I think it's a dangerous idea :-) IF it existed, it > would have to be > horribly costly, and anyone who has one could > probably have a castle or at > least storage space somewhere. > > No, I was thinking more along the lines of never > carrying too much stuff. > Bank accounts now work, I've heard; so this kind of > char would need to > learn to only carry the essential. Which sounds > challenging enough to be > fun. > > > best, > Lalo > Martins > -- > So many of our dreams at first seem > impossible, > then they seem improbable, and then, when we > summon the will, they soon become inevitable. > -- > http://www.laranja.org/ > mailto:lalo@laranja.org > pgp key: > http://garfield.laranja.org/~lalo/gpgkey-signed.asc > > GNU: never give up freedom > http://www.gnu.org/ > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail From fuchs.andy at gmail.com Wed May 25 16:00:07 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Wed May 25 16:00:48 2005 Subject: [crossfire] Client compile broken on linux Message-ID: The client won't compile on linux. Seemingly due to line 505 in common/metaserver.c: "for ( copy = min( index, CACHED_SERVERS_MAX - 1 ); copy > 0; copy-- )" where "min" isn't defined. -- -- Andrew Fuchs From nicolas.weeger at laposte.net Wed May 25 16:14:20 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed May 25 16:16:50 2005 Subject: [crossfire] Create food / alchemy abuse? Message-ID: <4294EAAC.50407@laposte.net> Same player on Metalforge that reported talisman issue also showed alchmy-related one. Player can easily use 'create mandrake root', and 'create booze' and things like that to make potions of cure disease. Thus again much money gained, for a real low risk. I thought items created with 'create food' were god-given? Nicolas From alex_sch at telus.net Wed May 25 18:31:40 2005 From: alex_sch at telus.net (Alex Schultz) Date: Wed May 25 18:32:49 2005 Subject: [crossfire] Create food / alchemy abuse? In-Reply-To: <4294EAAC.50407@laposte.net> References: <4294EAAC.50407@laposte.net> Message-ID: <42950ADC.6020301@telus.net> Nicolas Weeger wrote: > Same player on Metalforge that reported talisman issue also showed > alchmy-related one. > > Player can easily use 'create mandrake root', and 'create booze' and > things like that to make potions of cure disease. > Thus again much money gained, for a real low risk. > > I thought items created with 'create food' were god-given? Both I and eracc (poof or galahad on MF) have known about the fact that "create food" items being usable for alchemy for a long while now. Neither of us have really considered it a bug. We've done it for things like water of the wise and some others, but those alone aren't very profitable, though they are good for getting parts for other alchemy recipes. It seems you've stumbled across a highly profitable one compared to the ones eracc and I have been using for making alchemy parts. I don't consider this to be bug that create food spells can be used in alchemy, however I'm thinking that something need to be done to increase risk to those using it. One possible solution to this that I just thought of, would be making the items made by create food cursed a portion of the time to mess up people trying to abuse it for alchemy (as those who do alchemy should know well... throwing cured items into the mix can sure mess somebody up) Alex Schultz (aka Rednaxela) From cerzeo at gmail.com Wed May 25 19:06:01 2005 From: cerzeo at gmail.com (=?ISO-8859-1?Q?Alberto_S=E1ez_Lodeiros?=) Date: Wed May 25 19:06:49 2005 Subject: [crossfire] Problem in a new Linux Crossfire server. Help plz!!!!!!!!!!!! Message-ID: <3fa50945050525170610cd9d1b@mail.gmail.com> Hi again friends. I have uninstalled my Debian Sarge to install Mandriva 10.2. But before that, I created a backup of all important data, including crossfire server data. In this data i included the "players" directory. Now, once installed Crossfire server again in Mandriva, I'va copied the players folder to /usr/games/crossfire/var/crossfire/players, and overwrite all its contents. All is good, i can enter game with my old account, and i have the same things in inventory, but the problem is that i can't enter my city appartament in Scorn, i must pay for it again. What is wrong? No I have installed tha lastets version of crossfire server, and in Debian Sarge, i had a older version. Can this be the problem? Thanks :) -- -- Powered by Mandrake Linux-- From alex_sch at telus.net Wed May 25 20:24:08 2005 From: alex_sch at telus.net (Alex Schultz) Date: Wed May 25 20:24:50 2005 Subject: [crossfire] Problem in a new Linux Crossfire server. Help plz!!!!!!!!!!!! In-Reply-To: <3fa50945050525170610cd9d1b@mail.gmail.com> References: <3fa50945050525170610cd9d1b@mail.gmail.com> Message-ID: <42952538.50209@telus.net> Alberto S?ez Lodeiros wrote: >Hi again friends. > >I have uninstalled my Debian Sarge to install Mandriva 10.2. But >before that, I created a backup of all important data, including >crossfire server data. In this data i included the "players" >directory. > >Now, once installed Crossfire server again in Mandriva, I'va copied >the players folder to /usr/games/crossfire/var/crossfire/players, and >overwrite all its contents. > >All is good, i can enter game with my old account, and i have the same >things in inventory, but the problem is that i can't enter my city >appartament in Scorn, i must pay for it again. > >What is wrong? > One possibility you have missed the other files in the "players" directory that aren't *.pl This may or may not be related to the problem, but when doing such upgrades, the "unique-items" directory should also be copied. It would also help if you checked what the console of the server is saying when it loads the apartment map. Alex Schultz (aka Rednaxela) From mikeeusaaa at yahoo.com Wed May 25 20:56:46 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Wed May 25 20:58:51 2005 Subject: [crossfire] Create food / alchemy abuse? In-Reply-To: 6667 Message-ID: <20050526015646.87157.qmail@web61017.mail.yahoo.com> This sounds like a rather good solution! --- Alex Schultz wrote: > Nicolas Weeger wrote: > > > Same player on Metalforge that reported talisman > issue also showed > > alchmy-related one. > > > > Player can easily use 'create mandrake root', and > 'create booze' and > > things like that to make potions of cure disease. > > Thus again much money gained, for a real low risk. > > > > I thought items created with 'create food' were > god-given? > > Both I and eracc (poof or galahad on MF) have known > about the fact that > "create food" items being usable for alchemy for a > long while now. > Neither of us have really considered it a bug. We've > done it for things > like water of the wise and some others, but those > alone aren't very > profitable, though they are good for getting parts > for other alchemy > recipes. It seems you've stumbled across a highly > profitable one > compared to the ones eracc and I have been using for > making alchemy parts. > > I don't consider this to be bug that create food > spells can be used in > alchemy, however I'm thinking that something need to > be done to increase > risk to those using it. One possible solution to > this that I just > thought of, would be making the items made by create > food cursed a > portion of the time to mess up people trying to > abuse it for alchemy (as > those who do alchemy should know well... throwing > cured items into the > mix can sure mess somebody up) > > Alex Schultz (aka Rednaxela) > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/ From leaf at real-time.com Wed May 25 21:00:01 2005 From: leaf at real-time.com (Rick Tanner) Date: Wed May 25 21:02:59 2005 Subject: [CROSSFIRE] The Forge In-Reply-To: <3fa50945050512140915bf97b6@mail.gmail.com> References: <3fa50945050512140915bf97b6@mail.gmail.com> Message-ID: > How can i forge an armor? I have 4 mithrill crystals, and i do not how > to use them. You need to find a NPC that will craft the armor for you, assuming you have the right "ingredients" and can afford it. For instance, the Scorn Armour shop has a smith that can make certain armor and shield out of dragon scales. > Can i also forge weapons? You'll need to use a different forge for that - like the one found in the craft shops in the central area of Scorn. You'll also need the right ingredients as well in here as well. -- From handphone at gmail.com Wed May 25 21:35:58 2005 From: handphone at gmail.com (Neon Lim) Date: Wed May 25 21:36:51 2005 Subject: [crossfire] starting server Message-ID: <1124ed900505251935187a096a@mail.gmail.com> Hi, i am using ssh to control my linux server remotely. i tried running ./crossfire & the moment i close my putty, crossfire server is shut down. the same with ./crossloop & However, i am successful in using ./crossfire -detach & to start crossfire server and close my putty and it still running. My question: - is there a ./crossloop -detach ? because using ./crossfire -detach &, if the crossfire server is down, it will not restart..? - should i run ./crossloop -detach as root or run as normal user? - is there anyway to restrict the number of race/classes that can be choosen by players? - is there anyway to run crossfire server but stop people from making new characters? because i want to let some players play but stop new players from creating new character. Thanks. From tchize at myrealbox.com Thu May 26 02:15:38 2005 From: tchize at myrealbox.com (tchize) Date: Thu May 26 02:14:54 2005 Subject: [crossfire] Problem in a new Linux Crossfire server. =?iso-8859-1?q?Help=09plz!!!!!!!!!!!!?= In-Reply-To: <42952538.50209@telus.net> References: <3fa50945050525170610cd9d1b@mail.gmail.com> <42952538.50209@telus.net> Message-ID: <200505260915.38570.tchize@myrealbox.com> I also think you only saved the player files (*.pl) and not the player map files in same directory. Just check your players// directory and see if it contains anything else than the .pl If it contains the maps, then one possiblity would be you have switched at the reinstall from bigworld to smallworld or vice-versa. Le Jeudi 26 Mai 2005 03:24, Alex Schultz a ?crit : > Alberto S?ez Lodeiros wrote: > >Hi again friends. > > > >I have uninstalled my Debian Sarge to install Mandriva 10.2. But > >before that, I created a backup of all important data, including > >crossfire server data. In this data i included the "players" > >directory. > > > >Now, once installed Crossfire server again in Mandriva, I'va copied > >the players folder to /usr/games/crossfire/var/crossfire/players, and > >overwrite all its contents. > > > >All is good, i can enter game with my old account, and i have the same > >things in inventory, but the problem is that i can't enter my city > >appartament in Scorn, i must pay for it again. > > > >What is wrong? > > One possibility you have missed the other files in the "players" > directory that aren't *.pl > This may or may not be related to the problem, but when doing such > upgrades, the "unique-items" directory should also be copied. It would > also help if you checked what the console of the server is saying when > it loads the apartment map. > > Alex Schultz (aka Rednaxela) > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From tchize at myrealbox.com Thu May 26 02:42:14 2005 From: tchize at myrealbox.com (tchize) Date: Thu May 26 02:42:55 2005 Subject: [crossfire] Client compile broken on linux In-Reply-To: References: Message-ID: <200505260942.14845.tchize@myrealbox.com> /me impales Ryo fixed in CVS :) Le Mercredi 25 Mai 2005 23:00, Andrew Fuchs a ?crit : > The client won't compile on linux. Seemingly due to line 505 in > common/metaserver.c: > "for ( copy = min( index, CACHED_SERVERS_MAX - 1 ); copy > 0; copy-- )" > where "min" isn't defined. From kirschbaum at myrealbox.com Thu May 26 03:49:56 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Thu May 26 03:50:55 2005 Subject: [crossfire] Spellcasting Swords & Python Troubles In-Reply-To: <42946E47.8090300@telus.net> References: <428C1AF3.90500@telus.net> <428D026D.9070607@laposte.net> <428D2FA4.5070407@telus.net> <428D6762.50901@telus.net> <428DEEB3.90205@telus.net> <428EBF6C.5010909@telus.net> <20050524183031.GA30106@kirschbaum.myrealbox.com> <429411D2.6010505@telus.net> <20050525074828.GA14039@kirschbaum.myrealbox.com> <42946E47.8090300@telus.net> Message-ID: <20050526084955.GA20382@kirschbaum.myrealbox.com> Alex Schultz wrote: > Ok, but I am currently somewhat unclear on the advantage of switching > from CastAbility to a modified CastSpell would be. The script I sent > in the last e-mail seems to work perfectly with the fix-crash.diff > applied to the server. I had the impression that CastAbility would cast the spell with the default level (because you only give an archetype name and not a spell object with a customized level in it). But actually the spell level is defined by the caster level. Therefore your script using CastAbility works perfectly fine. From handphone at gmail.com Thu May 26 04:06:49 2005 From: handphone at gmail.com (Neon Lim) Date: Thu May 26 04:06:55 2005 Subject: [crossfire] server ip/name Message-ID: <1124ed9005052602061ec7a67@mail.gmail.com> how to save a list of server ip/host in my crossfire client so that i do not need to always retype/find out the ip/name to connect. Thanks. From cerzeo at gmail.com Thu May 26 05:26:07 2005 From: cerzeo at gmail.com (=?ISO-8859-1?Q?Alberto_S=E1ez_Lodeiros?=) Date: Thu May 26 05:26:56 2005 Subject: [crossfire] Problem in a new Linux Crossfire server. Help plz!!!!!!!!!!!! Message-ID: <3fa5094505052603261995dc12@mail.gmail.com> Yeah, i had before this server the smallworld maps set, and now the bigworld maps set, so, there is any way to update clients accounts to make city appartaments work correctly again? Thanks -- -- Powered by Mandrake Linux -- From tchize at myrealbox.com Thu May 26 05:56:40 2005 From: tchize at myrealbox.com (tchize) Date: Thu May 26 05:56:55 2005 Subject: Upgrading from small world to big world, Was: [crossfire] Problem in a new Linux Crossfire server. Help plz!!!!!!!!!!!! In-Reply-To: <3fa5094505052603261995dc12@mail.gmail.com> References: <3fa5094505052603261995dc12@mail.gmail.com> Message-ID: <200505261256.41110.tchize@myrealbox.com> I think metalforge once ran such a script on their player files, but not sure. Le Jeudi 26 Mai 2005 12:26, Alberto S?ez Lodeiros a ?crit : > Yeah, i had before this server the smallworld maps set, and now the > bigworld maps set, so, there is any way to update clients accounts to > make city appartaments work correctly again? > > Thanks From cerzeo at gmail.com Thu May 26 08:09:29 2005 From: cerzeo at gmail.com (cerzeo@gmail.com) Date: Thu May 26 08:00:57 2005 Subject: Upgrading from small world to big world, Was: [crossfire] Problem in a new Linux Crossfire server. Help plz!!!!!!!!!!!! Message-ID: <200505261509.29266.cerzeo@gmail.com> I was looking for this script, but i don't find it. Someone has this scrip or know how to "validate" small world map player's appartment to big world maps? Thanks. :) From leaf at real-time.com Thu May 26 11:10:37 2005 From: leaf at real-time.com (Rick Tanner) Date: Thu May 26 11:10:59 2005 Subject: Upgrading from small world to big world, Was: [crossfire] Problem in a new Linux Crossfire server. Help plz!!!!!!!!!!!! In-Reply-To: <200505261256.41110.tchize@myrealbox.com> References: <3fa5094505052603261995dc12@mail.gmail.com> <200505261256.41110.tchize@myrealbox.com> Message-ID: On Thu, 26 May 2005, tchize wrote: > I think metalforge once ran such a script on their player files, but not sure. When metalforge migrated from the small world maps to the big world maps, it was at the same time as the new skill system went in to affect. Player files were not migrated/updated - they started over on the new (and now current..) metalforge server. From fuchs.andy at gmail.com Thu May 26 14:11:05 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Thu May 26 14:13:01 2005 Subject: [crossfire] server ip/name In-Reply-To: <1124ed9005052602061ec7a67@mail.gmail.com> References: <1124ed9005052602061ec7a67@mail.gmail.com> Message-ID: On 5/26/05, Neon Lim wrote: > how to save a list of server ip/host in my crossfire client so that i > do not need to always retype/find out the ip/name to connect. Afaik the client currently in cvs caches the servers that one connect too. That is mainly in responce to the metaserver being down recently. -- -- Andrew Fuchs From tchize at myrealbox.com Thu May 26 15:17:19 2005 From: tchize at myrealbox.com (tchize) Date: Thu May 26 15:21:02 2005 Subject: Upgrading from small world to big world, Was: [crossfire] Problem in a new Linux Crossfire server. Help plz!!!!!!!!!!!! In-Reply-To: <200505261509.29266.cerzeo@gmail.com> References: <200505261509.29266.cerzeo@gmail.com> Message-ID: <200505262217.33939.tchize@myrealbox.com> This is a matter of renaiming the appartement files and patching the links back to the world in it. Also each player must be teleported to a safe place. The whole process has to be done for all players. Try contacting leaf on metalforge, maybe, is say **maybe** he may help you. Or just wait a few days on list to let everyone read your request. Le Jeudi 26 Mai 2005 15:09, cerzeo@gmail.com a ?crit : >I was looking for this script, but i don't find it. > >Someone has this scrip or know how to "validate" small world map player's >appartment to big world maps? > >Thanks. :) > >_______________________________________________ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- 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/20050526/9fb584b9/attachment.pgp From nicolas.weeger at laposte.net Thu May 26 16:14:27 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu May 26 16:17:02 2005 Subject: [crossfire] Client compile broken on linux In-Reply-To: <200505260942.14845.tchize@myrealbox.com> References: <200505260942.14845.tchize@myrealbox.com> Message-ID: <42963C33.5080100@laposte.net> tchize a ?crit : > /me impales Ryo That's payback for all the times i had to fix broken compilation under windows :) Ryo From B.T.Lally at warwick.ac.uk Thu May 26 23:16:32 2005 From: B.T.Lally at warwick.ac.uk (Brendan Lally) Date: Thu May 26 23:17:08 2005 Subject: [crossfire] new metaserver Message-ID: since the previous metaserver has shown itself to be unable to deal with an attack, and since having a metaserver is a nice thing, I have over the last few days been writing a distributed HTTP-based replacement. following a design described on IRC by TechII and Tchize (among others). This system comprises of a series of metaservers and a metametaserver. The metaservers collect server information, and propagate it to the metametaserver, and the metametaserver collates this and makes it available to all the metaservers. The metametaserver is /only/ connected to by the metametaservers and can be firewalled off from all but a small number of IP adresses. This will make it hard to attack. The metaservers are vulnerable, but there are several (at least half a dozen) and can be run on any webserver with php support (or even without, I'll clarify below) As of now, the web-based scripts operate as they should, and most show-stopper bugs appear to have been found. Metaservers can exist in two forms, what I call active and passive, active webservers allow the game servers to add themselves, they require php. passive servers merely mirror the server list and metaserver list, any webserver can support these. What is left is client and server support, plus maybe a few tweaks to filelocking and bizzare character filtering. Before I start doing that though, I would like to be able to freeze the server entry format. currently an entry looks like: cat2.dynu.ca 13327 1117165607 version 1023 1027 Crossfire Server cat2 1.7.0CVS no description with two lines, the top line being the port, ip or hostname of the server, (unix) time of the server entry and the protocol header. the second line contains information shown to the player, server name, server version, and comment. The question is, are other fields needed, and if so what? (player maybe could be one). the tracker item http://sourceforge.net/tracker/index.php?func=detail&aid=1208250&group_id=13833&atid=313833 contains various files related to this. From mikeeusaaa at yahoo.com Thu May 26 23:45:44 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Thu May 26 23:47:08 2005 Subject: [crossfire] new metaserver In-Reply-To: 6667 Message-ID: <20050527044544.73119.qmail@web61015.mail.yahoo.com> Amount of players connected would be a good statistic. --- Brendan Lally wrote: > since the previous metaserver has shown itself to be > unable to deal with an attack, and sAince having a > metaserver is a nice thing, I have over the last few > days been writing a distributed HTTP-based > replacement. following a design described on IRC by > TechII and Tchize (among others). > > This system comprises of a series of metaservers and > a metametaserver. > > The metaservers collect server information, and > propagate it to the metametaserver, and the > metametaserver collates this and makes it available > to all the metaservers. > > The metametaserver is /only/ connected to by the > metametaservers and can be firewalled off from all > but a small number of IP adresses. This will make it > hard to attack. > > The metaservers are vulnerable, but there are > several (at least half a dozen) and can be run on > any webserver with php support (or even without, > I'll clarify below) > > As of now, the web-based scripts operate as they > should, and most show-stopper bugs appear to have > been found. > > Metaservers can exist in two forms, what I call > active and passive, active webservers allow the game > servers to add themselves, they require php. > > passive servers merely mirror the server list and > metaserver list, any webserver can support these. > > What is left is client and server support, plus > maybe a few tweaks to filelocking and bizzare > character filtering. > > Before I start doing that though, I would like to be > able to freeze the server entry format. currently an > entry looks like: > > cat2.dynu.ca 13327 1117165607 version 1023 1027 > Crossfire Server > cat2 1.7.0CVS no description > > with two lines, the top line being the port, ip or > hostname of the server, (unix) time of the server > entry and the protocol header. > > the second line contains information shown to the > player, server name, server version, and comment. > > The question is, are other fields needed, and if so > what? (player maybe could be one). > > the tracker item > http://sourceforge.net/tracker/index.php?func=detail&aid=1208250&group_id=13833&atid=313833 > contains various files related to this. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html From mwedel at sonic.net Fri May 27 00:19:37 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri May 27 00:19:08 2005 Subject: [crossfire] multipart images In-Reply-To: <1116699507.3413.11.camel@oberon.kameria> References: <20050521174702.66102.qmail@web61021.mail.yahoo.com> <1116699507.3413.11.camel@oberon.kameria> Message-ID: <4296ADE9.2000909@sonic.net> Todd Mitchell wrote: > Changing the image names will have no impact on your maps, the arches > will refrence the proper images if updated properly, it's just mostly a > pain to remove and add the image files back into CVS. > > It wouldn't be much of a standard if we didn't rename the images > however... I have no issue with x being used. However, I'd also have to consider 1 being a proper first digit also (house.111, house.112), as it is only the first part. I had used x way back when just to hold the combined large images back before merged images were supported (back then, the merged images were just used because it was easier to make the image as a single piece than split it into small pieces). From mwedel at sonic.net Fri May 27 00:28:04 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri May 27 00:26:58 2005 Subject: [crossfire] Create food / alchemy abuse? In-Reply-To: <42950ADC.6020301@telus.net> References: <4294EAAC.50407@laposte.net> <42950ADC.6020301@telus.net> Message-ID: <4296AFE4.6050808@sonic.net> Alex Schultz wrote: > Nicolas Weeger wrote: > >> Same player on Metalforge that reported talisman issue also showed >> alchmy-related one. >> >> Player can easily use 'create mandrake root', and 'create booze' and >> things like that to make potions of cure disease. >> Thus again much money gained, for a real low risk. >> >> I thought items created with 'create food' were god-given? > > > Both I and eracc (poof or galahad on MF) have known about the fact that > "create food" items being usable for alchemy for a long while now. > Neither of us have really considered it a bug. We've done it for things > like water of the wise and some others, but those alone aren't very > profitable, though they are good for getting parts for other alchemy > recipes. It seems you've stumbled across a highly profitable one > compared to the ones eracc and I have been using for making alchemy parts. > > I don't consider this to be bug that create food spells can be used in > alchemy, however I'm thinking that something need to be done to increase > risk to those using it. One possible solution to this that I just > thought of, would be making the items made by create food cursed a > portion of the time to mess up people trying to abuse it for alchemy (as > those who do alchemy should know well... throwing cured items into the > mix can sure mess somebody up) Making stuff created via create food seems a little odd to me (your god is creating food for you, and creates cursed food?) The simplest is perhaps to disallow the player from specifying what to create with the create food command (without options right now, it will try to create the best food, via food value, anyways). Note however that booze is very common. Mandrake root is rarer, but can still be found now and again in shops - even buying from a shop, probably still make money in the deal. Another option would be to make it more difficult to make cure disease potions. However, these last two options aren't all that appealing - we don't really want to make it really hard to make alchemy items. From mwedel at sonic.net Fri May 27 00:31:29 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri May 27 00:31:08 2005 Subject: Upgrading from small world to big world, Was: [crossfire] Problem in a new Linux Crossfire server. Help plz!!!!!!!!!!!! In-Reply-To: References: <3fa5094505052603261995dc12@mail.gmail.com> <200505261256.41110.tchize@myrealbox.com> Message-ID: <4296B0B1.6000305@sonic.net> Rick Tanner wrote: > On Thu, 26 May 2005, tchize wrote: > > >>I think metalforge once ran such a script on their player files, but not sure. > > > > When metalforge migrated from the small world maps to the big world maps, > it was at the same time as the new skill system went in to affect. > > Player files were not migrated/updated - they started over on the new (and > now current..) metalforge server. You can try using the update_apart.pl in the maps/Info directory to update the apartments. Don't know for sure if it will work - probably should, but not 100% sure how well tested it ever really was. From mwedel at sonic.net Fri May 27 01:05:49 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri May 27 01:05:08 2005 Subject: [crossfire] new metaserver In-Reply-To: References: Message-ID: <4296B8BD.6050106@sonic.net> Brendan Lally wrote: > since the previous metaserver has shown itself to be unable to deal with an > attack, and since having a metaserver is a nice thing, I have over the last > few days been writing a distributed HTTP-based replacement. following a > design described on IRC by TechII and Tchize (among others). > > This system comprises of a series of metaservers and a metametaserver. > > The metaservers collect server information, and propagate it to the > metametaserver, and the metametaserver collates this and makes it available > to all the metaservers. A few questions on this: IS the idea to have DNS records for metaserver.crossfire.org (or whatever) point to all those possible/trusted meta servers? This of course doesn't really eliminate DOS attacks - it just means that someone has to attack 6 hosts instead of 1. Which is an improvement, but may not eliminate the problem. And while it runs on any web server is certainly convenient, it only does good if other people know about it of course (running it on mine does no good if no one knows about it, and if the main metaserver doesn't trust it) It seems to me that it would also be a better idea not to have a 'metametaserver' at all - just go peer to peer, with the active metaservers periodically sending the data to one of the other metaservers (once a minute or something, it could connect to another, the two exchange information, merging any duplicates/keeping the later). This removes the single point of failure if the metametaserver fails for some reason, at the expense of the data being not quite up to date. One other question I have is how the server sends its data to the active metaserver. Does it still use UDP? If not, and it uses TCP, be aware that you'll have to modify the server to fork, otherwise the servers can (and will) hang if the remote server is down or something. Udp doesn't have that problem of course. In terms of data to provide: IP address is a must. Much easier for the client to already know the IP address instead of having to do DNS looks. Hostname is then another field. As for the data: Version should be included in the top line, not the comment line, as it is now (one reason is that it is a compiled in value, so if you update your server, the version number reported will reflect this without having to go to your settings file and manually updating it.) The protocol versions, IMO, are of limited value to most people (no user is really going to know what 1027 vs 1029 gives them, where they may know that 1.7.0 is the latest). Plus, the protocol versions have been stable for a very long time. Including it does no harm, just doesn't really add anything. Note you should look at the current metaserver for what data it sends. For example, it also sends along the number of input and output bytes it has sent (useful for some scripts that collect that stuff) as well as how long the server has been up. From nicolas.weeger at laposte.net Fri May 27 02:35:15 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri May 27 02:37:10 2005 Subject: [crossfire] Create food / alchemy abuse? Message-ID: > Note however that booze is very common. Mandrake root is rarer, but can still > be found now and again in shops - even buying from a shop, probably still make > money in the deal. Indeed, mandrake root isn't that unusual, but players can make some hundred (i think) with one create food (low food value). So it beats buying in shops by far :) > Another option would be to make it more difficult to make cure disease potions. > > However, these last two options aren't all that appealing - we don't really > want to make it really hard to make alchemy items. I'd say the best way would be to forbid making alchemy items with items created by create food. But then we need to track that. Could we simply change the item's name? Like 'created mandrake root'? This way item has all properties set, but can't be used by alchemy (which uses name). Will also make sure the value of 0 is known. Or we could simply check the item's value, too - set to 0 by create food. Nicolas Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From mwedel at sonic.net Fri May 27 10:16:06 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri May 27 10:15:14 2005 Subject: [crossfire] Create food / alchemy abuse? In-Reply-To: References: Message-ID: <429739B6.4050308@sonic.net> Nicolas Weeger wrote: > > I'd say the best way would be to forbid making alchemy items with items created by create food. But then we need to track that. Could we simply change the item's name? Like 'created mandrake root'? This way item has all properties set, but can't be used by alchemy (which uses name). Will also make sure the value of 0 is known. > Or we could simply check the item's value, too - set to 0 by create food. Yes, that can be done. I think the reason why that wasn't done was so that the objects would merge nicely together (however, if the name is changed, that clarifies why they shouldn't merge). From tchize at myrealbox.com Fri May 27 10:16:15 2005 From: tchize at myrealbox.com (tchize) Date: Fri May 27 10:19:14 2005 Subject: [crossfire] new metaserver In-Reply-To: References: Message-ID: <200505271716.25901.tchize@myrealbox.com> MM this doesn't look like what i had in mind during irc chat. Here is my analysis of problem (no implementation done yet): Problem: Metaserver currently down Reason: DOS attack (polluted server list?) Solution: Revise protocol Things to care about: - DOS resistance and prevent list pollution - Redundancy to avoid downtime and easiness of redundant node creation - Reliability of data - redundant node should be able to be hosted on any web enabled isp (no active script) Analysis of current metaserver behavior: Currently, when a public server starts, it registers to the metaserver, using a simple protocol. It provides a server address, a description and a name. After, it updates the metaserver on a regular basis to inform it about current number of players. The metaserver keep track of servers for about one day. This protocol is subjet to several limitations: - Somebody could register lots of fake servers (DOS) resulting in client having to download a huge list of servers. - Somebody could register a server, faking another server, to gather passwords. - If the server crash and re-register to metaserver, old entry is not deleted, resulting in pollution of list when a server is unstable. - The informations from metaserver can not be trusted in any way. - If metaserver crash, no client can see a list of servers - udp/ip used for registering make it easy to do impersonate ips (attacker potentially untrackable) The proposition i'll make to create a new handling for metaserver will address all those limitations. Prevention of fake servers and list pollution, limitations on DOS: The list of public servers is something quite static. Unless when used for testing purposes, if someone starts a public server this is for at least a few week. For this, i suggest the addition of server to the metaserver list be something needing manual metaserver admin intervention. The sourceforge bugtrack allows the creation of new named bugtrack lists. This is currently the case for RFE (request for enhancement). I suggest to create a new buglist named Server. This list will be used by server admins to request for the register of their server in the metaserver list. Metaserver admins would then check the validity of entry and process the registration. We could also perhaps configure this list to request user authentification by sourceforge. The request must contain the servername, the server ip address or dns address (dynamic dns should be tolerated), the server admin email address, a server public description. Redundancy: The list of servers would be made available in a serverlist file, available on the metaserver root node. This list file will be downloaded on a regular basis by mirror nodes. The client could connect either to the root node, either to a mirror node to grab the list of public servers Trust of metaserver datas. Because of replication between nodes, there should be a way to ensure the list has not been tampered (preventing someone to fake a server). The client should have a list a public keys corresponding to the keys of metaserver root node admins. The server list must always be signed by a root metaserver node admin, probably the one doing the manual update and client would check the signature of list before using it. DOS resistance: The client should be always shipped with an uptodate static list of metaservers and list of servers. If root metaserver node is down, meaning the list of metaservers can not be found, client use cached metaserver list to grab a mirror metaservers. If it can't connect to any metaserver, it uses the cached server list and diplay it to user. Overall client process: - get the metaserverlist from sf if possible and check signature. If anything fails, fallback to cached list. If cached list fail, fall back to static list - connect to a random metaserver in lsit and process a GET for the url listed in the metaserver list. If this fail, or signature check fails, process to another metaserver. - update cached metaserver list - if all metaservers fails, process with cached server list and if it fails, process with the static server list. - update cached server list - for each server in list, eventually connect to it and grab it's current statistics (number of players, uptime, aso) Replication process: This is quite easy, each mirror node just has, on a regular basis, to download a specific file from root node and publish it. This could be done on any linux box with a wget followed by an ftp , the box executing the mirroring script does not have to be the one serving the files. (ie i can run a script twice a day on my dsl connected linux box to publish the mirrored file to http://users.skynet.be/tchize/server.list, i don not need my dsl linux box to be permanently connected (just twice a day). Drawbacks: metaserver does not keep anymore statical informations on server. Clients are supposed to gather such information themself (note this is a quite common behavior for first person shooter games) process of adding a new public server is a bit slow (wait for admin approval and then replication) Advantages: DOS resistant No single point of failure (isp's are quite difficult to DOS and even if all metaserver are under heavy load client can still rely on on cached datas) Server list can be trusted. Mirror can be put on most ISP (personal web spaces gracefully provided by provider) Le Vendredi 27 Mai 2005 06:16, Brendan Lally a ?crit : >since the previous metaserver has shown itself to be unable to deal with an > attack, and since having a metaserver is a nice thing, I have over the last > few days been writing a distributed HTTP-based replacement. following a > design described on IRC by TechII and Tchize (among others). > >This system comprises of a series of metaservers and a metametaserver. > >The metaservers collect server information, and propagate it to the > metametaserver, and the metametaserver collates this and makes it available > to all the metaservers. > >The metametaserver is /only/ connected to by the metametaservers and can be > firewalled off from all but a small number of IP adresses. This will make > it hard to attack. > >The metaservers are vulnerable, but there are several (at least half a > dozen) and can be run on any webserver with php support (or even without, > I'll clarify below) > >As of now, the web-based scripts operate as they should, and most > show-stopper bugs appear to have been found. > >Metaservers can exist in two forms, what I call active and passive, active > webservers allow the game servers to add themselves, they require php. > >passive servers merely mirror the server list and metaserver list, any > webserver can support these. > >What is left is client and server support, plus maybe a few tweaks to > filelocking and bizzare character filtering. > >Before I start doing that though, I would like to be able to freeze the > server entry format. currently an entry looks like: > >cat2.dynu.ca 13327 1117165607 version 1023 1027 Crossfire Server > cat2 1.7.0CVS no description > >with two lines, the top line being the port, ip or hostname of the server, > (unix) time of the server entry and the protocol header. > >the second line contains information shown to the player, server name, > server version, and comment. > >The question is, are other fields needed, and if so what? (player maybe > could be one). > >the tracker item > http://sourceforge.net/tracker/index.php?func=detail&aid=1208250&group_id=1 >3833&atid=313833 contains various files related to this. > >_______________________________________________ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- 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/20050527/1dd83250/attachment.pgp From mwedel at sonic.net Fri May 27 10:18:33 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri May 27 10:24:38 2005 Subject: [crossfire] starting server In-Reply-To: <1124ed900505251935187a096a@mail.gmail.com> References: <1124ed900505251935187a096a@mail.gmail.com> Message-ID: <42973A49.2000804@sonic.net> Neon Lim wrote: > Hi, > > i am using ssh to control my linux server remotely. > i tried running ./crossfire & > > the moment i close my putty, crossfire server is shut down. > > the same with ./crossloop & > > However, i am successful in using ./crossfire -detach & to start > crossfire server and close my putty and it still running. > > My question: > - is there a ./crossloop -detach ? because using ./crossfire -detach > &, if the crossfire server is down, it will not restart..? > > - should i run ./crossloop -detach as root or run as normal user? This is standard unix job control. Try doing 'nohup ./crossloop (or crossfire) &'. The nohup should result in the script running even after logout. > > - is there anyway to restrict the number of race/classes that can be > choosen by players? Not easily. You have to remove the archetypes for the race/classes you don't want people to be able to play. > > - is there anyway to run crossfire server but stop people from making > new characters? because i want to let some players play but stop new > players from creating new character. This would requiring the code, but wouldn't be that hard a change to make. From tchize at myrealbox.com Fri May 27 10:17:44 2005 From: tchize at myrealbox.com (tchize) Date: Fri May 27 10:24:42 2005 Subject: [crossfire] Client compile broken on linux In-Reply-To: <42963C33.5080100@laposte.net> References: <200505260942.14845.tchize@myrealbox.com> <42963C33.5080100@laposte.net> Message-ID: <200505271717.45191.tchize@myrealbox.com> Le Jeudi 26 Mai 2005 23:14, Nicolas Weeger a ?crit : >tchize a ?crit : >> /me impales Ryo > >That's payback for all the times i had to fix broken compilation under >windows :) > Windows IS broken by nature. >Ryo > >_______________________________________________ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- 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/20050527/50da3d75/attachment.pgp From mwedel at sonic.net Fri May 27 10:25:49 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri May 27 10:29:14 2005 Subject: [crossfire] Request for ui bindings for scripts. In-Reply-To: <1116093290.6945.12.camel@hawk> References: <1116093290.6945.12.camel@hawk> Message-ID: <42973BFD.1080100@sonic.net> Preston Crow wrote: > On Sat, 2005-05-14 at 13:39, Andrew Fuchs wrote: > >>It would be nice if a script can intergrate more fully with the >>client's ui. Namly, add enteries to the menubar, and otherwise >>maniuplate the ui of the client. > > > That would be nice. > > One thing nice about the current interface is it requires very little > modification of the non-common client code. It can be used with the old > cfclient, gtkclient, and pretty much anything else. > > If someone wrote a generic "add button" interface to the various > clients, then it would be fairly easy to hook the scripting in to it. > > I'm not familiar enough with the various toolkits to do something like > that. For GTK, it wouldn't be hard to have a pull down menu for the scripts (putting buttons someplace is harder, because you need that space someplace to draw those buttons, and most of the clients don't have the space). In terms of an interface, presumably not all clients would necessary have to support it - it is in a sense a convenience function. So clients in which it is easy to implement such a thing could certainly do so, but for other clients, like the X11 which really can't, the callback function could basically be a an empty function. From cerzeo at gmail.com Fri May 27 10:35:40 2005 From: cerzeo at gmail.com (cerzeo@gmail.com) Date: Fri May 27 10:29:58 2005 Subject: [crossfire] new metaserver In-Reply-To: <4296B8BD.6050106@sonic.net> References: <4296B8BD.6050106@sonic.net> Message-ID: <200505271735.41196.cerzeo@gmail.com> And there is possible to create a metaserver using the port number 80 or 21 (ftp port?). Me and sure many people are in a LAN, and proxy server have all ports closed, except 80, 21 and amsn port. If not, can someone connect (extern to mi LAN), connect to my server? My LAN IP is 163.117.65.99, but when i visit this web www.whatismyip.com, it sas that my IP is 163.117.36.72. Can it be possible? Someone can explain me this? Thanks. El Viernes 27 Mayo 2005 08:05, Mark Wedel escribi?: > Brendan Lally wrote: > > since the previous metaserver has shown itself to be unable to deal with > > an attack, and since having a metaserver is a nice thing, I have over the > > last few days been writing a distributed HTTP-based replacement. > > following a design described on IRC by TechII and Tchize (among others). > > > > This system comprises of a series of metaservers and a metametaserver. > > > > The metaservers collect server information, and propagate it to the > > metametaserver, and the metametaserver collates this and makes it > > available to all the metaservers. From alex_sch at telus.net Fri May 27 10:28:14 2005 From: alex_sch at telus.net (Alex Schultz) Date: Fri May 27 10:30:01 2005 Subject: [crossfire] Create food / alchemy abuse? In-Reply-To: References: Message-ID: <42973C8E.3090603@telus.net> Nicolas Weeger wrote: > >I'd say the best way would be to forbid making alchemy items with items created by create food. But then we need to track that. Could we simply change the item's name? Like 'created mandrake root'? This way item has all properties set, but can't be used by alchemy (which uses name). Will also make sure the value of 0 is known. >Or we could simply check the item's value, too - set to 0 by create food. > As I see it, one problem with alchemy is that many items are too hard to get without using either create food if they aren't items that have converter squares in alchemy shops. I don't think that there should be any recipes that could be created by using *only* create food spell, but I find that most recipes are already plenty hard enough to get the ingredients for even with create food. For example, the fact that both sage's heads and unicorn horns are rather commonly used alchemy items and are so rare makes those recipes to do in batches larger then one or two. I personally feel that many alchemy items are already too rare, and making more difficult to get in decent amounts would make alchemy with all but the basic items with converters in shops near impossible to do much useful things with. Some people (I know of one MF player who's rather well known for this but isn't on much lately) do 'hire' others to quest for such parts, but I find that it can be so difficult to find people to do that that you might as well spend hours and hours to get just enough to gain just 1 or 2 alchemy levels. To summarize my ranting, I think that alchemy parts are overall more than rare enough already and this is a step in the wrong direction *however* alchemy shouldn't be possible to do purely with created items. Alex Schultz (aka Rednaxela) From cerzeo at gmail.com Fri May 27 10:41:12 2005 From: cerzeo at gmail.com (cerzeo@gmail.com) Date: Fri May 27 10:31:41 2005 Subject: [crossfire] Client compile broken on linux In-Reply-To: <200505271717.45191.tchize@myrealbox.com> References: <42963C33.5080100@laposte.net> <200505271717.45191.tchize@myrealbox.com> Message-ID: <200505271741.12657.cerzeo@gmail.com> El Viernes 27 Mayo 2005 17:17, tchize escribi?: A friend of mine plays crossfire over my Linux Server. I play crossfire under Linux, and game loads faster in Linux than in Windows. Can it be because of the SDL? Is it possible to accelerate the loading time for Windows? > > Windows IS broken by nature. > Yeah! :P Linux Rules hahaha > >Ryo > > > >_______________________________________________ > >crossfire mailing list > >crossfire@metalforge.org > >http://mailman.metalforge.org/mailman/listinfo/crossfire From mwedel at sonic.net Fri May 27 10:33:27 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri May 27 10:33:15 2005 Subject: [crossfire] channels In-Reply-To: <200504301211.05688.tchize@myrealbox.com> References: <200504240152.09906.b.t.lally@warwick.ac.uk> <200504281632.46186.tchize@myrealbox.com> <427327F3.4070605@sonic.net> <200504301211.05688.tchize@myrealbox.com> Message-ID: <42973DC7.6060205@sonic.net> tchize wrote: >>>> I hope on #2 you are using the formatting features the GTK already has >>>>built in. If so, then it makes life much easier (it'd be really stupid to >>>>have to write our own parser for that when GTK provides one for us) >>> >>>working with gtk1, all i saw was samething called gtk-html, which is an >>>extension not include with the main gtk code, and i doubt it will work for >>>windows version :/ >>> >>>i choos to use something easy to handle (no closing tag, a tag just set a >>>value, there is no such thing as [normal]blabla[hand]foo-bar[/hand]other >>>blabla[/normal] >>> >>>Parsing is quite straight forward anddoesn't involve complicated things. >> >> I think I was looking at the pango parser: >>http://www.gtk.org/api/2.6/pango/PangoMarkupFormat.html >> >> This is a bit more complicated in its format, but then integrates very >>simply into the client. > > > lib pango is gtk2, not gtk1. And the format is indeed more complicated. This > sure simplifies to writing of gtk2 client, but it's a problem with other > clients (gtk1, opengl client, sdl client). > Also there is a problem for fonts, i want 5 fonts to be availabe, > corresponding to normal text, hand written text, magical text, > undecipherable text and fixed width text and the attribute does not . > I can't really see how the pango markup will be of help on that. Not to > mention it has no support for including pictures in text. > > Also, am not sure it's a good idea to have client/common have a permanent > dependency on libPango Well, if pango was used, the dependency would probably be in the graphical area anyways. That said, pango may not be the best choice, however, in looking at it, it seemed to somewhat match html. However, thinking about this, perhaps xml is really the way to go. Parsers are already out there, one can I believe write up the necessary description files so the data could even be displayed in web browsers. My real point here is to me, it makes no sense to come up with our own description language that then requires us to write our own parser for this. We should use what is out there if we can - writing everything from anew just seems like a waste of effort and more of a maintenance pain. xml would probably also be convenient in that new tags could be added, but the client should be able to pretty easily just ignore the tags it doesn't know about but still display the content. From mwedel at sonic.net Fri May 27 10:37:02 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri May 27 10:39:45 2005 Subject: [crossfire] channels In-Reply-To: <200505020011.50896.b.t.lally@warwick.ac.uk> References: <200504240152.09906.b.t.lally@warwick.ac.uk> <200504281425.32061.b.t.lally@warwick.ac.uk> <42732328.8020504@sonic.net> <200505020011.50896.b.t.lally@warwick.ac.uk> Message-ID: <42973E9E.8030409@sonic.net> Brendan Lally wrote: > On Saturday 30 Apr 2005 07:18, Mark Wedel wrote: > >> Just because the preference is stored on the client doesn't mean the >>client can't tell the server what its preference is. > > > ok, sure, that just means sending the data rather than using the save file. > However I am unsure how older clients would work then? Older clients will have issues in most any case, because they won't have the new logic to display the new channels nicely. However, the simple case is they would run with the default channel subscriptions, as if they had never changed it. > > >> So for channels, same thing could be done - as part of setting up the >>connection, the client can get the channel listing from the server, and for >>ones it knows about, send back whether it wants to subscribe to those >>channels or not. > > > What about the channels created after the client has logged on? Presumably in a similiar way to channels that have been created since the player has last logged in - there would be some default mechanism on what to do for such channels (subscribed or not subscribed). Also, in both cases, there would be some mechanism to inform the client of these new channels - the mechanism can basically be the same for nw ones created during playing and those new ones created since last login. From B.T.Lally at warwick.ac.uk Fri May 27 10:33:54 2005 From: B.T.Lally at warwick.ac.uk (Brendan Lally) Date: Fri May 27 10:40:19 2005 Subject: [crossfire] new metaserver Message-ID: >>> mwedel@sonic.net 05/27/05 07:08 AM >>> > IS the idea to have DNS records for metaserver.crossfire.org (or whatever) > point to all those possible/trusted meta servers? There are two lists, the game server list and the metaserver list. Each metaserver has a copy of both lists, that they sync with the metametaserver. when a client connects, they have their own list of metaservers (that will be install with the tarball) and they pick randomly a metaserver from that list. From that metaserver they get a list of servers, and a list of metaservers. In future they use that new list to pick randomly from. When a server connects they have the same list of metaservers, and they pick a random 'active' server and send a get request to http://metaserver/addme.php?name=server name&version=server version&comment=whatever they want to appear in the comment line&ip=their hostname[unless they want to use their ip directly, in which case this field is omitted] they then fetch the list of metaservers, and use that next time. > This of course doesn't really eliminate DOS attacks - it just means that > someone has to attack 6 hosts instead of 1. Which is > an improvement, but may > not eliminate the problem. This is true, but all that is required for the system to resurrect itself is for one of those servers to return. If that happens, then each client will eventually hit that one, and then they will get the entire new list of servers. 1 server out of 6-12 surviving a DoS attack is quite a reasonable expectation, especially since it is using HTTP which it is possible to make quite well hardened against such things. > And while it runs on any web server is certainly > convenient, it only does good if other people know > about it of course (running > it on mine does no good if no one knows about it, and > if the main metaserver > doesn't trust it) Yes, once you have a metaserver running, you would email the metametaserver admin, and say 'hello, I have a new [active/passive] metaserver it can be accessed as [ip adress or hostname] and updates via [ip adress or hostname] (those may or may not be the same. the list of metaservers would then be appended to include your metaserver, and the ip adress you use for updates would be let through the firewall around the metametaserver. This assumes that we trust you :) > It seems to me that it would also be a better idea not to have a > 'metametaserver' at all - just go peer to peer, with the active metaservers > periodically sending the data to one of the other metaservers (once a minute or > something, it could connect to another, the two exchange information, merging > any duplicates/keeping the later). This removes the single point of failure if > the metametaserver fails for some reason, at the expense of the data being not > quite up to date. I considered this, but I couldn't see a nice way to add new metaservers securely (bearing in mind that without some form of checking, a hostile server could crapflood the other servers into uselessness). All methods that were sane to implement would use a central auth server anyway. If that is the case, then you might as well connect to it to send the data too, since it is going to be there anyway. If there is a way around this that I haven't considered, then let me know. It also may increase traffic quite substantially compared to a system where each server expects to have ~ (number of hits old metaserver had on average )*2/number of metaservers + some updates sent out to the metametaserver. should the metametaserver fail, the individual servers will act quite autonomously for a while, they simply need to updated to point to a new metametaserver. It is easier to change a line in a dozen known copies of a perl script than to change a DEFINE in a thousand unknown compiled C programs. > One other question I have is how the server sends its data to the active > metaserver. Does it still use UDP? If not, and it uses TCP, be aware that > you'll have to modify the server to fork, otherwise the servers can (and will) > hang if the remote server is down or something. Udp doesn't have that problem > of course. Yeah, it'd use TCP, it has to to connect to a webserver I'm toying with the idea of using libcurl directly to handle most of it, this is fairly quick and easy, compared to implementing HTTP manually, but it does add a new dependancy (albeit a common one). The alternitive is to write directly to the socket. But certainly for the server starting up and forking to have the metaserver be contacted should be fine, it would just then travel randomly down the list of metaservers until it finds one that returns a 200. It should be quite easy to have a lock file setup to ensure that the metaserver requests don't overlap.. > In terms of data to provide: > IP address is a must. Much easier for the client to already know the IP address > instead of having to do DNS looks. Hostname is then another field. This is a fair point. Maybe forcing the use of ip adresses is simpler.... The 'name' field already exists, I guess a check should be made then that if the name field is a valid hostname (as opposed to just a server name) that it resolves to the ip given. > As for the data: > Version should be included in the top line, not the comment line, as it is now The point of the bottom line is that it is what the player 'sees', it isn't needed for the client to connect to know what release the server is running. A player however, will want to know which version the server runs, so it will go on the bottom line, as player-known information. > (one reason is that it is a compiled in value, so if you update your server, the > version number reported will reflect this without having to go to your settings > file and manually updating it.) The protocol versions, IMO, are of limited > value to most people (no user is really going to know what 1027 vs 1029 gives > them, where they may know that 1.7.0 is the latest). If the protocol changes, such that it breaks against older or newer clients, then the client will be able to compare the protocol entry and simply not show those that are of the wrong version. The player will never see it (it is on the first line), but nor would they be forced to update, or know the version numbers that their client will work with. This information is also acquired by the metaserver, it connects back to the ip and port it was given, and checks that the banner says 'crossfire' in it. In theory crossfire derivatives could use the same system. > Note you should look at the current metaserver for what data it sends. For > example, it also sends along the number of input and output bytes it has sent > (useful for some scripts that collect that stuff) as well as how long the server > has been up. Do any scripts actually collect that? I can't say I've noticed it being used, if it is wanted though, it can be added easily now. (adding it later, is more interesting....) Uptime is an interesting one, if nothing else it could allow netcraft-style uptime graphs on the metaservers..... (would require archiving the files though, and storage requirements may break that, a ~500byte file every few hours is the sort of thing that makes webservers hit their quotas....) From B.T.Lally at warwick.ac.uk Fri May 27 10:48:28 2005 From: B.T.Lally at warwick.ac.uk (Brendan Lally) Date: Fri May 27 10:52:26 2005 Subject: [crossfire] new metaserver Message-ID: >>> cerzeo@gmail.com 05/27/05 16:33 PM >>> > And there is possible to create a metaserver using the port number 80 or 21 > (ftp port?). > If not, can someone connect (extern to mi LAN), connect to my server? > My LAN IP is 163.117.65.99, but when i visit this web www.whatismyip.com, it > sas that my IP is 163.117.36.72. Can it be possible? Someone can explain me this? > Me and sure many people are in a LAN, and proxy server have all ports closed, > except 80, 21 and amsn port. It looks like you mean that you have all ports other than 80, 21, and 6-whatever it is, blocked outbound. If this is the case, we would expect that you have all inbound ports blocked (otherwise such a measure isn't sensible. Such configurations are normally only found in highly locked down environments. The new metaservers will use HTTP, this means that a webserver is needed to be one. If you can run a webserver, you can run one, if you can access other web servers then you can use them (but crossfire doesn't use HTTP for server-client communications, so you won't be able to connect to a remote server. You seem to be in a fairly large internal subnet though, so you should be able to run a server accessible in there quite easily. If you were to run a metaserver internally, you would be able to script the fetching of the server lists each day (or more frequently) and mirror them, propagating your own custom metaserver list. This isn't useful though, since you wouldn't be able to connect to the remote servers.... From mwedel at sonic.net Fri May 27 10:58:19 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri May 27 10:57:13 2005 Subject: [crossfire] new metaserver In-Reply-To: <200505271716.25901.tchize@myrealbox.com> References: <200505271716.25901.tchize@myrealbox.com> Message-ID: <4297439B.5070600@sonic.net> tchize wrote: > MM this doesn't look like what i had in mind during irc chat. Here is my > analysis of problem (no implementation done yet): A few notes. > > > Problem: > Metaserver currently down > Reason: > DOS attack (polluted server list?) My understanding is a flood of client requests trying to get data from the metaserver. Unknown if this is broken clients or something else. That said, the current metaserver implementation isn't that good (one change I made was to not send metaserver info to someone that connected in last minute or so). However other things could be done, like also putting a small sleep in the sending of data. > - Somebody could register lots of fake servers (DOS) resulting in client > having to download a huge list of servers. Correct. > - Somebody could register a server, faking another server, to gather > passwords. Yes - that could be improved by having the metaserver verify the hostname provided against IP. The problem here is that DNS lookups can be a slow operation, so can't be done in the very simple script used now. And if a threaded/forked call is done, you then have to sort out data consistency and file locking. > - If the server crash and re-register to metaserver, old entry is not deleted, > resulting in pollution of list when a server is unstable. Not true. Metaserver has no idea when it gets the UDP packet from the server if that server has restarted or if it is one of the periodic updates. It looks through the entries it has, and if it finds a matching one, updates it. The problem has been people running servers on dynamic ip adresses. It is the IP address the server uses to match for duplicates. So what happens is someone is running the server on a server that gets it via DHCP, and that server is restarting or whatever with new IP addresses, so you get a flood from that. One change was to reduce the timeout of servers we haven't get info from from 1 day to something like 60 minutes (even that is actually a bit long - if we haven't gotten data, unlikely server is up) > - The informations from metaserver can not be trusted in any way. > - If metaserver crash, no client can see a list of servers > - udp/ip used for registering make it easy to do impersonate ips (attacker > potentially untrackable) all true. > > Overall client process: > - get the metaserverlist from sf if possible and check signature. If anything > fails, fallback to cached list. If cached list fail, fall back to static list Note that this would seem to put a single point of failure on SF being up. It often is, but doesn't always seem to be the case. However, looking at the proposal, I have a few questions/thoughts. Since it seems that server admins will need to notify the metaserver admin to be listed, and it seems that some amount of the dynamic data currently listed won't be as up to date (due to timing, or perhaps not being included), it seems that this isn't that far away from just having a static HTML page that someone updates that is then replicated. Which of course isn't really what the metaserver is about. Just a thought - has anyone looked at what other games do (nettrek I think would be one example) - presumably, some games have already put a lot of thought into this - it could be simpler to just grab there server and client code and go from there. From cerzeo at gmail.com Fri May 27 11:37:52 2005 From: cerzeo at gmail.com (Alberto Saez Lodeiros) Date: Fri May 27 11:29:14 2005 Subject: [crossfire] new metaserver In-Reply-To: References: Message-ID: <200505271837.53058.cerzeo@gmail.com> El Viernes 27 Mayo 2005 17:48, Brendan Lally escribi?: > It looks like you mean that you have all ports other than 80, 21, and > 6-whatever it is, blocked outbound. If this is the case, we would expect > that you have all inbound ports blocked (otherwise such a measure isn't > sensible. Yes, we have all but 80, 21 and 6 ports blocked, but not only for inbound, too for outbound. > Such configurations are normally only found in highly locked down > environments. I'm in a student's residence, which is connectted directly to the University Net (with a Debian server) > The new metaservers will use HTTP, this means that a webserver is needed to > be one. If you can run a webserver, you can run one, if you can access > other web servers then you can use them (but crossfire doesn't use HTTP for > server-client communications, so you won't be able to connect to a remote > server. Do you mean something like an Apache server, using, by default, 8080 port? I have my Apache server, but I don't know if other external people can access my computer using Apache, who is using 8080 port. > You seem to be in a fairly large internal subnet though, so you should be > able to run a server accessible in there quite easily. If you were to run a > metaserver internally, you would be able to script the fetching of the > server lists each day (or more frequently) and mirror them, propagating > your own custom metaserver list. I play crossfire using a direct LAN connection between me and my residence's friends, internally. What do you mean with propagate my own custom metaserver list? > This isn't useful though, since you wouldn't be able to connect to the > remote servers.... The "comunication" port between crossfire server and client can't be changed anyway? I have tried to use port 21, 80 and console returns me an error in the client side: Can't connect to server: Network is unreachable Is it because of the client configuration, the server configuration or the systen/net configuration? I have changed the server port in the server settings file. (I tried ports 21 and 80). Thanks for your help. :) -- ========================================================== - Hay 10 tipos de personas: Las que NO entienden c?digo biario y las que SI. ========================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050527/fc65504e/attachment.html From mikeeusaaa at yahoo.com Fri May 27 11:43:27 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri May 27 11:45:15 2005 Subject: [crossfire] new metaserver In-Reply-To: Message-ID: <20050527164327.19615.qmail@web61021.mail.yahoo.com> Cave's meta server system is very good. You cannot defeat a DDoS, but this gives us abit better chance. I do not agree at all with admining the metametaserver as some suggested. That way unpopular people's (like me) servers would not make the list unless they kissed the asses of the admins. IE: "We shouldn't include him, he's and anti-women's-rights terrorist" etc. Just let everything be automatic. Also I sugest not nitpicking the thing, we should use what we have... and with this thing we can put it on almost _ANY_ webserver. That means we can host some metaservers on the biggest pipes available (webhosting sites). If they want to DDoS CF then... well they'll have to take out 1/2 the internet. __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/ From alex_sch at telus.net Fri May 27 11:53:22 2005 From: alex_sch at telus.net (Alex Schultz) Date: Fri May 27 11:53:34 2005 Subject: [crossfire] Spellcasting Swords & Python Troubles In-Reply-To: <20050526084955.GA20382@kirschbaum.myrealbox.com> References: <428C1AF3.90500@telus.net> <428D026D.9070607@laposte.net> <428D2FA4.5070407@telus.net> <428D6762.50901@telus.net> <428DEEB3.90205@telus.net> <428EBF6C.5010909@telus.net> <20050524183031.GA30106@kirschbaum.myrealbox.com> <429411D2.6010505@telus.net> <20050525074828.GA14039@kirschbaum.myrealbox.com> <42946E47.8090300@telus.net> <20050526084955.GA20382@kirschbaum.myrealbox.com> Message-ID: <42975082.4040208@telus.net> Hi again, With the script I've been making (see other posts in this topic), I'm having trouble getting it to work with arrows. The problem is that when one shoots an arrow, the inventory of the arrow is not duplicated properly. One possible solution would be modifying the server code to duplicate the inventory of arrow when shooting. Does anyone think this might break anything? If not, I'll attempt to make a patch for that. Thanks, Alex Schultz (aka Rednaxela) From B.T.Lally at warwick.ac.uk Fri May 27 12:04:49 2005 From: B.T.Lally at warwick.ac.uk (Brendan Lally) Date: Fri May 27 12:07:22 2005 Subject: [crossfire] new metaserver Message-ID: >>> tchize@myrealbox.com 05/27/05 16:25 PM >>> > MM this doesn't look like what i had in mind during irc chat. Ok, it is pretty close to what I believed you were thinking though (with a few modifications suggested by Rednaxela and TechII). Let's see how what you suggest is different, then look at which ways your formal proposal is superior to what I have done currently. >Here is my > analysis of problem (no implementation done yet): > Problem: > Metaserver currently down > Reason: > DOS attack (polluted server list?) > Solution: Revise protocol Concurred. > Things to care about: > - DOS resistance and prevent list pollution > - Redundancy to avoid downtime and easiness of redundant node creation > - Reliability of data Yes, these are good properties to have. > - redundant node should be able to be hosted on any web enabled isp (no > active script) In my system that is called a 'passive' node and can be used by the client, but not the server. > Analysis of current metaserver behavior: > Currently, when a public server starts, it registers to the metaserver, using > a simple protocol. It provides a server address, a description and a name. > After, it updates the metaserver on a regular basis to inform it about > current number of players. The metaserver keep track of servers for about one > day. This protocol is subjet to several limitations: > - Somebody could register lots of fake servers (DOS) resulting in client > having to download a huge list of servers. yes, this has happened. The way I got round that is to try and connect to the reporting server, if they deny the connection, they aren't a real server. > - Somebody could register a server, faking another server, to gather > passwords. Yes, this is justification for resolving the hostname properly. > - If the server crash and re-register to metaserver, old entry is not deleted, > resulting in pollution of list when a server is unstable. Yes, this is currently an issue, iff the ip address changes > - The informations from metaserver can not be trusted in any way. Why not? > - If metaserver crash, no client can see a list of servers This has been partially resolved already, by Ryo's server cache patch. > - udp/ip used for registering make it easy to do impersonate ips (attacker > potentially untrackable) Yes, although TCP isn't much better, web server logs can be helpful though. > The proposition i'll make to create a new handling for metaserver will address > all those limitations. > Prevention of fake servers and list pollution, limitations on DOS: > The list of public servers is something quite static. > Unless when used for > testing purposes, if someone starts a public server this is for at least a > few week. For this, i suggest the addition of server to the metaserver list > be something needing manual metaserver admin intervention. The sourceforge > bugtrack allows the creation of new named bugtrack lists. This is currently > the case for RFE (request for enhancement). I suggest to create a new buglist > named Server. This list will be used by server admins to request for the > register of their server in the metaserver list. Metaserver admins would then > check the validity of entry and process the registration. We could also > perhaps configure this list to request user authentification by sourceforge. > The request must contain the servername, the server ip address or dns address > (dynamic dns should be tolerated), the server admin email address, a server MWedel pointed out that if you have a need to resolve the DNS name of the server then the implementation is more complicated, this is an assessement I am inclined to agree with. > public description. > Redundancy: > The list of servers would be made available in a serverlist file, available on > the metaserver root node. This list file will be downloaded on a regular > basis by mirror nodes. The client could connect either to the root node, > either to a mirror node to grab the list of public servers Ah, there is a problem with allowing clients to connect to the root node. If they can connect directly, then it might get attacked/overwhelmed by requests. It seems better to hide the metametaserver/root node out of sight, behind a firewall where no one can attack it. > Trust of metaserver datas. > Because of replication between nodes, there should be a way to ensure the list > has not been tampered (preventing someone to fake a server). The client > should have a list a public keys corresponding to the keys of metaserver root > node admins. The server list must always be signed by a root metaserver node > admin, probably the one doing the manual update and client would check the > signature of list before using it. At best you are bringing GPGME in as a dependancy, at worst you are creating a nightmare for key distribution. What happens in the root node/metametaserver changes? the keys that were used presumably are not in the hands of the new operators. Possibly something could be done with signing the new keys and fetching from a keyserver, but this is where the key distribution nightmare comes in. > DOS resistance: > The client should be always shipped with an uptodate static list of > metaservers and list of servers. If root metaserver node is down, meaning the > list of metaservers can not be found, client use cached metaserver list to > grab a mirror metaservers. If it can't connect to any metaserver, it uses the > cached server list and diplay it to user. ok, how would that tie in with Ryo's cached server list? > Overall client process: > - get the metaserverlist from sf if possible and check signature. If anything > fails, fallback to cached list. If cached list fail, fall back to static list You seem to be using the terms cached list and static list ambiguously, maybe I'm not following very well, which list is which, and where do you get them from? > - connect to a random metaserver in lsit and process a GET for the url listed > in the metaserver list. If this fail, or signature check fails, process to Do you make crossfire illegal to run in some countries doing that? I think that there are probably some places that ban encryption altogether, and if not, there might be soon. > another metaserver. > - update cached metaserver list > - if all metaservers fails, process with cached server list and if it fails, > process with the static server list. > - update cached server list > - for each server in list, eventually connect to it and grab it's current > statistics (number of players, uptime, aso) hold up, am I understanding that right? you want to connect to every server listed, with every player? I'm not sure that would scale up too well... > Replication process: > This is quite easy, each mirror node just has, on a regular basis, to download > a specific file from root node and publish it. This could be done on any > linux box with a wget followed by an ftp , the box > executing the mirroring script does not have to be the one serving the files. > (ie i can run a script twice a day on my dsl connected linux box to publish > the mirrored file to http://users.skynet.be/tchize/server.list, i don not > need my dsl linux box to be permanently connected (just twice a day). a passive node can do that quite happily, an active node can do the same if it can run php. > Drawbacks: > metaserver does not keep anymore statical informations on server. Clients are > supposed to gather such information themself (note this is a quite common > behavior for first person shooter games) Do they really do that? I would've thought they might get the ping times, but that is something somewhat different. (should clients get the ping times of servers, it might be useful information?) Having said that, I don't play that many fps games, so wouldn't really know. > process of adding a new public server is a bit slow (wait for admin approval > and then replication) My implementation is quicker to propagate (on average 0.5*update interval for the server chosen) - actually better than that, but the maths is complicated enough to stick to the high estimate. It also allows the description or version to change without manual intervention. > Advantages: > DOS resistant > No single point of failure (isp's are quite difficult to DOS and even if all > metaserver are under heavy load client can still rely on on cached datas) > Server list can be trusted. > Mirror can be put on most ISP (personal web spaces gracefully provided by > provider) my implementation allows all of these, even the last one partially (for passive nodes) one exception, the metametaserver is a point of failure, but it is only so for the metaservers, not the rest of the system, and changing the metaservers should be easy. (compared to changing all the clients) I am cautious of the excessive verification idea, if although contacting multiple servers for their metaserver list may be a good idea, since then one hostile server would get outvoted. Furthermore, since the hostile server would get outvoted, it would be exposed as being disproportionatly outvoted, unless half the network were compromised, and then there are bigger problems. how to propagate such information is an interesting question, or even whether such information /should/ be propagated. From handphone at gmail.com Fri May 27 12:13:06 2005 From: handphone at gmail.com (Neon Lim) Date: Fri May 27 12:13:19 2005 Subject: [crossfire] info on php website Message-ID: <1124ed90050527101362a597fe@mail.gmail.com> Hi, Can anyone point me to anywhere i can find more info on how to put my players score / ranking / players online status / server online status on my website? I've been searching in the forum, nothing really show how. i will be using linux/apache/mysql/php Thanks. From B.T.Lally at warwick.ac.uk Fri May 27 12:23:17 2005 From: B.T.Lally at warwick.ac.uk (Brendan Lally) Date: Fri May 27 12:27:14 2005 Subject: [crossfire] new metaserver Message-ID: ok you could quite happily run your own internal metaserver using the old code. It would require changing a line in the client sourcecode though. in client/common/cconfig.h there are two lines #define SERVER "localhost" and #define META_SERVER "crossfire.real-time.com" if you have only one local server, it should be sufficiant to alter the first line to point to the server. If you run multiple internal servers, then you can run your own metaserver. point your servers at it (alter lib/settings) and set #define META_SERVER to point to it. this requires recompiling the clients. the metaserver itself is a perl script in the utils/ directory of your server sourcecode. with ports blocked as they are, this is unlikely to be visable outside (it defaults to port 13326 IIRC), so you should be safe from a DDoS - unless you annoy your fellow students of course :) This will be nicer to do once the new metaserver(s) start operating. From B.T.Lally at warwick.ac.uk Fri May 27 13:08:51 2005 From: B.T.Lally at warwick.ac.uk (Brendan Lally) Date: Fri May 27 13:09:16 2005 Subject: [crossfire] new metaserver Message-ID: >>> mwedel@sonic.net 05/27/05 17:00 PM >>> tchize wrote: >> - Somebody could register a server, faking another server, to gather >> passwords. > Yes - that could be improved by having the metaserver verify the hostname > provided against IP. The problem here is that DNS lookups can be a slow > operation, so can't be done in the very simple script used now. And if a > threaded/forked call is done, you then have to sort out data consistency and > file locking. Yeah, that is why I used php to get round that, flock and apache deal with all of that. > - If the server crash and re-register to metaserver, old entry is not deleted, > resulting in pollution of list when a server is unstable. > Overall client process: > - get the metaserverlist from sf if possible and check signature. If anything > fails, fallback to cached list. If cached list fail, fall back to static list > Just a thought - has anyone looked at what other games do (nettrek I think > would be one example) - presumably, some games have already put a lot of thought > into this - it could be simpler to just grab there server and client code and go > from there. Freeciv constructs HTTP POSTs and sends them to a single metaserver, I haven't been able to find the metaserver code as yet, but the server code is quite nice... POST is probably nicer than GET from a technical point of view too.... From fuchs.andy at gmail.com Fri May 27 14:19:47 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Fri May 27 14:21:16 2005 Subject: [crossfire] info on php website In-Reply-To: <1124ed90050527101362a597fe@mail.gmail.com> References: <1124ed90050527101362a597fe@mail.gmail.com> Message-ID: On 5/27/05, Neon Lim wrote: > Hi, > > Can anyone point me to anywhere i can find more info on how to put my > players score / ranking / players online status / server online status > on my website? > > I've been searching in the forum, nothing really show how. > > i will be using linux/apache/mysql/php There is a script, 'crossfire/utils/scores.pl' that will generate one large page. Then theres 'crossfire/plugin_logger' which did a bit more, but is now broken. (since it was not updated to work with the new skill system?) Mikeeusa, has some scripts that he runs at: https://cat2.dynu.ca/crossfire/scripts/index.php -- -- Andrew Fuchs From fuchs.andy at gmail.com Fri May 27 14:21:05 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Fri May 27 14:25:16 2005 Subject: [crossfire] Spellcasting Swords & Python Troubles In-Reply-To: <42975082.4040208@telus.net> References: <428C1AF3.90500@telus.net> <428D6762.50901@telus.net> <428DEEB3.90205@telus.net> <428EBF6C.5010909@telus.net> <20050524183031.GA30106@kirschbaum.myrealbox.com> <429411D2.6010505@telus.net> <20050525074828.GA14039@kirschbaum.myrealbox.com> <42946E47.8090300@telus.net> <20050526084955.GA20382@kirschbaum.myrealbox.com> <42975082.4040208@telus.net> Message-ID: On 5/27/05, Alex Schultz wrote: > Hi again, > > With the script I've been making (see other posts in this topic), I'm > having trouble getting it to work with arrows. The problem is that when > one shoots an arrow, the inventory of the arrow is not duplicated > properly. One possible solution would be modifying the server code to > duplicate the inventory of arrow when shooting. Does anyone think this > might break anything? If not, I'll attempt to make a patch for that. I doubt that it would. -- -- Andrew Fuchs From nicolas.weeger at laposte.net Fri May 27 16:45:09 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri May 27 16:47:18 2005 Subject: [crossfire] Client compile broken on linux In-Reply-To: <200505271741.12657.cerzeo@gmail.com> References: <42963C33.5080100@laposte.net> <200505271717.45191.tchize@myrealbox.com> <200505271741.12657.cerzeo@gmail.com> Message-ID: <429794E5.5040508@laposte.net> > A friend of mine plays crossfire over my Linux Server. I play crossfire under > Linux, and game loads faster in Linux than in Windows. > > Can it be because of the SDL? Is it possible to accelerate the loading time > for Windows? Client doesn't use SDL due to some windowing issues, so can't be SDL's fault :) The client may be slow due to GTK, which *is* slow under Windows (at least slower than under Linux, I think). Nicolas From cerzeo at gmail.com Fri May 27 17:16:41 2005 From: cerzeo at gmail.com (Alberto Saez Lodeiros) Date: Fri May 27 17:07:17 2005 Subject: [crossfire] Client compile broken on linux In-Reply-To: <429794E5.5040508@laposte.net> References: <200505271741.12657.cerzeo@gmail.com> <429794E5.5040508@laposte.net> Message-ID: <200505280016.41320.cerzeo@gmail.com> El Viernes 27 Mayo 2005 23:45, Nicolas Weeger escribi?: > Client doesn't use SDL due to some windowing issues, so can't be SDL's > fault :) > The client may be slow due to GTK, which *is* slow under Windows (at > least slower than under Linux, I think). > > Nicolas Yeah, GTK. Mistake mine. Sorry :P > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -- ========================================================== - Hay 10 tipos de personas: Las que NO entienden c?digo biario y las que SI. ========================================================== From handphone at gmail.com Fri May 27 21:38:39 2005 From: handphone at gmail.com (Neon Lim) Date: Fri May 27 21:39:20 2005 Subject: [crossfire] info on php website In-Reply-To: References: <1124ed90050527101362a597fe@mail.gmail.com> Message-ID: <1124ed9005052719384beac930@mail.gmail.com> Hi, Thanks for the insight. It seems those scripts are perl script. Any php version? Thanks On 5/28/05, Andrew Fuchs wrote: > On 5/27/05, Neon Lim wrote: > > Hi, > > > > Can anyone point me to anywhere i can find more info on how to put my > > players score / ranking / players online status / server online status > > on my website? > > > > I've been searching in the forum, nothing really show how. > > > > i will be using linux/apache/mysql/php > > There is a script, 'crossfire/utils/scores.pl' that will generate one > large page. > > Then theres 'crossfire/plugin_logger' which did a bit more, but is now > broken. (since it was not updated to work with the new skill system?) > > Mikeeusa, has some scripts that he runs at: > https://cat2.dynu.ca/crossfire/scripts/index.php > > -- > -- > Andrew Fuchs > From temitchell at sympatico.ca Fri May 27 21:49:59 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Fri May 27 21:51:22 2005 Subject: [crossfire] multipart images In-Reply-To: <4296ADE9.2000909@sonic.net> References: <20050521174702.66102.qmail@web61021.mail.yahoo.com> <1116699507.3413.11.camel@oberon.kameria> <4296ADE9.2000909@sonic.net> Message-ID: <1117248599.3936.6.camel@oberon.kameria> Not sure I am following - I am proposing using "x" for single images greater than a single tile in size. Images that are a single tile would still use the "1" as would the first tile in a large image which has not been merged. Since the first digit was only to denote the tile order using x will distinguish multi-tile images from single tile images. On Thu, 2005-26-05 at 22:19 -0700, Mark Wedel wrote: > Todd Mitchell wrote: > > Changing the image names will have no impact on your maps, the arches > > will refrence the proper images if updated properly, it's just mostly a > > pain to remove and add the image files back into CVS. > > > > It wouldn't be much of a standard if we didn't rename the images > > however... > > I have no issue with x being used. > > However, I'd also have to consider 1 being a proper first digit also > (house.111, house.112), as it is only the first part. > > I had used x way back when just to hold the combined large images back before > merged images were supported (back then, the merged images were just used > because it was easier to make the image as a single piece than split it into > small pieces). > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -- Todd Mitchell From mikeeusaaa at yahoo.com Fri May 27 22:59:21 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri May 27 23:01:22 2005 Subject: [crossfire] info on php website In-Reply-To: 6667 Message-ID: <20050528035921.74929.qmail@web61025.mail.yahoo.com> You do not want a script like these running on every single page view. The wloop script keeps the pages updating every so often. perl wloop & also motify the vars in the scripts to your paths --- Neon Lim wrote: > Hi, > > Thanks for the insight. > It seems those scripts are perl script. > Any php version? > > Thanks > > > On 5/28/05, Andrew Fuchs > wrote: > > On 5/27/05, Neon Lim wrote: > > > Hi, > > > > > > Can anyone point me to anywhere i can find more > info on how to put my > > > players score / ranking / players online status > / server online status > > > on my website? > > > > > > I've been searching in the forum, nothing really > show how. > > > > > > i will be using linux/apache/mysql/php > > > > There is a script, 'crossfire/utils/scores.pl' > that will generate one > > large page. > > > > Then theres 'crossfire/plugin_logger' which did a > bit more, but is now > > broken. (since it was not updated to work with the > new skill system?) > > > > Mikeeusa, has some scripts that he runs at: > > https://cat2.dynu.ca/crossfire/scripts/index.php > > > > -- > > -- > > Andrew Fuchs > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mwedel at sonic.net Sat May 28 00:43:34 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat May 28 00:43:23 2005 Subject: [crossfire] Spellcasting Swords & Python Troubles In-Reply-To: <42975082.4040208@telus.net> References: <428C1AF3.90500@telus.net> <428D026D.9070607@laposte.net> <428D2FA4.5070407@telus.net> <428D6762.50901@telus.net> <428DEEB3.90205@telus.net> <428EBF6C.5010909@telus.net> <20050524183031.GA30106@kirschbaum.myrealbox.com> <429411D2.6010505@telus.net> <20050525074828.GA14039@kirschbaum.myrealbox.com> <42946E47.8090300@telus.net> <20050526084955.GA20382@kirschbaum.myrealbox.com> <42975082.4040208@telus.net> Message-ID: <42980506.1000305@sonic.net> Alex Schultz wrote: > Hi again, > > With the script I've been making (see other posts in this topic), I'm > having trouble getting it to work with arrows. The problem is that when > one shoots an arrow, the inventory of the arrow is not duplicated > properly. One possible solution would be modifying the server code to > duplicate the inventory of arrow when shooting. Does anyone think this > might break anything? If not, I'll attempt to make a patch for that. It depends what the inventory is. You have to make sure that the inventory is properly handled when the arrow hits something or is otherwise stopped, eg, you don't want that inventory to end up on the map (or you probably don't). I don't know right now if the stop arrow code will already handle all of that properly, but that is a consideration. From mwedel at sonic.net Sat May 28 00:55:33 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat May 28 00:55:24 2005 Subject: [crossfire] multipart images In-Reply-To: <1117248599.3936.6.camel@oberon.kameria> References: <20050521174702.66102.qmail@web61021.mail.yahoo.com> <1116699507.3413.11.camel@oberon.kameria> <4296ADE9.2000909@sonic.net> <1117248599.3936.6.camel@oberon.kameria> Message-ID: <429807D5.8000108@sonic.net> Todd Mitchell wrote: > Not sure I am following - I am proposing using "x" for single images > greater than a single tile in size. Images that are a single tile would > still use the "1" as would the first tile in a large image which has not > been merged. Since the first digit was only to denote the tile order > using x will distinguish multi-tile images from single tile images. My point was that at some level, changing the naming to distinguish large (merged) images for other single images is inconsistent. that is to say, right now, I think there are some large (merged) images that are currently in the .111, .112, etc format. Those can all get renamed I suppose, but just a note. But because of that, having the first digit be a '1' for large images isn't necessary incorrect - it is the first part of the image - it just happens to be a large image. I also have the concern about sort of large images. For example, with the large image support, you could make something like an ogre that is 40 pixels high, and it will be drawn properly (ignoring existing drawing errors). Should that have an 'x' or '1' for the first tile? That's just a matter of clarification of when should an x be used instead of 1. From lalo at laranja.org Sat May 28 00:59:32 2005 From: lalo at laranja.org (Lalo Martins) Date: Sat May 28 01:01:23 2005 Subject: [crossfire] gmane Message-ID: <38014.221.122.43.98.1117259972.squirrel@webmail.laranja.org> Leaf, mwedel. I recently got addicted to gmane :-) saves me a lot of bandwidth to download more p0^W^W^Wplay crossfire. Would you be opposed to having the main crossfire lists (crossfire, crossfire-maps, crossfire-cvs) to gmane? If you give the ok, I'm fine with going to http://gmane.org/subscribe.php and doing the bureaucracy; or you may do it yourself, if you want control over descriptions and whatnot. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.laranja.org/ mailto:lalo@laranja.org pgp key: http://garfield.laranja.org/~lalo/gpgkey-signed.asc GNU: never give up freedom http://www.gnu.org/ From mikeeusaaa at yahoo.com Sat May 28 01:02:09 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat May 28 01:03:24 2005 Subject: [crossfire] multipart images In-Reply-To: 6667 Message-ID: <20050528060209.38885.qmail@web61014.mail.yahoo.com> I think this should be a non issue. Nothing is broken... changing the image names and the arches is usless busy work.... just a waste. --- Mark Wedel wrote: > Todd Mitchell wrote: > > Not sure I am following - I am proposing using "x" > for single images > > greater than a single tile in size. Images that > are a single tile would > > still use the "1" as would the first tile in a > large image which has not > > been merged. Since the first digit was only to > denote the tile order > > using x will distinguish multi-tile images from > single tile images. > > My point was that at some level, changing the > naming to distinguish large > (merged) images for other single images is > inconsistent. > > that is to say, right now, I think there are some > large (merged) images that > are currently in the .111, .112, etc format. Those > can all get renamed I > suppose, but just a note. > > But because of that, having the first digit be a > '1' for large images isn't > necessary incorrect - it is the first part of the > image - it just happens to be > a large image. > > I also have the concern about sort of large > images. For example, with the > large image support, you could make something like > an ogre that is 40 pixels > high, and it will be drawn properly (ignoring > existing drawing errors). Should > that have an 'x' or '1' for the first tile? That's > just a matter of > clarification of when should an x be used instead of > 1. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mikeeusaaa at yahoo.com Sat May 28 01:02:23 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat May 28 01:05:37 2005 Subject: [crossfire] multipart images In-Reply-To: 6667 Message-ID: <20050528060223.93539.qmail@web61025.mail.yahoo.com> I think this should be a non issue. Nothing is broken... changing the image names and the arches is usless busy work.... just a waste. --- Mark Wedel wrote: > Todd Mitchell wrote: > > Not sure I am following - I am proposing using "x" > for single images > > greater than a single tile in size. Images that > are a single tile would > > still use the "1" as would the first tile in a > large image which has not > > been merged. Since the first digit was only to > denote the tile order > > using x will distinguish multi-tile images from > single tile images. > > My point was that at some level, changing the > naming to distinguish large > (merged) images for other single images is > inconsistent. > > that is to say, right now, I think there are some > large (merged) images that > are currently in the .111, .112, etc format. Those > can all get renamed I > suppose, but just a note. > > But because of that, having the first digit be a > '1' for large images isn't > necessary incorrect - it is the first part of the > image - it just happens to be > a large image. > > I also have the concern about sort of large > images. For example, with the > large image support, you could make something like > an ogre that is 40 pixels > high, and it will be drawn properly (ignoring > existing drawing errors). Should > that have an 'x' or '1' for the first tile? That's > just a matter of > clarification of when should an x be used instead of > 1. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mikeeusaaa at yahoo.com Sat May 28 01:01:38 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat May 28 01:05:40 2005 Subject: [crossfire] multipart images In-Reply-To: 6667 Message-ID: <20050528060138.23543.qmail@web61018.mail.yahoo.com> I think this should be a non issue. Nothing is broken... changing the image names and the arches is usless busy work.... just a waste. --- Mark Wedel wrote: > Todd Mitchell wrote: > > Not sure I am following - I am proposing using "x" > for single images > > greater than a single tile in size. Images that > are a single tile would > > still use the "1" as would the first tile in a > large image which has not > > been merged. Since the first digit was only to > denote the tile order > > using x will distinguish multi-tile images from > single tile images. > > My point was that at some level, changing the > naming to distinguish large > (merged) images for other single images is > inconsistent. > > that is to say, right now, I think there are some > large (merged) images that > are currently in the .111, .112, etc format. Those > can all get renamed I > suppose, but just a note. > > But because of that, having the first digit be a > '1' for large images isn't > necessary incorrect - it is the first part of the > image - it just happens to be > a large image. > > I also have the concern about sort of large > images. For example, with the > large image support, you could make something like > an ogre that is 40 pixels > high, and it will be drawn properly (ignoring > existing drawing errors). Should > that have an 'x' or '1' for the first tile? That's > just a matter of > clarification of when should an x be used instead of > 1. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Discover Yahoo! Use Yahoo! to plan a weekend, have fun online and more. Check it out! http://discover.yahoo.com/ From mwedel at sonic.net Sat May 28 01:45:44 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat May 28 01:45:23 2005 Subject: [crossfire] new metaserver In-Reply-To: References: Message-ID: <42981398.4060306@sonic.net> Brendan Lally wrote: >>>> mwedel@sonic.net 05/27/05 07:08 AM >>> >> >> IS the idea to have DNS records for metaserver.crossfire.org (or whatever) >> point to all those possible/trusted meta servers? > > > There are two lists, the game server list and the metaserver list. > > Each metaserver has a copy of both lists, that they sync with the > metametaserver. > > when a client connects, they have their own list of metaservers (that will be > install with the tarball) and they pick randomly a metaserver from that > list. From that metaserver they get a list of servers, and a list of > metaservers. In future they use that new list to pick randomly from. I'd think that the client having too muched cache information can lead to its own problem. For example, if one of the metaservers goes away, that then leads to cases of when the client uses that metaserver, it could take a while for that connection attempt to time out. This really gets to be a problem when you see that there are still some pretty old clients in use out there (somewhat caused by variosu distributions having old client versions). so this list of metaserver should be ones that are really trusted or known that they will be sitting around for a long time. > Yes, once you have a metaserver running, you would email the metametaserver > admin, and say 'hello, I have a new [active/passive] metaserver it can be > accessed as [ip adress or hostname] and updates via [ip adress or hostname] > (those may or may not be the same. > > the list of metaservers would then be appended to include your metaserver, > and the ip adress you use for updates would be let through the firewall > around the metametaserver. > > This assumes that we trust you :) this does add a layer of administration that does not currently exist. At least for the metaservers, probably not that big an option, because this list probably doesn't change very much. However, probably need to set up a pretty solid policy for what metaserver will be added and what won't be - adding a metaserver to the client and servers as one to use that then goes away causes some problems. > > >> It seems to me that it would also be a better idea not to have a >> 'metametaserver' at all - just go peer to peer, with the active metaservers >> periodically sending the data to one of the other metaservers (once a >> minute or something, it could connect to another, the two exchange >> information, merging any duplicates/keeping the later). This removes the >> single point of failure if the metametaserver fails for some reason, at the >> expense of the data being not quite up to date. > > > I considered this, but I couldn't see a nice way to add new metaservers > securely (bearing in mind that without some form of checking, a hostile > server could crapflood the other servers into uselessness). All methods that > were sane to implement would use a central auth server anyway. If that is the > case, then you might as well connect to it to send the data too, since it is > going to be there anyway. Well, your already constructing a list of trusted metaservers to be maintained. In a peer to peer situation, it'd only take data from one of those other trusted metaservers. It really isn't much different than your metametaserver setup, but also ends up distributing the administration of that point. It also really doesn't change security at all. Right now, in your setup, if one of the trusted metaservers really isn't secure, it could send all sorts of bogus data about servers to the metametaserver. > > If there is a way around this that I haven't considered, then let me know. > > It also may increase traffic quite substantially compared to a system where > each server expects to have ~ (number of hits old metaserver had on average > )*2/number of metaservers + some updates sent out to the metametaserver. Traffic analysis on this would be what I consider 'odd'. Each metaserver in the p2p setup would exchange all the info it has. Thus, you would get something like A & B exchanging info (and thus at that instance, having exactly the same data). B & C then exchange data - at this moment, both B & C are perfectly in sync, and include the data from A. At some point, A talks to one of those servers (not important which ones) and gets all synced up again. If B goes away, A & C can still happily exchange info and keep up to date. The only real magic in all of this is how often the metaservers should exchange data. It also means that data may not be quite as up to date. Probably makes most sense for each metaserver to randomize the order of its lists of other known metaservers, but then just go in a simple round robin - that way, every server should remain pretty up to date. > > > Yeah, it'd use TCP, it has to to connect to a webserver I'm toying with the > idea of using libcurl directly to handle most of it, this is fairly quick and > easy, compared to implementing HTTP manually, but it does add a new > dependancy (albeit a common one). The alternitive is to write directly to the > socket. > > But certainly for the server starting up and forking to have the metaserver > be contacted should be fine, it would just then travel randomly down the list > of metaservers until it finds one that returns a 200. > > It should be quite easy to have a lock file setup to ensure that the > metaserver requests don't overlap.. The problem is you basically need to fork each time you connect to a metaserver to send it data. Right now, the server sends data every minute. I'm not sure the cost of the forks, but I know that due to memory leaks, the server image itself can become quite large. One thought I have is that the most like time to block is the initial lookup and connection. If the server can use the same connection, it could set the socket to non blocking, and this is then no longer a problem. However, I'm not sure if that will work with php based web scripts (I think the connection will be closed after each update). > > >> Version should be included in the top line, not the comment line, as it is >> now > > > The point of the bottom line is that it is what the player 'sees', it isn't > needed for the client to connect to know what release the server is running. > A player however, will want to know which version the server runs, so it will > go on the bottom line, as player-known information. Note that right now, for space reason, the comment (player section you describe) isn't even displayed. Also, I personally think it'd be much easier/nicer to be able to display version and number of current players in nice tabs, and that requires them being contained as seperate fields - otherwise, the client has to try pulling that data from the comment field. > > If the protocol changes, such that it breaks against older or newer clients, > then the client will be able to compare the protocol entry and simply not > show those that are of the wrong version. You're over analzying the problem. The protocol versions are there to avoid this problem - there shouldn't be problem with mistmached protocol versions - the design is such that propely written clients and servers won't send data to the other end that isn't supported by the protocol version at the other end. This can mean that in some cases, the client can't use the newest features (but wouldn't have the code for it anyways). It also does complicate things a little, because checks in the code are added for cases of protocol versions. That said, occasionally, there can be times where changes basically resuilt in clients not working - the only really case I can think of was the 'big image' support. However, there wasn't a clear point on this (the protocol was updated to handle it before images actually started to get merged, so there was an overlap where the old clients would work, until images started to get merged). But hte problem is that if there is a protocol mismatch, the client won't be able to know what to do about it. If the client version is later than the server, no problems - it can handle whatever the server throws at it, and will fallback to the older commands to send to the server. If the server is later than the client, the client can't have any idea how minor or major those changes are, and thus can't know if it will be able to properly talk to that server (once connected to the server, the server will examine the numbers, and can potentially know if there is a conflict) > This information is also acquired by the metaserver, it connects back to the > ip and port it was given, and checks that the banner says 'crossfire' in it. That of course complicates things, because that operation can now block also. > >> Note you should look at the current metaserver for what data it sends. For >> example, it also sends along the number of input and output bytes it has >> sent (useful for some scripts that collect that stuff) as well as how long >> the server has been up. > > > Do any scripts actually collect that? I can't say I've noticed it being used, > if it is wanted though, it can be added easily now. (adding it later, is more > interesting....) At one point, I think mids had script/data on his website that showed that data. The most important one is probably the number of players (and version) on the server - I think variosu people do look at the info when determining what server to play on. From kirschbaum at myrealbox.com Sat May 28 02:56:46 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sat May 28 02:57:24 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps Message-ID: <20050528075642.GA17903@kirschbaum.myrealbox.com> Currently many players clear the random maps (notably the training center in scorn) to gain experience. And quite a few players do not even bother to explore the world. I'd like to encourage players to adventure (outside the training center) by making the random maps less attractive. I think the random maps are currently very attractive due to: 1. Random maps give lots of experience (see table "current experience" below) but they do not contain much dangers because they do not contain many different monsters and are very regular maps. Note that the top six maps in the table are all random maps; all of them give considerably more experience than the quite hard warrior proving tower. 2. Many random maps are easily accessible. Especially the training center in scorn is no problem to reach even for a low level character. 3. Most random maps do get harder only up to some point. After that point the encountered monsters do not change anymore. To compensate for the missing dangers I'd like to reduce the experience you get for killing monsters in random maps. My proposal is to reduce it by a factor of 1/20. The resulting experience is listed below in table "experience after monster exp/20 modification". To accomplish this I'd like to change the server code but not the monsterstyle files because changing the server code affects all random maps, including not yet created maps. Therefore this problem would not appear again (but a map maker can still customize the monsterstyle files). Point 2. seems to be fixed for the training center now by simply removing the random maps from the game. Nevertheless, I'll include the experience values in the tables below. The following tables list the total experience I gained by killing all available monsters in the maps. current experience ================== 558 Heaven 200 dragon TC 165 Hell 164 humanoid TC 127 demon TC 104 undead TC 70 warrior proofing tower (entrance=10, up=25, down=30, lorkas=5) 28 Chaos Lair, snake pit, DA 23 Titan Quest (random=18, final=5) 20 Evil Master's castle 17 Three Sisters Quest, including the sisters 13 Mwizard 9 Temple of Fire God (east(Fire God)=4, west(Alchemy)=5) 8 Raffle 3 6 God Finger Quest (2 million distributed to four players) 5 Dragon Lair 4 Seven Gates of Hell 3 Dragon Hangar 2 Dragon Quest (random=1, final=1) 2 Tower of Demonology 1 Temple in Dark Forest experience after monster exp/20 modification ============================================ 70 warrior proofing tower 28 Chaos Lair, snake pit, DA 28 Heaven 20 Evil Master's castle 17 Three Sisters Quest, including the sisters 13 Mwizard 10 dragon TC 9 Temple of Fire God 8 Hell 8 humanoid TC 8 Raffle 3 6 demon TC 6 Titan Quest 6 God Finger Quest 5 undead TC 5 Dragon Lair 4 Seven Gates of Hell 3 Dragon Hangar 2 Tower of Demonology 1 Dragon Quest 1 Temple in Dark Forest From tchize at myrealbox.com Sat May 28 03:15:28 2005 From: tchize at myrealbox.com (tchize) Date: Sat May 28 03:17:26 2005 Subject: [crossfire] new metaserver In-Reply-To: <4297439B.5070600@sonic.net> References: <200505271716.25901.tchize@myrealbox.com> <4297439B.5070600@sonic.net> Message-ID: <200505281015.33647.tchize@myrealbox.com> Le Vendredi 27 Mai 2005 17:58, Mark Wedel a ?crit : >tchize wrote: >> Overall client process: >> - get the metaserverlist from sf if possible and check signature. If >> anything fails, fallback to cached list. If cached list fail, fall back to >> static list > > Note that this would seem to put a single point of failure on SF being up. > It often is, but doesn't always seem to be the case. well if sf is down, the client use the cached mirror list. I don't think it's a problem for sf being down for even a few weeks, mirror list are mostly static (from time to time a mirror may be leaving the mirror list at admin request or a new one could appear, but am sure all mirrors will not disappear in just a few weeks) > > However, looking at the proposal, I have a few questions/thoughts. > > Since it seems that server admins will need to notify the metaserver admin > to be listed, and it seems that some amount of the dynamic data currently > listed won't be as up to date (due to timing, or perhaps not being > included), it seems that this isn't that far away from just having a static > HTML page that someone updates that is then replicated. Which of course > isn't really what the metaserver is about. I suggest to have metaserver only list the public servers. If clients want stats like number of player, server version and so on, we could have client connect to the server and request this from server instead of having metaserver tracking such information. This is how it is done on commercial quake-like games like (greb a list of ips from metaserver, and request informations from each ip). This is all indeed about having a static file mirrored. > > Just a thought - has anyone looked at what other games do (nettrek I think >would be one example) - presumably, some games have already put a lot of > thought into this - it could be simpler to just grab there server and > client code and go from there. Indeed if something suitable exist on another GPL game, this could be usefull to reuse code > > >_______________________________________________ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- 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/20050528/ccda5763/attachment.pgp From eracclists at bellsouth.net Sat May 28 03:28:04 2005 From: eracclists at bellsouth.net (ERACC) Date: Sat May 28 03:29:25 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: <20050528075642.GA17903@kirschbaum.myrealbox.com> References: <20050528075642.GA17903@kirschbaum.myrealbox.com> Message-ID: <200505280328.05001.eracclists@bellsouth.net> On Saturday 28 May 2005 02:56 am Andreas Kirschbaum wrote: > Currently many players clear the random maps (notably the training > center in scorn) to gain experience. And quite a few players do not even > bother to explore the world. [...] Training Center is being broken up and moved into the wilderness. I have already committed these changes to CVS for the move. The low level TC maps are already in place in the wilderness. I am still in the process of finding locations for the high level TC maps. Please do not go reducing the experience one can get from killing critters in random maps. Gene -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 03:24:25 up 10 days, 4:01, 8 users, load average: 0.02, 0.13, 0.15 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandriva Linux, OpenServer & UnixWare resellers From temitchell at sympatico.ca Sat May 28 11:01:08 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Sat May 28 11:01:29 2005 Subject: [crossfire] multipart images In-Reply-To: <20050528060138.23543.qmail@web61018.mail.yahoo.com> References: <20050528060138.23543.qmail@web61018.mail.yahoo.com> Message-ID: <1117296068.3394.22.camel@oberon.kameria> On Fri, 2005-27-05 at 23:01 -0700, Mitch Obrian wrote: > I think this should be a non issue. Nothing is > broken... changing the image names and the arches is > usless busy work.... just a waste. > I don't consider it 'busy work'. This is a new case and not a historical conversion of the crossfire images. Aside from the few images just committed all the arches do follow this standard since I have been slowly merging the multipart images. The reason I am merging the images is to make them easier to edit and improve - not just to bounce my name across the internet. The image naming convention is there for a reason - to make managing and updating the arches easier. The name convention is "name.xyz.type.png" where x is the tile offset for a multipart image, y is the facing (clockwise) and z is the animation frame. Images larger than 1 tile are new and aside from the recent buildings added all have x as the first digit because this indicates a large image. Since I have been merging all the images they all were getting an x - It made it easy to fix the arch for the new image and as a bonus - to find a large image programatically. I thought I should try to formalize this. It may be useful to know which images are multi-tile at some point and it does make it easier to explain how to make an arch if this is always the case. Without a naming convention it becomes very hard to learn how to make arches and very hard to debug arches so I don't consider it busy work (making yet another colour of marble flooring however seems a bit superfluous to me). It took me a while to learn the ropes and I believe others had the same problem since I have also been doing a lot of fixes and clean up of the arches over the last few years because the name convention wasn't followed. Along the same vein - if crossfire ever had the ability to store animations as binary objects instead of a series of png (hypothetical - not a request) I would expect these images to use a 'z' as the third digit in the name convention to denote this. Contriwise - images with a single facing would have a y as the second position - I think this may take it too far however. Perhaps if crossfire ever used 3d models this would be the case. From fuchs.andy at gmail.com Sat May 28 12:19:06 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sat May 28 12:19:29 2005 Subject: [crossfire] Anyone want to fix the logger plugin? Message-ID: The logger plugin is currently broken, most likely because of the switch to the new skill system a while back. I think it would get some use if it is fixed. -- -- Andrew Fuchs From mikeeusaaa at yahoo.com Sat May 28 12:19:40 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat May 28 12:23:30 2005 Subject: [crossfire] multipart images In-Reply-To: 6667 Message-ID: <20050528171940.79634.qmail@web61024.mail.yahoo.com> I was agreeing with Mwedel. However if it makes cfarches easier to play with via scripts etc I suppose it is good. As I said, I will make all new multipart images start with x. > (making yet another colour of marble flooring > however seems a bit > superfluous to me). The jab was unnecessary. I processed the extra colors of marble because I did need them for my maps (baroque style, they splatterd all diffrent types of inlayed marble everywhere). I am sure all of my archtypes are superfluous... for we really do not need eastern buildings, mid-eastern buildings, violins, grand pianos, chandeliers, and such. In fact, the whole idea of having yet-another-rpg can be said to be superfluous. Yes diffrent marble colors are just a color change and easy to do... but I have great use for them in my levels so I make them. Drawing a violin or a grand piano from scratch is not. Death To women's Rights --- Todd Mitchell wrote: > On Fri, 2005-27-05 at 23:01 -0700, Mitch Obrian > wrote: > > I think this should be a non issue. Nothing is > > broken... changing the image names and the arches > is > > usless busy work.... just a waste. > > > > I don't consider it 'busy work'. > This is a new case and not a historical conversion > of the crossfire > images. Aside from the few images just committed all > the arches do > follow this standard since I have been slowly > merging the multipart > images. The reason I am merging the images is to > make them easier to > edit and improve - not just to bounce my name across > the internet. > > The image naming convention is there for a reason - > to make managing and > updating the arches easier. The name convention is > "name.xyz.type.png" > where x is the tile offset for a multipart image, y > is the facing > (clockwise) and z is the animation frame. Images > larger than 1 tile are > new and aside from the recent buildings added all > have x as the first > digit because this indicates a large image. Since I > have been merging > all the images they all were getting an x - It made > it easy to fix the > arch for the new image and as a bonus - to find a > large image > programatically. I thought I should try to > formalize this. It may be > useful to know which images are multi-tile at some > point and it does > make it easier to explain how to make an arch if > this is always the > case. > > Without a naming convention it becomes very hard to > learn how to make > arches and very hard to debug arches so I don't > consider it busy work > (making yet another colour of marble flooring > however seems a bit > superfluous to me). > > It took me a while to learn the ropes and I believe > others had the same > problem since I have also been doing a lot of fixes > and clean up of the > arches over the last few years because the name > convention wasn't > followed. > > Along the same vein - if crossfire ever had the > ability to store > animations as binary objects instead of a series of > png (hypothetical - > not a request) I would expect these images to use a > 'z' as the third > digit in the name convention to denote this. > > Contriwise - images with a single facing would have > a y as the second > position - I think this may take it too far however. > Perhaps if > crossfire ever used 3d models this would be the > case. > > > > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/ From fuchs.andy at gmail.com Sat May 28 12:32:53 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sat May 28 12:33:30 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: <20050528075642.GA17903@kirschbaum.myrealbox.com> References: <20050528075642.GA17903@kirschbaum.myrealbox.com> Message-ID: I think a better solution would be making the non random maps give more experience. Thus they become a better option than to use the training centers. -- -- Andrew Fuchs From alex_sch at telus.net Sat May 28 12:52:36 2005 From: alex_sch at telus.net (Alex Schultz) Date: Sat May 28 12:53:30 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: References: <20050528075642.GA17903@kirschbaum.myrealbox.com> Message-ID: <4298AFE4.5080504@telus.net> Andrew Fuchs wrote: >I think a better solution would be making the non random maps give >more experience. Thus they become a better option than to use the >training centers. > I agree; that sort of thing is one type of thing I've been thinking of when making this one map that I started working on recently. For high leveled people, large numbers of random levels are the only ways to get half decent experience currently, as in, many non-random maps should give more experience than they do. One of the problems is that for the very high level people, no monster gives enough experience, so killing monsters en mass in random maps is the only option if they want to gain any real levels, this is also true a medium levels to a lesser degree, though the current situation is well balanced for lower leveled people. Alex Schultz From mikeeusaaa at yahoo.com Sat May 28 15:50:40 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat May 28 15:51:32 2005 Subject: [crossfire] multipart images + Other stuff (btw thanks for the mlab -> CVS work :D) In-Reply-To: 6667 Message-ID: <20050528205040.87787.qmail@web61012.mail.yahoo.com> I will make all new big images I make use the x convention. Also thankyou very much for the mlab->cvs work :D. Thank you for fixing the shop bugs (I forgot to put the no_magic floors in). Thirdly, I was thinking about making a red-brick cwall set as some of my _fant arches use red brick. What should I call these arches for naming convention? Is there away to batch convert them with image magik or is the gimp needed (as I've done before)? --- Todd Mitchell wrote: > On Fri, 2005-27-05 at 23:01 -0700, Mitch Obrian > wrote: > > I think this should be a non issue. Nothing is > > broken... changing the image names and the arches > is > > usless busy work.... just a waste. > > > > I don't consider it 'busy work'. > This is a new case and not a historical conversion > of the crossfire > images. Aside from the few images just committed all > the arches do > follow this standard since I have been slowly > merging the multipart > images. The reason I am merging the images is to > make them easier to > edit and improve - not just to bounce my name across > the internet. > > The image naming convention is there for a reason - > to make managing and > updating the arches easier. The name convention is > "name.xyz.type.png" > where x is the tile offset for a multipart image, y > is the facing > (clockwise) and z is the animation frame. Images > larger than 1 tile are > new and aside from the recent buildings added all > have x as the first > digit because this indicates a large image. Since I > have been merging > all the images they all were getting an x - It made > it easy to fix the > arch for the new image and as a bonus - to find a > large image > programatically. I thought I should try to > formalize this. It may be > useful to know which images are multi-tile at some > point and it does > make it easier to explain how to make an arch if > this is always the > case. > > Without a naming convention it becomes very hard to > learn how to make > arches and very hard to debug arches so I don't > consider it busy work > (making yet another colour of marble flooring > however seems a bit > superfluous to me). > > It took me a while to learn the ropes and I believe > others had the same > problem since I have also been doing a lot of fixes > and clean up of the > arches over the last few years because the name > convention wasn't > followed. > > Along the same vein - if crossfire ever had the > ability to store > animations as binary objects instead of a series of > png (hypothetical - > not a request) I would expect these images to use a > 'z' as the third > digit in the name convention to denote this. > > Contriwise - images with a single facing would have > a y as the second > position - I think this may take it too far however. > Perhaps if > crossfire ever used 3d models this would be the > case. > > > > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From fuchs.andy at gmail.com Sat May 28 16:04:50 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sat May 28 16:05:31 2005 Subject: [crossfire] .desktop file for client is not installed with "make install" Message-ID: client/gtk/crossfire-client.desktop is not installed when "make install" is run. Cavesomething modified the MakeFile, but ./configure doesn't seem to setup the "datadir" varible. -- -- Andrew Fuchs From krudat at iinet.net.au Sat May 28 19:02:53 2005 From: krudat at iinet.net.au (Kevin Rudat) Date: Sat May 28 18:51:34 2005 Subject: [crossfire] Extending apply commands In-Reply-To: <20050430082206.GA4528@localhost.localdomain> References: <20050428230607.GA6101@localhost.localdomain> <4273223D.6030009@sonic.net> <20050430082206.GA4528@localhost.localdomain> Message-ID: <20050529000252.GA7869@localhost.localdomain> On Sat, Apr 30, 2005 at 06:22:06PM +1000, Kevin Rudat wrote: > It'd also put this extra bit in doc/Developers/objects: > 25012 Exits, doors, buildings (66) Question: for multi-tile building arches (linked with More in the .arc file), do I put the client_type in the first Object, or in all of them? > Client-side item name matching I've still got to give this a proper looking-at... > Implement apply_below and item-type-specific commands as a client-script. I think I've done this. All the commands Adam Ashenfelter wanted, that'll search without a name, don't appear to apply anything that'd "fail". From lalo at laranja.org Sat May 28 20:07:25 2005 From: lalo at laranja.org (Lalo Martins) Date: Sat May 28 20:09:35 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: <4298AFE4.5080504@telus.net> References: <20050528075642.GA17903@kirschbaum.myrealbox.com> <4298AFE4.5080504@telus.net> Message-ID: <3539.202.106.20.66.1117328845.squirrel@webmail.laranja.org> DISCLAIMER: when it comes to building levels, I'm just a n00b; I'm writing this based on what I've read while studying how to do it. I thing the *right* solution to this is to have more high-level maps (and possibly update the old ones, which fell behind changes in the rules). No monster *in the archetypes file* gives you enough experience. That's about right; if a monster is common enough to be there, it's not worth much. Now high-level maps are supposed to have *custom* monsters, like the nazgul in the pupland power station or the demilich in Old Scorn. These should be seriously harder to kill, and therefore worth many more points. This can also be done in large numbers; see the Dragon Hatchery. With the evolution of rules, all monsters in medium-high or high level maps became too easy to kill, and also not worth enough. Nazgul and the demilich and the ancient dragons and dragonmen in the hatchery are only incrementally harder and more xpworth than the normal ones (from the POV of high-levelers) since they are in medium-low level maps; in the high-level maps you should have monsters proportionally more customized. IMHO AFAICS FWIW YMMV KSC etc... > Andrew Fuchs wrote: > >>I think a better solution would be making the non random maps give >>more experience. Thus they become a better option than to use the >>training centers. >> > I agree; that sort of thing is one type of thing I've been thinking of > when making this one map that I started working on recently. For high > leveled people, large numbers of random levels are the only ways to get > half decent experience currently, as in, many non-random maps should > give more experience than they do. One of the problems is that for the > very high level people, no monster gives enough experience, so killing > monsters en mass in random maps is the only option if they want to gain > any real levels, this is also true a medium levels to a lesser degree, > though the current situation is well balanced for lower leveled people. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.laranja.org/ mailto:lalo@laranja.org pgp key: http://garfield.laranja.org/~lalo/gpgkey-signed.asc GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Sat May 28 22:40:20 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat May 28 22:39:35 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: <3539.202.106.20.66.1117328845.squirrel@webmail.laranja.org> References: <20050528075642.GA17903@kirschbaum.myrealbox.com> <4298AFE4.5080504@telus.net> <3539.202.106.20.66.1117328845.squirrel@webmail.laranja.org> Message-ID: <429939A4.5050907@sonic.net> My personal thought is changing code to adjust the exp reward for random maps is certainly the wrong approach. Updating the style maps would be the right thing (don't do something in the code if it can be done in the data files). If new styles are added but the exp isn't set right, that really isn't any different than someone putting in a map that gives too much treasure or too much exp. You don't go and change the code to try and fix such maps, you fix the maps. Same would hold true with style maps. That said, if this really is considered a problem, another approach would be to change the random map code to reduce the monster density. The problem isn't that the individual monsters are worth too much, the problem is that the random maps tend to have a very high monster density. And arguably, at some point, higher density doesn't make it any tougher. From alex_sch at telus.net Sat May 28 23:18:56 2005 From: alex_sch at telus.net (Alex Schultz) Date: Sat May 28 23:19:35 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: <3539.202.106.20.66.1117328845.squirrel@webmail.laranja.org> References: <20050528075642.GA17903@kirschbaum.myrealbox.com> <4298AFE4.5080504@telus.net> <3539.202.106.20.66.1117328845.squirrel@webmail.laranja.org> Message-ID: <429942B0.2000300@telus.net> Lalo Martins wrote: >I thing the *right* solution to this is to have more high-level maps (and >possibly update the old ones, which fell behind changes in the rules). > Indeed, this is exactly what inspired me to begin a map I'm working on that's made for lvl 95+. It has first part with some basic hidden paths and traps and three guardian monsters which are very difficult custom ones, and the reward for those is going to the next stage and being able to face a large number of difficult custom monsters that give a nice amount of experience for that monster density and the target level of the map. After that (which has some traps to slow the person down a little), theres some nice artifact treasure. Mark Wedel wrote: > My personal thought is changing code to adjust the exp reward for > random maps is certainly the wrong approach. Updating the style maps > would be the right thing (don't do something in the code if it can be > done in the data files). > > If new styles are added but the exp isn't set right, that really > isn't any different than someone putting in a map that gives too much > treasure or too much exp. You don't go and change the code to try and > fix such maps, you fix the maps. Same would hold true with style maps. Yeah, fixing the map(style) instead of the code is much cleaner. > That said, if this really is considered a problem, another approach > would be to change the random map code to reduce the monster density. > The problem isn't that the individual monsters are worth too much, the > problem is that the random maps tend to have a very high monster > density. And arguably, at some point, higher density doesn't make it > any tougher. I'm personally thinking that something along the lines a 25% decrease in density, and a 25% decrease in the number of levels in the large ones (heaven, hell, TCs, but leaving the smaller ones alone in number of levels) would be good. Overall, I'm thinking we both need slightly reduced monster density in random maps, in addition to more non-random high level maps that actually have a decent number of high exp monsters (unlike evil masters which is just puzzles and bosses, which are nice but don't do much for exp) Alex Schultz From antonoussik at gmail.com Sun May 29 03:35:07 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Sun May 29 03:35:38 2005 Subject: [crossfire] Buildable savebeds In-Reply-To: <20050525180901.81019.qmail@web61015.mail.yahoo.com> References: <20050525180901.81019.qmail@web61015.mail.yahoo.com> Message-ID: On 5/25/05, Mitch Obrian wrote: > I agree. No pocket reality please. In that case in order for it to be an alternative that characters may actually take there needs to also be some sort of travellers backpack, which can hold lots but you can only carry one of them. Perhaps make a special player class which gets their backpack as startequip and has their first tent in their equipment? From antonoussik at gmail.com Sun May 29 03:42:31 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Sun May 29 03:43:38 2005 Subject: [crossfire] server ip/name In-Reply-To: References: <1124ed9005052602061ec7a67@mail.gmail.com> Message-ID: On 5/26/05, Andrew Fuchs wrote: > On 5/26/05, Neon Lim wrote: > > how to save a list of server ip/host in my crossfire client so that i > > do not need to always retype/find out the ip/name to connect. > > Afaik the client currently in cvs caches the servers that one connect > too. That is mainly in responce to the metaserver being down > recently. Also you can pass -server argument to the client when you start it, which means if you only play on one server the client will connect to it straight away. From antonoussik at gmail.com Sun May 29 03:59:58 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Sun May 29 04:01:38 2005 Subject: [crossfire] Create food / alchemy abuse? In-Reply-To: <42973C8E.3090603@telus.net> References: <42973C8E.3090603@telus.net> Message-ID: On 5/27/05, Alex Schultz wrote: > Nicolas Weeger wrote: > To summarize my ranting, I think that alchemy parts are overall more > than rare enough already Yes, there are parts that are hard to find. Perhaps a better way of fixing this would not be to make the ingredients more avaliable, but to make there be more formulae, so there are more chances of what you have being a valid recipe. > *however* alchemy shouldn't be possible to do purely with created items. Correct. Any changes to fix this probably belong in the formulae file, not code itself, which seems to be working well. If someone has a spare afternoon they could go through the formulae file and archetypes file and expand the formulae recipes to make it possible to create more items with alchemy or invent new ways of making the items. From antonoussik at gmail.com Sun May 29 04:07:48 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Sun May 29 04:08:51 2005 Subject: [crossfire] Request for ui bindings for scripts. In-Reply-To: <42973BFD.1080100@sonic.net> References: <1116093290.6945.12.camel@hawk> <42973BFD.1080100@sonic.net> Message-ID: On 5/27/05, Mark Wedel wrote: > Preston Crow wrote: > > On Sat, 2005-05-14 at 13:39, Andrew Fuchs wrote: > > > >>It would be nice if a script can intergrate more fully with the > >>client's ui. Namly, add enteries to the menubar, and otherwise > >>maniuplate the ui of the client. > > > > That would be nice. > > > > If someone wrote a generic "add button" interface to the various > > clients, then it would be fairly easy to hook the scripting in to it. > > For GTK, it wouldn't be hard to have a pull down menu for the scripts (putting > buttons someplace is harder, because you need that space someplace to draw those > buttons, and most of the clients don't have the space). Perhaps on startup search for scripts in ~/.crossfire/scripts and add them to a menu? (with scripts either being a list of locations the scripts themselves can be found, or a directory containing the actual scripts) From lalo at laranja.org Sun May 29 04:29:59 2005 From: lalo at laranja.org (Lalo Martins) Date: Sun May 29 04:33:39 2005 Subject: [crossfire] Buildable savebeds In-Reply-To: References: <20050525180901.81019.qmail@web61015.mail.yahoo.com> Message-ID: <1100.61.135.3.2.1117358999.squirrel@webmail.laranja.org> > On 5/25/05, Mitch Obrian wrote: > > In that case in order for it to be an alternative that characters may > actually take there needs to also be some sort of travellers backpack, > which can hold lots but you can only carry one of them. > > Perhaps make a special player class which gets their backpack as > startequip and has their first tent in their equipment? now that sounds good. But what would be the DISadvantage? Inability to buy apartments? (That would require some coding, but I could do it). Or just less money? (That's too easy to work around...) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.laranja.org/ mailto:lalo@laranja.org pgp key: http://garfield.laranja.org/~lalo/gpgkey-signed.asc GNU: never give up freedom http://www.gnu.org/ From antonoussik at gmail.com Sun May 29 04:51:25 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Sun May 29 04:51:41 2005 Subject: [crossfire] new metaserver In-Reply-To: <200505281015.33647.tchize@myrealbox.com> References: <200505271716.25901.tchize@myrealbox.com> <4297439B.5070600@sonic.net> <200505281015.33647.tchize@myrealbox.com> Message-ID: It's great that so much attention is being drawn towards making the server list accessible. However, will it then not be easier to just DoS attack the actual CF server? How resiliant is CF server to DoS attacks? There already exist several methods that make the server crawl even on fast hardware, such as loading huge maps and casting several meteor storms. After providing a reliable way of clients to connect to the server, the next step would be to make the server itself be more reliable. From antonoussik at gmail.com Sun May 29 05:15:39 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Sun May 29 05:17:39 2005 Subject: [crossfire] Buildable savebeds In-Reply-To: <1100.61.135.3.2.1117358999.squirrel@webmail.laranja.org> References: <20050525180901.81019.qmail@web61015.mail.yahoo.com> <1100.61.135.3.2.1117358999.squirrel@webmail.laranja.org> Message-ID: On 5/29/05, Lalo Martins wrote: > > > On 5/25/05, Mitch Obrian wrote: > > > > In that case in order for it to be an alternative that characters may > > actually take there needs to also be some sort of travellers backpack, > > which can hold lots but you can only carry one of them. > > > > Perhaps make a special player class which gets their backpack as > > startequip and has their first tent in their equipment? > > now that sounds good. But what would be the DISadvantage? Inability to > buy apartments? (That would require some coding, but I could do it). Or > just less money? (That's too easy to work around...) Good question. Players selecting that class just to increase their carry limit and then proceeding to play as before is the last thing we want. Inability to buy apartments is a good idea. It can be introduced into the game consistently by outputting a message to a player who tries to buy an apartment along the lines of them feeling ill of being constrained to such a confined space. Upon joining a guild or buying an old-style apartment/castle the players will get a permanent apartment anyhow though, and that may make this player class an attractive guild class. This certainly requires more thought. From handphone at gmail.com Sun May 29 08:20:55 2005 From: handphone at gmail.com (Neon Lim) Date: Sun May 29 08:21:42 2005 Subject: [crossfire] handbook / spoiler generation Message-ID: <1124ed9005052906203e2e5dc9@mail.gmail.com> Hi, May i know how do i generate handbook-html / spoiler-html in html. i've look into the Makefile in the doc directory, it seems that it will be able to generate many more html, such as god.html, items.html , etc. i saw in the directory has items-extract, skills-extract, etc, but didnt know how to extract. i am running a linux server. Can anyone advise me how do i generate the html files? Thanks. From tchize at myrealbox.com Sun May 29 08:24:58 2005 From: tchize at myrealbox.com (tchize) Date: Sun May 29 08:25:35 2005 Subject: [crossfire] new metaserver In-Reply-To: <20050527164327.19615.qmail@web61021.mail.yahoo.com> References: <20050527164327.19615.qmail@web61021.mail.yahoo.com> Message-ID: <200505291525.02695.tchize@myrealbox.com> Le Vendredi 27 Mai 2005 18:43, Mitch Obrian a ?crit : >Cave's meta server system is very good. >You cannot defeat a DDoS, but this gives us abit >better chance. Any url? > >I do not agree at all with admining the metametaserver >as some suggested. That way unpopular people's (like >me) servers would not make the list unless they kissed >the asses of the admins. IE: "We shouldn't include >him, he's and anti-women's-rights terrorist" etc. What does your opinions on women have to do with the discusisons on metaserver? The idea to have admin on metaserver is to avoid attempts to corrupt the server list with fake servers. > >Just let everything be automatic. Also I sugest not >nitpicking the thing, we should use what we have... >and with this thing we can put it on almost _ANY_ >webserver. That means we can host some metaservers on >the biggest pipes available (webhosting sites). If >they want to DDoS CF then... well they'll have to take >out 1/2 the internet. > > > >__________________________________ >Do you Yahoo!? >Yahoo! Small Business - Try our new Resources site >http://smallbusiness.yahoo.com/resources/ > >_______________________________________________ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- 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/20050529/7d455319/attachment.pgp From tchize at myrealbox.com Sun May 29 08:26:14 2005 From: tchize at myrealbox.com (tchize) Date: Sun May 29 08:29:22 2005 Subject: [crossfire] new metaserver In-Reply-To: References: <200505281015.33647.tchize@myrealbox.com> Message-ID: <200505291526.14887.tchize@myrealbox.com> One step at a time, have the server itself DOS resistant is another discussion, please put it on it's own thread. Le Dimanche 29 Mai 2005 11:51, Anton Oussik a ?crit : >It's great that so much attention is being drawn towards making the >server list accessible. However, will it then not be easier to just >DoS attack the actual CF server? How resiliant is CF server to DoS >attacks? There already exist several methods that make the server >crawl even on fast hardware, such as loading huge maps and casting >several meteor storms. After providing a reliable way of clients to >connect to the server, the next step would be to make the server >itself be more reliable. > >_______________________________________________ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- 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/20050529/884a1ce2/attachment.pgp From fuchs.andy at gmail.com Sun May 29 10:04:03 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun May 29 10:05:42 2005 Subject: [crossfire] Request for ui bindings for scripts. In-Reply-To: References: <1116093290.6945.12.camel@hawk> <42973BFD.1080100@sonic.net> Message-ID: > Perhaps on startup search for scripts in ~/.crossfire/scripts and add > them to a menu? (with scripts either being a list of locations the > scripts themselves can be found, or a directory containing the actual > scripts) Which would be nice, however a method to have a script manupulate the ui of the client is more of what I was looking for (add several menus that send signals to the script). -- -- Andrew Fuchs From lalo at laranja.org Sun May 29 10:56:02 2005 From: lalo at laranja.org (Lalo Martins) Date: Sun May 29 10:57:43 2005 Subject: [crossfire] Buildable savebeds In-Reply-To: References: <20050525180901.81019.qmail@web61015.mail.yahoo.com> <1100.61.135.3.2.1117358999.squirrel@webmail.laranja.org> Message-ID: <2424.61.135.24.65.1117382162.squirrel@webmail.laranja.org> > Upon joining a guild or buying an old-style apartment/castle the > players will get a permanent apartment anyhow though, and that may > make this player class an attractive guild class. This certainly > requires more thought. This is supposed to only happen at a relatively high level. So I think if we're modeling gipsies and traveling merchants (for example), it's not uncommon that they join a guild after some experience. By that point, we'll have to trust that the player has come to *enjoy* the wilderness life enough to prefer it rather than reverting to a "normal" guild player. *Or* we can be extra-evil and forbid them guilds too. (But I see no practical way to forbid castles. Maybe that's ok.) Then we would see bands of these players forming "caravans" or "camps" for protection. Hmm. What I worry more is - how are they "attacked" in their "sleep"? Just logging in to find "sorry, your character is dead" is VERY uncool. Maybe the attack happens *when* you log in (on the excuse that "you wake up to strange sounds. Oh no! Your tent is being attacked by wild creatures!") Or better, the presence of an occupied tent will "attract" these random monsters, which will stick around until someone wakes up. (From the strictly technical point of view, with map loading and unloading, that's not exactly what happens, but you get my point.) So this is a way in which a "caravan" would make people more safe; bigger chance that someone else will take care of the monster before you "wake up" ;-) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.laranja.org/ mailto:lalo@laranja.org pgp key: http://garfield.laranja.org/~lalo/gpgkey-signed.asc GNU: never give up freedom http://www.gnu.org/ From antonoussik at gmail.com Sun May 29 11:30:47 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Sun May 29 11:31:44 2005 Subject: [crossfire] Buildable savebeds In-Reply-To: <2424.61.135.24.65.1117382162.squirrel@webmail.laranja.org> References: <20050525180901.81019.qmail@web61015.mail.yahoo.com> <1100.61.135.3.2.1117358999.squirrel@webmail.laranja.org> <2424.61.135.24.65.1117382162.squirrel@webmail.laranja.org> Message-ID: On 5/29/05, Lalo Martins wrote: > > > Upon joining a guild or buying an old-style apartment/castle the > > players will get a permanent apartment anyhow though, and that may > > make this player class an attractive guild class. This certainly > > requires more thought. > > This is supposed to only happen at a relatively high level. So I think if > we're modeling gipsies and traveling merchants (for example), it's not > uncommon that they join a guild after some experience. By that point, > we'll have to trust that the player has come to *enjoy* the wilderness > life enough to prefer it rather than reverting to a "normal" guild player. In that case I guess it may be OK to allow them into guilds, although strictly speaking it may be easier to disallow them to sleep on beds of reality. That would require them to be outside in the wilderness to save, unable to get to sleep on a bed. > What I worry more is - how are they "attacked" in their "sleep"? Just > logging in to find "sorry, your character is dead" is VERY uncool. Maybe > the attack happens *when* you log in (on the excuse that "you wake up to > strange sounds. Oh no! Your tent is being attacked by wild creatures!") Coding-wise this wya seems best. > Or better, the presence of an occupied tent will "attract" these random > monsters, which will stick around until someone wakes up. (From the > strictly technical point of view, with map loading and unloading, that's > not exactly what happens, but you get my point.) So this is a way in > which a "caravan" would make people more safe; bigger chance that someone > else will take care of the monster before you "wake up" ;-) I'm not sure how this can be done. Perhaps it could be left out to start with, and then tied into a more general "wild animals" patch (there was talk earlier of making realistic wildlife by adding more animals and have them breed, eat, and hunt each other. Therefore depending on the climate different plants would grow, thereofre different animals would be able to survive eating those plants, therefore different predators would be able to survive eating them. Therefore we could end up with wild penguins and polar bears at the poles, and wild camels in the desert. Since a real simulation would be too resource-consuming the game would have to approximate and seed the map with the correct number of animals at map load. Perhaps presence of a tent to reality on the map should have a chance of increasing the number of man-eating monsters). From mikeeusaaa at yahoo.com Sun May 29 12:42:36 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sun May 29 12:43:44 2005 Subject: [crossfire] Buildable savebeds In-Reply-To: 6667 Message-ID: <20050529174236.27153.qmail@web61020.mail.yahoo.com> I doubt that a sim would take up much cpu time if abstracted abit. When a player enters the area then gen the real animals. --- Anton Oussik wrote: > On 5/29/05, Lalo Martins wrote: > > > > > Upon joining a guild or buying an old-style > apartment/castle the > > > players will get a permanent apartment anyhow > though, and that may > > > make this player class an attractive guild > class. This certainly > > > requires more thought. > > > > This is supposed to only happen at a relatively > high level. So I think if > > we're modeling gipsies and traveling merchants > (for example), it's not > > uncommon that they join a guild after some > experience. By that point, > > we'll have to trust that the player has come to > *enjoy* the wilderness > > life enough to prefer it rather than reverting to > a "normal" guild player. > > In that case I guess it may be OK to allow them into > guilds, although > strictly speaking it may be easier to disallow them > to sleep on beds > of reality. That would require them to be outside in > the wilderness to > save, unable to get to sleep on a bed. > > > What I worry more is - how are they "attacked" in > their "sleep"? Just > > logging in to find "sorry, your character is dead" > is VERY uncool. Maybe > > the attack happens *when* you log in (on the > excuse that "you wake up to > > strange sounds. Oh no! Your tent is being > attacked by wild creatures!") > > Coding-wise this wya seems best. > > > Or better, the presence of an occupied tent will > "attract" these random > > monsters, which will stick around until someone > wakes up. (From the > > strictly technical point of view, with map loading > and unloading, that's > > not exactly what happens, but you get my point.) > So this is a way in > > which a "caravan" would make people more safe; > bigger chance that someone > > else will take care of the monster before you > "wake up" ;-) > > I'm not sure how this can be done. Perhaps it could > be left out to > start with, and then tied into a more general "wild > animals" patch > (there was talk earlier of making realistic wildlife > by adding more > animals and have them breed, eat, and hunt each > other. Therefore > depending on the climate different plants would > grow, thereofre > different animals would be able to survive eating > those plants, > therefore different predators would be able to > survive eating them. > Therefore we could end up with wild penguins and > polar bears at the > poles, and wild camels in the desert. Since a real > simulation would be > too resource-consuming the game would have to > approximate and seed the > map with the correct number of animals at map load. > Perhaps presence > of a tent to reality on the map should have a chance > of increasing the > number of man-eating monsters). > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From fuchs.andy at gmail.com Sun May 29 12:45:42 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun May 29 12:49:00 2005 Subject: [crossfire] No autogen.sh for the client? Message-ID: The client is missing autogen.sh, which is an issue AL13N brought up on irc. >From irc: techii: where is that autogen.sh ? the client doesn't have one why noe? *not? -- -- Andrew Fuchs From tchize at myrealbox.com Sun May 29 13:20:21 2005 From: tchize at myrealbox.com (tchize) Date: Sun May 29 13:21:45 2005 Subject: [crossfire] No autogen.sh for the client? In-Reply-To: References: Message-ID: <200505292020.27980.tchize@myrealbox.com> Configure is enough to build client, there is an autogen.sh on server part of code, but i never use it. My system has several version of automake/ autoheader/ autoconf and autogen.sh always picks up the wrong one. So i do the process by hand. Le Dimanche 29 Mai 2005 19:45, Andrew Fuchs a ?crit : >The client is missing autogen.sh, which is an issue AL13N brought up on irc. > >>From irc: > > techii: where is that autogen.sh ? > the client doesn't have one > why noe? > *not? -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- 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/20050529/afa185e7/attachment.pgp From kirschbaum at myrealbox.com Sun May 29 14:04:19 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sun May 29 14:05:45 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: <429939A4.5050907@sonic.net> References: <20050528075642.GA17903@kirschbaum.myrealbox.com> <4298AFE4.5080504@telus.net> <3539.202.106.20.66.1117328845.squirrel@webmail.laranja.org> <429939A4.5050907@sonic.net> Message-ID: <20050529190418.GA25400@kirschbaum.myrealbox.com> Mark Wedel wrote: > My personal thought is changing code to adjust the exp reward for random maps > is certainly the wrong approach. Updating the style maps would be the right > thing (don't do something in the code if it can be done in the data files). I see. Besides that, changing the server code would create another problem: in the editor, you would not be able to check the real exp value without remembering the modifying factor in the server code. (It would be just like the item value that is multiplied by 4 in the current server code (for most items): it always bites me when I calculate item prices from the "value" field.) > That said, if this really is considered a problem, another approach would be > to change the random map code to reduce the monster density. The problem > isn't that the individual monsters are worth too much, the problem is that > the random maps tend to have a very high monster density. Sorry, I fail to see that reduced monster density will change that: the random maps are very regular and do not contain much other than lots of similar monsters. Especially, there are no quests inside that could slow down a player. Therefore with a lower monster density players can clear the maps even faster. But after that they just continue in the next level. The overall experience gain per time will not change much. And if you try to limit the experience by the number of available levels this would create yet another maps that are not normally available because everybody tries to clear them after a reset. (For example (not for experience but for another reason), the dragonmountain maps are seldom available.) Such maps are just not fun. Therefore I'm very reluctant to create more maps of that kind. > And arguably, at some point, higher density doesn't make it any tougher. That is the real problem I tried to explain in my initial post: many monsters of the same kind over and over. If you can kill a few, you probably can kill them all. From kirschbaum at myrealbox.com Sun May 29 14:05:30 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sun May 29 14:05:50 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: <429942B0.2000300@telus.net> References: <20050528075642.GA17903@kirschbaum.myrealbox.com> <4298AFE4.5080504@telus.net> <3539.202.106.20.66.1117328845.squirrel@webmail.laranja.org> <429942B0.2000300@telus.net> Message-ID: <20050529190530.GB25400@kirschbaum.myrealbox.com> Alex Schultz wrote: > I'm personally thinking that something along the lines a 25% decrease in > density, and a 25% decrease in the number of levels in the large ones > (heaven, hell, TCs, but leaving the smaller ones alone in number of > levels) would be good. That is, you suggest (for heaven) 75 levels with 75% of the monsters in it? That would still result in more than 200 million exp you can gain there. Compare that to the non-random warrior proofing tower that only gives you 70 million exp. And I'd say the warrior tower is much harder to solve (which is why I suggest you should get much more exp from the warrior tower than from any random map). > Overall, I'm thinking we both need slightly reduced monster density in > random maps, in addition to more non-random high level maps that > actually have a decent number of high exp monsters (unlike evil masters > which is just puzzles and bosses, which are nice but don't do much for exp) I don't think so. See my arguments below. It seems to me that nobody else than me thinks that the random maps give (far) too much experience. Nobody even bothered to comment on the experience tables in my initial mail. The responses merely said something like "please don't reduce the experience" without disproving my arguments. Therefore I'll try to illustrate my point of view a little more: In my opinion, a game must be fun for players. Otherwise they will just not play it (for a long time). One fun aspect of a game (again in my opinion) is that you always should have the impression that you could reach even more than you reached before if you just try. Be it more levels/experience, equipment, knowledge, etc. Therefore, if you are able to reach the maximum level in no time, it does not give you any sense of achievement when you actually reach it. On the other hand, it would just render the game to be not fun. Actually, reaching the maximum level makes the game boring because do not have that impression I described before. Note: I consider level 110 (but not 115) as the "maximum level" for crossfire because additional levels above 110 require double exp but do not give you much more benefits. Therefore these levels are just not worth the effort you need to gain them. That said, I'd rather make the game (much) harder to level than to create new high-level maps for level 110+ characters. With "much harder" I imagine something like: - level 30-50 is the common level for many (serious) players, - level 70+ should require quite some work (maybe at least a few weeks playtime if you really know what you are doing), - level 100+ should be really hard (at least a few months playtime), and - level 110+ should be virtually unreachable (maybe a year playtime) One more reason is that (in my opinion) a player should have lots of maps to choose from, regardless of his level. (Probably with the exception of level 115 characters: I do not care too much for these characters.) Now, my impression is that many developers are working on new server (and client) features but very few actually create new maps. Therefore, if we make it easy to become a high-level character, most of the existing maps become useless. So even if we create a few new high-level maps, overall we end with fewer (useful) maps than before. To demonstrate my point how easy it is to become a high level character by using the currently existing random maps, I created two new characters on my local server. I used different races and used skills to level them. With both characters I reached about level 90 in less than one hour playtime. Of course, I outfitted them with good starting equipment, but I think reaching a high level should mean quite a lot work, no matter what items you start with. (Besides that, I cannot think of any way to archive that with non-random maps -- ignoring that some other skill(s) do have the same problem.) Said that, my point in draining the experience from the random maps was a) to prevent players to gain huge amounts of exp (and high-levels) simply by doing random maps over and over. For example, my test-characters would have reached level 45 only (which also is too much for one hour playtime) with my exp/20 proposal, and b) to encourage players to clear non-random maps simply by making the exp reward for (comparably simple random) maps not rewarding. PS: one last note about the training center: on metalforge I've seen quite a few players that got killed somewhere, then switched to the TC because it is safe and effortless to level there. (It's their own choice to do so, but I don't think the training center (or any other random map) should make it possible to level faster than by clearing "regular" (non-random) maps.) From mikeeusaaa at yahoo.com Sun May 29 14:34:53 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sun May 29 14:35:46 2005 Subject: [crossfire] Red (brick) walls. Please up to CVS Message-ID: <20050529193453.45476.qmail@web61016.mail.yahoo.com> Red (brick) walls to match the outside of some of my buildings. Please up to CVS https://cat2.dynu.ca/crossfirearch/cwall-red/ __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From kirschbaum at myrealbox.com Sun May 29 14:44:29 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sun May 29 14:45:45 2005 Subject: [crossfire] Create food / alchemy abuse? In-Reply-To: References: <4296AFE4.6050808@sonic.net> Message-ID: <20050529194429.GA25505@kirschbaum.myrealbox.com> Nicolas Weeger wrote: > Or we could simply check the item's value, too - set to 0 by create > food. I think that will not work: dragon scales and beholdereyes are used as alchemy ingredients. Both of them have a value of 0. From alex_sch at telus.net Sun May 29 15:10:13 2005 From: alex_sch at telus.net (Alex Schultz) Date: Sun May 29 15:11:46 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: <20050529190530.GB25400@kirschbaum.myrealbox.com> References: <20050528075642.GA17903@kirschbaum.myrealbox.com> <4298AFE4.5080504@telus.net> <3539.202.106.20.66.1117328845.squirrel@webmail.laranja.org> <429942B0.2000300@telus.net> <20050529190530.GB25400@kirschbaum.myrealbox.com> Message-ID: <429A21A5.9030906@telus.net> Andreas Kirschbaum wrote: >That is, you suggest (for heaven) 75 levels with 75% of the monsters in it? >That would still result in more than 200 million exp you can gain there. >Compare that to the non-random warrior proofing tower that only gives you 70 >million exp. And I'd say the warrior tower is much harder to solve (which is >why I suggest you should get much more exp from the warrior tower than from any >random map). > Point taken, however one should note that heaven takes much more time than the warrior tower to complete fully and decreased monster density would further cause the exp/time ratio to go down further. >It seems to me that nobody else than me thinks that the random maps give (far) >too much experience. Nobody even bothered to comment on the experience tables >in my initial mail. The responses merely said something like "please don't >reduce the experience" without disproving my arguments. Therefore I'll try to >illustrate my point of view a little more: > I certainly agree that random maps need to be toned down (the few dungeons that use 5 or less random levels are fine as they are though). It's just that I think that there's another problem. I find that the maps made for those lvl 85 to 100 seem to give no more exp than those made for a lvl 50, which tends to drive people to go to the TCs and/or other random maps once they get to about level 50. I feel that this problem could be partially fixed by toning the random maps down significantly, however I feel that maps made for lvl 85-100 need to have a reasonable amount more exp than maps that a lvl 50 can complete. Though one may say that traps and puzzles are much more fun at those levels, which is quite true, a solution to that would be making the "bosses" (i.e. evil masters) and possibly some puzzles themselves give notably more exp. >To demonstrate my point how easy it is to become a high level character by >using the currently existing random maps, I created two new characters on my >local server. I used different races and used skills to level them. With both >characters I reached about level 90 in less than one hour playtime. > Really? This is certainly a problem then, though I can't see how one would achieve that without using banish rods or disabling item power. This sounds like there were exploits used other than the random maps alone (banish rod type ones) >Said that, my point in draining the experience from the random maps was > >a) to prevent players to gain huge amounts of exp (and high-levels) simply by > doing random maps over and over. > Which leads to another interesting point about repetition of maps, >b) to encourage players to clear non-random maps simply by making the exp > reward for (comparably simple random) maps not rewarding. > I think that something along these lines needs to be done, however I feel that the exp also needs to be tuned up on non-random maps that have some traps/puzzles and a small number of "bosses" to make those maps more attractive. >PS: one last note about the training center: on metalforge I've seen quite a > few players that got killed somewhere, then switched to the TC because it > is safe and effortless to level there. (It's their own choice to do so, but > I don't think the training center (or any other random map) should make it > possible to level faster than by clearing "regular" (non-random) maps.) > Yes, this often happens with quests like the pupland ones, where it has very nice puzzles and such, but it's hard not to die so much that you lose more exp than you gain there, and though exp shouldn't be too easy to get, players don't find non-random maps attractive if all the ones that are interesting (as in, haven't beaten 10 times before) have areas that they will almost constantly lose more exp than they gain. To summarize my points, I feel this is almost as much of a problem with the non-random maps as it is a problem of the random maps. Alex Schultz From alex_sch at telus.net Sun May 29 15:23:37 2005 From: alex_sch at telus.net (Alex Schultz) Date: Sun May 29 15:23:46 2005 Subject: [crossfire] Create food / alchemy abuse? In-Reply-To: References: <42973C8E.3090603@telus.net> Message-ID: <429A24C9.4000306@telus.net> Anton Oussik wrote: >On 5/27/05, Alex Schultz wrote: > >>To summarize my ranting, I think that alchemy parts are overall more >>than rare enough already >> >Yes, there are parts that are hard to find. Perhaps a better way of >fixing this would not be to make the ingredients more avaliable, but >to make there be more formulae, so there are more chances of what you >have being a valid recipe. > That helps for the occasional experimentation with alchemy, though I don't see how it helps too much for someone who wants to create a batch of 100 of something other than the basics like phil items and wise water. >>*however* alchemy shouldn't be possible to do purely with created items. >> >Correct. Any changes to fix this probably belong in the formulae file, >not code itself, which seems to be working well. If someone has a >spare afternoon they could go through the formulae file and archetypes >file and expand the formulae recipes to make it possible to create >more items with alchemy or invent new ways of making the items. > I'm not sure what you're proposing for fixing "alchemy shouldn't be possible to do purely with created items". Do you mean that the recipes that use only food items (creatable ones) should be changed? and if so, in what manner (i.e. adding other ingredients)? Alex Schultz From antonoussik at gmail.com Sun May 29 16:05:30 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Sun May 29 16:05:46 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: <429A21A5.9030906@telus.net> References: <20050528075642.GA17903@kirschbaum.myrealbox.com> <4298AFE4.5080504@telus.net> <3539.202.106.20.66.1117328845.squirrel@webmail.laranja.org> <429942B0.2000300@telus.net> <20050529190530.GB25400@kirschbaum.myrealbox.com> <429A21A5.9030906@telus.net> Message-ID: On 5/29/05, Alex Schultz wrote: > Andreas Kirschbaum wrote: > I feel that maps made for lvl 85-100 need to have > a reasonable amount more exp than maps that a lvl 50 can complete. I agree. There is little else to do at that level once you complete the quests and get all the equipment you can. > >To demonstrate my point how easy it is to become a high level character by > >using the currently existing random maps, I created two new characters on my > >local server. I used different races and used skills to level them. With both > >characters I reached about level 90 in less than one hour playtime. > > > Really? This is certainly a problem then, though I can't see how one > would achieve that without using banish rods or disabling item power. > This sounds like there were exploits used other than the random maps > alone (banish rod type ones) Not necessarily. The other day I made a firebourne of Valriel on Metalforge, gave it banishment spell, and had lots of fun in Demon TC. Levelled very quickly, although originally electricity caused much pain. Then I got enough hp to sustain it, and became virtually invincible there. The trick was to avoid fire elementals that I couldn't kill... but that's getting OT. There exist other even faster ways of levelling quickly if one knows the game, IIRC it is even possible to get to the top of xp table (lvl 115) in a day given some external help, not exploiting any bugs as such. The problem is not high level players doing TCs, but low level players being able to do them and quickly gain levels, and also that there is no real other way of getting to lvl110+ in acceptable time. I consider the xp gained from random maps as needed to gain high level, and will protest against them being toned down or removed unless something else is added to replace them that will allow high level players to level. Quests provide far too little for the time they occupy. > I > feel that the exp also needs to be tuned up on non-random maps that have > some traps/puzzles and a small number of "bosses" to make those maps > more attractive. Maybe if quests got combined with random maps, like adding random areas to quests, which a player may chose to complete (so a warrior-like player can do it to get better at one-handed for example) but also provide a shortcut that would require things like trap disarming, navigating trap mazes, and so on so a "thief"-like character can also complete the quests, the game would become more balanced. I appologise for the length of the last sentence. > >PS: one last note about the training center: on metalforge I've seen quite a > > few players that got killed somewhere, then switched to the TC because it > > is safe and effortless to level there. (It's their own choice to do so, but > > I don't think the training center (or any other random map) should make it > > possible to level faster than by clearing "regular" (non-random) maps.) > > > Yes, this often happens with quests like the pupland ones, where it has > very nice puzzles and such, but it's hard not to die so much that you > lose more exp than you gain there, and though exp shouldn't be too easy > to get, players don't find non-random maps attractive if all the ones > that are interesting (as in, haven't beaten 10 times before) have areas > that they will almost constantly lose more exp than they gain. I agree. My main MF character became more-less useless once monsters started casting banishment. Even doing TCs loses xp after lvl 113. (I actually went through the code and calculated it. If I continuously do Heaven I will reach and stay at lvl113). Non-random maps are even worse, and fixing this by giving giving hw protection has little effect as 5% of 10,000 damage a second is still 500/sec. With the lag of 400ms, thinking time 400ms, and reaction time another 200ms, by the time I press the key to get out of banished area I'm at 50hp, by which time it's too late. To summarise last paragraph, another problem with non-random maps is increased danger, which makes them less attractive for players that have spent long time developing skills. From mikeeusaaa at yahoo.com Sun May 29 17:01:23 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sun May 29 17:01:47 2005 Subject: [crossfire] Recent MLAB CDC bank commits Message-ID: <20050529220123.71594.qmail@web61020.mail.yahoo.com> Recent MLAB CDC bank commits removed the bar -> Imp converters. This is problematic as the players who bought vaults should beable to convert their bars into something. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From lalo at laranja.org Sun May 29 17:40:17 2005 From: lalo at laranja.org (Lalo Martins) Date: Sun May 29 17:43:48 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: <20050529190530.GB25400@kirschbaum.myrealbox.com> References: <20050528075642.GA17903@kirschbaum.myrealbox.com> <4298AFE4.5080504@telus.net> <3539.202.106.20.66.1117328845.squirrel@webmail.laranja.org> <429942B0.2000300@telus.net> <20050529190530.GB25400@kirschbaum.myrealbox.com> Message-ID: <3053.202.106.20.1.1117406417.squirrel@webmail.laranja.org> > It seems to me that nobody else than me thinks that the random maps give > (far) too much experience. Nobody even bothered to comment on the > experience tables in my initial mail. The responses merely said > something like "please don't reduce the experience" without > disproving my arguments. Nope, I think most people agree, so much so that this thread has grown a lot :-) What we said was not "please don't reduce the experience", but "please don't touch the server code" because that introduces unnecessary weirdness and inconsistency. Fix the (random) maps, not the server. One possible quickfix is to change the random map *LOADER*; so that if you don't specify how much XP the monsters should give (in the monsterstyle), then the default is 20% of the normal exp listed on the arch. This would, it seems, fix most random maps, and a quick "grep" job will show you what others need manual intervention: lalo:~SRC/crossfire/maps-arch> grep exp styles/monsterstyles/ -r --files-with-matches styles/monsterstyles/chaos/chaos_1 styles/monsterstyles/chaos/chaos_2 styles/monsterstyles/undead_quest/undead_quest_21 styles/monsterstyles/nethack/nethack_10 styles/monsterstyles/nethack/nethack_11 styles/monsterstyles/nethack/nethack_12 styles/monsterstyles/nethack/nethack_13 styles/monsterstyles/nethack/nethack_14 styles/monsterstyles/nethack/nethack_15 styles/monsterstyles/nethack/nethack_16 styles/monsterstyles/nethack/nethack_17 styles/monsterstyles/nethack/nethack_18 styles/monsterstyles/nethack/nethack_19 styles/monsterstyles/nethack/nethack_20 styles/monsterstyles/nethack/nethack_21 styles/monsterstyles/nethack/nethack_1 styles/monsterstyles/nethack/nethack_2 styles/monsterstyles/nethack/nethack_3 styles/monsterstyles/nethack/nethack_4 styles/monsterstyles/nethack/nethack_5 styles/monsterstyles/nethack/nethack_6 styles/monsterstyles/nethack/nethack_7 styles/monsterstyles/nethack/nethack_8 styles/monsterstyles/nethack/nethack_9 styles/monsterstyles/sylvan/sylvan_10 styles/monsterstyles/sylvan/sylvan_3 styles/monsterstyles/sylvan/sylvan_4 styles/monsterstyles/sylvan/sylvan_5 styles/monsterstyles/sylvan/sylvan_6 styles/monsterstyles/sylvan/sylvan_7 styles/monsterstyles/sylvan/sylvan_8 styles/monsterstyles/sylvan/sylvan_9 styles/monsterstyles/wyvern/wyvern_1 styles/monsterstyles/wyvern/wyvern_2 styles/monsterstyles/wyvern/wyvern_3 styles/monsterstyles/wyvern/wyvern_4 styles/monsterstyles/wyvern/wyvern_5 styles/monsterstyles/wyvern/wyvern_6 styles/monsterstyles/wyvern/wyvern_7 best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.laranja.org/ mailto:lalo@laranja.org pgp key: http://garfield.laranja.org/~lalo/gpgkey-signed.asc GNU: never give up freedom http://www.gnu.org/ From lalo at laranja.org Sun May 29 18:22:39 2005 From: lalo at laranja.org (Lalo Martins) Date: Sun May 29 18:25:48 2005 Subject: [crossfire] Buildable savebeds In-Reply-To: References: <20050525180901.81019.qmail@web61015.mail.yahoo.com> <1100.61.135.3.2.1117358999.squirrel@webmail.laranja.org> <2424.61.135.24.65.1117382162.squirrel@webmail.laranja.org> Message-ID: <3202.202.106.20.1.1117408959.squirrel@webmail.laranja.org> > On 5/29/05, Lalo Martins wrote: > In that case I guess it may be OK to allow them into guilds, although > strictly speaking it may be easier to disallow them to sleep on beds > of reality. That would require them to be outside in the wilderness to > save, unable to get to sleep on a bed. I thought about that, but there is a big problem. Disallowing them to sleep "safely" in beds is only *part* of the problem; I daresay, not the most important one. The really important part is to disallow them to have safe storage to hoard up items. That said, if the "wild animals" thing is done right, disallowing them to sleep in beds would be a good idea *too*. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.laranja.org/ mailto:lalo@laranja.org pgp key: http://garfield.laranja.org/~lalo/gpgkey-signed.asc GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Sun May 29 18:31:11 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun May 29 18:31:47 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: <20050529190418.GA25400@kirschbaum.myrealbox.com> References: <20050528075642.GA17903@kirschbaum.myrealbox.com> <4298AFE4.5080504@telus.net> <3539.202.106.20.66.1117328845.squirrel@webmail.laranja.org> <429939A4.5050907@sonic.net> <20050529190418.GA25400@kirschbaum.myrealbox.com> Message-ID: <429A50BF.10608@sonic.net> My thought that reducing monster density would help out was this: In my limited experience, best way to get that gobs of exp is through spells. If monsters are lined up in all directions, you cast that cone or bolt spell and hit a lot more monsters. So you quickly kill everything in just a few spells, move onto the next map, etc. If the density is lower, you don't kill as many, and this reduces exp to some degree. Player now has to spend more time moving to the exits, and possibly regaining sp/grace It may not be a big change, but would perhaps help out. Other thoughts: Reducing the number of levels of some dungeons may make sense - at least those that do have end maps and not some of the infinitely deep dungeons. But I consider this more a game play issue - dungeons that take several hours to complete are harder to play, eg, I only have 2 hours to play, won't be able to get through that dungeon because it is 10 levels deep, should do something else. One thing which has been suggested is the idea of exp reward for quests. Right now, if we look at the scorn nobility quest, the reward is an item and ability to get through the gate. But most commercial games I've played give a direct exp reward for the quest (beyond what you get killing the things in it itself). This probably makes sense for crossfire, especially if target at certain skills (I'll train you in alchemy if you do ....) That could also help out rewards for some of the tough maps that right now don't give a lot. For random maps, it might be reasonable to put in something like an 'exp_multiplier' in the map header or description of the random map. It could default to 1 (use values in style map), but could be adjusted to other values for other maps. I do agree the exp gains is a problem. Random maps are probably the biggest indicator, but mostly because they have high density and are deep. But things like the pupland raffle are similiar - high monster density, and if you're the appropriate level, a good place to pick up a fair amount of exp on the same basis. And there are other non random maps that are crammed full of monsters (some in brest, like the administration building come to mind). The random maps are probably popular simply because they are so deep. I think as long as these high density/easy to get to maps are around, the players are going to look for them simply for that reason. I don't have a good solution on how to fix those problems. From mwedel at sonic.net Sun May 29 18:38:30 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun May 29 18:37:48 2005 Subject: [crossfire] Buildable savebeds In-Reply-To: References: <20050525180901.81019.qmail@web61015.mail.yahoo.com> <1100.61.135.3.2.1117358999.squirrel@webmail.laranja.org> <2424.61.135.24.65.1117382162.squirrel@webmail.laranja.org> Message-ID: <429A5276.30100@sonic.net> It has long been suggested that the wilderness maps should have various animals or other wild creatures on it, and that could certainly go with people camping there. presuming the monsters are intelligent, perhaps they hang out near the tent. Or perhaps when player logs back in, quickly run some logic to see if a monster should be generated nearby. As an aside, it has been suggested in the past that it should be possible to rest to increase sp/grace regeneration (taking a nap should let you get that back fairly quickly). Letting these players have high carrying capacity bags is problematic however. While perhaps necessary to let them carry their items about, it then also means that they can loot the dungeon more easily (what works for their personal items will work for everything in the dungeon also). And that may not be a good thing. From mwedel at sonic.net Sun May 29 18:42:38 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun May 29 18:41:48 2005 Subject: [crossfire] Create food / alchemy abuse? In-Reply-To: References: <42973C8E.3090603@telus.net> Message-ID: <429A536E.2040800@sonic.net> Anton Oussik wrote: > >>*however* alchemy shouldn't be possible to do purely with created items. > > > Correct. Any changes to fix this probably belong in the formulae file, > not code itself, which seems to be working well. If someone has a > spare afternoon they could go through the formulae file and archetypes > file and expand the formulae recipes to make it possible to create > more items with alchemy or invent new ways of making the items. I'm unsure how that really fixes the problem. If I remember quickly, the formula in question uses booze and mandrake root. If the requirement is that one of the items can't one via create food, it is obvious - you go to the store to buy all the boozes (which are pretty common), and then use create food for the mandrake root. It doesn't really fix the problem (except the stores won't have booze anymore because it will be sold out). From fuchs.andy at gmail.com Sun May 29 20:11:04 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun May 29 20:11:48 2005 Subject: [crossfire] Recent MLAB CDC bank commits In-Reply-To: <20050529220123.71594.qmail@web61020.mail.yahoo.com> References: <20050529220123.71594.qmail@web61020.mail.yahoo.com> Message-ID: On 5/29/05, Mitch Obrian wrote: > Recent MLAB CDC bank commits removed the bar -> Imp > converters. This is problematic as the players who > bought vaults should beable to convert their bars into > something. So bar -> platinum converters then? -- -- Andrew Fuchs From fuchs.andy at gmail.com Sun May 29 20:25:16 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun May 29 20:25:48 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: <429A50BF.10608@sonic.net> References: <20050528075642.GA17903@kirschbaum.myrealbox.com> <4298AFE4.5080504@telus.net> <3539.202.106.20.66.1117328845.squirrel@webmail.laranja.org> <429939A4.5050907@sonic.net> <20050529190418.GA25400@kirschbaum.myrealbox.com> <429A50BF.10608@sonic.net> Message-ID: On 5/29/05, Mark Wedel wrote: > The random maps are probably popular simply because they are so deep. I think > as long as these high density/easy to get to maps are around, the players are > going to look for them simply for that reason. I don't have a good solution on > how to fix those problems. Increase what has to be "payed" at the alter to get in. Such as instead of just a dragon scale, to get into the draogn tc, require a few quested items, and a few different parts of dragons (eyes, scale, heart brain, etc). IMO the items should be availble in multiple dungeons. -- -- Andrew Fuchs From mikeeusaaa at yahoo.com Sun May 29 20:31:09 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sun May 29 20:31:48 2005 Subject: [crossfire] Recent MLAB CDC bank commits In-Reply-To: 6667 Message-ID: <20050530013109.17726.qmail@web61025.mail.yahoo.com> That would work. The reason I use imp in the dev map is because banks in the real word would want to keep as much bullion as possible, giving out paper money would allow them to keep increasing their bullion amount thus allowing them to back more and more transactions.... and making them richer and richer in a real sense. --- Andrew Fuchs wrote: > On 5/29/05, Mitch Obrian > wrote: > > Recent MLAB CDC bank commits removed the bar -> > Imp > > converters. This is problematic as the players who > > bought vaults should beable to convert their bars > into > > something. > > So bar -> platinum converters then? > > -- > -- > Andrew Fuchs > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From fuchs.andy at gmail.com Sun May 29 20:28:54 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun May 29 20:31:52 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: <429A50BF.10608@sonic.net> References: <20050528075642.GA17903@kirschbaum.myrealbox.com> <4298AFE4.5080504@telus.net> <3539.202.106.20.66.1117328845.squirrel@webmail.laranja.org> <429939A4.5050907@sonic.net> <20050529190418.GA25400@kirschbaum.myrealbox.com> <429A50BF.10608@sonic.net> Message-ID: As for reducing the monster density, I think the amount present on lower level random maps is fine, but the higher level ones have issues. -- -- Andrew Fuchs From fuchs.andy at gmail.com Sun May 29 20:35:19 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun May 29 20:35:46 2005 Subject: [crossfire] Create food / alchemy abuse? In-Reply-To: <429A536E.2040800@sonic.net> References: <42973C8E.3090603@telus.net> <429A536E.2040800@sonic.net> Message-ID: On 5/29/05, Mark Wedel wrote: > I'm unsure how that really fixes the problem. > > If I remember quickly, the formula in question uses booze and mandrake root. > If the requirement is that one of the items can't one via create food, it is > obvious - you go to the store to buy all the boozes (which are pretty common), > and then use create food for the mandrake root. It doesn't really fix the > problem (except the stores won't have booze anymore because it will be sold out). You will have 20 or so booze, instead of hundreds. I think simply modifying the name of the created items would be the best solution for now. It would solve the problem, and make quests where one has to find items that can be created with spells, harder. -- -- Andrew Fuchs From tchize at myrealbox.com Mon May 30 14:10:07 2005 From: tchize at myrealbox.com (tchize) Date: Mon May 30 14:11:58 2005 Subject: [crossfire] ingame music Message-ID: <200505302110.07811.tchize@myrealbox.com> Hello, buzzsaw just provided a first midi sample to use as HallOfSelection background music. Comments welcomed (though it's only a few seconds in length) http://users.skynet.be/tchize/hall.mp3 -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html From fuchs.andy at gmail.com Mon May 30 14:30:33 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Mon May 30 14:31:59 2005 Subject: [crossfire] ingame music In-Reply-To: <200505302110.07811.tchize@myrealbox.com> References: <200505302110.07811.tchize@myrealbox.com> Message-ID: On 5/30/05, tchize wrote: > Hello, buzzsaw just provided a first midi sample > to use as HallOfSelection background music. I can probaly make more, once I get access to my main box back. -- -- Andrew Fuchs From mikeeusaaa at yahoo.com Mon May 30 14:39:27 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Mon May 30 14:41:58 2005 Subject: [crossfire] ingame music In-Reply-To: 6667 Message-ID: <20050530193927.39401.qmail@web61017.mail.yahoo.com> Can we get this in midi aswell? --- Andrew Fuchs wrote: > On 5/30/05, tchize wrote: > > Hello, buzzsaw just provided a first midi sample > > to use as HallOfSelection background music. > > I can probaly make more, once I get access to my > main box back. > > -- > -- > Andrew Fuchs > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mwedel at sonic.net Mon May 30 14:46:09 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon May 30 14:45:59 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: References: <20050528075642.GA17903@kirschbaum.myrealbox.com> <4298AFE4.5080504@telus.net> <3539.202.106.20.66.1117328845.squirrel@webmail.laranja.org> <429939A4.5050907@sonic.net> <20050529190418.GA25400@kirschbaum.myrealbox.com> <429A50BF.10608@sonic.net> Message-ID: <429B6D81.4000206@sonic.net> Andrew Fuchs wrote: > On 5/29/05, Mark Wedel wrote: > >> The random maps are probably popular simply because they are so deep. I think >>as long as these high density/easy to get to maps are around, the players are >>going to look for them simply for that reason. I don't have a good solution on >>how to fix those problems. > > > Increase what has to be "payed" at the alter to get in. Such as > instead of just a dragon scale, to get into the draogn tc, require a > few quested items, and a few different parts of dragons (eyes, scale, > heart brain, etc). IMO the items should be availble in multiple > dungeons. Perhaps that would be good for the training tower type of maps. However, on a larger scale, I'm a little concerned. If this is done on a large scale, and getting those items is actually difficult, what now results in that players go to other maps. One of the reasons behind random maps was to provide effectively more maps to adventure on, because players were targetting certain maps and just hitting those repeatedly (which basically means you had to see what was available when you logged in). So we have to be careful in that regard - if all we do is end up driving players from one map to another, I don't know if that really fixes the problem. Another possibility of course is to add some more style maps, and put some custom monsters on them that are _really_ tough. Such that a player surround by 5 of them could be in for some serious hurt. One other reason here is that as the dungeons levels get deeper, the treasure gets better. If at some point the monster difficulty maxes out (top according to style map, map at 100% monster density), it just means the players get better and better items. All that said, I don't have a problem with reducing the exp for some of the tougher monsters on the style maps. I know from my own experience that the titans quest was a good place to pick up quite a bit of exp if I had the right spells. From mwedel at sonic.net Mon May 30 14:48:12 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon May 30 14:50:08 2005 Subject: [crossfire] Create food / alchemy abuse? In-Reply-To: References: <42973C8E.3090603@telus.net> <429A536E.2040800@sonic.net> Message-ID: <429B6DFC.1070608@sonic.net> Andrew Fuchs wrote: > On 5/29/05, Mark Wedel wrote: > >> I'm unsure how that really fixes the problem. >> >> If I remember quickly, the formula in question uses booze and mandrake root. >>If the requirement is that one of the items can't one via create food, it is >>obvious - you go to the store to buy all the boozes (which are pretty common), >>and then use create food for the mandrake root. It doesn't really fix the >>problem (except the stores won't have booze anymore because it will be sold out). > > > You will have 20 or so booze, instead of hundreds. > > I think simply modifying the name of the created items would be the > best solution for now. It would solve the problem, and make quests > where one has to find items that can be created with spells, harder. > I'm not sure if there are any money->booze converters out there. But either way, it helps the problem somewhat. Changing name of created items then require addition of new formulae if you want the players to be able to create it via god given items. From antonoussik at gmail.com Mon May 30 17:18:55 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Mon May 30 17:20:01 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: <429B6D81.4000206@sonic.net> References: <20050528075642.GA17903@kirschbaum.myrealbox.com> <4298AFE4.5080504@telus.net> <3539.202.106.20.66.1117328845.squirrel@webmail.laranja.org> <429939A4.5050907@sonic.net> <20050529190418.GA25400@kirschbaum.myrealbox.com> <429A50BF.10608@sonic.net> <429B6D81.4000206@sonic.net> Message-ID: Just thought it was worth mentioning how another game has dealt with this problem. Anarchy Online has static quests, like in CF, which people camp for items. However, for levelling, often a "random quest generator" is used, which is a terminal which issues a random quest, with random maps, and a random boss dropping random arches at the end. This is very similar to random maps apart from the boss. What slows players down is the need for a party to complete the quest (you need around 5-6 people to kill the monsters in there), and the quest is generated specifically for you level. Also maps have "instances". There is more than one of each map, so instead of entering (and resetting the reset timer on a map) a completed map a player may enter a new instance, which is not completed by anyone yet. Not sure if any of those are appropriate for CF though. From fuchs.andy at gmail.com Mon May 30 17:26:31 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Mon May 30 17:28:01 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: References: <20050528075642.GA17903@kirschbaum.myrealbox.com> <4298AFE4.5080504@telus.net> <3539.202.106.20.66.1117328845.squirrel@webmail.laranja.org> <429939A4.5050907@sonic.net> <20050529190418.GA25400@kirschbaum.myrealbox.com> <429A50BF.10608@sonic.net> <429B6D81.4000206@sonic.net> Message-ID: On 5/30/05, Anton Oussik wrote: > Not sure if any of those are appropriate for CF though. Well, there is the issue with the number of players... -- -- Andrew Fuchs From trhyne at MIT.EDU Tue May 31 08:07:33 2005 From: trhyne at MIT.EDU (Vernon T Rhyne) Date: Tue May 31 08:11:21 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: References: <20050528075642.GA17903@kirschbaum.myrealbox.com> <4298AFE4.5080504@telus.net> <3539.202.106.20.66.1117328845.squirrel@webmail.laranja.org> <429939A4.5050907@sonic.net> <20050529190418.GA25400@kirschbaum.myrealbox.com> <429A50BF.10608@sonic.net> <429B6D81.4000206@sonic.net> Message-ID: <1117544853.429c61955fae5@webmail.mit.edu> Quoting Andrew Fuchs : > On 5/30/05, Anton Oussik wrote: > > Not sure if any of those are appropriate for CF though. > > Well, there is the issue with the number of players... > > -- > -- > Andrew Fuchs > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > I don't often comment here, but I've followed this thread a good bit and wanted to put my cents in. At heart the issue is (in this and many other multiplayer level-based games) that experience generation is monotonous and non-stimulating. The random-based maps are a workaround (as they were in Anarchy Online). They allow you to tackle the monotony in a convenient setting. Without them, experience generation would be not only monotonous, but also more predatory. The "best" maps would be camped out even more. Yes, with the near-infinite resources and items an experienced player has, generating a second character at the same level is trivial. Rare loot is a much more meaningful scoring device in Crossfire than experience is. This loot combined with the knowledge generated from the first go-around SHOULD make the second (or Nth) time simplistic. This isn't a bad thing. It certainly shouldn't be taken as proof that a new player can achieve level 100+ in a trivial period if unaided. Since this issue has migrated a number of directions, let me throw out a few: 1) Significant experience generated for quest completion. (slay the quest, get a cookie...) 2) Less of a death penalty. The treadmill has a frightful slope, especially when combined with the "angel with a rod of banishment" and other such random mishaps. While it might be nice to quest-map to a level the first time, the Nth time you just want to get there as safely as possible. 3) A conversion for money into powerups or lessening death penalties. Directly into exp is a bad idea, but temporary bonuses could be effective. I also believe there to be silly amounts of money lying around in a Crossfire world, with no real current value. From B.T.Lally at warwick.ac.uk Tue May 31 08:51:22 2005 From: B.T.Lally at warwick.ac.uk (Brendan Lally) Date: Tue May 31 08:53:23 2005 Subject: [crossfire] Proposal to fix experience inflation due torandom maps Message-ID: >>> trhyne@MIT.EDU 05/31/05 14:14 PM >>> > 1) Significant experience generated for quest completion. (slay the quest, get > a cookie...) let me run with that for a moment. (this ties in with the thread a while back on quest tracking, but is actually looking at it from the opposite direction). What if there were a new skill 'questing', (heroism?) that would give exp if and only if the character completed a quest (not a random map). If tracker items were used as well, then it could be checked to stop exp being give repeatedly for the same quest. (this isn't remarkably different to Runescape's idea of quest points, only less horrible, and a proper skill. This gives an interesting way then to control gameplay, since then certain parts of the game can check your questing exp (eg, you can only leave scorn at above questing level 5, only enter nurnberg above level 20, etc. With items being given as well, it is possible to track all of the players who have completed a given quest. If you also allow extra stats to be collected, maybe have a 'start quest' object, which is slain by the end quest one. Then you can have tables and the like generated from the player files (who has completed the WDSM quest, who did so the quickest, who did so at the lowest level, etc) Assuming that the exp granted is reasonable, then the quests would be better than the random maps, especially after the exp from them is toned down by an order of magnitude, and there is another way to 'beat' the game, since there would then be a more interesting high score list than the main one (which is full of retired scripters anyway). From kari at sammakko.yok.utu.fi Tue May 31 14:18:55 2005 From: kari at sammakko.yok.utu.fi (Kari Pahula) Date: Tue May 31 14:20:13 2005 Subject: [crossfire] include/living.h in crossfire Message-ID: <20050531191855.290871B09E71F@sammakko.yok.utu.fi> Looks like living.h has some extra bits left in it. savethrow is a static variable in living.c. That extern declaration is useless. turn_bonus is declared twice, once is enough. And that learn_prayer_chance is neither defined nor used anywhere. diff -u -r crossfire.orig/include/living.h crossfire/include/living.h --- crossfire.orig/include/living.h 2005-05-31 22:11:39.263284251 +0300 +++ crossfire/include/living.h 2005-05-31 22:11:52.211604660 +0300 @@ -53,9 +53,6 @@ extern int turn_bonus[MAX_STAT + 1]; extern int max_carry[MAX_STAT + 1]; extern int dam_bonus[MAX_STAT + 1]; -extern int savethrow[111]; -extern int turn_bonus[MAX_STAT + 1]; -extern int learn_prayer_chance[MAX_STAT + 1]; extern int learn_spell[]; extern char *restore_msg[NUM_STATS]; extern char *statname[NUM_STATS]; From kirschbaum at myrealbox.com Tue May 31 14:20:32 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Tue May 31 14:26:14 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: <429A50BF.10608@sonic.net> References: <20050528075642.GA17903@kirschbaum.myrealbox.com> <4298AFE4.5080504@telus.net> <3539.202.106.20.66.1117328845.squirrel@webmail.laranja.org> <429939A4.5050907@sonic.net> <20050529190418.GA25400@kirschbaum.myrealbox.com> <429A50BF.10608@sonic.net> Message-ID: <20050531192028.GA21551@kirschbaum.myrealbox.com> Mark Wedel wrote: > My thought that reducing monster density would help out was this: > > In my limited experience, best way to get that gobs of exp is through > spells. If monsters are lined up in all directions, you cast that cone > or bolt spell and hit a lot more monsters. So you quickly kill > everything in just a few spells, move onto the next map, etc. Yes, spells are probably the fastest way. But even with melee it does not take long (if the rooms are large enough): since most monsters try to reach you, they crowd around you. The only thing you have to do is to run forth and back, possibly quaff a healing potion or cast restoration once in a while. > If the density is lower, you don't kill as many, and this reduces exp > to some degree. Player now has to spend more time moving to the exits, > and possibly regaining sp/grace > > It may not be a big change, but would perhaps help out. After some more thinking about it, I realized that my concern probably is not (only) the huge amount of exp but more how easy you can gain it. Therefore monster density could be in fact the problem: for example, the undead random dungeon north west of Wolfsburg contains the same kind of monsters as the undead training center. But that dungeon near Wolfsburg consists mainly of narrow and twisted corridors but only has few large rooms. That layout both results in a lower monster density and it slows down players considerably. (If you ignore some other broken (or at least way too powerful) spells that can clear whole levels at once.) > One thing which has been suggested is the idea of exp reward for > quests. Right now, if we look at the scorn nobility quest, the reward > is an item and ability to get through the gate. But most commercial > games I've played give a direct exp reward for the quest (beyond what > you get killing the things in it itself). This probably makes sense > for crossfire, especially if target at certain skills (I'll train you > in alchemy if you do ....) That could also help out rewards for some > of the tough maps that right now don't give a lot. That could be a good idea. Especially since the items you gain there are not that useful, but a moderate amount of exp would be really nice because you normally solve it when you are still fairly low-level. An other example I could imagine is a boss monster at the end of Heaven/Hell (maybe the Avatar of Valriel/Gorokh). Just like the Avatar of the Fire God in the Temple of the Fire God: a really hard monster at the end protecting the treasure room. Maybe that monster could give a huge amount of exp if you manage to kill it. > I do agree the exp gains is a problem. Random maps are probably the > biggest indicator, but mostly because they have high density and are > deep. Another note: I just checked the random map generation code. It already limits the maximum exp per tile. But that limit is quite large. For example, in the last dungeon of the dragon tc it is 18.500 exp/tile. Map sizes about 33x33 (1000 tiles) are quite common but I've seen sizes up to 50x50 (2500 tiles). That means the exp per level is limited to 18 million (1000 tiles) or 46 million (2500 tiles). > But things like the pupland raffle are similiar - high monster > density, and if you're the appropriate level, a good place to pick up > a fair amount of exp on the same basis. That is true, but I do not consider it such a big problem because you cannot possibly reach a very high level there, and I had the impression there was a todo item (but currently I cannot find it) to make monster generators stop working after some time. Therefore maps like the raffle will become toned down automatically as soon as that generator patch is done. > And there are other non random maps that are crammed full of monsters > (some in brest, like the administration building come to mind). I agree. But that should not prevent us from starting to fix the exp problem in the random maps. After all, we can just fix the remaining non-random maps as well if they are really (too) problematic. > The random maps are probably popular simply because they are so deep. > I think as long as these high density/easy to get to maps are around, > the players are going to look for them simply for that reason. Sure, players normally take the easiest way that works for them. > I don't have a good solution on how to fix those problems. I think the only (but not easy) solution is to watch out for (too) popular maps and fix them (or improve other maps) if necessary. From elshar at cheekan.org Tue May 31 16:14:55 2005 From: elshar at cheekan.org (Michael) Date: Tue May 31 16:08:15 2005 Subject: [crossfire] new metaserver In-Reply-To: <200505271735.41196.cerzeo@gmail.com> References: <4296B8BD.6050106@sonic.net> <200505271735.41196.cerzeo@gmail.com> Message-ID: <429CD3CF.8090405@cheekan.org> You are most likely behind a transparent (Or not so transparent) http proxy. I know when I setup a squidcache (an http proxy), people would goto those kinds of websites and see their ip as the squidcache's address, as it was the one making the external http requests. Elshar cerzeo@gmail.com wrote: >And there is possible to create a metaserver using the port number 80 or 21 >(ftp port?). > >Me and sure many people are in a LAN, and proxy server have all ports closed, >except 80, 21 and amsn port. > >If not, can someone connect (extern to mi LAN), connect to my server? > >My LAN IP is 163.117.65.99, but when i visit this web www.whatismyip.com, it >sas that my IP is 163.117.36.72. Can it be possible? >Someone can explain me this? > >Thanks. > > From kirschbaum at myrealbox.com Tue May 31 16:55:18 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Tue May 31 16:56:16 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: <429A21A5.9030906@telus.net> References: <20050528075642.GA17903@kirschbaum.myrealbox.com> <4298AFE4.5080504@telus.net> <3539.202.106.20.66.1117328845.squirrel@webmail.laranja.org> <429942B0.2000300@telus.net> <20050529190530.GB25400@kirschbaum.myrealbox.com> <429A21A5.9030906@telus.net> Message-ID: <20050531215518.GA22424@kirschbaum.myrealbox.com> 5BAlex Schultz wrote: > Point taken, however one should note that heaven takes much more time > than the warrior tower to complete fully and decreased monster density > would further cause the exp/time ratio to go down further. Probably. But clearing the warrior tower takes quite some time, too. And a big difference is that the warrior tower gets harder and harder the more you advance. If you are not good enough yet, you simply cannot complete it. The result is that your exp is proportional (or maybe a little more than linear) to your skill level. On the other hand, you can clear Heaven completely if you can clear a certain depth. Therefore Heaven is quite different: initially the exp is proportional to your skill level, but as soon as you reach the maximum difficulty you gain a huge amount of exp in one fell swoop. > I certainly agree that random maps need to be toned down (the few > dungeons that use 5 or less random levels are fine as they are > though). That probably calls for the 'exp_multiplier' field Mark Wedel suggested in a previous mail. In my initial mail I just intended to equally tone down all random maps. But I did not think of the many low-level random maps that are just fine. > It's just that I think that there's another problem. I find that the > maps made for those lvl 85 to 100 seem to give no more exp than those > made for a lvl 50, which tends to drive people to go to the TCs and/or > other random maps once they get to about level 50. I feel that this > problem could be partially fixed by toning the random maps down > significantly, however I feel that maps made for lvl 85-100 need to > have a reasonable amount more exp than maps that a lvl 50 can > complete. Though one may say that traps and puzzles are much more fun > at those levels, which is quite true, a solution to that would be > making the "bosses" (i.e. evil masters) and possibly some puzzles > themselves give notably more exp. Which maps do you consider level 50 and which 85-100? > > To demonstrate my point how easy it is to become a high level > > character by using the currently existing random maps, I created two > > new characters on my local server. I used different races and used > > skills to level them. With both characters I reached about level 90 > > in less than one hour playtime. > > Really? This is certainly a problem then, though I can't see how one > would achieve that without using banish rods or disabling item power. > This sounds like there were exploits used other than the random maps > alone (banish rod type ones) One character used a rod of banishment to clear Heaven. The other one burned down Heaven with meteor swarm. But I did not disable item power. If fact, item power did not matter much: banishment and meteor swarm killed the monsters very fast. Therefore I died a few times only (one time with banishment, four or five times with meteor swarm) until I had enough exp to wear all my protective gear. > > a) to prevent players to gain huge amounts of exp (and high-levels) > > simply by doing random maps over and over. > > Which leads to another interesting point about repetition of maps, I do not have any problems with players clearing some maps over and over again. If they have fun doing so, let them do it... They just should not be able to gain incredible amounts of exp by doing so. > > b) to encourage players to clear non-random maps simply by making > > the exp reward for (comparably simple random) maps not rewarding. > > I think that something along these lines needs to be done, however I > feel that the exp also needs to be tuned up on non-random maps that > have some traps/puzzles and a small number of "bosses" to make those > maps more attractive. Yes, many non-random maps neither give you much exp nor any decent item(s) at the end. Therefore a player normally does not bother to clear such a map again. Besides that, I do not have any problem with tuning up some maps if the ratio reward (exp+items) per work (necessary time+danger) is reasonable. > To summarize my points, I feel this is almost as much of a problem > with the non-random maps as it is a problem of the random maps. I agree. But fixing the random maps is much easier than fixing the non-random ones. Therefore we should start with the random ones... From kari at sammakko.yok.utu.fi Tue May 31 17:03:09 2005 From: kari at sammakko.yok.utu.fi (Kari Pahula) Date: Tue May 31 17:04:16 2005 Subject: [crossfire] client: another useless variable declaration in gtk/gx11.h Message-ID: <20050531220309.40A4C1C520B65@sammakko.yok.utu.fi> The variable gtkwin_config in gtk/gx11.h is not used anywhere. Furthermore, it makes the build fail on gcc 4.0 which is pickier with variable names, since gtkwin_config is used (twice actually, in different files) as a static variable name too. From kari at sammakko.yok.utu.fi Tue May 31 17:29:09 2005 From: kari at sammakko.yok.utu.fi (Kari Pahula) Date: Tue May 31 17:29:25 2005 Subject: [crossfire] client: Mismatch in man page dir and section Message-ID: <20050531222909.683B71C520B69@sammakko.yok.utu.fi> Hi, it's me again. There's a problem with x11/Makefile.in. You have in there: mandir=${DESTDIR}@mandir@/man1 ... install: $(INSTALL) -d ${bindir} $(INSTALL) -d ${mandir} $(INSTALL) cfclient ${bindir}/cfclient $(INSTALL) -m 444 cfclient.man ${mandir}/cfclient.6 As you can see, you install a man.6 file to man1 dir. mandir should have man6 instead. For reference, gtk/Makefile.in is correct. mandir=${DESTDIR}@mandir@/man6 ... install: $(INSTALL) -d ${bindir} $(INSTALL) -d ${mandir} $(INSTALL) gcfclient ${bindir}/gcfclient $(INSTALL) -m 444 gcfclient.man ${mandir}/gcfclient.6 From alex_sch at telus.net Tue May 31 18:58:12 2005 From: alex_sch at telus.net (Alex Schultz) Date: Tue May 31 18:58:18 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: <20050531215518.GA22424@kirschbaum.myrealbox.com> References: <20050528075642.GA17903@kirschbaum.myrealbox.com> <4298AFE4.5080504@telus.net> <3539.202.106.20.66.1117328845.squirrel@webmail.laranja.org> <429942B0.2000300@telus.net> <20050529190530.GB25400@kirschbaum.myrealbox.com> <429A21A5.9030906@telus.net> <20050531215518.GA22424@kirschbaum.myrealbox.com> Message-ID: <429CFA14.7010006@telus.net> Andreas Kirschbaum wrote: >clearing the warrior tower takes quite some time, too. And >a big difference is that the warrior tower gets harder and harder the >more you advance. If you are not good enough yet, you simply cannot >complete it. The result is that your exp is proportional (or maybe a >little more than linear) to your skill level. > >On the other hand, you can clear Heaven completely if you can clear a >certain depth. Therefore Heaven is quite different: initially the exp is >proportional to your skill level, but as soon as you reach the maximum >difficulty you gain a huge amount of exp in one fell swoop. > > Very true, which reminds me of something that has always annoyed me about the random maps like heaven, hell, dragon tc, etc. which is that once you get to the hardest type of monster is has, you still have another 25 or so levels to go with just tons of those never getting any harder. Perhaps random maps should get more things that are more difficult after that stage, which wouldn't eliminate the problem, but would help. >>I certainly agree that random maps need to be toned down (the few >>dungeons that use 5 or less random levels are fine as they are >>though). >> >> >That probably calls for the 'exp_multiplier' field Mark Wedel suggested >in a previous mail. In my initial mail I just intended to equally tone >down all random maps. But I did not think of the many low-level random >maps that are just fine. > > Indeed, and even if there is a better solution than lowering the exp, adding exp_multiplier capability wouldn't be a bad thing nor should it be difficult to code. >>It's just that I think that there's another problem. I find that the >>maps made for those lvl 85 to 100 seem to give no more exp than those >>made for a lvl 50, which tends to drive people to go to the TCs and/or >>other random maps once they get to about level 50. I feel that this >>problem could be partially fixed by toning the random maps down >>significantly, however I feel that maps made for lvl 85-100 need to >>have a reasonable amount more exp than maps that a lvl 50 can >>complete. Though one may say that traps and puzzles are much more fun >>at those levels, which is quite true, a solution to that would be >>making the "bosses" (i.e. evil masters) and possibly some puzzles >>themselves give notably more exp. >> >> >Which maps do you consider level 50 and which 85-100? > > 85-100 is something like the evil masters/gothwote maps, whereas lvl 50 is something like the dragon cave. >One character used a rod of banishment to clear Heaven. The other one >burned down Heaven with meteor swarm. But I did not disable item power. >If fact, item power did not matter much: banishment and meteor swarm >killed the monsters very fast. Therefore I died a few times only (one >time with banishment, four or five times with meteor swarm) until I had >enough exp to wear all my protective gear. > > Ah, makes sense, though I've tried MSing in heaven before, and the arch angles resist it pretty well. >>Which leads to another interesting point about repetition of maps, >> >> >I do not have any problems with players clearing some maps over and over >again. If they have fun doing so, let them do it... They just should not >be able to gain incredible amounts of exp by doing so. > > Which is why it might be useful to do something of making it possible for maps (on a per map basis) to give normal exp upon the first clear, and give slightly lessened exp upon further tries. I don't think this should be too widely used, but I think it would be good to at least make it possible for a map maker to do that. >Yes, many non-random maps neither give you much exp nor any decent >item(s) at the end. Therefore a player normally does not bother to clear >such a map again. Besides that, I do not have any problem with tuning up >some maps if the ratio reward (exp+items) per work (necessary >time+danger) is reasonable. > > Indeed, as I have mentioned somewhere here before, this issue, especially in high level maps, is what inspired me to begin one map I'm currently making. >>To summarize my points, I feel this is almost as much of a problem >>with the non-random maps as it is a problem of the random maps. >> >> >I agree. But fixing the random maps is much easier than fixing the >non-random ones. Therefore we should start with the random ones... > Very true, though I think that people making non-random maps should try to be aware of this. Alex Schultz From temitchell at sympatico.ca Tue May 31 21:32:09 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Tue May 31 21:32:18 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: <20050531192028.GA21551@kirschbaum.myrealbox.com> References: <20050528075642.GA17903@kirschbaum.myrealbox.com> <4298AFE4.5080504@telus.net> <3539.202.106.20.66.1117328845.squirrel@webmail.laranja.org> <429939A4.5050907@sonic.net> <20050529190418.GA25400@kirschbaum.myrealbox.com> <429A50BF.10608@sonic.net> <20050531192028.GA21551@kirschbaum.myrealbox.com> Message-ID: <429D1E29.5020000@sympatico.ca> monster density - I think part of the problem with the monster density is that terrain is either blocked or not. It would be different if you had more types of blocking terrain which would prevent the MOB crowd effect. Having to run around barriers to get at monsters lobbing missiles over them would add some quick difficulty to random maps. In built maps this can be constructed but random maps are very prone to monster density issues and this is a result of the combat/movement system. Adding things like half walls, holes and water (or even spell shields) to random maps would allow the inclusion of some different tatical combinations in the styles. Boss monsters - good idea One point - the random map styles are very ripe for development and adjustment. This alone would really improve the random maps and allow more control - especially with the difficulty stepping code that was recently added. From alex_sch at telus.net Tue May 31 23:43:48 2005 From: alex_sch at telus.net (Alex Schultz) Date: Tue May 31 23:44:20 2005 Subject: [crossfire] Python bindings and forces Message-ID: <429D3D04.2020902@telus.net> Hi, Today I was tring to extend the "CreateInvisibleObjectInside" function in the python bindings to also allow limited duration forces to be created in the same manner that markers can do that. So I attempted to add another optional parameter to allow the duration to set (in the same measurement as the food parameter of marker objects). However when I try to call it with: force = CFPython.CreateInvisibleObjectInside(activator, forcename, 1.00) the script crashes with: TypeError: function takes exactly 2 arguments (3 given) I've attached the modifications that I've tried to make to it here. Anybody have any ideas? Thanks, Alex Schultz -------------- next part -------------- A non-text attachment was scrubbed... Name: marker.diff Type: text/x-patch Size: 3677 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050531/a8c37766/marker.bin