From kirschbaum at myrealbox.com Wed Jun 1 00:58:21 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Wed Jun 1 01:00:21 2005 Subject: [crossfire] include/living.h in crossfire In-Reply-To: <20050531191855.290871B09E71F@sammakko.yok.utu.fi> References: <20050531191855.290871B09E71F@sammakko.yok.utu.fi> Message-ID: <20050601055820.GA23718@kirschbaum.myrealbox.com> Applied to CVS. From kirschbaum at myrealbox.com Wed Jun 1 01:19:36 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Wed Jun 1 01:20:21 2005 Subject: [crossfire] client: another useless variable declaration in gtk/gx11.h In-Reply-To: <20050531220309.40A4C1C520B65@sammakko.yok.utu.fi> References: <20050531220309.40A4C1C520B65@sammakko.yok.utu.fi> Message-ID: <20050601061936.GB23718@kirschbaum.myrealbox.com> Fixed in CVS. From mwedel at sonic.net Wed Jun 1 01:24:24 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Jun 1 01:24:21 2005 Subject: [crossfire] Python bindings and forces In-Reply-To: <429D3D04.2020902@telus.net> References: <429D3D04.2020902@telus.net> Message-ID: <429D5498.9010404@sonic.net> I'm not sure, since I haven't played with the python stuff much. But one thing to be aware - the python code is in a plugin shared library, and the server loads that library from someplace where prefix points to. So if you do what I often do, which is run the server directory from the build directory and don't run make install, you'll continue to have the old plugin code until you do a make install. One other note on your change - if you are modifying the object speed, you need to add a call to update_ob_speed, otherwise the object won't be processed and do anything. Alex Schultz wrote: > 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 > > > > ------------------------------------------------------------------------ > > Index: plugin/plugin_python.c > =================================================================== > RCS file: /cvsroot/crossfire/crossfire/plugin/plugin_python.c,v > retrieving revision 1.62 > diff -C10 -r1.62 plugin_python.c > *** plugin/plugin_python.c 20 May 2005 19:28:02 -0000 1.62 > --- plugin/plugin_python.c 1 Jun 2005 04:28:48 -0000 > *************** > *** 2362,2413 **** > { > if(tmp2->type == FORCE && tmp2->slaying && !strcmp(tmp2->slaying,id)) > break; > }; > > return Py_BuildValue("l",(long)(tmp2)); > }; > > /*****************************************************************************/ > /* Name : CFCreateInvisibleObjectInside */ > ! /* Python : CFPython.CreateInvisibleObjectInside(object,string) */ > /*****************************************************************************/ > static PyObject* CFCreateInvisibleObjectInside(PyObject* self, PyObject* args) > { > long whereptr; > char* txt; > char txt2[6]; > object *myob; > object *where; > CFParm* CFR; > > ! if (!PyArg_ParseTuple(args,"ls",&whereptr,&txt)) > return NULL; > > CHECK_OBJ(whereptr); > > where = (object *)(whereptr); > > strcpy(txt2,"force"); > > GCFP.Value[0] = (void *)(txt2); > CFR = (PlugHooks[HOOK_GETARCHETYPE])(&GCFP); > myob = (object *)(CFR->Value[0]); > PyFreeMemory( CFR ); > > if(strncmp(query_name(myob), "singluarity", 11) == 0) > { > PyFreeObject(myob); > set_exception("can't find archetype 'force'"); > return NULL; > } > ! myob->speed = 0.0; > GCFP.Value[0] = (void *)(myob); > (PlugHooks[HOOK_UPDATESPEED])(&GCFP); > > if (myob->slaying != NULL) > DELETE_STRING(myob->slaying); > myob->slaying = add_string(txt); > myob = insert_ob_in_ob(myob, where); > > GCFP.Value[0] = (void *)(where); > GCFP.Value[1] = (void *)(myob); > --- 2366,2422 ---- > { > if(tmp2->type == FORCE && tmp2->slaying && !strcmp(tmp2->slaying,id)) > break; > }; > > return Py_BuildValue("l",(long)(tmp2)); > }; > > /*****************************************************************************/ > /* Name : CFCreateInvisibleObjectInside */ > ! /* Python : CFPython.CreateInvisibleObjectInside(object,string[,food]) */ > /*****************************************************************************/ > static PyObject* CFCreateInvisibleObjectInside(PyObject* self, PyObject* args) > { > long whereptr; > char* txt; > char txt2[6]; > + double lspeed = 0; > object *myob; > object *where; > CFParm* CFR; > > ! if (!PyArg_ParseTuple(args,"ls|d",&whereptr,&txt,&lspeed)) > return NULL; > > CHECK_OBJ(whereptr); > > where = (object *)(whereptr); > > strcpy(txt2,"force"); > > GCFP.Value[0] = (void *)(txt2); > CFR = (PlugHooks[HOOK_GETARCHETYPE])(&GCFP); > myob = (object *)(CFR->Value[0]); > PyFreeMemory( CFR ); > > if(strncmp(query_name(myob), "singluarity", 11) == 0) > { > PyFreeObject(myob); > set_exception("can't find archetype 'force'"); > return NULL; > } > ! myob->speed = 0; > ! if (lspeed) { > ! myob->speed = 0.01; > ! myob->speed_left = -(lspeed); > ! } > GCFP.Value[0] = (void *)(myob); > (PlugHooks[HOOK_UPDATESPEED])(&GCFP); > > if (myob->slaying != NULL) > DELETE_STRING(myob->slaying); > myob->slaying = add_string(txt); > myob = insert_ob_in_ob(myob, where); > > GCFP.Value[0] = (void *)(where); > GCFP.Value[1] = (void *)(myob); > > > ------------------------------------------------------------------------ > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From alex_sch at telus.net Wed Jun 1 01:35:08 2005 From: alex_sch at telus.net (Alex Schultz) Date: Wed Jun 1 01:35:31 2005 Subject: [crossfire] Python bindings and forces In-Reply-To: <429D5498.9010404@sonic.net> References: <429D3D04.2020902@telus.net> <429D5498.9010404@sonic.net> Message-ID: <429D571C.9020408@telus.net> Mark Wedel wrote: > I'm not sure, since I haven't played with the python stuff much. > > But one thing to be aware - the python code is in a plugin shared > library, and the server loads that library from someplace where prefix > points to. > > So if you do what I often do, which is run the server directory from > the build directory and don't run make install, you'll continue to > have the old plugin code until you do a make install. I am doing a full "make && make install" when I'm doing this > > One other note on your change - if you are modifying the object > speed, you need to add a call to update_ob_speed, otherwise the object > won't be processed and do anything. The existing code in "CreateInvisibleObjectInside" already calls update_op_speed and I haven't changed that. From what I can tell, the issue has to do with usage of "PyArg_ParseTuple", but I'm not sure. From kirschbaum at myrealbox.com Wed Jun 1 03:22:23 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Wed Jun 1 03:24:22 2005 Subject: [crossfire] client: Mismatch in man page dir and section In-Reply-To: <20050531222909.683B71C520B69@sammakko.yok.utu.fi> References: <20050531222909.683B71C520B69@sammakko.yok.utu.fi> Message-ID: <20050601082223.GC23718@kirschbaum.myrealbox.com> Fixed in CVS. From kirschbaum at myrealbox.com Wed Jun 1 12:51:35 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Wed Jun 1 12:52:28 2005 Subject: [crossfire] Python bindings and forces In-Reply-To: <429D3D04.2020902@telus.net> References: <429D3D04.2020902@telus.net> Message-ID: <20050601175134.GA32226@kirschbaum.myrealbox.com> Alex Schultz wrote: > 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? It works as intended for me: I can call the modified function with either two or three arguments. The two argument one creates a permanent, the three argument one a temporary force. Maybe Mark was right and your "make install" did not work? Or maybe you did not restart your server? From kari at sammakko.yok.utu.fi Wed Jun 1 22:13:08 2005 From: kari at sammakko.yok.utu.fi (Kari Pahula) Date: Wed Jun 1 22:14:34 2005 Subject: [crossfire] Remember to replace config.{sub,guess} for releases Message-ID: <20050602031308.4058F1B54A483@sammakko.yok.utu.fi> The config.sub and config.guess files are used by configure to determine architecture depentand features of the system. The autotools don't replace them themselves, but you have to update them yourself from time to time. The current config.sub and config.guess files in crossfire date back to 2001-09-07 and client's files are from 2003-06-18. It would be a good idea to replace them for the next release. From handphone at gmail.com Wed Jun 1 22:50:20 2005 From: handphone at gmail.com (Neon Lim) Date: Wed Jun 1 22:50:34 2005 Subject: [crossfire] [cross] generating html guide Message-ID: <1124ed9005060120504c06ef84@mail.gmail.com> Hi, I finally know how to generate html guide of cross by someone giving me hint at irc. cd into /doc/spoiler-html/ make archive However, there are some problems. make archive is suppose to generate various html of monster, spells, etc. But in the linux server distribution of crossfire-1.7.0, after i run the command, it cant find spellist.h in the include directory. And many images are not generated. i have the /lib/arch installed. After checking in the /doc/scripts/monster.pl , the code seems correct, it is suppose to read the graphics file ***.base.111.png , etc. at the lib/arch/monster directory. But when running the make archive, it tried to read ***.111.png , without the base... therefore causing reading error file not found and generate 0 byte .gif Can anyone advise on how to solve the broken image problem? Or is that html guide generating script having problem? Thanks. From mwedel at sonic.net Thu Jun 2 01:46:48 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jun 2 01:46:36 2005 Subject: [crossfire] [cross] generating html guide In-Reply-To: <1124ed9005060120504c06ef84@mail.gmail.com> References: <1124ed9005060120504c06ef84@mail.gmail.com> Message-ID: <429EAB58.9030106@sonic.net> Neon Lim wrote: > Hi, > > I finally know how to generate html guide of cross by someone giving > me hint at irc. > > cd into /doc/spoiler-html/ > > make archive make spoiler.html is the more proper command in this case. > > However, there are some problems. make archive is suppose to generate > various html of monster, spells, etc. But in the linux server > distribution of crossfire-1.7.0, after i run the command, it cant find > spellist.h in the include directory. yes - it appears the spoiler generation was never updated for the new spell logic. > > And many images are not generated. > > i have the /lib/arch installed. > > After checking in the /doc/scripts/monster.pl , the code seems > correct, it is suppose to read the graphics file ***.base.111.png , > etc. at the lib/arch/monster directory. > > But when running the make archive, it tried to read ***.111.png , > without the base... therefore causing reading error file not found and > generate 0 byte .gif > > > Can anyone advise on how to solve the broken image problem? Or is that > html guide generating script having problem? make archive is meant to pack up all the generated data into a tar archive. If you haven't made the files first, via the make spoiler.html, it won't have the stuff to pack up. I just tried it - there were some errors generating some of the images, but this appered to be more a problem with perhaps the pngtopnm program not liking the original files, vs path problem. From alex_sch at telus.net Thu Jun 2 01:51:30 2005 From: alex_sch at telus.net (Alex Schultz) Date: Thu Jun 2 01:52:48 2005 Subject: [crossfire] Spellcasting Swords progress In-Reply-To: <20050601175134.GA32226@kirschbaum.myrealbox.com> References: <429D3D04.2020902@telus.net> <20050601175134.GA32226@kirschbaum.myrealbox.com> Message-ID: <429EAC72.2010207@telus.net> Andreas Kirschbaum wrote: >Alex Schultz wrote: > >>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. >> >It works as intended for me: I can call the modified fuction with >either two or three arguments. The two argument one creates a permanent, >the three argument one a temporary force. > >Maybe Mark was right and your "make install" did not work? Or maybe you >did not restart your server? > I remembered those, but it turns out it wasn't installing the new plugin_python.so for some reason. Anyways, that's fixed now (for no apparent reason, but oh well), however theres one issue I'm having when I try make some archtypes using them; In order to store the spell data, I need to insert a rod in the object's inventory. The first try I did of that was embedding it in the arch like one can do with maps, but that didn't work. Then I tried by making treasurelists for the rods, however they failed to keep spell data that I embedded in the treasurelist. I know that using treasurelists, and at the same time making custom rod arches for each of the spellswords would work, however I don't see that as being a very clean solution. Anybody have any better suggestions? Thanks, Alex Schultz From mwedel at sonic.net Thu Jun 2 01:55:23 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jun 2 01:55:35 2005 Subject: [crossfire] gmane In-Reply-To: <38014.221.122.43.98.1117259972.squirrel@webmail.laranja.org> References: <38014.221.122.43.98.1117259972.squirrel@webmail.laranja.org> Message-ID: <429EAD5B.2070202@sonic.net> Lalo Martins wrote: > 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. I don't see a problem. I suppose if some problem does show up, we can always remove it from gmane at that point. I believe that even as right now, the mailing lists are publically archived on the web, so I can't see that the increased visibility should cause any problems. From mwedel at sonic.net Thu Jun 2 01:57:55 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jun 2 01:56:36 2005 Subject: [crossfire] .desktop file for client is not installed with "make install" In-Reply-To: References: Message-ID: <429EADF3.8010303@sonic.net> Andrew Fuchs wrote: > 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. > Most likely is that the gtk/Makefile.in doesn't have any line like datadir=@datadir@ for configure to set the appropriate value. Configure will substitute hundreds of @...@ variables. The makefiles are generally set up to only set those they actually need. In the past, the makefile within the gtk directory did not need this. If you look at the top level makefile (really, makefile.in), it does set this. From mwedel at sonic.net Thu Jun 2 01:59:04 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jun 2 01:59:56 2005 Subject: [crossfire] Extending apply commands In-Reply-To: <20050529000252.GA7869@localhost.localdomain> References: <20050428230607.GA6101@localhost.localdomain> <4273223D.6030009@sonic.net> <20050430082206.GA4528@localhost.localdomain> <20050529000252.GA7869@localhost.localdomain> Message-ID: <429EAE38.2090504@sonic.net> Kevin Rudat wrote: > 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? I'd suggest you put it in all of them to be safe, however, in theory, it should be sufficient to just put them in the head object - if that doesn't work, then code needs to be fixed (in general, there shouldn't be need to put the values in every part of the object) From mwedel at sonic.net Thu Jun 2 02:01:43 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jun 2 02:00:26 2005 Subject: [crossfire] No autogen.sh for the client? In-Reply-To: <200505292020.27980.tchize@myrealbox.com> References: <200505292020.27980.tchize@myrealbox.com> Message-ID: <429EAED7.1050302@sonic.net> tchize wrote: > 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. the other reason is that until the addition of the gtk-v2 portion of the code, the only 'auto' command to run for the client was autoconf (and perhaps aclocal) - certainly a small enough set of tools that anyone doing it could figure out those command on their own. Since the gtk-v2 client does use automake, probably makes sense to put in an autogen file, but even then, only 'serious' developers should really need it, and hopefully they know what commands they need to run anyways. From mwedel at sonic.net Thu Jun 2 02:03:56 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jun 2 02:04:41 2005 Subject: [crossfire] ingame music In-Reply-To: <200505302110.07811.tchize@myrealbox.com> References: <200505302110.07811.tchize@myrealbox.com> Message-ID: <429EAF5C.7010107@sonic.net> tchize wrote: > 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 > The obvious question for this is how to handle it. Would it be sufficient to have map wide values of 'music' to play, such that we just need to add a value to the map header? Or do people see the need/desire that they may want different music depending where on the map they are? I'd separate this discussion from that of background or other noises, of which those should be tied to objects. But something like this music wouldn't seem to be tied to any specific object. From mwedel at sonic.net Thu Jun 2 02:08:00 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jun 2 02:06:05 2005 Subject: [crossfire] Spellcasting Swords progress In-Reply-To: <429EAC72.2010207@telus.net> References: <429D3D04.2020902@telus.net> <20050601175134.GA32226@kirschbaum.myrealbox.com> <429EAC72.2010207@telus.net> Message-ID: <429EB050.3030108@sonic.net> Alex Schultz wrote: > I remembered those, but it turns out it wasn't installing the new > plugin_python.so for some reason. Anyways, that's fixed now (for no > apparent reason, but oh well), however theres one issue I'm having when > I try make some archtypes using them; In order to store the spell data, > I need to insert a rod in the object's inventory. The first try I did of > that was embedding it in the arch like one can do with maps, but that > didn't work. Then I tried by making treasurelists for the rods, however > they failed to keep spell data that I embedded in the treasurelist. > I know that using treasurelists, and at the same time making custom rod > arches for each of the spellswords would work, however I don't see that > as being a very clean solution. Anybody have any better suggestions? Can you be a little clearer? Are you trying to insert a rod into the sword, and a spell into the rod? Which part of the object is being lost? The spell into the rod? How is the rod being created? Treasurelists are only created/processed for specific events. If you just do something like 'arch_to_object(...)', it won't do anything with treasurelists - you need to call create_treasures to do that. In the case of some specific objects, this processing is done automatically. But if you're trying to put a sword on a map, I'm not sure if the full recursion is handled properly. But I need a little clearer picture on this. From alex_sch at telus.net Thu Jun 2 02:18:14 2005 From: alex_sch at telus.net (Alex Schultz) Date: Thu Jun 2 02:18:37 2005 Subject: [crossfire] Spellcasting Swords progress In-Reply-To: <429EB050.3030108@sonic.net> References: <429D3D04.2020902@telus.net> <20050601175134.GA32226@kirschbaum.myrealbox.com> <429EAC72.2010207@telus.net> <429EB050.3030108@sonic.net> Message-ID: <429EB2B6.9010806@telus.net> Mark Wedel wrote: > Alex Schultz wrote: > >> I remembered those, but it turns out it wasn't installing the new >> plugin_python.so for some reason. Anyways, that's fixed now (for no >> apparent reason, but oh well), however theres one issue I'm having >> when I try make some archtypes using them; In order to store the >> spell data, I need to insert a rod in the object's inventory. The >> first try I did of that was embedding it in the arch like one can do >> with maps, but that didn't work. Then I tried by making treasurelists >> for the rods, however they failed to keep spell data that I embedded >> in the treasurelist. >> I know that using treasurelists, and at the same time making custom >> rod arches for each of the spellswords would work, however I don't >> see that as being a very clean solution. Anybody have any better >> suggestions? > > > Can you be a little clearer? Are you trying to insert a rod into the > sword, and a spell into the rod? I'm trying to insert a rod into the sword, where the rod has a spell in it (I've usually done that with the old style spell numbers in my tests which the server seems to nicely convert). For example, I make the following treasurelist which is in the "randomitems" of the sword arch: treasureone katanafire arch rod_light sp 82 level 15 hp 50 maxhp 50 no_drop 1 no_pickup 1 startequip 1 chance 100 end > Which part of the object is being lost? The spell into the rod? How > is the rod being created? Everything about the rod is being lost except it's archtype and the defaults of that (it loses the spell, spellpoints, no_drop etc.) > Treasurelists are only created/processed for specific events. If > you just do something like 'arch_to_object(...)', it won't do anything > with treasurelists - you need to call create_treasures to do that. > > In the case of some specific objects, this processing is done > automatically. But if you're trying to put a sword on a map, I'm not > sure if the full recursion is handled properly. But I need a little > clearer picture on this. I tested it putting the sword on a map and that works except for the above mentioned information loss. However when I tested it by using the DM "create" command, the randomitems were not obeyed. I assume this information loss is because the treasurelists don't accept such data and only use the defaults of the arch, so one solution would be creating an arch for each rod that I want to use on the swords, however I feel that would be a bit kludgy, and I am wondering if anybody has any better solutions. Alex Schultz From mwedel at sonic.net Thu Jun 2 02:20:59 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jun 2 02:22:36 2005 Subject: [crossfire] new metaserver In-Reply-To: <200505291525.02695.tchize@myrealbox.com> References: <20050527164327.19615.qmail@web61021.mail.yahoo.com> <200505291525.02695.tchize@myrealbox.com> Message-ID: <429EB35B.9020000@sonic.net> I was thinking about this metaserver some more, and had some various thoughts. 1) Has someone agreed to run the metametaserver? What about the slave metaservers? While all this looks nice, if you don't have people willing to run it/take care of it, it is all pretty pointless. For the metametaserver, I'm thinking more of the Tanner's, since they currently hold the main crossfire home page, but of course, the metametaserver could move someplace else (not as sure how many people have as stable and ip address and network connection that they do). 2) having the clients connect to the various servers to get stats like current number of active players is IMO an extra level of complication that can be done without. If we have a dozen active servers (which was actually low if I recall), you probably don't want to do it sequentially - that means it coudl take a significant amount of time to go through them all. Especially if one is down or unresponsive. this means you need to do it in parallel, and writing that threaded code is a bit more complicated. Add to the fact that the client would then have to send some commands and parses the responses from the server. I just don't see any reason that dynamic info shouldn't be included. 3) I'd much rather have a simpler approach than something really complicated for many reasons. The current approach seems to be going towards the overly complicated approach. 4) Has anyone considered the approach where all the servers talk to the metametaserver (lets call it the master metaserver), and all the metaservers just regularly pull updates from the master metaserver? And we disallows directy client queries to the master metaserver (basically, it will only allow queries from the client metaservers)? This goes to #3, where it seems to be a much simpler approach. And it is only slightly less resilent then the proposals I've seen. In this approach, if the master metaserver is down, the clients just use the last copy of the data they have. But at least all the client metasevers are sure to have the same data. Just some thoughts. I'd probably still be good to rewrite the metaserver logic, but IMO, having the servers talk to web servers is an extra complication - pretty much all metaservers that are out there (certainly netrek at a minimum) use their own protocol for the servers to update the metaserver. From tchize at myrealbox.com Thu Jun 2 02:47:18 2005 From: tchize at myrealbox.com (tchize) Date: Thu Jun 2 02:46:37 2005 Subject: [crossfire] No autogen.sh for the client? In-Reply-To: <429EAED7.1050302@sonic.net> References: <200505292020.27980.tchize@myrealbox.com> <429EAED7.1050302@sonic.net> Message-ID: <200506020947.18192.tchize@myrealbox.com> Le Jeudi 2 Juin 2005 09:01, Mark Wedel a ?crit : > tchize wrote: > > 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. > > the other reason is that until the addition of the gtk-v2 portion of the > code, the only 'auto' command to run for the client was autoconf (and > perhaps aclocal) - certainly a small enough set of tools that anyone doing > it could figure out those command on their own. > > Since the gtk-v2 client does use automake, probably makes sense to put in > an autogen file, but even then, only 'serious' developers should really > need it, and hopefully they know what commands they need to run anyways. > > Speaking about automake. Since a few week i noticed each time i do a commit, all the Makefile.in are commited along. Did someone change the configure script to regenerate automake.in file each time a ./configure is run? If that's the case, maybe removing Makefile.in files from cvs would be a good think (if they became machine dependent, there is no reason to keep them in CVS) > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From tchize at myrealbox.com Thu Jun 2 02:48:04 2005 From: tchize at myrealbox.com (tchize) Date: Thu Jun 2 02:50:51 2005 Subject: [crossfire] new metaserver In-Reply-To: <429EB35B.9020000@sonic.net> References: <20050527164327.19615.qmail@web61021.mail.yahoo.com> <200505291525.02695.tchize@myrealbox.com> <429EB35B.9020000@sonic.net> Message-ID: <200506020948.04549.tchize@myrealbox.com> Le Jeudi 2 Juin 2005 09:20, Mark Wedel a ?crit : > I was thinking about this metaserver some more, and had some various > thoughts. > > 1) Has someone agreed to run the metametaserver? What about the slave > metaservers? While all this looks nice, if you don't have people willing > to run it/take care of it, it is all pretty pointless. For the > metametaserver, I'm thinking more of the Tanner's, since they currently > hold the main crossfire home page, but of course, the metametaserver could > move someplace else (not as sure how many people have as stable and ip > address and network connection that they do). That's were a static list on various website is usefull, easy to place (crossfire.sourceforge.net could be a place to hold the list) > > 2) having the clients connect to the various servers to get stats like > current number of active players is IMO an extra level of complication that > can be done without. If we have a dozen active servers (which was actually > low if I recall), you probably don't want to do it sequentially - that > means it coudl take a significant amount of time to go through them all. > Especially if one is down or unresponsive. this means you need to do it in > parallel, and writing that threaded code is a bit more complicated. Add to > the fact that the client would then have to send some commands and parses > the responses from the server. I just don't see any reason that dynamic > info shouldn't be included. could be done in udp (send a packet to each server than wait 2 second for any response) > > 3) I'd much rather have a simpler approach than something really > complicated for many reasons. The current approach seems to be going > towards the overly complicated approach. probably > > 4) Has anyone considered the approach where all the servers talk to the > metametaserver (lets call it the master metaserver), and all the > metaservers just regularly pull updates from the master metaserver? And we > disallows directy client queries to the master metaserver (basically, it > will only allow queries from the client metaservers)? This goes to #3, > where it seems to be a much simpler approach. And it is only slightly less > resilent then the proposals I've seen. In this approach, if the master > metaserver is down, the clients just use the last copy of the data they > have. But at least all the client metasevers are sure to have the same > data. Could you rephrase it, am not sure to understand (i think there is a mix between master server clients and game clients) > > Just some thoughts. I'd probably still be good to rewrite the metaserver > logic, but IMO, having the servers talk to web servers is an extra > complication - pretty much all metaservers that are out there (certainly > netrek at a minimum) use their own protocol for the servers to update the > metaserver. > I was proposing something that could be run without special servers. A static list anyone could mirror on their isp personal web page. Anyway, if it's possible to have at least 3 or 4 mirrors using a metaserver dedicated protocol, why not. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -- David Delbecq Royal Meteorological Institute of Belgium - Is there life after /sbin/halt -p? From lalo at laranja.org Thu Jun 2 04:15:24 2005 From: lalo at laranja.org (Lalo Martins) Date: Thu Jun 2 04:18:53 2005 Subject: [crossfire] gmane In-Reply-To: <429EAD5B.2070202@sonic.net> References: <38014.221.122.43.98.1117259972.squirrel@webmail.laranja.org> <429EAD5B.2070202@sonic.net> Message-ID: <51134.221.122.43.98.1117703724.squirrel@webmail.laranja.org> Ok, I submitted crossfire, -cvs and -maps to be respectively gmane.games.crossfire, gmane.games.crossfire.cvs, gmane.games.crossfire.maps. We should hear back from them in a few days (depending on how swamped they are). 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 kari at sammakko.yok.utu.fi Thu Jun 2 08:06:51 2005 From: kari at sammakko.yok.utu.fi (Kari Pahula) Date: Thu Jun 2 08:08:39 2005 Subject: [crossfire] license problem with file lib/adm/map_check Message-ID: <20050602130651.B102D1B54A480@sammakko.yok.utu.fi> This was already discussed on irc, but for record, I'll repeat this to the mailing list too. File lib/adm/map_check in crossfire has the following license: #!/usr/bin/perl # # (C) Copyright Markus Weber, 1994. All rights reserved. # Permission is granted to use, copy, and modify for non-commercial use. # I'm not aware of crossfire's licence policy, but at least Debian requires that all parts of the programs are usable, copiable and modifiable for commercial use too. I noticed this so close to the sarge's release that the release manager told me to either get this fixed in a few hours or have crossfire-server dropped from it. Crossfire tarballs are now repackaged in Debian to exclude this file. Apparently nothing else used this script, it was just there available in case the user wanted to use it directly. From fuchs.andy at gmail.com Thu Jun 2 14:07:23 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Thu Jun 2 14:08:43 2005 Subject: [crossfire] ingame music In-Reply-To: <429EAF5C.7010107@sonic.net> References: <200505302110.07811.tchize@myrealbox.com> <429EAF5C.7010107@sonic.net> Message-ID: On 6/2/05, Mark Wedel wrote: > The obvious question for this is how to handle it. > > Would it be sufficient to have map wide values of 'music' to play, such that > we just need to add a value to the map header? Or do people see the need/desire > that they may want different music depending where on the map they are? > > I'd separate this discussion from that of background or other noises, of which > those should be tied to objects. But something like this music wouldn't seem to > be tied to any specific object. Yes, having the value in the map header is mainly what is needed, though hijacking the lighting code would be the way to go for connecting it to specific objects. There is also the posibility of adding fields to triger sounds when items are applied (not hard coded like the current system). -- -- Andrew Fuchs From fuchs.andy at gmail.com Thu Jun 2 14:17:23 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Thu Jun 2 14:18:42 2005 Subject: [crossfire] Spellcasting Swords progress In-Reply-To: <429EB2B6.9010806@telus.net> References: <429D3D04.2020902@telus.net> <20050601175134.GA32226@kirschbaum.myrealbox.com> <429EAC72.2010207@telus.net> <429EB050.3030108@sonic.net> <429EB2B6.9010806@telus.net> Message-ID: On 6/2/05, Alex Schultz wrote: > I tested it putting the sword on a map and that works except for the > above mentioned information loss. However when I tested it by using the > DM "create" command, the randomitems were not obeyed. > > I assume this information loss is because the treasurelists don't accept > such data and only use the defaults of the arch, so one solution would > be creating an arch for each rod that I want to use on the swords, > however I feel that would be a bit kludgy, and I am wondering if anybody > has any better solutions. I the file "/lib/artifacts" in the server branch takes care of the modifiers for objects. Though, IMO this still is not very clean. -- -- Andrew Fuchs From fuchs.andy at gmail.com Thu Jun 2 14:39:45 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Thu Jun 2 14:40:42 2005 Subject: [crossfire] new metaserver In-Reply-To: <200506020948.04549.tchize@myrealbox.com> References: <20050527164327.19615.qmail@web61021.mail.yahoo.com> <200505291525.02695.tchize@myrealbox.com> <429EB35B.9020000@sonic.net> <200506020948.04549.tchize@myrealbox.com> Message-ID: Mark Wedel Wrote: > I was thinking about this metaserver some more, and had some various > thoughts. > > 1) Has someone agreed to run the metametaserver? What about the slave > metaservers? While all this looks nice, if you don't have people willing > to run it/take care of it, it is all pretty pointless. For the > metametaserver, I'm thinking more of the Tanner's, since they currently > hold the main crossfire home page, but of course, the metametaserver could > move someplace else (not as sure how many people have as stable and ip > address and network connection that they do). As I discused on irc, I may be able to host one of the metaservers, pending the purchase of new hardware. > Just some thoughts. I'd probably still be good to rewrite the metaserver > logic, but IMO, having the servers talk to web servers is an extra complication > - pretty much all metaservers that are out there (certainly netrek at a minimum) > use their own protocol for the servers to update the metaserver. http is simple imo afaik the header can be thrown away, except for any error codes included in it. -- -- Andrew Fuchs -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050602/001a5b12/attachment.html From alex_sch at telus.net Thu Jun 2 18:04:57 2005 From: alex_sch at telus.net (Alex Schultz) Date: Thu Jun 2 18:06:45 2005 Subject: [crossfire] Spellcasting Swords progress In-Reply-To: References: <429D3D04.2020902@telus.net> <20050601175134.GA32226@kirschbaum.myrealbox.com> <429EAC72.2010207@telus.net> <429EB050.3030108@sonic.net> <429EB2B6.9010806@telus.net> Message-ID: <429F9099.1080807@telus.net> Andrew Fuchs wrote: >On 6/2/05, Alex Schultz wrote: > >>I tested it putting the sword on a map and that works except for the >>above mentioned information loss. However when I tested it by using the >>DM "create" command, the randomitems were not obeyed. >> >>I assume this information loss is because the treasurelists don't accept >>such data and only use the defaults of the arch, so one solution would >>be creating an arch for each rod that I want to use on the swords, >>however I feel that would be a bit kludgy, and I am wondering if anybody >>has any better solutions. >> > >I the file "/lib/artifacts" in the server branch takes care of the >modifiers for objects. >Though, IMO this still is not very clean. > However the problem is that unless I'm missing something, there is no way to insert something made from the artifacts file into the inventory of an arch by default. This doesn't prevent what I mentioned above about creating an arch for every rod that I want to make a spellcasting sword with, however IMO that's way too much of a dirty hack. Unless somebody has a better solution, I might try and make it possible to nest objects inside others in arches just like one can already do in maps. Thanks, Alex Schultz From B.T.Lally at warwick.ac.uk Thu Jun 2 20:01:44 2005 From: B.T.Lally at warwick.ac.uk (Brendan Lally) Date: Thu Jun 2 20:02:46 2005 Subject: [crossfire] new metaserver Message-ID: >>> mwedel@sonic.net 06/02/05 08:23 AM >>> > 1) Has someone agreed to run the metametaserver? What about the slave > metaservers? I can host one, maybe two, but this assumes the use of HTTP. > 4) Has anyone considered the approach where all the servers talk to the > metametaserver (lets call it the master metaserver), and all the metaservers > just regularly pull updates from the master metaserver? That is pretty much what I have been doing, except with all metaservers being 'passive' and without the metametaserver being protected. > Just some thoughts. I'd probably still be good to rewrite the metaserver >logic, but IMO, having the servers talk to web servers is an extra complication >- pretty much all metaservers that are out there (certainly netrek at a minimum) > use their own protocol for the servers to update the metaserver. I know that freeciv uses HTTP POSTs to send data to its metaserver. As it is HTTP is simpler, there are libraries (libcurl) that make it easier than dealing with sockets directly, and when there is a web server sitting in the middle then issues like threading, locking and blocking are dealt with automagically. Web servers often can behefit from things like caching also, and it may be possible to get compression for free too (I haven't looked into mod_gzip in detail yet). It is also far easier to find places to host. From mwedel at sonic.net Thu Jun 2 23:17:35 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jun 2 23:16:48 2005 Subject: [crossfire] No autogen.sh for the client? In-Reply-To: <200506020947.18192.tchize@myrealbox.com> References: <200505292020.27980.tchize@myrealbox.com> <429EAED7.1050302@sonic.net> <200506020947.18192.tchize@myrealbox.com> Message-ID: <429FD9DF.5020501@sonic.net> tchize wrote: > > Speaking about automake. > > Since a few week i noticed each time i do a commit, all the Makefile.in are > commited along. Did someone change the configure script to regenerate > automake.in file each time a ./configure is run? If that's the case, maybe > removing Makefile.in files from cvs would be a good think (if they became > machine dependent, there is no reason to keep them in CVS) Some file is out of sync, so it keeps re-running automake. One would normally thing this should correct itself once the up to date ones are committed. Maybe something that the makefiles depend on was committed with a bogus date. The rationale for having the Makefile.in's in CVS is to make it easier for users to grab snapshots and not need a large set of tools. Ideally, this dependency should get fixed up somehow so that it doesn't re-run automake every time. From mwedel at sonic.net Thu Jun 2 23:20:27 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jun 2 23:20:48 2005 Subject: [crossfire] ingame music In-Reply-To: References: <200505302110.07811.tchize@myrealbox.com> <429EAF5C.7010107@sonic.net> Message-ID: <429FDA8B.5000302@sonic.net> Andrew Fuchs wrote: > On 6/2/05, Mark Wedel wrote: > >> The obvious question for this is how to handle it. >> >> Would it be sufficient to have map wide values of 'music' to play, such that >>we just need to add a value to the map header? Or do people see the need/desire >>that they may want different music depending where on the map they are? >> >> I'd separate this discussion from that of background or other noises, of which >>those should be tied to objects. But something like this music wouldn't seem to >>be tied to any specific object. > > > Yes, having the value in the map header is mainly what is needed, > though hijacking the lighting code would be the way to go for > connecting it to specific objects. Perhaps, but not positive if that will work. Lighting is just a single value. If you try to hijack that code for music, you will get cases of two sources overlapping, so that single value doesn't work - you then need to store both sources or figure out which is louder or something. > > There is also the posibility of adding fields to triger sounds when > items are applied (not hard coded like the current system). Yes, and that is on the TODO list. But that is seperate from music, because those are mostly going to be things that get played as direct result of actions and not persist in the background for ever (although there are perhaps some sounds that should). From mikeeusaaa at yahoo.com Thu Jun 2 23:39:31 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Thu Jun 2 23:40:49 2005 Subject: [crossfire] new metaserver In-Reply-To: Message-ID: <20050603043931.83959.qmail@web61020.mail.yahoo.com> I can also host a slave metaserver. --- Brendan Lally wrote: > >>> mwedel@sonic.net 06/02/05 08:23 AM >>> > > > 1) Has someone agreed to run the metametaserver? > What about the slave > > metaservers? > > I can host one, maybe two, but this assumes the use > of HTTP. > > > 4) Has anyone considered the approach where all > the servers talk to the > > metametaserver (lets call it the master > metaserver), and all the metaservers > > just regularly pull updates from the master > metaserver? > > That is pretty much what I have been doing, except > with all metaservers being 'passive' and without the > metametaserver being protected. > > > Just some thoughts. I'd probably still be good > to rewrite the metaserver > >logic, but IMO, having the servers talk to web > servers is an extra complication > >- pretty much all metaservers that are out there > (certainly netrek at a minimum) > > use their own protocol for the servers to update > the metaserver. > > I know that freeciv uses HTTP POSTs to send data to > its metaserver. > > As it is HTTP is simpler, there are libraries > (libcurl) that make it easier than dealing with > sockets directly, and when there is a web server > sitting in the middle then issues like threading, > locking and blocking are dealt with automagically. > Web servers often can behefit from things like > caching also, and it may be possible to get > compression for free too (I haven't looked into > mod_gzip in detail yet). > > It is also far easier to find places to host. > > _______________________________________________ > 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 eracclists at bellsouth.net Fri Jun 3 14:33:53 2005 From: eracclists at bellsouth.net (ERACC) Date: Fri Jun 3 14:38:20 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: <429D1E29.5020000@sympatico.ca> References: <20050528075642.GA17903@kirschbaum.myrealbox.com> <20050531192028.GA21551@kirschbaum.myrealbox.com> <429D1E29.5020000@sympatico.ca> Message-ID: <200506031433.53301.eracclists@bellsouth.net> On Tuesday 31 May 2005 09:32 pm Todd Mitchell wrote: > monster density - I think part of the problem with the monster density > is that terrain is either blocked or not. [...] I am looking at the Valriel random map settings (within the map /scorn/temples/valriel3) in anticipation of reducing the number of levels, reducing monster density, adding some "new", tougher monsters called "saints" using existing NPC arches and making the random maps larger. One question I have but haven't been able to resolve: is random map monster density determined by /styles/monsterstyles/* or is it elsewhere? I asked this on IRC this morning (here) but apparently everyone is dead there today. :-) > Boss monsters - good idea This would mean making a final map (like the one for Titan Quest) and adding these boss monsters. Maybe for the Valriel one have one fight the Avatar of Valriel (a customized Arch Angel perhaps). Should these bosses drop or guard some sort of special treasure or is the experience gained reward enough? > 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. Well, I am looking in the map /styles directory for information on how to work on these. Is there somewhere else I should be looking as well? If it is a code problem then I'm not the one that can fix that. If it is all handled with map settings then I just need to know what to tweak. How does one use the "difficulty stepping code" in defining random maps or is that automagical? Gene -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 14:14:26 up 16 days, 14:51, 8 users, load average: 0.05, 0.53, 0.62 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandriva Linux, OpenServer & UnixWare resellers From eracclists at bellsouth.net Fri Jun 3 16:33:10 2005 From: eracclists at bellsouth.net (ERACC) Date: Fri Jun 3 16:34:10 2005 Subject: [crossfire] Lone Town Permanent Apartment Message-ID: <200506031633.10857.eracclists@bellsouth.net> Hello All, I am working on ideas for the Permanent Apartments I am placing in Lone Town. I am thinking of making it buildable of course. I am also thinking of making an area in the main apartment that one can purchase (for a LOT of diamonds) that is a "kitchen" and has a stove one may use for "food" alchemy. I am also considering a basement area that has side rooms for the other types of alchemy like jeweler, bowyer and smithery with the proper "cauldron" for each. Each of these would have to be purchased separately and would cost a great deal to purchase. The cauldrons would be on regular tiles and would return after a reset if they "got blowed up". The other areas in each room would be unique. Discussion please. Gene -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 16:17:53 up 16 days, 16:54, 8 users, load average: 0.07, 0.02, 0.01 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandriva Linux, OpenServer & UnixWare resellers From temitchell at sympatico.ca Fri Jun 3 19:44:52 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Fri Jun 3 19:45:02 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: <200506031433.53301.eracclists@bellsouth.net> References: <20050528075642.GA17903@kirschbaum.myrealbox.com> <20050531192028.GA21551@kirschbaum.myrealbox.com> <429D1E29.5020000@sympatico.ca> <200506031433.53301.eracclists@bellsouth.net> Message-ID: <1117845892.3398.9.camel@oberon.kameria> On Fri, 2005-03-06 at 14:33 -0500, ERACC wrote: > On Tuesday 31 May 2005 09:32 pm > Todd Mitchell wrote: > > > monster density - I think part of the problem with the monster density > > is that terrain is either blocked or not. [...] > > I am looking at the Valriel random map settings (within the map > /scorn/temples/valriel3) in anticipation of reducing the number of > levels, reducing monster density, adding some "new", tougher monsters > called "saints" using existing NPC arches and making the random maps > larger. One question I have but haven't been able to resolve: is > random map monster density determined by /styles/monsterstyles/* or > is it elsewhere? I asked this on IRC this morning (here) but > apparently everyone is dead there today. :-) > I believe it is determined by the monsterstyles but not sure how it functions. > > Boss monsters - good idea > > This would mean making a final map (like the one for Titan Quest) and > adding these boss monsters. Maybe for the Valriel one have one fight > the Avatar of Valriel (a customized Arch Angel perhaps). Should these > bosses drop or guard some sort of special treasure or is the > experience gained reward enough? Well the final map is one thing but Boss monsters would have to be done in the code I think - something to figure out what monsters are being placed and then constructing a suped up version for that level. Like if the map is placing many giants, adding a custom giant of higher level with more hp and xp as a boss. > > > 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. > > Well, I am looking in the map /styles directory for information on > how to work on these. Is there somewhere else I should be looking as > well? If it is a code problem then I'm not the one that can fix that. > If it is all handled with map settings then I just need to know what > to tweak. How does one use the "difficulty stepping code" in defining > random maps or is that automagical? > > Gene There's a document on random maps in the server package which gives you info on the paramaters. Just making new monsterstyles which give good progression would be a great start. -- Todd Mitchell From B.T.Lally at warwick.ac.uk Fri Jun 3 21:52:28 2005 From: B.T.Lally at warwick.ac.uk (Brendan Lally) Date: Fri Jun 3 21:55:06 2005 Subject: [crossfire] ingame music Message-ID: >>> mwedel@sonic.net 06/03/05 05:24 AM >>> > Perhaps, but not positive if that will work. Lighting is just a single value. > If you try to hijack that code for music, you will get cases of two sources > overlapping, so that single value doesn't work - you then need to store both > sources or figure out which is louder or something. This is a limitation the lighting code could do without also. If such a mechanism were used for the sound code anyway, then it could usefully be extended to the lighting code to allow coloured lights. I don't know how easy it would be to implement client side, but it would be a nice way to give feedback on some levels, or create interesting optical effects. The easist thing to do in that case then would be to store RGB values in the stats for the light object, and then when they overlap have the resulting colour be the weighted mean in each value. (based on proximity and strength of source). Likewise with music, the resulting sound could be the songs all mixed together with volumes varing depending on their source volume (glow radius) and the distance from the source. From mikeeusaaa at yahoo.com Fri Jun 3 21:54:31 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Jun 3 21:55:09 2005 Subject: [crossfire] Lone Town Permanent Apartment In-Reply-To: <200506031633.10857.eracclists@bellsouth.net> Message-ID: <20050604025431.94035.qmail@web61021.mail.yahoo.com> For the non-unique floors I suggest naming them nosave or something similar. (tis what I do). That way users won't leave stuff there. Death To women's Rights. --- ERACC wrote: > Hello All, > > I am working on ideas for the Permanent Apartments I > am placing in > Lone Town. I am thinking of making it buildable of > course. I am also > thinking of making an area in the main apartment > that one can > purchase (for a LOT of diamonds) that is a "kitchen" > and has a stove > one may use for "food" alchemy. I am also > considering a basement area > that has side rooms for the other types of alchemy > like jeweler, > bowyer and smithery with the proper "cauldron" for > each. Each of > these would have to be purchased separately and > would cost a great > deal to purchase. The cauldrons would be on regular > tiles and would > return after a reset if they "got blowed up". The > other areas in each > room would be unique. > > Discussion please. > > Gene > -- > Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 > 16:17:53 up 16 days, 16:54, 8 users, load > average: 0.07, 0.02, 0.01 > ERA Computer Consulting - http://www.eracc.com/ > eCS, OS/2, Mandriva Linux, OpenServer & UnixWare > resellers > > _______________________________________________ > 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 B.T.Lally at warwick.ac.uk Fri Jun 3 22:01:52 2005 From: B.T.Lally at warwick.ac.uk (Brendan Lally) Date: Fri Jun 3 22:03:19 2005 Subject: [crossfire] Lone Town Permanent Apartment Message-ID: >>> eracclists@bellsouth.net 06/03/05 22:36 PM >>> > The cauldrons would be on regular tiles and would > return after a reset if they "got blowed up". The other > areas in each > room would be unique. Given that these are player apartments, they are the only ones that can blow up their cauldrons. I therefore think that they should be charged for destroying them/ heavily cursing them. How to do that is an interesting question however, probably something would need to be done with creators and destructors, maybe an alter that takes money in order to destroy the cauldron and create a new one? (maybe it should take something else too, lead perhaps?) From fuchs.andy at gmail.com Fri Jun 3 22:21:41 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Fri Jun 3 22:22:13 2005 Subject: [crossfire] Lone Town Permanent Apartment In-Reply-To: <200506031633.10857.eracclists@bellsouth.net> References: <200506031633.10857.eracclists@bellsouth.net> Message-ID: On 6/3/05, ERACC wrote: ... > I am working on ideas for the Permanent Apartments I am placing in > Lone Town. I am thinking of making it buildable of course. I am also > thinking of making an area in the main apartment that one can > purchase (for a LOT of diamonds) that is a "kitchen" and has a stove > one may use for "food" alchemy. I am also considering a basement area > that has side rooms for the other types of alchemy like jeweler, > bowyer and smithery with the proper "cauldron" for each. Each of > these would have to be purchased separately and would cost a great > deal to purchase. The cauldrons would be on regular tiles and would > return after a reset if they "got blowed up". The other areas in each > room would be unique. AFAIK, per player unique maps save EVERYTHING on the map. So setting some tiles non unique, won't work. For the cauldrons, just have an altar next to them, that is connected to a creator. So that if you blow up the cauldron, you buy another one. -- -- Andrew Fuchs From mwedel at sonic.net Fri Jun 3 23:42:54 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Jun 3 23:41:05 2005 Subject: [crossfire] ingame music In-Reply-To: References: Message-ID: <42A1314E.4050502@sonic.net> Brendan Lally wrote: > This is a limitation the lighting code could do without also. If such a > mechanism were used for the sound code anyway, then it could usefully be > extended to the lighting code to allow coloured lights. I don't know how easy > it would be to implement client side, but it would be a nice way to give > feedback on some levels, or create interesting optical effects. > > The easist thing to do in that case then would be to store RGB values in the > stats for the light object, and then when they overlap have the resulting > colour be the weighted mean in each value. (based on proximity and strength > of source). Having the server figure out the color for each space is a complication it doesn't need. If/when colored lighting is added, it will be handled by the client. The server will still figure out what spaces are actually visible based on lighting, but won't care about the color. Conversely, the client should be able to apply properly lighting techniques by knowing where the light sources are and drawing properly shaded/dimmed circles of the right color. This will just allow for better handling of lighting in any case - right now, all the lighting mechanisms for the client are a bit of hacks and add a lot of complication in trying to figure out light value for all the spaces. From kirschbaum at myrealbox.com Sat Jun 4 05:16:15 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sat Jun 4 05:17:08 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: <200506031433.53301.eracclists@bellsouth.net> References: <20050528075642.GA17903@kirschbaum.myrealbox.com> <20050531192028.GA21551@kirschbaum.myrealbox.com> <429D1E29.5020000@sympatico.ca> <200506031433.53301.eracclists@bellsouth.net> Message-ID: <20050604101606.GA19254@kirschbaum.myrealbox.com> ERACC wrote: > I am looking at the Valriel random map settings (within the map > /scorn/temples/valriel3) in anticipation of reducing the number of > levels, reducing monster density, adding some "new", tougher monsters > called "saints" using existing NPC arches and making the random maps > larger. One question I have but haven't been able to resolve: is > random map monster density determined by /styles/monsterstyles/* or is > it elsewhere? There seems to be no parameter to set monster density. The random map monster generator places monster until at least one of the following conditions is met: - average experience per tile is above limit: (total monster experience) > (exp for difficulty level)*(map area)/1000 For example for a random map with dungeon_level 24, difficulty 0, difficulty_increase 0, and size 25x40 the difficulty is 23 (=dungeon_level-1). You need 10.6 million experience to reach level 23. Therefore the total monster experience is limited to (10.6 million*25*40/1000) = 10.6 million. - 100 failed monster placements (because no free spot could be found) - number of monsters exceeds (map area)/8 For the above example at most 25*40/8=125 monsters would be placed. I wonder why the last condition uses the number of monsters but not the area these monsters occupy. Since multi-tile monsters occupy much space, just a few of them can increase the monster density quite considerably. The attached patch changes this. The reduced monster density is noticeable, but since the resulting maps do not feel sparse to me, I think it is still acceptable. Besides that, it also affects the total experience: current with patch =========== ======= ======= Valriel 542-720 156-288 Undead TC 34-139 34-139 Gorokh 83-237 14-122 Dragon TC 70-258 35-119 Demon TC 43-173 20- 67 Humanoid TC 54-204 17- 58 (all values are million experience) If you really need less monster density I could add another configuration parameter. It could default to 8 and be used instead of the fixed number "8" in the third of the above conditions. -------------- next part -------------- Index: random_maps/monster.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/random_maps/monster.c,v retrieving revision 1.13 diff -c -5 -r1.13 monster.c *** random_maps/monster.c 8 Mar 2003 05:35:32 -0000 1.13 --- random_maps/monster.c 4 Jun 2005 10:14:54 -0000 *************** *** 67,76 **** --- 67,77 ---- char styledirname[256]; mapstruct *style_map=0; int failed_placements; sint64 exp_per_sq, total_experience; int number_monsters=0; + archetype *at; sprintf(styledirname,"%s","/styles/monsterstyles"); style_map = find_style(styledirname,monsterstyle,difficulty); if(style_map == 0) return; *************** *** 94,104 **** copy_object_with_inv(this_monster,new_monster); new_monster->x = x; new_monster->y = y; insert_multisquare_ob_in_map(new_monster,map); total_experience+= this_monster->stats.exp; ! number_monsters++; RP->total_map_hp+=new_monster->stats.hp; /* a global count */ } else { failed_placements++; } --- 95,106 ---- copy_object_with_inv(this_monster,new_monster); new_monster->x = x; new_monster->y = y; insert_multisquare_ob_in_map(new_monster,map); total_experience+= this_monster->stats.exp; ! for(at = new_monster->arch; at != NULL; at = at->more) ! number_monsters++; RP->total_map_hp+=new_monster->stats.hp; /* a global count */ } else { failed_placements++; } From tchize at myrealbox.com Sat Jun 4 05:27:40 2005 From: tchize at myrealbox.com (tchize) Date: Sat Jun 4 05:29:09 2005 Subject: [crossfire] No autogen.sh for the client? In-Reply-To: <429FD9DF.5020501@sonic.net> References: <200506020947.18192.tchize@myrealbox.com> <429FD9DF.5020501@sonic.net> Message-ID: <200506041227.47673.tchize@myrealbox.com> Le Vendredi 03 Juin 2005 06:17, Mark Wedel a ?crit : >tchize wrote: >> Speaking about automake. >> >> Since a few week i noticed each time i do a commit, all the Makefile.in >> are commited along. Did someone change the configure script to regenerate >> automake.in file each time a ./configure is run? If that's the case, maybe >> removing Makefile.in files from cvs would be a good think (if they became >> machine dependent, there is no reason to keep them in CVS) > > Some file is out of sync, so it keeps re-running automake. One would > normally thing this should correct itself once the up to date ones are > committed. Maybe something that the makefiles depend on was committed with > a bogus date. > > The rationale for having the Makefile.in's in CVS is to make it easier for >users to grab snapshots and not need a large set of tools. Ideally, this >dependency should get fixed up somehow so that it doesn't re-run automake > every time. > > Problem is, when i only modify some .c files, MAkefile.in's are regenerated (and commited along) >_______________________________________________ >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/20050604/31d6007d/attachment.pgp From B.T.Lally at warwick.ac.uk Sat Jun 4 08:08:59 2005 From: B.T.Lally at warwick.ac.uk (Brendan Lally) Date: Sat Jun 4 08:11:14 2005 Subject: [crossfire] ingame music Message-ID: >>> mwedel@sonic.net 06/04/05 05:46 AM >>> > If/when colored lighting is added, it will be handled by the client. The > server will still figure out what spaces are actually visible based on lighting, > but won't care about the color. > Conversely, the client should be able to apply properly lighting techniques by > knowing where the light sources are and drawing properly shaded/dimmed circles > of the right color. Ok. so then the proper way to deal with music/sound would be analogous, that there should be shaded/dimmed circles of the right music (there is an initial complication involving sync times, but that is a minor issue by comparison. In terms of the overall effect, where the calculation is done (which data is sent and which is calculated) is an issue with the implementation details. From eracclists at bellsouth.net Sat Jun 4 16:58:05 2005 From: eracclists at bellsouth.net (ERACC) Date: Sat Jun 4 16:59:16 2005 Subject: [crossfire] Lone Town Permanent Apartment In-Reply-To: References: Message-ID: <200506041658.06065.eracclists@bellsouth.net> On Friday 03 June 2005 10:01 pm Brendan Lally wrote: > >>> eracclists@bellsouth.net 06/03/05 22:36 PM >>> > > The cauldrons would be on regular tiles and would > > return after a reset if they "got blowed up". The other > areas in each > > room would be unique. > > Given that these are player apartments, they are the only ones that can > blow up their cauldrons. I therefore think that they should be charged > for destroying them/ heavily cursing them. Works for me. > How to do that is an interesting question however, probably something > would need to be done with creators and destructors, maybe an alter that > takes money in order to destroy the cauldron and create a new one? > (maybe it should take something else too, lead perhaps?) Sounds good. However, I can find the archetype for a creator in the CFJavaEditor archlists but I cannot find anything called destructor other than the tool related to buildable buildings. What is a destructor and how does one use it? Gene -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 16:53:57 up 17 days, 17:30, 8 users, load average: 0.12, 0.10, 0.09 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandriva Linux, OpenServer & UnixWare resellers From eracclists at bellsouth.net Sat Jun 4 17:01:18 2005 From: eracclists at bellsouth.net (ERACC) Date: Sat Jun 4 17:03:15 2005 Subject: [crossfire] Lone Town Permanent Apartment In-Reply-To: References: <200506031633.10857.eracclists@bellsouth.net> Message-ID: <200506041701.18967.eracclists@bellsouth.net> On Friday 03 June 2005 10:21 pm Andrew Fuchs wrote: > On 6/3/05, ERACC wrote: > ... > > I am working on ideas for the Permanent Apartments I am placing in > > Lone Town. I am thinking of making it buildable of course. I am also > > thinking of making an area in the main apartment that one can > > purchase (for a LOT of diamonds) that is a "kitchen" and has a stove > > one may use for "food" alchemy. I am also considering a basement area > > that has side rooms for the other types of alchemy like jeweler, > > bowyer and smithery with the proper "cauldron" for each. Each of > > these would have to be purchased separately and would cost a great > > deal to purchase. The cauldrons would be on regular tiles and would > > return after a reset if they "got blowed up". The other areas in each > > room would be unique. > > AFAIK, per player unique maps save EVERYTHING on the map. So setting > some tiles non unique, won't work. You're probably correct. > For the cauldrons, just have an altar next to them, that is connected > to a creator. So that if you blow up the cauldron, you buy another > one. Working on this. However, what if the cauldron is just cursed? I need a way to get rid of the non-pickable cauldrons (stove, etc.) and replace them with new ones. Brendan mentioned "destructors" but I do not seem to be able to find these in the CFJavaEditor pick lists. Gene -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 16:58:19 up 17 days, 17:35, 8 users, load average: 0.36, 0.18, 0.11 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandriva Linux, OpenServer & UnixWare resellers From nicolas.weeger at laposte.net Sat Jun 4 17:10:32 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat Jun 4 17:13:17 2005 Subject: [crossfire] Lone Town Permanent Apartment In-Reply-To: <200506041658.06065.eracclists@bellsouth.net> References: <200506041658.06065.eracclists@bellsouth.net> Message-ID: <42A226D8.2020903@laposte.net> > Sounds good. However, I can find the archetype for a creator in the > CFJavaEditor archlists but I cannot find anything called destructor > other than the tool related to buildable buildings. > > What is a destructor and how does one use it? As you say, destructor is related to map-building. It removes the topmost buildable item on the spot it's applied to. I don't think there's anything to destroy items. One suggestion, then. Prolly complex for nothing, but well. * put a creator at desired spot * put a teleporter on it * teleporter gets activated by the 'buy new cauldron' altar * teleporter destination is an altar slaying a cauldron, doing nothing (or a "burp" sound? * the 'buy new cauldron' also activates (with a small delay?) the creator This way, old cauldron (if still there) is removed, and a new one is created. Maybe strange, but should work. > Gene Nicolas From fuchs.andy at gmail.com Sat Jun 4 19:20:57 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sat Jun 4 19:21:16 2005 Subject: [crossfire] Lone Town Permanent Apartment In-Reply-To: <42A226D8.2020903@laposte.net> References: <200506041658.06065.eracclists@bellsouth.net> <42A226D8.2020903@laposte.net> Message-ID: On 6/4/05, Nicolas Weeger wrote: ... > One suggestion, then. Prolly complex for nothing, but well. > * put a creator at desired spot > * put a teleporter on it > * teleporter gets activated by the 'buy new cauldron' altar > * teleporter destination is an altar slaying a cauldron, doing nothing > (or a "burp" sound? > * the 'buy new cauldron' also activates (with a small delay?) the creator > > This way, old cauldron (if still there) is removed, and a new one is > created. > > Maybe strange, but should work. What happens when the player leaves something on the square that has/had the cauldron on it? -- -- Andrew Fuchs From B.T.Lally at warwick.ac.uk Sat Jun 4 19:28:25 2005 From: B.T.Lally at warwick.ac.uk (Brendan Lally) Date: Sat Jun 4 19:29:17 2005 Subject: [crossfire] Lone Town Permanent Apartment Message-ID: >>> eracclists@bellsouth.net 06/04/05 23:05 PM >>> > Sounds good. However, I can find the archetype for a creator in the > CFJavaEditor archlists but I cannot find anything called destructor > other than the tool related to buildable buildings. > What is a destructor and how does one use it? That is what I was thinking of, you are of course correct that it is limited to the buildable items, I had momentarily forgotten this. I apologise If I have caused unnecessary confusion. Of course, there is always the meteor swarm approach, it is somewhat more satisfying too :) From fuchs.andy at gmail.com Sat Jun 4 19:27:46 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sat Jun 4 19:29:21 2005 Subject: [crossfire] No autogen.sh for the client? In-Reply-To: <200506041227.47673.tchize@myrealbox.com> References: <200506020947.18192.tchize@myrealbox.com> <429FD9DF.5020501@sonic.net> <200506041227.47673.tchize@myrealbox.com> Message-ID: On 6/4/05, tchize wrote: > Problem is, when i only modify some .c files, MAkefile.in's are regenerated > (and commited along) I think there is usualy a target to clean the generated files in the makefiles. -- -- Andrew Fuchs From fuchs.andy at gmail.com Sat Jun 4 19:24:21 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sat Jun 4 19:29:32 2005 Subject: [crossfire] Lone Town Permanent Apartment In-Reply-To: References: <200506041658.06065.eracclists@bellsouth.net> <42A226D8.2020903@laposte.net> Message-ID: Hmm, It could be solved by making buildable arches for the cauldrons. Which would be simpler. Then there is the issue of how they are obtained. For that I would think requiring quested items to "create" the cauldron building arch, and a high fee for having the buildable cauldron created. -- -- Andrew Fuchs From alex_sch at telus.net Sat Jun 4 19:33:55 2005 From: alex_sch at telus.net (Alex Schultz) Date: Sat Jun 4 19:35:19 2005 Subject: [crossfire] Lone Town Permanent Apartment In-Reply-To: References: <200506041658.06065.eracclists@bellsouth.net> <42A226D8.2020903@laposte.net> Message-ID: <42A24873.1070808@telus.net> Andrew Fuchs wrote: >On 6/4/05, Nicolas Weeger wrote: >... > >>One suggestion, then. Prolly complex for nothing, but well. >>* put a creator at desired spot >>* put a teleporter on it >>* teleporter gets activated by the 'buy new cauldron' altar >>* teleporter destination is an altar slaying a cauldron, doing nothing >>(or a "burp" sound? >>* the 'buy new cauldron' also activates (with a small delay?) the creator >> >>This way, old cauldron (if still there) is removed, and a new one is >>created. >> >>Maybe strange, but should work. >> > >What happens when the player leaves something on the square that >has/had the cauldron on it? > Yes... in that design it would teleport that too. Perhaps a sign should be on the 'buy new cauldron' altar that say that it destroys everything on the square. Another alternative would be to not have it destroy the old one at all: as those cauldrons are burnable, leave the player to manually burn the old one first (making sure to have a note to tell the player that he has to do that) From mwedel at sonic.net Sun Jun 5 01:01:23 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Jun 5 01:01:20 2005 Subject: [crossfire] new metaserver In-Reply-To: <200506020948.04549.tchize@myrealbox.com> References: <20050527164327.19615.qmail@web61021.mail.yahoo.com> <200505291525.02695.tchize@myrealbox.com> <429EB35B.9020000@sonic.net> <200506020948.04549.tchize@myrealbox.com> Message-ID: <42A29533.9000609@sonic.net> tchize wrote: > Le Jeudi 2 Juin 2005 09:20, Mark Wedel a ?crit : >>1) Has someone agreed to run the metametaserver? What about the slave >>metaservers? While all this looks nice, if you don't have people willing >>to run it/take care of it, it is all pretty pointless. For the >>metametaserver, I'm thinking more of the Tanner's, since they currently >>hold the main crossfire home page, but of course, the metametaserver could >>move someplace else (not as sure how many people have as stable and ip >>address and network connection that they do). > > > That's were a static list on various website is usefull, easy to place > (crossfire.sourceforge.net could be a place to hold the list) Yes, but a static list != metaserver. That is a seperate issue. Certainly, having static lists isn't a bad backup plan, but isn't really the same thing. > > >>2) having the clients connect to the various servers to get stats like >>current number of active players is IMO an extra level of complication that >>can be done without. If we have a dozen active servers (which was actually >>low if I recall), you probably don't want to do it sequentially - that >>means it coudl take a significant amount of time to go through them all. >>Especially if one is down or unresponsive. this means you need to do it in >>parallel, and writing that threaded code is a bit more complicated. Add to >>the fact that the client would then have to send some commands and parses >>the responses from the server. I just don't see any reason that dynamic >>info shouldn't be included. > > > could be done in udp (send a packet to each server than wait 2 second for any > response) udp is probably not a good option. Most peoples private firewalls will probably not work in that setup without changing the configuration (they'd need to be modified to let the return udp packet through the firewall). So from a client perspective, we really want to just stick to tcp. From mwedel at sonic.net Sun Jun 5 01:27:56 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Jun 5 01:27:21 2005 Subject: [crossfire] new metaserver In-Reply-To: References: Message-ID: <42A29B6C.4080605@sonic.net> As asked, here is my thought on this. To make typing this easier, CMS = chief (core) metaserver. SMS = slave metaserver There is one CMS. All crossfire servers that want to be listed in metaserver output send there data to this server (exactly how - udp/tcp, and what to send is an open issue. My thought is that the server should send most every bit of data the might be useful - after all, it's only sending an update packet once a minute or something, so the amount of bandwidth for that is trivial). My thought is also that this should be an actual daemon like program - I think having it be up holds some advantages. One being that the connections from the servers to it can be persistent (presuming tcp here) - that makes things a lot easier on the server side, and also replication side. The only sites that can request data from the CMS are trusted SMSs. The CMS serves the data in a relative raw format. The CMS would also provide information on the SMS's, just like the server (haven't got any requests from this SMS for a while, etc). The new CMS would need to be a bit more robust than what is there now. There are numerous SMS's. The clients talk to one of the various SMSs. These SMS's talk to the CMS to get their data. The ideal case, IMO, would be for the SMSs to also be persistent program, and thus could just have a tcp connection to the CMS. However, probably not any reason that the CMS couldn't just to a connection to SMS, get data, close connection. Thus a php script could be written to get this data. Probably a reasonable idea for the SMS to at least potentially be web based. Depending on the web server and access a person has to it, the way it gets data could vary. For example, a php based one would just contact the CMS periodically (not necessarily every time it gets a requests - presumable it should have a cache file it uses - if the cache file is too old, then it gets new data from the server). For other people, that can actually run scripts on the web server, they can perhaps have a persistent script that is in contact with the CMS, and just gets the data and stores it as static pages. The client would ship with a file that lists the current SMS's as web addresses (given different people host them, you can't just have a URL like http://myhost/cfservers - people may need to do things like http://myhost/~username/cfservers or whatever). The SMS would have two bits of data from the CMS - the list of all the servers and their stats, which has obvious usefulness. However, it would also have a list of the other SMSs, so that the client can update its lists of what SMS's are out there. Thus, as long as a client can find one SMS, it can talk to it, and now get an updated list of all the new SMS. Thus, as SMSs come and go, the client will automatically keep up to date and not have to rely on some other external site. If the CMS is down, the SMS's just serve the last data they have. This data will eventually become stale, but with very limited traffic going to the CMS, I think DOS attacks against the CMS are much less likely. A few other notes: An agreement/usage policy for people that want to be SMSs is probably in order. Probably the main bit of that policy is that it won't abuse the CMS (eg, behave correctly), but also that it has to serve the data it gets from the CMS in basically an unaltered state (can't drop servers it doesn't like, can't add/fake servers it does like, etc). Also, relative to the client getting the data, it should be served up in a raw form (eg, not html, but something easy to parse). That said, the CMS can also make html output if it so desires, but that would be for human readable format, not for the clients. I think this takes various bits people have discussed but with some changes. From mwedel at sonic.net Sun Jun 5 01:38:34 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Jun 5 01:37:20 2005 Subject: [crossfire] Spellcasting Swords progress In-Reply-To: <429EB2B6.9010806@telus.net> References: <429D3D04.2020902@telus.net> <20050601175134.GA32226@kirschbaum.myrealbox.com> <429EAC72.2010207@telus.net> <429EB050.3030108@sonic.net> <429EB2B6.9010806@telus.net> Message-ID: <42A29DEA.9090503@sonic.net> Alex Schultz wrote: > I'm trying to insert a rod into the sword, where the rod has a spell in > it (I've usually done that with the old style spell numbers in my tests > which the server seems to nicely convert). For example, I make the > following treasurelist which is in the "randomitems" of the sword arch: > > treasureone katanafire > arch rod_light > sp 82 > level 15 > hp 50 > maxhp 50 > no_drop 1 > no_pickup 1 > startequip 1 > chance 100 > end That is not valid syntax for the treasures file. You can not make changes to the archetype in the treasures file. I imagine if you watch the server startup, you'd probably see a bunch of error messages related to that. > I tested it putting the sword on a map and that works except for the > above mentioned information loss. However when I tested it by using the > DM "create" command, the randomitems were not obeyed. If you use the map editor to create the sword, put the rod in the sword, and put a spell in the rod (clear out randomitems from the rod), then it should work. If that doesn't work, I'd consider it a bug. I don't remember for sure if the dm create command actually does all the right thing, regarding setting up the treasure lists. > > I assume this information loss is because the treasurelists don't accept > such data and only use the defaults of the arch, so one solution would > be creating an arch for each rod that I want to use on the swords, > however I feel that would be a bit kludgy, and I am wondering if anybody > has any better solutions. That is one solution. But is your goal to make these show up randomly? Or is your goal to put these on a few special maps? If the later, then see my note above. The other possiblity would be to change the code, so that the sword itself can act as the caster object. I'm not sure what changes would need to be made - perhaps not too many. The real complication here is that for weapon improvement, it probably uses some of the same fields as you'd need to it to be a casting object. The simple solution this is that spell casting weapons can't be improved - then you don't have to worry about that conflicting use of fields. From nicolas.weeger at laposte.net Sun Jun 5 03:20:58 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun Jun 5 03:23:21 2005 Subject: [crossfire] Spellcasting Swords progress In-Reply-To: <42A29DEA.9090503@sonic.net> References: <429D3D04.2020902@telus.net> <20050601175134.GA32226@kirschbaum.myrealbox.com> <429EAC72.2010207@telus.net> <429EB050.3030108@sonic.net> <429EB2B6.9010806@telus.net> <42A29DEA.9090503@sonic.net> Message-ID: <42A2B5E9.8020203@laposte.net> > The other possiblity would be to change the code, so that the sword > itself can act as the caster object. I'm not sure what changes would > need to be made - perhaps not too many. The real complication here is > that for weapon improvement, it probably uses some of the same fields as > you'd need to it to be a casting object. The simple solution this is > that spell casting weapons can't be improved - then you don't have to > worry about that conflicting use of fields. I propose an option, but it's a long-time goal as it implies to refactor many parts of the code. It's a rough proposal. The idea is to replace the 'type' field (which stores only one value) with a binary value, flags indicating what the item can do. So you could have 'is_weapon 1', and 'cast_spell 1' at the same time. Of course arises the issue of the different parameters of the item (spell points, and so on). Let's put items in the inventory, with a special flag ('is_parameter 1') and the associated specific flag. Thus you'd have: (* = item, + = parameter) * sword + is_weapon 1 + casts_spell 1 * sword caracteristics + is_parameter 1 + is_weapon + wc + damage * spell caracteristics + is_parameter 1 + casts_spell 1 + sp + level Drawback, there will be many flags (basically one for each item type...). Also requires to convert all existing items (argh), and fix all maps (argh again). Can probably be done incrementally, ie let server convert at load time. Also it may slow the server, as there's a need to find the item parameters often. Nicolas From alex_sch at telus.net Sun Jun 5 10:02:17 2005 From: alex_sch at telus.net (Alex Schultz) Date: Sun Jun 5 10:03:25 2005 Subject: [crossfire] Spellcasting Swords progress In-Reply-To: <42A29DEA.9090503@sonic.net> References: <429D3D04.2020902@telus.net> <20050601175134.GA32226@kirschbaum.myrealbox.com> <429EAC72.2010207@telus.net> <429EB050.3030108@sonic.net> <429EB2B6.9010806@telus.net> <42A29DEA.9090503@sonic.net> Message-ID: <42A313F9.7000800@telus.net> Mark Wedel wrote: > If you use the map editor to create the sword, put the rod in the > sword, and put a spell in the rod (clear out randomitems from the > rod), then it should work. If that doesn't work, I'd consider it a bug. Yes, that does work, that's what I've been testing with from the beginning. > I don't remember for sure if the dm create command actually does all > the right thing, regarding setting up the treasure lists. From what I've found it does not. Though see below that I've found a nice method around this that avoids treasurelists. > > That is one solution. But is your goal to make these show up > randomly? Or is your goal to put these on a few special maps? If the > later, then see my note above. I'm trying to make it show up randomly. Since the e-mail you're replying to, I've found a nice solution: create another python script that runs when it's applied which generates a rod if it doesn't already have one, and it is generated based upon parameters given the event options of the script. This seems to work quite nicely, and and still allows map makers to just put the rod in via the map if they want (which I see as easier for map makers). The only issue I'm running into now, is where the best place to insert such items into the treasurelists to make them randomly appear. I do know of several places that would work technically, but I'm not sure which is the most proper and from what I see chance values add up to 100 so I would have to change existing ones so I'm not sure of the best way to do that. Thanks, Alex Schultz From mikeeusaaa at yahoo.com Sun Jun 5 11:41:50 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sun Jun 5 11:42:52 2005 Subject: [crossfire] new metaserver In-Reply-To: <42A29B6C.4080605@sonic.net> Message-ID: <20050605164150.91134.qmail@web61016.mail.yahoo.com> Cave's php metaservers are great. The sms's are sent the data by the servers. They then send the info to the cms which sends the info to the other sms's. This way (since the sms's are trusted) the cms is unDoSable as it's ip is unknown except for the trusted sms. Since cave's metaservers are written in php they can be hosted anywhere... including hosting companies with near unlimited bandwidth. We should implement it, it has been written. It is good. The time for discussing how it should be done is passed as we allready have a product now. --- Mark Wedel wrote: > > As asked, here is my thought on this. > > To make typing this easier, CMS = chief (core) > metaserver. SMS = slave metaserver > > There is one CMS. All crossfire servers that want > to be listed in metaserver > output send there data to this server (exactly how - > udp/tcp, and what to send > is an open issue. My thought is that the server > should send most every bit of > data the might be useful - after all, it's only > sending an update packet once a > minute or something, so the amount of bandwidth for > that is trivial). My > thought is also that this should be an actual daemon > like program - I think > having it be up holds some advantages. One being > that the connections from the > servers to it can be persistent (presuming tcp here) > - that makes things a lot > easier on the server side, and also replication > side. The only sites that can > request data from the CMS are trusted SMSs. The CMS > serves the data in a > relative raw format. The CMS would also provide > information on the SMS's, just > like the server (haven't got any requests from this > SMS for a while, etc). The > new CMS would need to be a bit more robust than what > is there now. > > There are numerous SMS's. The clients talk to one > of the various SMSs. These > SMS's talk to the CMS to get their data. The ideal > case, IMO, would be for the > SMSs to also be persistent program, and thus could > just have a tcp connection to > the CMS. However, probably not any reason that the > CMS couldn't just to a > connection to SMS, get data, close connection. Thus > a php script could be > written to get this data. Probably a reasonable > idea for the SMS to at least > potentially be web based. Depending on the web > server and access a person has > to it, the way it gets data could vary. > > For example, a php based one would just contact > the CMS periodically (not > necessarily every time it gets a requests - > presumable it should have a cache > file it uses - if the cache file is too old, then it > gets new data from the server). > > For other people, that can actually run scripts on > the web server, they can > perhaps have a persistent script that is in contact > with the CMS, and just gets > the data and stores it as static pages. > > The client would ship with a file that lists the > current SMS's as web > addresses (given different people host them, you > can't just have a URL like > http://myhost/cfservers - people may need to do > things like > http://myhost/~username/cfservers or whatever). > > The SMS would have two bits of data from the CMS - > the list of all the servers > and their stats, which has obvious usefulness. > However, it would also have a > list of the other SMSs, so that the client can > update its lists of what SMS's > are out there. Thus, as long as a client can find > one SMS, it can talk to it, > and now get an updated list of all the new SMS. > Thus, as SMSs come and go, the > client will automatically keep up to date and not > have to rely on some other > external site. > > If the CMS is down, the SMS's just serve the last > data they have. This data > will eventually become stale, but with very limited > traffic going to the CMS, I > think DOS attacks against the CMS are much less > likely. > > A few other notes: > > An agreement/usage policy for people that want to be > SMSs is probably in order. > Probably the main bit of that policy is that it > won't abuse the CMS (eg, > behave correctly), but also that it has to serve the > data it gets from the CMS > in basically an unaltered state (can't drop servers > it doesn't like, can't > add/fake servers it does like, etc). > > Also, relative to the client getting the data, it > should be served up in a raw > form (eg, not html, but something easy to parse). > That said, the CMS can also > make html output if it so desires, but that would be > for human readable format, > not for the clients. > > I think this takes various bits people have > discussed but with some changes. > > > _______________________________________________ > 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 Sun Jun 5 11:43:02 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sun Jun 5 11:43:26 2005 Subject: [crossfire] new metaserver In-Reply-To: <42A29533.9000609@sonic.net> Message-ID: <20050605164302.66278.qmail@web61017.mail.yahoo.com> I could run the meta-metaserver if you wanted... --- Mark Wedel wrote: > tchize wrote: > > Le Jeudi 2 Juin 2005 09:20, Mark Wedel a ?crit : > > >>1) Has someone agreed to run the metametaserver? > What about the slave > >>metaservers? While all this looks nice, if you > don't have people willing > >>to run it/take care of it, it is all pretty > pointless. For the > >>metametaserver, I'm thinking more of the Tanner's, > since they currently > >>hold the main crossfire home page, but of course, > the metametaserver could > >>move someplace else (not as sure how many people > have as stable and ip > >>address and network connection that they do). > > > > > > That's were a static list on various website is > usefull, easy to place > > (crossfire.sourceforge.net could be a place to > hold the list) > > Yes, but a static list != metaserver. That is a > seperate issue. Certainly, > having static lists isn't a bad backup plan, but > isn't really the same thing. > > > > > > >>2) having the clients connect to the various > servers to get stats like > >>current number of active players is IMO an extra > level of complication that > >>can be done without. If we have a dozen active > servers (which was actually > >>low if I recall), you probably don't want to do it > sequentially - that > >>means it coudl take a significant amount of time > to go through them all. > >>Especially if one is down or unresponsive. this > means you need to do it in > >>parallel, and writing that threaded code is a bit > more complicated. Add to > >>the fact that the client would then have to send > some commands and parses > >>the responses from the server. I just don't see > any reason that dynamic > >>info shouldn't be included. > > > > > > could be done in udp (send a packet to each server > than wait 2 second for any > > response) > > udp is probably not a good option. Most peoples > private firewalls will > probably not work in that setup without changing the > configuration (they'd need > to be modified to let the return udp packet through > the firewall). So from a > client perspective, we really want to just stick to > tcp. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From fuchs.andy at gmail.com Sun Jun 5 12:00:54 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun Jun 5 12:01:26 2005 Subject: [crossfire] new metaserver In-Reply-To: <42A29B6C.4080605@sonic.net> References: <42A29B6C.4080605@sonic.net> Message-ID: I think that some of the "client metaservers" should be able to work directly with the servers, these metaservers would have to be more trusted than the normal ones though. -- -- Andrew Fuchs From alex_sch at telus.net Sun Jun 5 13:08:32 2005 From: alex_sch at telus.net (Alex Schultz) Date: Sun Jun 5 13:09:27 2005 Subject: [crossfire] new metaserver In-Reply-To: References: <42A29B6C.4080605@sonic.net> Message-ID: <42A33FA0.5000304@telus.net> Andrew Fuchs wrote: >I think that some of the "client metaservers" should be able to work >directly with the servers, these metaservers would have to be more >trusted than the normal ones though. > > Something that could be done well with the way that cavehippo's php one is set up with 'active' and 'passive' servers for the client accessible ones. Just would need to add some authentication to that scheme (even something as simple as having the central metaserver have a list of ones trusted to add servers). From leaf at real-time.com Sun Jun 5 13:08:53 2005 From: leaf at real-time.com (Rick Tanner) Date: Sun Jun 5 13:09:32 2005 Subject: [crossfire] new metaserver In-Reply-To: <429EB35B.9020000@sonic.net> References: <20050527164327.19615.qmail@web61021.mail.yahoo.com> <200505291525.02695.tchize@myrealbox.com> <429EB35B.9020000@sonic.net> Message-ID: On Thu, 2 Jun 2005, Mark Wedel wrote: > > 1) Has someone agreed to run the metametaserver? What about the slave > metaservers? While all this looks nice, if you don't have people willing to > run it/take care of it, it is all pretty pointless. For the metametaserver, > I'm thinking more of the Tanner's, since they currently hold the main > crossfire home page, but of course, the metametaserver could move someplace > else (not as sure how many people have as stable and ip address and network > connection that they do). Yes, we can still run the metametaserver or related server. From temitchell at sympatico.ca Sun Jun 5 13:40:49 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Sun Jun 5 13:41:28 2005 Subject: [crossfire] Java Editor Message-ID: <1117996849.3991.7.camel@oberon.kameria> The current Java Editor does not seem to be very stable. Especially it tends to have a problem with really big maps (can't open them) and eventually won't open maps and has to be restarted. Behaves like a Memory leak? Also sometimes the map window graphics are getting corrupted by the file menus from the main window (something updating the wrong container?) This is on Debian using Blackdown J2re 1.4.2 and the editor was built from current CVS (a few tries) using ant 1.6.2. Prior versions worked pretty good on this same platform. -- Todd Mitchell From fuchs.andy at gmail.com Sun Jun 5 14:27:34 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun Jun 5 14:31:28 2005 Subject: [crossfire] Java Editor In-Reply-To: <1117996849.3991.7.camel@oberon.kameria> References: <1117996849.3991.7.camel@oberon.kameria> Message-ID: I have the same issues, on gentoo and ubuntu (stable). Also I have experienced an issue when resizing maps, the window does not update to reflect the change, but it used to in the last "stable" version (which had more memory leaks if I remember correctly). The issue with loading larger maps, would be with the memory allocated for runing the editor, which can be changed with a command line option, which I don't remember atm. -- -- Andrew Fuchs From eracclists at bellsouth.net Sun Jun 5 14:45:07 2005 From: eracclists at bellsouth.net (ERACC) Date: Sun Jun 5 14:45:27 2005 Subject: [crossfire] Java Editor In-Reply-To: <1117996849.3991.7.camel@oberon.kameria> References: <1117996849.3991.7.camel@oberon.kameria> Message-ID: <200506051445.07683.eracclists@bellsouth.net> On Sunday 05 June 2005 01:40 pm Todd Mitchell wrote: > The current Java Editor does not seem to be very stable. Especially it > tends to have a problem with really big maps (can't open them) and > eventually won't open maps and has to be restarted. Behaves like a > Memory leak? Also sometimes the map window graphics are getting > corrupted by the file menus from the main window (something updating the > wrong container?) Noticed these problems here too. Hopefully some Java guru will have a try at fixing it and release a new .jar (I haven't tried yet to build from source). I did make it able to open huge maps by increasing the maximum heap size using a command line switch. My personal bash script to run the editor is attached. Gene -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 13:56:46 up 18 days, 14:33, 8 users, load average: 0.07, 0.07, 0.02 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandriva Linux, OpenServer & UnixWare resellers -------------- next part -------------- A non-text attachment was scrubbed... Name: cfedit Type: application/x-shellscript Size: 315 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050605/fb54401d/cfedit.bin From mwedel at sonic.net Sun Jun 5 16:39:03 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Jun 5 16:37:30 2005 Subject: [crossfire] Spellcasting Swords progress In-Reply-To: <42A2B5E9.8020203@laposte.net> References: <429D3D04.2020902@telus.net> <20050601175134.GA32226@kirschbaum.myrealbox.com> <429EAC72.2010207@telus.net> <429EB050.3030108@sonic.net> <429EB2B6.9010806@telus.net> <42A29DEA.9090503@sonic.net> <42A2B5E9.8020203@laposte.net> Message-ID: <42A370F7.8020207@sonic.net> Nicolas Weeger wrote: >> The other possiblity would be to change the code, so that the sword >> itself can act as the caster object. I'm not sure what changes would >> need to be made - perhaps not too many. The real complication here is >> that for weapon improvement, it probably uses some of the same fields >> as you'd need to it to be a casting object. The simple solution this >> is that spell casting weapons can't be improved - then you don't have >> to worry about that conflicting use of fields. > > > I propose an option, but it's a long-time goal as it implies to refactor > many parts of the code. It's a rough proposal. > > The idea is to replace the 'type' field (which stores only one value) > with a binary value, flags indicating what the item can do. > So you could have 'is_weapon 1', and 'cast_spell 1' at the same time. > Of course arises the issue of the different parameters of the item > (spell points, and so on). Let's put items in the inventory, with a > special flag ('is_parameter 1') and the associated specific flag. > > Thus you'd have: (* = item, + = parameter) > * sword > + is_weapon 1 > + casts_spell 1 > * sword caracteristics > + is_parameter 1 > + is_weapon > + wc > + damage > * spell caracteristics > + is_parameter 1 > + casts_spell 1 > + sp > + level > > Drawback, there will be many flags (basically one for each item > type...). Also requires to convert all existing items (argh), and fix > all maps (argh again). Can probably be done incrementally, ie let server > convert at load time. > Also it may slow the server, as there's a need to find the item > parameters often. In addition to ones that have to get updated, presuming that we don't reset the server, also need to update all player files as well as their apartments. The idea has merit. The problems are as you discussed. Also, you end up needing a lot of flags to accurately describe items. For example, cast_spell isn't good enough right now to cover the spellcasting objects (potions/scrolls, wands, rods). For potions & scrolls, you'd need something like the is_used_up flag - that already exists - to denote the item is used in casting. for wands, you need something like an is_charged_item flag, to denote it has charges. For rods/horns, you need some other flag to denote that it regenerates sp. But the biggest problem is that you describe - the fact that the structure fields often overlap. At some level, the approach that Alex is using isn't a bad one - put an object in an object in an object. The real problem is that the treasurelist doesn't allow setting attributes for the objects. It could be intersting, for more than this case, to be able to specify archetype type parameters in the treasurelist (the treasurelist basically holds a copy of the archetype that could be modified). This actually makes the treasurelists much more extensible. From mwedel at sonic.net Sun Jun 5 16:43:14 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Jun 5 16:42:10 2005 Subject: [crossfire] Spellcasting Swords progress In-Reply-To: <42A313F9.7000800@telus.net> References: <429D3D04.2020902@telus.net> <20050601175134.GA32226@kirschbaum.myrealbox.com> <429EAC72.2010207@telus.net> <429EB050.3030108@sonic.net> <429EB2B6.9010806@telus.net> <42A29DEA.9090503@sonic.net> <42A313F9.7000800@telus.net> Message-ID: <42A371F2.2070200@sonic.net> Alex Schultz wrote: > I'm trying to make it show up randomly. Since the e-mail you're replying > to, I've found a nice solution: create another python script that runs > when it's applied which generates a rod if it doesn't already have one, > and it is generated based upon parameters given the event options of the > script. This seems to work quite nicely, and and still allows map makers > to just put the rod in via the map if they want (which I see as easier > for map makers). > > The only issue I'm running into now, is where the best place to insert > such items into the treasurelists to make them randomly appear. I do > know of several places that would work technically, but I'm not sure > which is the most proper and from what I see chance values add up to 100 > so I would have to change existing ones so I'm not sure of the best way > to do that. Probably best to find existing weapons in the treasurelist and reduce the chance of those. Note that the total value of the chance fields in a treasurelist does not need to be 100%. Look at the doc/Developers/objects for more about treasures. Briefly: If if it is a 'treasureone' type list, one item is generated. At load time, the server sums out the chance fields - they don't have to sum to 100, probably just habit that they do. If it is a 'treasure' list, then the chance field is the percentage chance of each object showing up. In a normal treasure list, you can get 20 items from one list showing up. From mwedel at sonic.net Sun Jun 5 16:49:26 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Jun 5 16:49:30 2005 Subject: [crossfire] Java Editor In-Reply-To: <200506051445.07683.eracclists@bellsouth.net> References: <1117996849.3991.7.camel@oberon.kameria> <200506051445.07683.eracclists@bellsouth.net> Message-ID: <42A37366.2050905@sonic.net> ERACC wrote: > On Sunday 05 June 2005 01:40 pm > Todd Mitchell wrote: > > >>The current Java Editor does not seem to be very stable. Especially it >>tends to have a problem with really big maps (can't open them) and >>eventually won't open maps and has to be restarted. Behaves like a >>Memory leak? Also sometimes the map window graphics are getting >>corrupted by the file menus from the main window (something updating the >>wrong container?) > > > Noticed these problems here too. Hopefully some Java guru will have a > try at fixing it and release a new .jar (I haven't tried yet to build > from source). I did make it able to open huge maps by increasing the > maximum heap size using a command line switch. My personal bash > script to run the editor is attached. I've noticed it to on fedora core 3. Using the -Xmxm to increase the heap size helps out. I don't know what the default is, but does seem to small. It certainly is a memory leak issue, because I do see errors like this from the window I run it from when it starts to misbehave: [java] Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space In theory, java is supposed to reclaim memory so there shouldn't be memory management issues. I wonder if some pointer isn't being cleared, and therefor memory from the map isn't being freed as it should. One can see the problem pretty easily - load one of the world_x_y maps and do enter north/east/whatever a few times. Increasing the heap size really just masks the problem. OTOH, I think the default is probably pretty low for how much memory most systems probably have now days. From B.T.Lally at warwick.ac.uk Sun Jun 5 17:34:00 2005 From: B.T.Lally at warwick.ac.uk (Brendan Lally) Date: Sun Jun 5 17:35:31 2005 Subject: [crossfire] Spellcasting Swords progress Message-ID: >>> nicolas.weeger@laposte.net 06/05/05 09:26 AM >>> > The idea is to replace the 'type' field (which stores only one value) > with a binary value, flags indicating what the item can do. > So you could have 'is_weapon 1', and 'cast_spell 1' at the same time. I quite like this idea, it seems rather elegant, it would also allow types to be changed quite easily. (think statues of monsters that animate themselves, or treasure chests that conditionally become exits) Ideally the existing flags (no_pick etc,) would be folded in to this too. > Drawback, there will be many flags (basically one for each item > type...). Wouldn't there be substantial overlap here? you could for example have a casts_spells value, which would cover rods, horns and scrolls with combinations of flags, it might be possible to define all the existing type checks with relatively few flags (~20-30 maybe) > Also requires to convert all existing items (argh), and fix > all maps (argh again). Can probably be done incrementally, ie let > server convert at load time. That would be a potential nightmare, although most of the map editing could probably be dealt with by a well crufted perl script. From eracclists at bellsouth.net Sun Jun 5 18:05:12 2005 From: eracclists at bellsouth.net (ERACC) Date: Sun Jun 5 18:05:31 2005 Subject: [crossfire] Java Editor In-Reply-To: <42A37366.2050905@sonic.net> References: <1117996849.3991.7.camel@oberon.kameria> <200506051445.07683.eracclists@bellsouth.net> <42A37366.2050905@sonic.net> Message-ID: <200506051805.12161.eracclists@bellsouth.net> On Sunday 05 June 2005 04:49 pm Mark Wedel wrote: [...] > Increasing the heap size really just masks the problem. OTOH, I think the > default is probably pretty low for how much memory most systems probably have > now days. According to "man java" the default is 64MB: -Xmxn Specifies the maximum size, in bytes, of the memory allocation pool. This value must be a multiple of 1024 greater than 2 MB. Append the letter k or K to indicate kilobytes or the letter m or M to indicate megabytes. The default value is 64MB. Exam- ples: -Xmx83886080 -Xmx81920k -Xmx80m Gene -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 18:03:36 up 18 days, 18:40, 8 users, load average: 0.01, 0.02, 0.00 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandriva Linux, OpenServer & UnixWare resellers From temitchell at sympatico.ca Sun Jun 5 18:56:39 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Sun Jun 5 18:57:32 2005 Subject: [crossfire] Java Editor In-Reply-To: <42A37366.2050905@sonic.net> References: <1117996849.3991.7.camel@oberon.kameria> <200506051445.07683.eracclists@bellsouth.net> <42A37366.2050905@sonic.net> Message-ID: <42A39137.2070301@sympatico.ca> > One can see the problem pretty easily - load one of the world_x_y > maps and do enter north/east/whatever a few times. Yes, or use the "enter exit" function for a bit... > > > Increasing the heap size really just masks the problem. OTOH, I > think the default is probably pretty low for how much memory most > systems probably have now days. Ya, I increased the memory but eventually (and usually when you're humming along) it will run out. From eracclists at bellsouth.net Sun Jun 5 21:05:09 2005 From: eracclists at bellsouth.net (ERACC) Date: Sun Jun 5 21:05:35 2005 Subject: [crossfire] Color Spray Message-ID: <200506052105.10835.eracclists@bellsouth.net> I cannot believe HOW neutered this spell is. It used to be an awesome spell worth the effort of going to get. Now I am sorry I wasted an entire evening going to get it on crossfire.metalforge.net earlier. As hard as it is to get this spell it should be at least as powerful as I remember it being. What's with neutering hard-to-get spells? Can the spell be returned to its' former glory, please? Otherwise it just takes up space in my spell list. Level 46 sorcery and it takes THREE casts of color spray to kill about 10 - 15 Fiends. They should ALL be dead in one cast based on how the spell USED to work. Gene -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 20:58:23 up 18 days, 21:35, 8 users, load average: 0.18, 0.11, 0.04 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandriva Linux, OpenServer & UnixWare resellers From alex_sch at telus.net Sun Jun 5 21:53:26 2005 From: alex_sch at telus.net (Alex Schultz) Date: Sun Jun 5 21:53:34 2005 Subject: [crossfire] Java Editor In-Reply-To: <42A39137.2070301@sympatico.ca> References: <1117996849.3991.7.camel@oberon.kameria> <200506051445.07683.eracclists@bellsouth.net> <42A37366.2050905@sonic.net> <42A39137.2070301@sympatico.ca> Message-ID: <42A3BAA6.6020901@telus.net> Todd Mitchell wrote: >> One can see the problem pretty easily - load one of the world_x_y >> maps and do enter north/east/whatever a few times. > > Yes, or use the "enter exit" function for a bit... Heh, never knew about that 'enter exit' feature, I wish I had. >> Increasing the heap size really just masks the problem. OTOH, I >> think the default is probably pretty low for how much memory most >> systems probably have now days. > > > Ya, I increased the memory but eventually (and usually when you're > humming along) it will run out. I haven't run into these problems myself, then again, I haven't loaded any 'large' maps in it and I set the stack size to 256MB. Alex Schultz From alex_sch at telus.net Sun Jun 5 21:59:35 2005 From: alex_sch at telus.net (Alex Schultz) Date: Sun Jun 5 21:59:33 2005 Subject: [crossfire] Color Spray In-Reply-To: <200506052105.10835.eracclists@bellsouth.net> References: <200506052105.10835.eracclists@bellsouth.net> Message-ID: <42A3BC17.8030001@telus.net> ERACC wrote: >I cannot believe HOW neutered this spell is. It used to be an awesome >spell worth the effort of going to get. Now I am sorry I wasted an >entire evening going to get it on crossfire.metalforge.net earlier. >As hard as it is to get this spell it should be at least as powerful >as I remember it being. What's with neutering hard-to-get spells? > >Can the spell be returned to its' former glory, please? Otherwise it >just takes up space in my spell list. Level 46 sorcery and it takes >THREE casts of color spray to kill about 10 - 15 Fiends. They should >ALL be dead in one cast based on how the spell USED to work. > I agree, it's currently underpowered to the point where it's useless even when it might otherwise be attractive due to it's variety of attacktypes being difficult to resist. Even if I inscribe lots of scrolls of it that are about lvl 100, it can't even graze a lvl 60 in the arena or any monster that's of the slightest worth. The balance of the spell might currently be ok for a lvl 15-30, however it's near impossible for a lvl 15-30 to get it considering the quest it's in and the fact that spellbooks can't be carried out. Alex Schultz From tchize at myrealbox.com Mon Jun 6 02:36:06 2005 From: tchize at myrealbox.com (tchize) Date: Mon Jun 6 02:35:35 2005 Subject: [crossfire] Java Editor In-Reply-To: <42A3BAA6.6020901@telus.net> References: <1117996849.3991.7.camel@oberon.kameria> <42A39137.2070301@sympatico.ca> <42A3BAA6.6020901@telus.net> Message-ID: <200506060936.06679.tchize@myrealbox.com> Promised, i'll try to fix this tonight if it occurs un CVS too, dunno what is causing this but a bit java profiling will find it immediatly :) Le Lundi 6 Juin 2005 04:53, Alex Schultz a ?crit : > Todd Mitchell wrote: > >> One can see the problem pretty easily - load one of the world_x_y > >> maps and do enter north/east/whatever a few times. > > > > Yes, or use the "enter exit" function for a bit... > > Heh, never knew about that 'enter exit' feature, I wish I had. > > >> Increasing the heap size really just masks the problem. OTOH, I > >> think the default is probably pretty low for how much memory most > >> systems probably have now days. > > > > Ya, I increased the memory but eventually (and usually when you're > > humming along) it will run out. > > I haven't run into these problems myself, then again, I haven't loaded > any 'large' maps in it and I set the stack size to 256MB. > > Alex Schultz > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From andi.vogl at gmx.net Mon Jun 6 06:52:16 2005 From: andi.vogl at gmx.net (Andreas Vogl) Date: Mon Jun 6 06:53:39 2005 Subject: [crossfire] Java Editor Message-ID: <26403.1118058736@www1.gmx.net> In reply to Todd Mitchell: > The current Java Editor does not seem to be very stable. > Especially it tends to have a problem with really big maps > (can't open them) and eventually won't open maps and has > to be restarted. Behaves like a Memory leak? > Also sometimes the map window graphics are getting corrupted > by the file menus from the main window (something updating > the wrong container?) I don't know about the memory leaks, but I do have an idea what may cause the graphic corruptions in some places: In some of the older JREs, it was difficult to force an immediate redraw of a component. The "Component.repaint()" method, which is supposed to do the job, sometimes did not do it, because the JRE somehow tried to be smart about it and postponed the redraw when there was other important stuff to do. For that reason I sometimes used the following hack to force a repaint: // JComponent myComponent; myComponent.update(myComponent.getGraphics()); // forced redraw, buggy This leads to drawing glitches in modern JREs, in fact it may have caused trouble all along. In modern JREs the "Component.repaint()" works perfectly reliable and should in all cases replace the hack as seen above. Search for the string ".getGraphics" in the java sources to find the buggers, and change into: // JComponent myComponent; myComponent.repaint(); // forced redraw, safe Im not 100% sure wether this will make all graphic glitches go away, but at least some of them probably. It should be done anyways. Greetings, AndreasV -- Geschenkt: 3 Monate GMX ProMail gratis + 3 Ausgaben stern gratis ++ Jetzt anmelden & testen ++ http://www.gmx.net/de/go/promail ++ From mikeeusaaa at yahoo.com Mon Jun 6 17:42:07 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Mon Jun 6 17:43:46 2005 Subject: [crossfire] Color Spray In-Reply-To: <42A3BC17.8030001@telus.net> Message-ID: <20050606224207.41227.qmail@web61025.mail.yahoo.com> Perhapse it's time to PUMP (THE SPELL) UP! ... and maybe make circular spells talked about earlier... please... --- Alex Schultz wrote: > ERACC wrote: > > >I cannot believe HOW neutered this spell is. It > used to be an awesome > >spell worth the effort of going to get. Now I am > sorry I wasted an > >entire evening going to get it on > crossfire.metalforge.net earlier. > >As hard as it is to get this spell it should be at > least as powerful > >as I remember it being. What's with neutering > hard-to-get spells? > > > >Can the spell be returned to its' former glory, > please? Otherwise it > >just takes up space in my spell list. Level 46 > sorcery and it takes > >THREE casts of color spray to kill about 10 - 15 > Fiends. They should > >ALL be dead in one cast based on how the spell USED > to work. > > > I agree, it's currently underpowered to the point > where it's useless > even when it might otherwise be attractive due to > it's variety of > attacktypes being difficult to resist. Even if I > inscribe lots of > scrolls of it that are about lvl 100, it can't even > graze a lvl 60 in > the arena or any monster that's of the slightest > worth. > The balance of the spell might currently be ok for a > lvl 15-30, however > it's near impossible for a lvl 15-30 to get it > considering the quest > it's in and the fact that spellbooks can't be > carried out. > > Alex Schultz > > _______________________________________________ > 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 Tue Jun 7 00:17:18 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Jun 7 00:15:50 2005 Subject: [crossfire] Color Spray In-Reply-To: <20050606224207.41227.qmail@web61025.mail.yahoo.com> References: <20050606224207.41227.qmail@web61025.mail.yahoo.com> Message-ID: <42A52DDE.1010008@sonic.net> Mitch Obrian wrote: > Perhapse it's time to PUMP (THE SPELL) UP! > ... > and maybe make circular spells talked about earlier... > please... > What do you mean by circular spells? Cone spells can already be cast in a 'circular' fashion if you fire on your own position (shift .) and not a specific direction. And the space you are in will not be affected by the spell. From mikeeusaaa at yahoo.com Tue Jun 7 00:25:14 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Tue Jun 7 00:25:49 2005 Subject: [crossfire] Color Spray In-Reply-To: <42A52DDE.1010008@sonic.net> Message-ID: <20050607052514.79450.qmail@web61013.mail.yahoo.com> Some new spell ideas me and red were discussing. --- Mark Wedel wrote: > Mitch Obrian wrote: > > Perhapse it's time to PUMP (THE SPELL) UP! > > ... > > and maybe make circular spells talked about > earlier... > > please... > > > > What do you mean by circular spells? > > Cone spells can already be cast in a 'circular' > fashion if you fire on your > own position (shift .) and not a specific direction. > And the space you are in > will not be affected by the spell. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Discover Yahoo! Find restaurants, movies, travel and more fun for the weekend. Check it out! http://discover.yahoo.com/weekend.html From mwedel at sonic.net Tue Jun 7 00:28:44 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Jun 7 00:29:42 2005 Subject: [crossfire] Pet Peeve - converters/altars/other that take gold, not money. Message-ID: <42A5308C.1010700@sonic.net> This is an old pet peeve of mine - originally, I thought it was just a matter of old maps not being updated, but I'm seeing new maps that are similarly broken. What is basically comes down to is altars, converter tables, etc that require gold. You can't use platinum, you can't use silver, it must be gold and only gold. This then requires that you go to the bank, convert that platinum to gold, go back, etc. If you set the altar/converter to take 'money' instead of 'gold' or other coinage, it will take the appropriate sum of money (it has to be all of one type of money, and it won't make change). Not that money is in silver pieces, so to convert existing objects, the sacrifice count needs to be increased. Maybe map designers don't know about this. I can't think of any compelling reason that the requirement should be gold. After all, when you to the shop to sell stuff, they pay you in platinum. There are tables to convert from one coinage to another with no extra fee. If you buy stuff from a shop, it will take any of those currencies. If one were to think about this in modern currency terms, it'd be like a place saying it will only take $5 bills, and not $20 bills (substitute $ for currency of choice). Such a policy could make sense if you're being something for $15, but most all the tables I've seen are wanting sums in the hundreds, if not thousands - surely such tables would prefer the bigger currency and not the small bills. From mikeeusaaa at yahoo.com Tue Jun 7 00:47:25 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Tue Jun 7 00:47:51 2005 Subject: [crossfire] Pet Peeve - converters/altars/other that take gold, not money. In-Reply-To: <42A5308C.1010700@sonic.net> Message-ID: <20050607054725.10606.qmail@web61020.mail.yahoo.com> On one of my map areas the kingdom that owns the area is short on gold due to dwarves taking over the mines. Thus it want's people to pay in gold rather then silver etc. (This is explained in the maps). It has a boat load of emeralds though... so it pays you in emeralds for stuff you do etc. For most things though... peeps just probably don't know. --- Mark Wedel wrote: > > This is an old pet peeve of mine - originally, I > thought it was just a matter > of old maps not being updated, but I'm seeing new > maps that are similarly broken. > > What is basically comes down to is altars, > converter tables, etc that require > gold. You can't use platinum, you can't use silver, > it must be gold and only gold. > > This then requires that you go to the bank, > convert that platinum to gold, go > back, etc. > > If you set the altar/converter to take 'money' > instead of 'gold' or other > coinage, it will take the appropriate sum of money > (it has to be all of one type > of money, and it won't make change). Not that money > is in silver pieces, so to > convert existing objects, the sacrifice count needs > to be increased. > > Maybe map designers don't know about this. I > can't think of any compelling > reason that the requirement should be gold. After > all, when you to the shop to > sell stuff, they pay you in platinum. There are > tables to convert from one > coinage to another with no extra fee. If you buy > stuff from a shop, it will > take any of those currencies. > > If one were to think about this in modern currency > terms, it'd be like a place > saying it will only take $5 bills, and not $20 bills > (substitute $ for currency > of choice). Such a policy could make sense if > you're being something for $15, > but most all the tables I've seen are wanting sums > in the hundreds, if not > thousands - surely such tables would prefer the > bigger currency and not the > small bills. > > > > _______________________________________________ > 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 tchize at myrealbox.com Tue Jun 7 14:27:39 2005 From: tchize at myrealbox.com (tchize) Date: Tue Jun 7 14:29:56 2005 Subject: [crossfire] Java Editor In-Reply-To: <1117996849.3991.7.camel@oberon.kameria> References: <1117996849.3991.7.camel@oberon.kameria> Message-ID: <200506072127.45923.tchize@myrealbox.com> Memory leak fixed in CVS. The fix however does only work with 1.5 jvm, there seems to be a bug in 1.4 jvm so the InternalFrame used by mapviews is not freed even if editor code is not using it anymore and dispose() was called. Note: this leak was very hard to find out, and i located the problem in a surprising part of code, the mapcontrols were used as key to the undo stack hashtable. Calls to getInstance(activemap) on this stack did the offending referencing. Those calls were done by refresh of toolbar, so every opened map got added there. The stack depth to get there was of 62 (very nice to follow). Fixed by using a weakhashmap (weak references does allow garbage collecting). I wouldn't have found the bad guy if it wasn't for the help of a tool named jprofiler. This tool costs a 179euro licence fee for educational. Does someone want to make a donation? :D PS: can someone test with blackdown? Le Dimanche 05 Juin 2005 20:40, Todd Mitchell a ?crit : >The current Java Editor does not seem to be very stable. Especially it >tends to have a problem with really big maps (can't open them) and >eventually won't open maps and has to be restarted. Behaves like a >Memory leak? Also sometimes the map window graphics are getting >corrupted by the file menus from the main window (something updating the >wrong container?) > >This is on Debian using Blackdown J2re 1.4.2 and the editor was built >from current CVS (a few tries) using ant 1.6.2. Prior versions worked >pretty good on this same platform. -- -- 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/20050607/1f2a36f9/attachment.pgp From eracclists at bellsouth.net Wed Jun 8 00:11:08 2005 From: eracclists at bellsouth.net (ERACC) Date: Wed Jun 8 00:12:03 2005 Subject: [crossfire] Java Editor In-Reply-To: <200506072127.45923.tchize@myrealbox.com> References: <1117996849.3991.7.camel@oberon.kameria> <200506072127.45923.tchize@myrealbox.com> Message-ID: <200506080011.08399.eracclists@bellsouth.net> On Tuesday 07 June 2005 02:27 pm tchize wrote: > Memory leak fixed in CVS. [...] Thank you, thank you, thank you! Brendan L. made a .jar file and put it up on his web space. I have a copy of JUST the CFJavaEditor.jar on my site here (includes *none* of the resource stuff): http://www.eracc.com/files/CFJavaEditor.jar.tar.gz It runs fine with my 'java version "1.5.0_03"'. I'll leave it up to Brendan to share his URL. :-) Gene -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 00:04:03 up 21 days, 41 min, 8 users, load average: 0.32, 0.21, 0.17 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandriva Linux, OpenServer & UnixWare resellers From lalo at exoweb.net Wed Jun 8 01:02:35 2005 From: lalo at exoweb.net (Lalo Martins) Date: Wed Jun 8 01:26:04 2005 Subject: [crossfire] Re: Java Editor In-Reply-To: <200506080011.08399.eracclists@bellsouth.net> References: <1117996849.3991.7.camel@oberon.kameria> <200506072127.45923.tchize@myrealbox.com> <200506080011.08399.eracclists@bellsouth.net> Message-ID: And so says ERACC on 06/08/2005 01:11 PM... > http://www.eracc.com/files/CFJavaEditor.jar.tar.gz (0.5 off-topic) Gene, I'm under the impression that a jar is a glorified zip file; is there any benefit in making a tar.gz of it? 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.exoweb.net/ mailto:lalo@exoweb.net GNU: never give up freedom http://www.gnu.org/ From eracclists at bellsouth.net Wed Jun 8 02:40:48 2005 From: eracclists at bellsouth.net (ERACC) Date: Wed Jun 8 02:42:05 2005 Subject: [crossfire] Re: Java Editor In-Reply-To: References: <1117996849.3991.7.camel@oberon.kameria> <200506080011.08399.eracclists@bellsouth.net> Message-ID: <200506080240.49461.eracclists@bellsouth.net> On Wednesday 08 June 2005 01:02 am Lalo Martins wrote: > And so says ERACC on 06/08/2005 01:11 PM... > > http://www.eracc.com/files/CFJavaEditor.jar.tar.gz > > (0.5 off-topic) > > Gene, I'm under the impression that a jar is a glorified zip file; Basically, it is. > is there any benefit in making a tar.gz of it? Yes, for broken browsers (if used for DL) that will attempt to open the file in a window because they have no clue what a .jar is. Most browsers should know how to handle .tar.gz by now. I would just use wget and not worry about the extension but I realize not everyone does things the way I do. Could also use .zip extension in place of .jar (I think, haven't tried that so going on anecdotal mention) but that might be a wee bit confusing to some who would DL and attempt to unzip it. Gene -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 02:33:41 up 21 days, 3:10, 8 users, load average: 0.51, 0.42, 0.42 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandriva Linux, OpenServer & UnixWare resellers From tchize at myrealbox.com Wed Jun 8 02:57:23 2005 From: tchize at myrealbox.com (tchize) Date: Wed Jun 8 02:58:05 2005 Subject: [crossfire] Re: Java Editor In-Reply-To: <200506080240.49461.eracclists@bellsouth.net> References: <1117996849.3991.7.camel@oberon.kameria> <200506080240.49461.eracclists@bellsouth.net> Message-ID: <200506080957.23862.tchize@myrealbox.com> Just configure your apache server to associated .jar files to file type application/octets-stream, this should force every browser to download Le Mercredi 8 Juin 2005 09:40, ERACC a ?crit : > On Wednesday 08 June 2005 01:02 am > > Lalo Martins wrote: > > And so says ERACC on 06/08/2005 01:11 PM... > > > > > http://www.eracc.com/files/CFJavaEditor.jar.tar.gz > > > > (0.5 off-topic) > > > > Gene, I'm under the impression that a jar is a glorified zip file; > > Basically, it is. > > > is there any benefit in making a tar.gz of it? > > Yes, for broken browsers (if used for DL) that will attempt to open > the file in a window because they have no clue what a .jar is. Most > browsers should know how to handle .tar.gz by now. I would just use > wget and not worry about the extension but I realize not everyone > does things the way I do. > > Could also use .zip extension in place of .jar (I think, haven't > tried that so going on anecdotal mention) but that might be a wee bit > confusing to some who would DL and attempt to unzip it. > > Gene From eracclists at bellsouth.net Wed Jun 8 12:28:51 2005 From: eracclists at bellsouth.net (ERACC) Date: Wed Jun 8 12:29:21 2005 Subject: [crossfire] Re: Java Editor In-Reply-To: <200506080957.23862.tchize@myrealbox.com> References: <1117996849.3991.7.camel@oberon.kameria> <200506080240.49461.eracclists@bellsouth.net> <200506080957.23862.tchize@myrealbox.com> Message-ID: <200506081228.51288.eracclists@bellsouth.net> On Wednesday 08 June 2005 02:57 am tchize wrote: > Le Mercredi 8 Juin 2005 09:40, ERACC a ?crit : > > On Wednesday 08 June 2005 01:02 am > > > > Lalo Martins wrote: > > > And so says ERACC on 06/08/2005 01:11 PM... > > > > > > > http://www.eracc.com/files/CFJavaEditor.jar.tar.gz > > > > > > is there any benefit in making a tar.gz of it? > > > > Yes, for broken browsers (if used for DL) that will attempt to open > > the file in a window because they have no clue what a .jar is. Most > > browsers should know how to handle .tar.gz by now. I would just use > > wget and not worry about the extension but I realize not everyone > > does things the way I do. > > Just configure your apache server to associated .jar files to file type > application/octets-stream, this should force every browser to download I would do that, if it were my server. I am using a web host so I can get the benefits of their larger bandwidth. But, using a web host means I don't have access to the apache config files. I know I could use .htaccess for odd mime types but I also don't like messing with my site more than necessary. I really just don't want to do it. :-) Gene -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 12:19:11 up 21 days, 12:56, 8 users, load average: 0.06, 0.10, 0.04 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandriva Linux, OpenServer & UnixWare resellers From temitchell at sympatico.ca Wed Jun 8 17:55:09 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Wed Jun 8 17:56:15 2005 Subject: [crossfire] Java Editor In-Reply-To: <200506072127.45923.tchize@myrealbox.com> References: <1117996849.3991.7.camel@oberon.kameria> <200506072127.45923.tchize@myrealbox.com> Message-ID: <1118271309.3867.1.camel@oberon.kameria> Sure, Blackdown j2re1.4.2 still shows the leak (not sure there is a blackdown 1.5 yet). On Tue, 2005-07-06 at 21:27 +0200, tchize wrote: > Memory leak fixed in CVS. The fix however does only work with 1.5 jvm, there > seems to be a bug in 1.4 jvm so the InternalFrame used by mapviews is not > freed even if editor code is not using it anymore and dispose() was called. > > PS: can someone test with blackdown? From lalo at exoweb.net Wed Jun 8 23:31:03 2005 From: lalo at exoweb.net (Lalo Martins) Date: Wed Jun 8 23:34:17 2005 Subject: [crossfire] Re: Java Editor In-Reply-To: <200506081228.51288.eracclists@bellsouth.net> References: <1117996849.3991.7.camel@oberon.kameria> <200506080240.49461.eracclists@bellsouth.net> <200506080957.23862.tchize@myrealbox.com> <200506081228.51288.eracclists@bellsouth.net> Message-ID: And so says ERACC on 06/09/2005 01:28 AM... > I really just don't want to do it. :-) then what about just .jar.gz? :-) 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.exoweb.net/ mailto:lalo@exoweb.net GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Thu Jun 9 00:04:16 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jun 9 00:04:18 2005 Subject: [crossfire] new metaserver In-Reply-To: <20050605164150.91134.qmail@web61016.mail.yahoo.com> References: <20050605164150.91134.qmail@web61016.mail.yahoo.com> Message-ID: <42A7CDD0.7060606@sonic.net> Mitch Obrian wrote: > Cave's php metaservers are great. The sms's are sent > the data by the servers. They then send the info to > the cms which sends the info to the other sms's. This > way (since the sms's are trusted) the cms is unDoSable > as it's ip is unknown except for the trusted sms. > Since cave's metaservers are written in php they can > be hosted anywhere... including hosting companies with > near unlimited bandwidth. seems to me that making the CMS ip secret is just security through obscurity. Once someone discovers that IP through whatever method, you lose that benefit - this means the CMS has to be secure on its own. > > We should implement it, it has been written. It is > good. The time for discussing how it should be done is > passed as we allready have a product now. You discussed the metaserver/program before, however, when asked to provide link/URL, did not provide one. Trying to search for info on it is pretty meaningless, as cave is just too common a word. From elshar at cheekan.org Thu Jun 9 14:19:09 2005 From: elshar at cheekan.org (Michael) Date: Thu Jun 9 14:10:26 2005 Subject: [crossfire] new metaserver In-Reply-To: <42A7CDD0.7060606@sonic.net> References: <20050605164150.91134.qmail@web61016.mail.yahoo.com> <42A7CDD0.7060606@sonic.net> Message-ID: <42A8962D.8080602@cheekan.org> I'm not sure if its been suggested, and I'm probably missing some part of the discussion. I heard somewhere on the list that the metaserver required the use of udp, which is easily spoofable. By that I mean that no connection handshake required to start data transfer, and most isps don't seem to bother to check if the packets leaving their network should be doing so... So how about changing it to tcp, and have the server connect to the metaserver via a spawned thread (I read somewhere, possibly same thread that changing to tcp would cause issues with the game server.. This would 'fix' that, imo)? Maybe have the metaserver throw the requesting server some kind of randomly generated key that the requesting server has to reply to. Also, if you wanted to do the multiple metaserver thing (I can't imagine why), you could structure it alot like irc servers are. By that I mean that you have ways of telling the meta servers which server is the 'master', which ones are other 'slaves', and which ones are game servers. And mechanisms to control behavior for all of them. Hell, you could probably write a small perl/php script to use an irc server as a metaserver. Then you'd already have all the parts. I think basically what I'm trying to say is that the game server shouldn't itself care if its contacted the metaserver. That should be a seperate proccess which 'checks in' every so often to give an update. And that those updates should be spaced far enough apart as to not be construed as a DOS with the meta server smart enough to realize that a repeated message from the same server isn't a seperate advertisement, but an update to the previous.. Granted, I'm totally ignorant of how the system works, but maybe this idea would be of use to someone. :) Mark Wedel wrote: > Mitch Obrian wrote: > >> Cave's php metaservers are great. The sms's are sent >> the data by the servers. They then send the info to >> the cms which sends the info to the other sms's. This >> way (since the sms's are trusted) the cms is unDoSable >> as it's ip is unknown except for the trusted sms. >> Since cave's metaservers are written in php they can >> be hosted anywhere... including hosting companies with >> near unlimited bandwidth. > > > seems to me that making the CMS ip secret is just security through > obscurity. Once someone discovers that IP through whatever method, > you lose that benefit - this means the CMS has to be secure on its own. > >> >> We should implement it, it has been written. It is >> good. The time for discussing how it should be done is >> passed as we allready have a product now. > > > You discussed the metaserver/program before, however, when asked to > provide link/URL, did not provide one. Trying to search for info on > it is pretty meaningless, as cave is just too common a word. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From mikeeusaaa at yahoo.com Thu Jun 9 15:03:24 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Thu Jun 9 15:04:26 2005 Subject: [crossfire] new metaserver In-Reply-To: <42A7CDD0.7060606@sonic.net> Message-ID: <20050609200324.97755.qmail@web61012.mail.yahoo.com> Obsurity is just one layer of security. It is used by IRC servers rather sucessfully for their hub server. http://cavetroll.uwcs.co.uk/ http://cavetroll.uwcs.co.uk/metaserver/ --- Mark Wedel wrote: > Mitch Obrian wrote: > > Cave's php metaservers are great. The sms's are > sent > > the data by the servers. They then send the info > to > > the cms which sends the info to the other sms's. > This > > way (since the sms's are trusted) the cms is > unDoSable > > as it's ip is unknown except for the trusted sms. > > Since cave's metaservers are written in php they > can > > be hosted anywhere... including hosting companies > with > > near unlimited bandwidth. > > seems to me that making the CMS ip secret is just > security through obscurity. > Once someone discovers that IP through whatever > method, you lose that benefit > - this means the CMS has to be secure on its own. > > > > > We should implement it, it has been written. It is > > good. The time for discussing how it should be > done is > > passed as we allready have a product now. > > You discussed the metaserver/program before, > however, when asked to provide > link/URL, did not provide one. Trying to search for > info on it is pretty > meaningless, as cave is just too common a word. > > > _______________________________________________ > 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 B.T.Lally at warwick.ac.uk Thu Jun 9 20:54:27 2005 From: B.T.Lally at warwick.ac.uk (Brendan Lally) Date: Thu Jun 9 20:56:30 2005 Subject: [crossfire] new metaserver Message-ID: >>> mikeeusaaa@yahoo.com 06/09/05 21:07 PM >>> > Obsurity is just one layer of security. It is used by > IRC servers rather sucessfully for their hub server. > http://cavetroll.uwcs.co.uk/ > http://cavetroll.uwcs.co.uk/metaserver/ er, that one doesn't actually work properly, (an issue with perl modules), so is probably not the best link to use. In fact I don't actually have a stable one set up, this is more due to the fact that to have multiple servers, they need to be set up independently, and whenever I have done that, I have tended to alter one or the other.... best bet is to look at the patch that is on the tracker, since the metaserver/metametaserver don't have online help anyway. (they have a README in the tarball though...) https://sourceforge.net/tracker/index.php?func=detail&aid=1208250&group_id=13833&atid=313833 From B.T.Lally at warwick.ac.uk Thu Jun 9 20:59:43 2005 From: B.T.Lally at warwick.ac.uk (Brendan Lally) Date: Thu Jun 9 21:02:31 2005 Subject: [crossfire] new metaserver Message-ID: >>> mwedel@sonic.net 06/09/05 06:08 AM >>> > seems to me that making the CMS ip secret is just security through obscurity. > Once someone discovers that IP through whatever method, you lose that benefit > - this means the CMS has to be secure on its own. Yeah, what I have had in mind all along is that the metametaserver/CMS wouldn't just be a secret, but that it would be firewalled off from /all/ incoming requests except from the SMS's Knowing the IP adress wouldn't do an attacker any good unless they had a SMS being the attacker, and it is pretty hard to launch an attack when there are only a score of ip adresses to attack from and get replies. That isn't security through obscurity, it is security through dropping packets... From mwedel at sonic.net Fri Jun 10 00:27:27 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Jun 10 00:26:32 2005 Subject: [crossfire] new metaserver In-Reply-To: References: Message-ID: <42A924BF.7000508@sonic.net> A few more notes/thoughts: For the server, switching to tcp is perhaps a good thing. What I'd actually think is the best thing is there to be a small helper program that the server executes, and then talks to that helper program then a named socket (or perhaps just a pipe). The server could send the helper program things like number of players and any other dynamic data (for the static date, the helper program could just read the settings file). This then eliminates the problem of costly or dead connections to the metaserver - only the the helper program would have any issue, and it can basically take as much time as it wants (if it takes 5 minutes to make the connection, not a big deal). This helper program can also be quite small so the cost of the initial pipe creation isn't that big (and if it dies, not very costly for the server to restart). The one concern I have about tcp is number of active connections allowed to the meta server. Most OS's put some limit on the number of open file descriptors any program can have - often set at 1024 or lower. Thus, a perfectly valid DDOS attack is for a bunch of systems to just make connections to the metaserver and just keep the connection active. Maybe this is unlikely - never really had an attack like that on existing server. The metaserver can obviously enforce the idea of only 1 connection from 1 ip address, so getting 1000+ hacked systems might be unlikely. But the fact is that if you want to make persistent connections, you can't do that to a web server script I don't believe. OTOH, I'm not sure how quickly web servers will time out connections. But it also just seems inefficient to have to execute an entire script for each update - having a persistent program is much more efficient in all its processing. IT just means you can't run such a program on any web server. One possibility is a hybrid approach - trusted SMS can update the CMS. Servers can talk to the CMS directly. Just one other note - having something done first does not mean that is the way to go. This is not any comment on Brendan's work, but the argument 'xyz has done this so you should use it' holds no weight to me. This approach has certainly be used a few times in crossfire, and if that first approach isn't a good one, it just results in extra work, as that code has to be fixed/removed/redone/whatever. If one takes this approach, then any code that anyone submits to crossfire should just be accepted, and that certainly wouldn't be a good thing. As said, this doesn't reflect on the code in the patch - I haven't looked over that closely enough to make any comment on it. But I will make the comment that it seems to be missing the server -> metaserver notification piece, and IMO that is really the core piece, because that is the one where the most problems can arise (eg, you can't cause the server to block, you don't want a slow update time, but you still want to provide dynamic data. The small helper program I mention above is probably the way to fix that, and actually should be pretty easy to do). From b.t.lally at warwick.ac.uk Mon Jun 13 00:24:08 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Mon Jun 13 00:03:15 2005 Subject: [crossfire] new metaserver In-Reply-To: <42A924BF.7000508@sonic.net> References: <42A924BF.7000508@sonic.net> Message-ID: <200506130624.09093.b.t.lally@warwick.ac.uk> On Friday 10 June 2005 06:27, Mark Wedel wrote: > A few more notes/thoughts: > > For the server, switching to tcp is perhaps a good thing. What I'd > actually think is the best thing is there to be a small helper program that > the server executes, and then talks to that helper program then a named > socket (or perhaps just a pipe). The server could send the helper program > things like number of players and any other dynamic data (for the static > date, the helper program could just read the settings file). This seems like a nice idea, it has the added benefit of making it possibile to send data about servers that are down, (assuming that it keeps running, and new servers speak to it...) as well as those that are up. (if the server isn't updating data to the subproccess, then it could notify the metaserver that the server is unresponsive, which is probably more useful than having a server suddenly disappear from the list. > But the fact is that if you want to make persistent connections, you > can't do that to a web server script I don't believe. OTOH, I'm not sure > how quickly web servers will time out connections. But it also just seems > inefficient to have to execute an entire script for each update - having a > persistent program is much more efficient in all its processing. IT just > means you can't run such a program on any web server. For a well configured web server, something like mod_php or zend or similar will be running anyway, the scripts will be acting like compiled code in many respects. It will still be slower than a well written independent program, but then that is the price that is paid for having a web server handle all of the availability stuff. > Just one other note - having something done first does not mean that is > the way to go. > 'xyz has done this so you should use it' holds no weight to me. Which is why I didn't do it first, what I have done is mostly just a couple of php and perl scripts, which use libraries to deal with the connection issues, should they end up doing something vaguely similar to their current function, the changes are mostly changing port numbers, and maybe a couple of lines of function calls. > As said, this doesn't reflect on the code in the patch - I haven't looked > over that closely enough to make any comment on it. But I will make the > comment that it seems to be missing the server -> metaserver notification > piece, and IMO that is really the core piece, because that is the one where > the most problems can arise This was the reason that I hadn't done that before starting this thread, as you say, that is the core piece, and also the one that is likely to be very specific to the actually form of the implementation. So I was going to leave it until last. By comparison, however the final system is implemented, the client /will/ connect to a server and parse some information recieved from it. However that server is configured, libcurl can pretty much cope, so writing a fairly generic parser attached to libcurl is a nice base to begin from, should libcurl be disliked as a dependancy, then it is simply a matter of adding the appropriate socket code later. > (eg, you can't cause the server to block, you > don't want a slow update time, but you still want to provide dynamic data. > The small helper program I mention above is probably the way to fix that, > and actually should be pretty easy to do). [notwithstanding the paragraphs before this one.] It seems to have been mostly done already.... watchdog when it is compiled in has the server send UDP packets to a local socket. AFAICT it doesn't really matter to much /what/ it sends, so it might as well send the data that the metaserver will use, in that case then the program you describe would end up looking similar to crossfire/utils/crossfire-loop.c (though maybe in perl?) The only problem I can really see is that such an approach would probably fail on a windows system. From kirschbaum at myrealbox.com Tue Jun 14 16:16:37 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Tue Jun 14 16:17:37 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: maps-bigworld/scorn/shops In-Reply-To: References: Message-ID: <20050614211637.GA20683@kirschbaum.myrealbox.com> > Module Name: maps-bigworld > Committed By: eracc > Date: Tue Jun 14 03:46:45 UTC 2005 > > Modified Files: > maps-bigworld/scorn/shops: scorn.sale1 > > Log Message: > Major overhaul. New look. Made the area around the entrance mat No > Sale so lazy dinks would quit dropping crap there. The new woodfloor tiles ("No Sale Area") allows the use of word of recall. Therefore you now can steal unpaid items from the shop. From eracclists at bellsouth.net Tue Jun 14 16:23:27 2005 From: eracclists at bellsouth.net (ERACC) Date: Tue Jun 14 16:25:39 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: maps-bigworld/scorn/shops In-Reply-To: <20050614211637.GA20683@kirschbaum.myrealbox.com> References: <20050614211637.GA20683@kirschbaum.myrealbox.com> Message-ID: <200506141623.27601.eracclists@bellsouth.net> On Tuesday 14 June 2005 04:16 pm Andreas Kirschbaum wrote: > > Module Name: maps-bigworld > > Committed By: eracc > > Date: Tue Jun 14 03:46:45 UTC 2005 > > > > Modified Files: > > maps-bigworld/scorn/shops: scorn.sale1 > > > > Log Message: > > Major overhaul. New look. Made the area around the entrance mat No > > Sale so lazy dinks would quit dropping crap there. > > The new woodfloor tiles ("No Sale Area") allows the use of word of > recall. Therefore you now can steal unpaid items from the shop. Oops, I thought I made those damned. Will fix asap. Gene -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 16:22:59 up 27 days, 17:01, 8 users, load average: 0.07, 0.05, 0.01 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandriva Linux, OpenServer & UnixWare resellers From eracclists at bellsouth.net Tue Jun 14 16:37:05 2005 From: eracclists at bellsouth.net (ERACC) Date: Tue Jun 14 16:37:38 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: maps-bigworld/scorn/shops In-Reply-To: <20050614211637.GA20683@kirschbaum.myrealbox.com> References: <20050614211637.GA20683@kirschbaum.myrealbox.com> Message-ID: <200506141637.06011.eracclists@bellsouth.net> On Tuesday 14 June 2005 04:16 pm Andreas Kirschbaum wrote: > > Module Name: maps-bigworld > > Committed By: eracc > > Date: Tue Jun 14 03:46:45 UTC 2005 > > > > Modified Files: > > maps-bigworld/scorn/shops: scorn.sale1 > > > > Log Message: > > Major overhaul. New look. Made the area around the entrance mat No > > Sale so lazy dinks would quit dropping crap there. > > The new woodfloor tiles ("No Sale Area") allows the use of word of > recall. Therefore you now can steal unpaid items from the shop. Fix submitted to CVS and on tracker for quick fixes: http://sourceforge.net/tracker/index.php?func=detail&aid=1220774&group_id=13833&atid=313833 Gene -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 16:35:58 up 27 days, 17:13, 8 users, load average: 0.15, 0.15, 0.08 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandriva Linux, OpenServer & UnixWare resellers From mwedel at sonic.net Thu Jun 16 00:02:24 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jun 16 00:01:58 2005 Subject: [crossfire] new metaserver In-Reply-To: <200506130624.09093.b.t.lally@warwick.ac.uk> References: <42A924BF.7000508@sonic.net> <200506130624.09093.b.t.lally@warwick.ac.uk> Message-ID: <42B107E0.7040901@sonic.net> Brendan Lally wrote: > On Friday 10 June 2005 06:27, Mark Wedel wrote: > >> A few more notes/thoughts: >> >> For the server, switching to tcp is perhaps a good thing. What I'd >>actually think is the best thing is there to be a small helper program that >>the server executes, and then talks to that helper program then a named >>socket (or perhaps just a pipe). The server could send the helper program >>things like number of players and any other dynamic data (for the static >>date, the helper program could just read the settings file). > > > This seems like a nice idea, it has the added benefit of making it possibile > to send data about servers that are down, (assuming that it keeps running, > and new servers speak to it...) as well as those that are up. (if the server > isn't updating data to the subproccess, then it could notify the metaserver > that the server is unresponsive, which is probably more useful than having a > server suddenly disappear from the list. Yes - that depends on implementation. Ideally, a down server is automatically restarted, but I suppose there are cases that doesn't happen. Since server updates may be sporadic, presumably the metaservers won't drop the listing for a server until some amount of time passes (30 minutes or something). Note also that the current metaserver tracks when it last got an update from a server, and does provide that information to the client (I haven't heard from this server in xyz seconds). > For a well configured web server, something like mod_php or zend or similar > will be running anyway, the scripts will be acting like compiled code in many > respects. It will still be slower than a well written independent program, > but then that is the price that is paid for having a web server handle all of > the availability stuff. Right - I'm not sure the cost of doing it web server based vs independent program. For the number of crossfire servers we're talking about, probably not a big deal in any case - although with it being web server based, you do have to be concerned with things like file locking, which may not scale will with large number of updates happening - this is mostly because it has to do all updates through a file. A standalone metaserver has the advantage it only has to do some locking on the data structures, and only periodically needs to write it out to a few (say every few minutes for backup purposes). The php one has to read/write the file every time in gets an update. As said, for the number of servers we have, may not be a big dea. > By comparison, however the final system is implemented, the client /will/ > connect to a server and parse some information recieved from it. However that > server is configured, libcurl can pretty much cope, so writing a fairly > generic parser attached to libcurl is a nice base to begin from, should > libcurl be disliked as a dependancy, then it is simply a matter of adding the > appropriate socket code later. I never like adding new dependencies if it can be avoided. As a data point, my system did not have libcurl installed on to it. In my ideal world, the metaservers should be able to provide information in both 'pretty' html and something raw. One could envision this by something like: http://myhost/metaserver.php giving nice html output, and something like: http://myhost/metaserver.php?output=raw providing real raw output (something like we have now). I think however the client would still have to toss the http headers, but that shouldn't be too bad. > > watchdog when it is compiled in has the server send UDP packets to a local > socket. AFAICT it doesn't really matter to much /what/ it sends, so it might > as well send the data that the metaserver will use, in that case then the > program you describe would end up looking similar to > crossfire/utils/crossfire-loop.c (though maybe in perl?) IMO, the metaserver notification helper has to be started automatically by the server, and not be an external entity started via script (like the watchdog one uses). This is simply easy of use - otherwise the problem is that someone starts it by hand, or uses their own monitoring script and don't send metaserver updates when they should. Also, it is probably nice for the metaserver updater to be connected via tcp or pipe to the server, so each can know when the other dies. If the helper sees the server dies, it can send a last update to the metaserver informing it that the server just died, and then exit. If the server sees the helper dies for any reason, it can start up another copy. The problem with the udp notification and watchdog is that the watchdog could be dead and server would never know. The helper program also needs to have some basic security - making sure the connection is coming from the local host and not something remote (don't want some remote host connecting to the helper and forging information). The other nice bit about the helper and server talking via tcp is the potential, perhaps in the future, for the helper to talk back to the server with bits of information. I'm not sure what info that would be, but would still be nice to be able to do it. From b.t.lally at warwick.ac.uk Thu Jun 16 18:40:13 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Thu Jun 16 18:20:09 2005 Subject: [crossfire] new metaserver In-Reply-To: <42B107E0.7040901@sonic.net> References: <200506130624.09093.b.t.lally@warwick.ac.uk> <42B107E0.7040901@sonic.net> Message-ID: <200506170040.20314.b.t.lally@warwick.ac.uk> On Thursday 16 June 2005 06:02, Mark Wedel wrote: > Since server updates may be sporadic, presumably the metaservers won't > drop the listing for a server until some amount of time passes (30 minutes > or something). Note also that the current metaserver tracks when it last > got an update from a server, and does provide that information to the > client (I haven't heard from this server in xyz seconds). Yeah, that is another point, since the clients are breaking anyway, it is possible to prettify this output, and present it in human-readable form. (eg as 1h, 23m) > > > For a well configured web server, something like mod_php or zend or > > similar will be running anyway, the scripts will be acting like compiled > > code in many respects. It will still be slower than a well written > > independent program, but then that is the price that is paid for having a > > web server handle all of the availability stuff. > > Right - I'm not sure the cost of doing it web server based vs independent > program. For the number of crossfire servers we're talking about, probably > not a big deal in any case - although with it being web server based, you > do have to be concerned with things like file locking, which may not scale > will with large number of updates happening - this is mostly because it has > to do all updates through a file. A standalone metaserver has the > advantage it only has to do some locking on the data structures, and only > periodically needs to write it out to a few (say every few minutes for > backup purposes). The php one has to read/write the file every time in > gets an update. As said, for the number of servers we have, may not be a > big dea. Yes, I don't know how to get round this, although at least on a good webserver, if the files are accessed enough to matter, they shouldn't be leaving RAM. > > By comparison, however the final system is implemented, the client /will/ > > connect to a server and parse some information recieved from it. However > > that server is configured, libcurl can pretty much cope, so writing a > > fairly generic parser attached to libcurl is a nice base to begin from, > > should libcurl be disliked as a dependancy, then it is simply a matter of > > adding the appropriate socket code later. > > I never like adding new dependencies if it can be avoided. As a data > point, my system did not have libcurl installed on to it. sure, but for playing with prospective designs, libcurl is nice, since it is simply a case of changing a couple of lines to deal with a whole new protocol. Unless the final form is quite a complex protocol (and I don't think it will be) then replacing libcurl with direct socket access is quite straightforward. > In my ideal world, the metaservers should be able to provide information > in both 'pretty' html and something raw. One could envision this by > something like: > > http://myhost/metaserver.php > giving nice html output, and something like: > > http://myhost/metaserver.php?output=raw > or indeed, showservers.php and showserversclient.php, which were two of the first things that I wrote when I started to play with this. (since a webbrowser is easier to play with than some quickly crufted C code.) I haven't done file locking there because I am yet to get round to it. You could have a get call and merge the two I guess. > providing real raw output (something like we have now). I think however > the client would still have to toss the http headers, but that shouldn't be > too bad. Well, it can check that it got a 200, and if not try somewhere else automatically. > > watchdog when it is compiled in has the server send UDP packets to a > > local socket. AFAICT it doesn't really matter to much /what/ it sends, so > > it might as well send the data that the metaserver will use, in that case > > then the program you describe would end up looking similar to > > crossfire/utils/crossfire-loop.c (though maybe in perl?) > > IMO, the metaserver notification helper has to be started automatically > by the server, and not be an external entity started via script (like the > watchdog one uses). This is simply easy of use - otherwise the problem is > that someone starts it by hand, or uses their own monitoring script and > don't send metaserver updates when they should. True, but a fork and exec at startup can do that. > Also, it is probably nice for the metaserver updater to be connected via > tcp or pipe to the server, so each can know when the other dies. If the > helper sees the server dies, it can send a last update to the metaserver > informing it that the server just died, and then exit. If the server sees > the helper dies for any reason, it can start up another copy. The problem > with the udp notification and watchdog is that the watchdog could be dead > and server would never know. This is true, although to a certain extent the idea is that the watchdog is simple enough to not die. > The helper program also needs to have some basic security - making sure > the connection is coming from the local host and not something remote > (don't want some remote host connecting to the helper and forging > information). Is it insecure at the moment? It /is/ already in the server code, this was why I suggested using it, if it is there presumably it at least works in some fashion (although this has been shown to be false in the past). > The other nice bit about the helper and server talking via tcp is the > potential, perhaps in the future, for the helper to talk back to the server > with bits of information. I'm not sure what info that would be, but would > still be nice to be able to do it. Yes, Server intercommunication could then be done at the proper level, so that shouts could go between servers. Then tell would act in a similar way to jabber. eg, tell leaf@crossfire.metalforge.net or tell mikeeusa@cat2.dynu.ca with a missing @ obviously implying a local tell. possibly there could even be interserver postal service, and interserver querying of 'who' output (I don't know if that would be considered a good thing) I'm inclined to say even interserver balance transfers, although that would allow lots of potential for abuse.... From fuchs.andy at gmail.com Fri Jun 17 20:59:25 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Fri Jun 17 21:00:27 2005 Subject: [crossfire] new metaserver In-Reply-To: <200506170040.20314.b.t.lally@warwick.ac.uk> References: <200506130624.09093.b.t.lally@warwick.ac.uk> <42B107E0.7040901@sonic.net> <200506170040.20314.b.t.lally@warwick.ac.uk> Message-ID: On 6/16/05, Brendan Lally wrote: ... > Yes, Server intercommunication could then be done at the proper level, so that > shouts could go between servers. > > Then tell would act in a similar way to jabber. > eg, > > tell leaf@crossfire.metalforge.net > or > tell mikeeusa@cat2.dynu.ca > > with a missing @ obviously implying a local tell. > > possibly there could even be interserver postal service, and interserver > querying of 'who' output (I don't know if that would be considered a good > thing) > > I'm inclined to say even interserver balance transfers, although that would > allow lots of potential for abuse.... > Yes, but if if a whitelist of servers is used (along with encryption/signing) it would be feasable. There is also the posibility of playerfiles being transfered between servers (or more likely stored in a central database); so if there is enough load we could have: "metalforge1" + "metalforge2", and/or "cat2-1" + "cat2-2", with each set of servers working together, but independant from the other set. This is not needed now, but could be useful in the future. Besides IMO encryption is needed atleast for the player's passwords with the current client -> server protocol (could allow plaintext passwords for backwards compatability though). -- -- Andrew Fuchs From mwedel at sonic.net Sun Jun 19 16:51:18 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Jun 19 16:50:53 2005 Subject: [crossfire] new metaserver In-Reply-To: <200506170040.20314.b.t.lally@warwick.ac.uk> References: <200506130624.09093.b.t.lally@warwick.ac.uk> <42B107E0.7040901@sonic.net> <200506170040.20314.b.t.lally@warwick.ac.uk> Message-ID: <42B5E8D6.3030101@sonic.net> Brendan Lally wrote: >> Right - I'm not sure the cost of doing it web server based vs independent >>program. For the number of crossfire servers we're talking about, probably >>not a big deal in any case - although with it being web server based, you >>do have to be concerned with things like file locking, which may not scale >>will with large number of updates happening - this is mostly because it has >>to do all updates through a file. A standalone metaserver has the >>advantage it only has to do some locking on the data structures, and only >>periodically needs to write it out to a few (say every few minutes for >>backup purposes). The php one has to read/write the file every time in >>gets an update. As said, for the number of servers we have, may not be a >>big dea. > > > Yes, I don't know how to get round this, although at least on a good > webserver, if the files are accessed enough to matter, they shouldn't be > leaving RAM. True, but that is harder to predict. The OS will do the file caching, but if the webserver is busy enough, the cache hit rate might be poor. The flip side is that if the metaserver is used a lot, more likely that the file will be cached, and thus performance improves. But how the OS caches varies OS to OS. Linux is very aggressive on caching data, others less so. OTOH, if the core metaserver can be run as a non web program, I think there are still benefits from doing that. It's a little more work to write such a program, but probably not much. Related to this, how do the slave metaservers do updates? They can obviously only do anything when someone is requesting data from them. Do they look at their local cache modification time, and if it hasn't been updated in X minutes, go talk to the core metaserver to get up to date information? > >> In my ideal world, the metaservers should be able to provide information >>in both 'pretty' html and something raw. One could envision this by >>something like: >> >>http://myhost/metaserver.php >> giving nice html output, and something like: >> >>http://myhost/metaserver.php?output=raw >> > > > or indeed, showservers.php and showserversclient.php, which were two of the > first things that I wrote when I started to play with this. (since a > webbrowser is easier to play with than some quickly crufted C code.) > > I haven't done file locking there because I am yet to get round to it. > > You could have a get call and merge the two I guess. Probably not a big difference for them to be one program. Two seperate scripts work just fine. >>>watchdog when it is compiled in has the server send UDP packets to a >>>local socket. AFAICT it doesn't really matter to much /what/ it sends, so >>>it might as well send the data that the metaserver will use, in that case >>>then the program you describe would end up looking similar to >>>crossfire/utils/crossfire-loop.c (though maybe in perl?) >> >> IMO, the metaserver notification helper has to be started automatically >>by the server, and not be an external entity started via script (like the >>watchdog one uses). This is simply easy of use - otherwise the problem is >>that someone starts it by hand, or uses their own monitoring script and >>don't send metaserver updates when they should. > > > True, but a fork and exec at startup can do that. Right, but that then isn't really the watchdog program. >> Also, it is probably nice for the metaserver updater to be connected via >>tcp or pipe to the server, so each can know when the other dies. If the >>helper sees the server dies, it can send a last update to the metaserver >>informing it that the server just died, and then exit. If the server sees >>the helper dies for any reason, it can start up another copy. The problem >>with the udp notification and watchdog is that the watchdog could be dead >>and server would never know. > > > This is true, although to a certain extent the idea is that the watchdog is > simple enough to not die. Famous last words. But there are of course other possiblities beyond the watchdog having faults. Someone accidentally kills it. Something external to it causes it to fail (out of memory, disk error, whatever). And right now, if the watchdog does die, not a big deal - server continues to run, no one notices anything different. However, if the metaserver helper dies and is not noticed, then the server in question is no longer reported, which does cause problems I'd personally like things to be simpler - if a user can just run the main server, and everything works, that is much better them then having to restart the helper manually. > > >> The helper program also needs to have some basic security - making sure >>the connection is coming from the local host and not something remote >>(don't want some remote host connecting to the helper and forging >>information). > > > Is it insecure at the moment? It /is/ already in the server code, this was why > I suggested using it, if it is there presumably it at least works in some > fashion (although this has been shown to be false in the past). Right now, it appears insecure, in that a udp packet to port 13325 resets the watchdog timeout. The code does not appear to do any validation that the packet in fact came from the local host. the other problem is that it does use udp. While spoofing IP here probably isn't much a concern, it does mean that it is now very difficult for the server to know if that packet has been received, and thus if the helper is still alive. The other gotcha is that the main purpose of the watchdog program is to restart the server if it dies or is not responsive. The main perhaps of the metaserver helper program is to send data to the metaserver. I can envision cases where this helper could basically freeze up resolving IP addresses and trying to connect to them - in this case, this helper really can't be doing anything else, such as restarting the server if it crashes. IMO, much better for this to be a standalone program with a specific purpose. I otherwise fear if the watchdog program is modified, these short comings could make it not useful as a watchdog program anymore. > > >> The other nice bit about the helper and server talking via tcp is the >>potential, perhaps in the future, for the helper to talk back to the server >>with bits of information. I'm not sure what info that would be, but would >>still be nice to be able to do it. > > > Yes, Server intercommunication could then be done at the proper level, so that > shouts could go between servers. > > Then tell would act in a similar way to jabber. > eg, > > tell leaf@crossfire.metalforge.net > or > tell mikeeusa@cat2.dynu.ca > > with a missing @ obviously implying a local tell. > > possibly there could even be interserver postal service, and interserver > querying of 'who' output (I don't know if that would be considered a good > thing) > > I'm inclined to say even interserver balance transfers, although that would > allow lots of potential for abuse.... Well, I'll leave it open what data would go between servers. I'm a little reluctant to reinvent irc here - if we're going that route, lets just grab the ircd sources and use that. I say that because a potential fear I'd have about interserver shouts would be you could get a server with no DM on the moment and someone on that server shouting to another server and making things very annoying over there. That said, things like interstellar 'who' could be useful. If you have a friend that plays, but you're not always on the same server, being able to easily see where they are playing might be nice. But in any case, my main point was that by it being a 2 way communication, these things would in fact be posible. The metaserver helper program is really a bad name - what it really is is just a proxy (which could actually be in perl) - the main point of it being a proxy is so that timely blocking operations (dns looks) don't freeze the main server. From mikeeusaaa at yahoo.com Sun Jun 19 21:57:07 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sun Jun 19 22:00:55 2005 Subject: [crossfire] new metaserver In-Reply-To: <42B5E8D6.3030101@sonic.net> Message-ID: <20050620025707.42719.qmail@web61019.mail.yahoo.com> Most webservers out there are linux. This isn't a problem IMO. --- Mark Wedel wrote: > Brendan Lally wrote: > > >> Right - I'm not sure the cost of doing it web > server based vs independent > >>program. For the number of crossfire servers > we're talking about, probably > >>not a big deal in any case - although with it > being web server based, you > >>do have to be concerned with things like file > locking, which may not scale > >>will with large number of updates happening - this > is mostly because it has > >>to do all updates through a file. A standalone > metaserver has the > >>advantage it only has to do some locking on the > data structures, and only > >>periodically needs to write it out to a few (say > every few minutes for > >>backup purposes). The php one has to read/write > the file every time in > >>gets an update. As said, for the number of > servers we have, may not be a > >>big dea. > > > > > > Yes, I don't know how to get round this, although > at least on a good > > webserver, if the files are accessed enough to > matter, they shouldn't be > > leaving RAM. > > True, but that is harder to predict. The OS will > do the file caching, but if > the webserver is busy enough, the cache hit rate > might be poor. The flip side > is that if the metaserver is used a lot, more likely > that the file will be > cached, and thus performance improves. > > But how the OS caches varies OS to OS. Linux is > very aggressive on caching > data, others less so. > > OTOH, if the core metaserver can be run as a non > web program, I think there > are still benefits from doing that. It's a little > more work to write such a > program, but probably not much. > > Related to this, how do the slave metaservers do > updates? They can obviously > only do anything when someone is requesting data > from them. Do they look at > their local cache modification time, and if it > hasn't been updated in X minutes, > go talk to the core metaserver to get up to date > information? > > > > > >> In my ideal world, the metaservers should be > able to provide information > >>in both 'pretty' html and something raw. One > could envision this by > >>something like: > >> > >>http://myhost/metaserver.php > >> giving nice html output, and something like: > >> > >>http://myhost/metaserver.php?output=raw > >> > > > > > > or indeed, showservers.php and > showserversclient.php, which were two of the > > first things that I wrote when I started to play > with this. (since a > > webbrowser is easier to play with than some > quickly crufted C code.) > > > > I haven't done file locking there because I am yet > to get round to it. > > > > You could have a get call and merge the two I > guess. > > Probably not a big difference for them to be one > program. Two seperate > scripts work just fine. > > > >>>watchdog when it is compiled in has the server > send UDP packets to a > >>>local socket. AFAICT it doesn't really matter to > much /what/ it sends, so > >>>it might as well send the data that the > metaserver will use, in that case > >>>then the program you describe would end up > looking similar to > >>>crossfire/utils/crossfire-loop.c (though maybe in > perl?) > >> > >> IMO, the metaserver notification helper has to > be started automatically > >>by the server, and not be an external entity > started via script (like the > >>watchdog one uses). This is simply easy of use - > otherwise the problem is > >>that someone starts it by hand, or uses their own > monitoring script and > >>don't send metaserver updates when they should. > > > > > > True, but a fork and exec at startup can do that. > > Right, but that then isn't really the watchdog > program. > > > >> Also, it is probably nice for the metaserver > updater to be connected via > >>tcp or pipe to the server, so each can know when > the other dies. If the > >>helper sees the server dies, it can send a last > update to the metaserver > >>informing it that the server just died, and then > exit. If the server sees > >>the helper dies for any reason, it can start up > another copy. The problem > >>with the udp notification and watchdog is that the > watchdog could be dead > >>and server would never know. > > > > > > This is true, although to a certain extent the > idea is that the watchdog is > > simple enough to not die. > > Famous last words. But there are of course other > possiblities beyond the > watchdog having faults. Someone accidentally kills > it. Something external to > it causes it to fail (out of memory, disk error, > whatever). And right now, if > the watchdog does die, not a big deal - server > continues to run, no one notices > anything different. However, if the metaserver > helper dies and is not noticed, > then the server in question is no longer reported, > which does cause problems > > I'd personally like things to be simpler - if a > user can just run the main > server, and everything works, that is much better > them then having to restart > the helper manually. > > > > > > >> The helper program also needs to have some basic > security - making sure > >>the connection is coming from the local host and > not something remote > >>(don't want some remote host connecting to the > helper and forging > >>information). > > > > > > Is it insecure at the moment? It /is/ already in > the server code, this was why > > I suggested using it, if it is there presumably it > at least works in some > > fashion (although this has been shown to be false > in the past). > > Right now, it appears insecure, in that a udp > packet to port 13325 resets the > watchdog timeout. The code does not appear to do > any validation that the packet > in fact came from the local host. > > the other problem is that it does use udp. While > spoofing IP here probably > isn't much a concern, it does mean that it is now > very difficult for the server > to know if that packet has been received, and thus > if the helper is still alive. > > The other gotcha is that the main purpose of the > watchdog program is to > restart the server if it dies or is not responsive. > > The main perhaps of the metaserver helper program > is to send data to the > metaserver. I can envision cases where this helper > could basically freeze up > resolving IP addresses and trying to connect to them > - in this case, this helper > really can't be doing anything else, such as > restarting the server if it > crashes. IMO, much better for this to be a > standalone === message truncated === __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From fuchs.andy at gmail.com Mon Jun 20 14:40:13 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Mon Jun 20 14:41:05 2005 Subject: [crossfire] new characters unable to use skills Message-ID: Some players have reported that in rare cases, characters they just created (inculding going through the hall of sellection), are unable to use most of their skills. I don't have any information useful for debuging this, except that the objects for the skills seem to be in the player's inventory. (listed by commands, etc), and that once they die, they can use those skills. Tracker item: http://sourceforge.net/tracker/index.php?func=detail&aid=1224351&group_id=13833&atid=113833 -- -- Andrew Fuchs From kirschbaum at myrealbox.com Wed Jun 22 17:34:02 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Wed Jun 22 17:35:37 2005 Subject: [crossfire] The real cause of the metaserver DOS attack Message-ID: <20050622223402.GA20863@kirschbaum.myrealbox.com> I'm fairly sure that the real cause of the metaserver DOS is not some random attacker but the crossfire server itself: you just need to set up a (new) crossfire server and change the "metaserver_notification off" config option to "on" to make your server flood the metaserver. The patch cvs diff -r 1.9 -r 1.10 lib/settings changed the default value for the "fastclock" config option from 0 to 1. That probably means that many new servers will run in fastclock mode. Furthermore, socket/loop.c contains a logic error if fastclock is enabled: (excerpt from socket/loop.c; I stripped code not related to the problem) | /** Waits for new connection */ | static void block_until_new_connection() { | do { | /* Every minutes is a bit often for updates - especially if | * nothing is going on. This slows it down to every 6 minutes. | */ | cycles++; | if (cycles == 7) { | metaserver_update(); | cycles=1; | } | if (settings.fastclock > 0) { | Timeout.tv_sec=0; | Timeout.tv_usec=50; | } else { | Timeout.tv_sec=60; | Timeout.tv_usec=0; | } | } | while (select([...], &Timeout)==0); [...] This function is called whenever a server has no active connections. Basically, with fastclock=0, the metaserver update will be sent once per 6 minutes but with fastclock=1 it will be sent once per 6*50 usec (which could be more than 3000 packets per second on a fast machine). From mwedel at sonic.net Wed Jun 22 23:58:48 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Jun 22 23:59:41 2005 Subject: [crossfire] The real cause of the metaserver DOS attack In-Reply-To: <20050622223402.GA20863@kirschbaum.myrealbox.com> References: <20050622223402.GA20863@kirschbaum.myrealbox.com> Message-ID: <42BA4188.4070902@sonic.net> Andreas Kirschbaum wrote: > I'm fairly sure that the real cause of the metaserver DOS is not some > random attacker but the crossfire server itself: you just need to set up > a (new) crossfire server and change the "metaserver_notification off" > config option to "on" to make your server flood the metaserver. > > > The patch > > cvs diff -r 1.9 -r 1.10 lib/settings > > changed the default value for the "fastclock" config option from 0 to 1. > That probably means that many new servers will run in fastclock mode. > > > Furthermore, socket/loop.c contains a logic error if fastclock is > enabled: > > (excerpt from socket/loop.c; I stripped code not related to the problem) > | /** Waits for new connection */ > | static void block_until_new_connection() { > | do { > | /* Every minutes is a bit often for updates - especially if > | * nothing is going on. This slows it down to every 6 minutes. > | */ > | cycles++; > | if (cycles == 7) { > | metaserver_update(); > | cycles=1; > | } > | if (settings.fastclock > 0) { > | Timeout.tv_sec=0; > | Timeout.tv_usec=50; > | } else { > | Timeout.tv_sec=60; > | Timeout.tv_usec=0; > | } > | } > | while (select([...], &Timeout)==0); > [...] > > This function is called whenever a server has no active connections. > Basically, with fastclock=0, the metaserver update will be sent once per > 6 minutes but with fastclock=1 it will be sent once per 6*50 usec (which > could be more than 3000 packets per second on a fast machine). Probably so. Related, but limited to the local system, if fastclock is sent, the server will also send a ton of udp packets for the watchdog logic. This is at least on the local system, but probably increases the load about. Real bug here was the commit of the settings files that changed the value of fastclock. Unfortunately, changing the settings file back doesn't really help things out because by default, the settings file is not installed if one already exists - thus, all the people will broken settings file will continue to have it. I'll commit a fixed settings file and also work on some bug for the fastclock logic in that loop itself. From mwedel at sonic.net Wed Jun 22 23:58:48 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Jun 22 23:59:45 2005 Subject: [crossfire] The real cause of the metaserver DOS attack In-Reply-To: <20050622223402.GA20863@kirschbaum.myrealbox.com> References: <20050622223402.GA20863@kirschbaum.myrealbox.com> Message-ID: <42BA4188.4070902@sonic.net> Andreas Kirschbaum wrote: > I'm fairly sure that the real cause of the metaserver DOS is not some > random attacker but the crossfire server itself: you just need to set up > a (new) crossfire server and change the "metaserver_notification off" > config option to "on" to make your server flood the metaserver. > > > The patch > > cvs diff -r 1.9 -r 1.10 lib/settings > > changed the default value for the "fastclock" config option from 0 to 1. > That probably means that many new servers will run in fastclock mode. > > > Furthermore, socket/loop.c contains a logic error if fastclock is > enabled: > > (excerpt from socket/loop.c; I stripped code not related to the problem) > | /** Waits for new connection */ > | static void block_until_new_connection() { > | do { > | /* Every minutes is a bit often for updates - especially if > | * nothing is going on. This slows it down to every 6 minutes. > | */ > | cycles++; > | if (cycles == 7) { > | metaserver_update(); > | cycles=1; > | } > | if (settings.fastclock > 0) { > | Timeout.tv_sec=0; > | Timeout.tv_usec=50; > | } else { > | Timeout.tv_sec=60; > | Timeout.tv_usec=0; > | } > | } > | while (select([...], &Timeout)==0); > [...] > > This function is called whenever a server has no active connections. > Basically, with fastclock=0, the metaserver update will be sent once per > 6 minutes but with fastclock=1 it will be sent once per 6*50 usec (which > could be more than 3000 packets per second on a fast machine). Probably so. Related, but limited to the local system, if fastclock is sent, the server will also send a ton of udp packets for the watchdog logic. This is at least on the local system, but probably increases the load about. Real bug here was the commit of the settings files that changed the value of fastclock. Unfortunately, changing the settings file back doesn't really help things out because by default, the settings file is not installed if one already exists - thus, all the people will broken settings file will continue to have it. I'll commit a fixed settings file and also work on some bug for the fastclock logic in that loop itself. From lalo at exoweb.net Thu Jun 23 19:18:05 2005 From: lalo at exoweb.net (Lalo Martins) Date: Thu Jun 23 19:19:53 2005 Subject: [crossfire] Re: The real cause of the metaserver DOS attack In-Reply-To: <42BA4188.4070902@sonic.net> References: <20050622223402.GA20863@kirschbaum.myrealbox.com> <42BA4188.4070902@sonic.net> Message-ID: And so says Mark Wedel on 23/06/05 12:58... > Real bug here was the commit of the settings files that changed the > value of fastclock. Unfortunately, changing the settings file back > doesn't really help things out because by default, the settings file is > not installed if one already exists - thus, all the people will broken > settings file will continue to have it. May I respectfully suggest a hard throttle, so that no matter what else, the server just won't talk to the metaserver more than, oh, once per minute or so? Then even people with fastclock on will have this solved. 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.exoweb.net/ mailto:lalo@exoweb.net GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Thu Jun 23 23:55:19 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jun 23 23:56:01 2005 Subject: [crossfire] Re: The real cause of the metaserver DOS attack In-Reply-To: References: <20050622223402.GA20863@kirschbaum.myrealbox.com> <42BA4188.4070902@sonic.net> Message-ID: <42BB9237.7080707@sonic.net> Lalo Martins wrote: > And so says Mark Wedel on 23/06/05 12:58... > >>Real bug here was the commit of the settings files that changed the >>value of fastclock. Unfortunately, changing the settings file back >>doesn't really help things out because by default, the settings file is >>not installed if one already exists - thus, all the people will broken >>settings file will continue to have it. > > > May I respectfully suggest a hard throttle, so that no matter what else, > the server just won't talk to the metaserver more than, oh, once per > minute or so? Then even people with fastclock on will have this solved. The code change I put in place reduces this rate considerably to something normal. However, unless/until people update to this newest code, they will continue to flood packets. From tchize at myrealbox.com Mon Jun 27 15:21:02 2005 From: tchize at myrealbox.com (tchize) Date: Mon Jun 27 15:22:48 2005 Subject: [crossfire] programming contest Message-ID: <200506272221.08485.tchize@myrealbox.com> Hi, just for the fun, someone is making a contest there: http://informanux.in.funpic.de/forum/index.php?showtopic=29 This is a programming contest, one rules, can be in team or alone, no price, just a listing in the winner list at the end. Only rule is, project should work on windows and linux :D As it cost nothing to subscribe and can make just a small amount of advertising for crossfire, maybe we could submit the crossfire project there :) I asked the contest admit, He sees, for now, no objection on projects developped in group since 15 years. What is your opinion? -- -- 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/20050627/b5160aad/attachment.pgp From mwedel at sonic.net Mon Jun 27 23:53:09 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Jun 27 23:54:54 2005 Subject: [crossfire] cone damage oddity Message-ID: <42C0D7B5.3070109@sonic.net> After playing a bit I noticed a cone oddity - it turns out if you are right next to the caster, you take less damage than if you are far away. Through experimentation, I quickly found that if you are 2 or more spaces away, you will take 3 times as much damage than if you are right next to the caster. If you are always at the very edge of the cone, you will take the same damage (as if you were right next to the caster). Basic diagram: 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 2 0 0 0 0 0 0 1 2 3 0 0 0 0 0 1 2 3 3 0 0 0 0 1 2 3 3 3 0 0 0 1 2 3 3 3 3 0 0 1 2 3 3 3 3 3 0 1 2 3 3 3 3 3 3 1 2 3 3 3 3 3 3 3 1 3 3 3 3 3 3 3 3 1 2 3 3 3 3 3 3 3 0 1 2 3 3 3 3 3 3 0 0 1 2 3 3 3 3 3 0 0 0 1 2 3 3 3 3 0 0 0 0 1 2 3 3 3 0 0 0 0 0 1 2 3 3 0 0 0 0 0 0 1 2 3 0 0 0 0 0 0 0 1 2 0 0 0 0 0 0 0 0 1 Think of that table as a damage multiplier. I guess the first question is whether this is considered a significant flaw or not. It has long been held that center of cone does more than edges, but in this case, center has a very broad meaning. And the fact that being next to the caster does less seems quite odd. Now it is a very simple fix to make it so that the entire cone does the same amount of damage. A side benefit of such a change is that it would also reduce server load - basically, reduce the number of objects used in the spell casting by a factor of 3. This would obviously weaken spells, so all cone spells would need to be upped in the damage they currently do. Trying to do any fix more sophisticated than that gets pretty complicated. This is basically because as the spell moves, the new objects are created, so you can't precalculate the damage for all spaces within the cone - you'd basically have to store a lot of info within each spell object, and I can't think of any way of doing that without things getting really complicated and messy. From mwedel at sonic.net Tue Jun 28 00:59:04 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Jun 28 01:00:55 2005 Subject: [crossfire] Color Spray In-Reply-To: <42A3BC17.8030001@telus.net> References: <200506052105.10835.eracclists@bellsouth.net> <42A3BC17.8030001@telus.net> Message-ID: <42C0E728.3080205@sonic.net> Alex Schultz wrote: > ERACC wrote: > >> I cannot believe HOW neutered this spell is. It used to be an awesome >> spell worth the effort of going to get. Now I am sorry I wasted an >> entire evening going to get it on crossfire.metalforge.net earlier. >> As hard as it is to get this spell it should be at least as powerful >> as I remember it being. What's with neutering hard-to-get spells? >> >> Can the spell be returned to its' former glory, please? Otherwise it >> just takes up space in my spell list. Level 46 sorcery and it takes >> THREE casts of color spray to kill about 10 - 15 Fiends. They should >> ALL be dead in one cast based on how the spell USED to work. >> > I agree, it's currently underpowered to the point where it's useless > even when it might otherwise be attractive due to it's variety of > attacktypes being difficult to resist. Even if I inscribe lots of > scrolls of it that are about lvl 100, it can't even graze a lvl 60 in > the arena or any monster that's of the slightest worth. > The balance of the spell might currently be ok for a lvl 15-30, however > it's near impossible for a lvl 15-30 to get it considering the quest > it's in and the fact that spellbooks can't be carried out. Comparing it to dragonbreath (which seems properly powerful), there are a few things I quickly notice: Base damage for dragonbreath is 25, for colorspray, 8. Both increase damage at same rate (1 point/3 levels) Colorspray has a longer range (10 vs 7), both increase at 1 sq/5 levels. Colorspray costs considerably more mana (35 vs 13) Looking at this, it'd seem that starting damage may be a bit low and casting cost a bit high. But I also wonder if some of the problem is that nature of the spell itself. If casting on high level creatures, chances are they are probably highly resistant to several of the attacktypes. For example, if a creature is immune to half the attacktypes, the damage it does would effectively be reduced. In comparison, you'll use dragon breath or other single attacktype spells on the creatures that it works on. So in that sense, it is probably also more effective. From leaf at real-time.com Tue Jun 28 18:06:16 2005 From: leaf at real-time.com (Rick Tanner) Date: Tue Jun 28 18:07:05 2005 Subject: [crossfire] cone damage oddity In-Reply-To: <42C0D7B5.3070109@sonic.net> References: <42C0D7B5.3070109@sonic.net> Message-ID: > I guess the first question is whether this is considered a significant flaw or > not. It has long been held that center of cone does more than edges, but in > this case, center has a very broad meaning. And the fact that being next to the > caster does less seems quite odd. Might be a different subject matter - but how does damage propegate outwards from a ball spell exploding? Should this damage (from ball spells) work the same as cone spells? Or work the same as updated (from this email thread) cone spells? > Now it is a very simple fix to make it so that the entire cone does the same > amount of damage. A side benefit of such a change is that it would also reduce > server load - basically, reduce the number of objects used in the spell casting > by a factor of 3. > > This would obviously weaken spells, so all cone spells would need to be upped > in the damage they currently do. Going back to your original table which showed 1's on the edges, then 2's, followed by 3's in the middle - would it be easier and less spell damage tweaking to use the "3" for all areas of the spell isntead of the 1's or 2's? From mwedel at sonic.net Thu Jun 30 00:12:39 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jun 30 00:13:25 2005 Subject: [crossfire] cone damage oddity In-Reply-To: References: <42C0D7B5.3070109@sonic.net> Message-ID: <42C37F47.1070505@sonic.net> Rick Tanner wrote: > >> I guess the first question is whether this is considered a significant flaw or >>not. It has long been held that center of cone does more than edges, but in >>this case, center has a very broad meaning. And the fact that being next to the >>caster does less seems quite odd. > > > Might be a different subject matter - but how does damage propegate > outwards from a ball spell exploding? Don't have any real examples. The code appears proper in that the explosion has proper tracking for uniqueness. Thus, the main reason fireballs do more damage is that the inside of the fireball lasts longer than the edges. > > Should this damage (from ball spells) work the same as cone spells? > Or work the same as updated (from this email thread) cone spells? Maybe. OTOH, its somewhat obvious how the ball spells work - the fact the fire lasts longer would be pretty clear indication that standing there will do more damage. I actually like the fireballs - how it explodes and then collapses back on itself - I think it would actually be odder if it expanded, and at some point, there was no fire left at the center while it continued to expand outwards. > > >> Now it is a very simple fix to make it so that the entire cone does the same >>amount of damage. A side benefit of such a change is that it would also reduce >>server load - basically, reduce the number of objects used in the spell casting >>by a factor of 3. >> >> This would obviously weaken spells, so all cone spells would need to be upped >>in the damage they currently do. > > > Going back to your original table which showed 1's on the edges, then 2's, > followed by 3's in the middle - would it be easier and less spell damage > tweaking to use the "3" for all areas of the spell isntead of the 1's or > 2's? The reason that diagram exists is pretty basic - think of 3 cone spells emanating from those initial 3 spaces. Where they don't overlap, it is a 1. Where it overlaps with 1 other cone, it does 2x damage (2 spell cones active). Where it overlaps with 2 other cones, it does 3x. the basic change I have in mind would make that area act as one logical cone spell, so the entier cone would do the same damage. It makes things more efficient because now there would only be 1 fire object on those spaces instead of 3. As I've said before, I generally don't like the code to make adjustments that aren't obvious to the player. So if I did the above change, the cone spells would effectively do less damage because there is no overlap. The archetypes would be adjusted upward to take account for this (although perhaps not as much as 3x). Thus when an archetype says 'dam 40', you know it will do 40 damage, not 120, not 13, etc.