From maligor at gmail.com Tue Nov 1 03:42:26 2005 From: maligor at gmail.com (Veli-Matti Valtonen) Date: Tue Nov 1 03:43:38 2005 Subject: [crossfire] Crossfire Gtk Client compiled against Gtk 2.0 Message-ID: <9F29FCA8-5740-423C-BA01-42FC4C86BE4E@gmail.com> The patch included adds a --enable-cfgtk2 option to configure, that's disabled by default. It's based on the Windows gtk 2.0 client changes made to the gcfclient and is quite simple. Since it changes some of the #ifdef WIN32 to CFGTK2 the windows project files will also need to be changed accordingly, also the patch doesn't include a 'configure' since it makes patches look friggen ugly so automake is needed to recreate it. The configure.in changes also have some smmall issues: - It reruns PKG_CHECK_MODULES macro that's already been run for gtkv2 (I didn't want to restructure that part) - defining --enable-cfgtk2 will cause a configure failure if GTK 2.0 is not found, it doesn't fall back (a non-issue really) - it defines -DGTK_WINDOW_DIALOG=GTK_WINDOW_TOPLEVEL as a compiler flag, instead of using CFGTK2 in the source files (Actually I've never tried redefining macroes as compiler flags before but apparently it works) - the use of GTK_ENABLE_BROKEN isn't all that beautiful but would require some major work on the multiline text widgets, this is also used on the windows client The patch has only been tested on Debian sid amd64 setup and SDL didn't seem to work, rather strangely you need to disable it in the game configuration files of the game or it'll result in a crash even if SDL isn't compiled against it. -------------- next part -------------- A non-text attachment was scrubbed... Name: cf-gtk2.patch Type: application/octet-stream Size: 3446 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20051101/b94493ff/cf-gtk2.obj From nicolas.weeger at laposte.net Tue Nov 1 11:42:09 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue Nov 1 11:41:45 2005 Subject: [crossfire] Changing Python scripts for global events Message-ID: <4367A8F1.1020805@laposte.net> Hello. I was wondering if it wouldn't be interesting to make the /python/event/python_xxx scripts simply run all scripts in a subdir eg /python/event/born/, or have the plugin do that itself. (yes, it feels like runlevels in linux) The idea is to "modularize" the scripts, to be able to simply distribute extensions. So we could for instance pack the whole "postoffice" scripts, and make that an install option. Then make a "guild" package, and thus (a "gps" one, ...). Ryo From rbrockway at opentrend.net Tue Nov 1 11:48:26 2005 From: rbrockway at opentrend.net (Robert Brockway) Date: Tue Nov 1 11:41:47 2005 Subject: [crossfire] Wiki organization. In-Reply-To: References: Message-ID: On Wed, 26 Oct 2005, Andrew Fuchs wrote: > Should in-game (map guide, etc) be seperated from out of game stuff > (client help)? I'd say overall the two should be logically seperated yes. Ie, a single article should not contain in-game and out-of-game info. Of course wikilinks may go between them. > Should there be a section describing each server? For sure. Being a Wiki these can be maintained by the server admins. > Should there be a section describing each server's guilds? If appropriate, sure. > What to do about spoilers? (rot-13?) I'd rather not rot-13 the data without an easy way to make it legible (unless the s/w in use does include this). The Wikipedia approach works well - a big spoiler warning :) Cheers, Rob -- Robert Brockway B.Sc. Phone: +1-416-669-3073 Senior Technical Consultant Email: support@opentrend.net OpenTrend Solutions Ltd. Web: www.opentrend.net We are open 24x7x365 for technical support. Call us in a crisis. From yann.chachkoff at myrealbox.com Tue Nov 1 13:34:14 2005 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Tue Nov 1 12:37:45 2005 Subject: [crossfire] Changing Python scripts for global events In-Reply-To: <4367A8F1.1020805@laposte.net> References: <4367A8F1.1020805@laposte.net> Message-ID: <200511011934.22680.yann.chachkoff@myrealbox.com> Le Mardi 1 Novembre 2005 17:42, Nicolas Weeger a ?crit : > Hello. > > I was wondering if it wouldn't be interesting to make the > /python/event/python_xxx scripts simply run all scripts in a subdir eg > /python/event/born/, or have the plugin do that itself. > Sounds indeed like a good idea. I'd prefer to see the plugin do the job itself - it looks somewhat more logical to me. > (yes, it feels like runlevels in linux) > > The idea is to "modularize" the scripts, to be able to simply distribute > extensions. So we could for instance pack the whole "postoffice" > scripts, and make that an install option. Then make a "guild" package, > and thus (a "gps" one, ...). > ... And the next logical step could be the packaging of new maps in the same way - so if I don't install the Post Office Script package, I cannot install the Post Office maps (and the buildings are simply unlinked). Admittedly, this is a rather long-term idea, and maybe unnecessary - but well, maybe there is something good to gather from that silly idea ? > Ryo > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -- Yann Chachkoff ----------------------- Garden Dwarf's Best Friend ----------------------- GPG Key : http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 -------------- 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/20051101/7634889d/attachment.pgp From fuchs.andy at gmail.com Tue Nov 1 14:23:53 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Tue Nov 1 14:25:46 2005 Subject: [crossfire] Changing Python scripts for global events In-Reply-To: <200511011934.22680.yann.chachkoff@myrealbox.com> References: <4367A8F1.1020805@laposte.net> <200511011934.22680.yann.chachkoff@myrealbox.com> Message-ID: On 11/1/05, Yann Chachkoff wrote: > Le Mardi 1 Novembre 2005 17:42, Nicolas Weeger a ?crit : ... > > I was wondering if it wouldn't be interesting to make the > > /python/event/python_xxx scripts simply run all scripts in a subdir eg > > /python/event/born/, or have the plugin do that itself. Sounds good. > Sounds indeed like a good idea. > I'd prefer to see the plugin do the job itself - it looks somewhat more > logical to me. Agreed. ... -- Andrew Fuchs From mikeeusaaa at yahoo.com Fri Nov 4 12:25:54 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Nov 4 12:32:18 2005 Subject: [crossfire] Changing Python scripts for global events In-Reply-To: <200511011934.22680.yann.chachkoff@myrealbox.com> Message-ID: <20051104182554.45136.qmail@web61021.mail.yahoo.com> I don't like this idea at all. "Let's add layers of complexity for no reason!!1111" Time would better be spent creating usefull things like new maps and scripts rather then pissing off people trying to install things IMHO. --- Yann Chachkoff wrote: > ... And the next logical step could be the packaging > of new maps in the same > way - so if I don't install the Post Office Script > package, I cannot install > the Post Office maps (and the buildings are simply > unlinked). > Admittedly, this is a rather long-term idea, and > maybe unnecessary - but well, > maybe there is something good to gather from that > silly idea ? __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com From lalo.martins at gmail.com Fri Nov 4 12:39:16 2005 From: lalo.martins at gmail.com (Lalo Martins) Date: Fri Nov 4 12:52:56 2005 Subject: [crossfire] Re: Crossfire Gtk Client compiled against Gtk 2.0 In-Reply-To: <9F29FCA8-5740-423C-BA01-42FC4C86BE4E@gmail.com> References: <9F29FCA8-5740-423C-BA01-42FC4C86BE4E@gmail.com> Message-ID: Very nifty. Couple of comments: - I had to use --disable-gtktest for it to compile. This is probably related to the configure logic you reused, as mentioned in your post. - SDL works for me, although lighting leaves some odd effects. As I haven't been using SDL recently (by mistake), I don't know if these effects are a problem of the gtk2 build, or "normal". - If "popup windows" is disabled, I can't log in (can't type the username). I suppose, until the gtk-v2 client matures, this is the best bet for a "default" client? 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.martins@gmail.com GNU: never give up freedom http://www.gnu.org/ From nicolas.weeger at laposte.net Sat Nov 5 03:01:39 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat Nov 5 03:01:11 2005 Subject: [crossfire] Changing Python scripts for global events In-Reply-To: <20051104182554.45136.qmail@web61021.mail.yahoo.com> References: <20051104182554.45136.qmail@web61021.mail.yahoo.com> Message-ID: <436C74F3.1040608@laposte.net> Mitch Obrian a ?crit : > I don't like this idea at all. > "Let's add layers of complexity for no reason!!1111" > > Time would better be spent creating usefull things > like new maps and scripts rather then pissing off > people trying to install things IMHO. Hum actually I see my proposal as a way to simplify distribution & maintenance of map & Python stuff. Right now, to add a script for a new player event, you have to modify the python_born.py script, and insert correct lines. Thus if a server maintainer wants to disable a function, need to comment out lines, figure out which and such. Also, if someone makes some scripts, to add them, need again to patch the script. If & when we have many scripts, in a modular way, it'll be a real pain to manage the global event files. But well, YMMV, of course :) Ryo From nicolas.weeger at laposte.net Sat Nov 5 03:09:06 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat Nov 5 03:09:11 2005 Subject: [crossfire] Pickup issues Message-ID: <436C76B2.2040904@laposte.net> Hello. The query_cost function was changed part of selling / buying improvement. But now the pickup ratio, which uses this function to estimate the item's price, grabs much more items than before. Should we try to fix to keep previous behaviour? Or just ignore & leave like that? (with ratio 75 [max], i picked all items in dragonmountain except 2 really heavy armors lol) Ryo From nicolas.weeger at laposte.net Sat Nov 5 10:37:33 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat Nov 5 10:37:19 2005 Subject: [crossfire] Weather bug, continued Message-ID: <436CDFCD.3000008@laposte.net> Hello. I think I figured out why some tiles disappear under weather. weather.c:change_the_world handles removal of grown items, including (for instance) grass. It handles ground by simply checking from the get_ob_map()->above object. When the overlay for a map is loaded, by map.c:load_overlay_map, items are inserted, but for some *under* the grass. The revelant code in object.c:insert_ob_in_map is: originator->below = op; } else { /* If there are other objects, then */ if((! (flag & INS_MAP_LOAD)) && ((top=GET_MAP_OB(op->map,op->x,op->y))!=NULL)) { object *last=NULL; /* * If there are multiple objects on this space, we do some trickier handling. what happens is that a tmap overloading, INS_MAP_LOAD is set, so items are inserted *below* other items. So next run the change_the_world will simply check from eg the grass, and remove it if weather conditions prevent it. My proposed check is to change insert_ob_in_map for: originator->below = op; } else { /* If there are other objects, then */ if((top=GET_MAP_OB(op->map,op->x,op->y))!=NULL) { object *last=NULL; /* * If there are multiple objects on this space, we do some trickier handling. ie search floor & such all the time. The code after handles INS_MAP_LOAD and INS_ABOVE_FLOOR_ONLY flags. Btw it looks strange to me that an overlay is always on top. Ryo From brenlally at gmail.com Sat Nov 5 14:46:31 2005 From: brenlally at gmail.com (Brendan Lally) Date: Sat Nov 5 14:47:23 2005 Subject: [crossfire] alchemy/alchemy Message-ID: <7903f03c0511051246g405410ddp402791a8da71dedb@mail.gmail.com> Currently there are two concepts within the game world called 'alchemy', the first is a skill for the transformation of items, the second (which I was just reminded of today, having forgotten of it due to its general uselessness) is the spell alchemy which transforms items into gold. These two things having the same name is confusing, so I propose that one of them change their name. since alchemy.c is a file that deals with the skill alchemy, it would be more consistent to rename the spell. I propose the name 'aura of midas' although if someone else has another idea then that would be fine too. If it were the case that it were decided to keep the name alchemy for the spell, then notwithstanding the comment about source file names, it would be equally straightforward to rename the alchemy skill. In this case I would suggest something like apothecary as a suitable replacement name. From brenlally at gmail.com Sat Nov 5 14:51:35 2005 From: brenlally at gmail.com (Brendan Lally) Date: Sat Nov 5 14:53:15 2005 Subject: [crossfire] Pickup issues In-Reply-To: <436C76B2.2040904@laposte.net> References: <436C76B2.2040904@laposte.net> Message-ID: <7903f03c0511051251g53ed0067lb0b4c89a51e1caac@mail.gmail.com> On 11/5/05, Nicolas Weeger wrote: > Hello. > > The query_cost function was changed part of selling / buying > improvement. But now the pickup ratio, which uses this function to > estimate the item's price, grabs much more items than before. > Should we try to fix to keep previous behaviour? Or just ignore & leave > like that? That it doesn't have the previous behaviour would be a bug. You are however welcome to call it a feature, although I believe ragnor has just gone and fixed it on me, so such a nomenclature will be short lived.. From mikeeusaaa at yahoo.com Sat Nov 5 08:38:52 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat Nov 5 15:05:10 2005 Subject: [crossfire] Changing Python scripts for global events In-Reply-To: <436C74F3.1040608@laposte.net> Message-ID: <20051105143852.94244.qmail@web61014.mail.yahoo.com> Eh, guess it won't affect me anyhow since I use CVS and install everything aswell. --- Nicolas Weeger wrote: > Mitch Obrian a ?crit : > > I don't like this idea at all. > > "Let's add layers of complexity for no > reason!!1111" > > > > Time would better be spent creating usefull things > > like new maps and scripts rather then pissing off > > people trying to install things IMHO. > > Hum actually I see my proposal as a way to simplify > distribution & > maintenance of map & Python stuff. > > Right now, to add a script for a new player event, > you have to modify > the python_born.py script, and insert correct lines. > Thus if a server > maintainer wants to disable a function, need to > comment out lines, > figure out which and such. Also, if someone makes > some scripts, to add > them, need again to patch the script. > If & when we have many scripts, in a modular way, > it'll be a real pain > to manage the global event files. > > But well, YMMV, of course :) > > Ryo > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com From mikeeusaaa at yahoo.com Sat Nov 5 07:53:02 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat Nov 5 15:05:12 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: arch/mapbuilding In-Reply-To: Message-ID: <20051105135302.83373.qmail@web61016.mail.yahoo.com> Do I have to update code for this to work, or just the archtypes? --- crossfire-cvs-admin@lists.sourceforge.net wrote: > > Module Name: arch > Committed By: eracc > Date: Sat Nov 5 04:58:40 UTC 2005 > > Modified Files: > arch/mapbuilding: building.arc building.trs > Added Files: > arch/mapbuilding: mbdwall_0.base.111.png > > Log Message: > Attempt to add dwall* as buildable archetypes. > > > > Start of context diffs > > > Index: arch/mapbuilding/building.arc > diff -c arch/mapbuilding/building.arc:1.3 > arch/mapbuilding/building.arc:1.4 > *** arch/mapbuilding/building.arc:1.3 Thu Aug 18 > 17:13:10 2005 > --- arch/mapbuilding/building.arc Fri Nov 4 > 20:58:40 2005 > *************** > *** 58,63 **** > --- 58,73 ---- > face mbwall.111 > slaying wall_0 > end > + Object building_wall2 > + name DWall material > + nrof 1 > + weight 1500 > + value 1500 > + type 161 > + subtype 2 > + face mbdwall.111 > + slaying dwall_0 > + end > Object building_vertical_gate > name Vertical gate material > nrof 1 > > Index: arch/mapbuilding/building.trs > diff -c arch/mapbuilding/building.trs:1.5 > arch/mapbuilding/building.trs:1.6 > *** arch/mapbuilding/building.trs:1.5 Thu Aug 18 > 17:13:10 2005 > --- arch/mapbuilding/building.trs Fri Nov 4 > 20:58:40 2005 > *************** > *** 11,16 **** > --- 11,19 ---- > arch building_wall > chance 25 > more > + arch building_wall2 > + chance 20 > + more > arch building_vertical_gate > chance 10 > more > > Index: arch/mapbuilding/mbdwall_0.base.111.png > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's > Geronimo App Server. Download > it for free - -and be entered to win a 42" plasma tv > or your very own > Sony(tm)PSP. Click here to play: > http://sourceforge.net/geronimo.php > _______________________________________________ > Crossfire-cvs mailing list > Crossfire-cvs@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/crossfire-cvs > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From nicolas.weeger at laposte.net Sat Nov 5 15:09:25 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat Nov 5 15:09:23 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: arch/mapbuilding In-Reply-To: <20051105135302.83373.qmail@web61016.mail.yahoo.com> References: <20051105135302.83373.qmail@web61016.mail.yahoo.com> Message-ID: <436D1F85.7040504@laposte.net> Mitch Obrian a ?crit : > Do I have to update code for this to work, or just the > archtypes? Collecting archs should be enough, since it's a floor and does not require any special handling. Ryo From nicolas.weeger at laposte.net Sat Nov 5 15:23:07 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat Nov 5 15:23:22 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: arch/mapbuilding In-Reply-To: <20051105135302.83373.qmail@web61016.mail.yahoo.com> References: <20051105135302.83373.qmail@web61016.mail.yahoo.com> Message-ID: <436D22BB.5040003@laposte.net> Mitch Obrian a ?crit : > Do I have to update code for this to work, or just the > archtypes? Just found out a bug: make sure that the built wall archetype has the 'WALL' type, and not 0 or something else. This is true for all walls that people want to build on/build: wall should be WALL type, not 0. It won't crash, you'll just be able to stack walls :) Ryo From mikeeusaaa at yahoo.com Sat Nov 5 08:05:45 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat Nov 5 16:54:01 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: maps-bigworld/python/IPO In-Reply-To: Message-ID: <20051105140545.88427.qmail@web61014.mail.yahoo.com> The package delevery is broken now? Why? When will it be fixed if so? --- crossfire-cvs-admin@lists.sourceforge.net wrote: > > Module Name: maps-bigworld > Committed By: ryo_saeba > Date: Sat Nov 5 10:40:25 UTC 2005 > > Modified Files: > maps-bigworld/python/IPO: say.py > > Log Message: > Fix case > > > > Start of context diffs > > > Index: maps-bigworld/python/IPO/say.py > diff -c maps-bigworld/python/IPO/say.py:1.8 > maps-bigworld/python/IPO/say.py:1.9 > *** maps-bigworld/python/IPO/say.py:1.8 Tue Oct 18 > 11:13:28 2005 > --- maps-bigworld/python/IPO/say.py Sat Nov 5 > 02:40:24 2005 > *************** > *** 185,188 **** > whoami.Say('Sorry, our package delivery service > is currently in strike. Please come back later.') > else: > whoami.Say('Do you need help?') > ! Crossfire.setReturnValue(1) > \ No newline at end of file > --- 185,188 ---- > whoami.Say('Sorry, our package delivery service > is currently in strike. Please come back later.') > else: > whoami.Say('Do you need help?') > ! Crossfire.SetReturnValue(1) > \ No newline at end of file > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's > Geronimo App Server. Download > it for free - -and be entered to win a 42" plasma tv > or your very own > Sony(tm)PSP. Click here to play: > http://sourceforge.net/geronimo.php > _______________________________________________ > Crossfire-cvs mailing list > Crossfire-cvs@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/crossfire-cvs > __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com From eracclists at bellsouth.net Sat Nov 5 17:14:07 2005 From: eracclists at bellsouth.net (ERACC) Date: Sat Nov 5 17:15:24 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: arch/mapbuilding In-Reply-To: <20051105135302.83373.qmail@web61016.mail.yahoo.com> References: <20051105135302.83373.qmail@web61016.mail.yahoo.com> Message-ID: <200511051714.08670.eracclists@bellsouth.net> On Saturday 05 November 2005 07:53 am Mitch Obrian wrote: > --- crossfire-cvs-admin@lists.sourceforge.net wrote: > > > > > Module Name: arch > > Committed By: eracc > > Date: Sat Nov 5 04:58:40 UTC 2005 > > > > Modified Files: > > arch/mapbuilding: building.arc building.trs > > Added Files: > > arch/mapbuilding: mbdwall_0.base.111.png > > > > Log Message: > > Attempt to add dwall* as buildable archetypes. > > > > > > > > Start of context diffs > > > > > > Index: arch/mapbuilding/building.arc > > diff -c arch/mapbuilding/building.arc:1.3 > > arch/mapbuilding/building.arc:1.4 > > *** arch/mapbuilding/building.arc:1.3 Thu Aug 18 > > 17:13:10 2005 > > --- arch/mapbuilding/building.arc Fri Nov 4 > > 20:58:40 2005 > > *************** > > *** 58,63 **** > > --- 58,73 ---- > > face mbwall.111 > > slaying wall_0 > > end > > + Object building_wall2 > > + name DWall material > > + nrof 1 > > + weight 1500 > > + value 1500 > > + type 161 > > + subtype 2 > > + face mbdwall.111 > > + slaying dwall_0 > > + end > > Object building_vertical_gate > > name Vertical gate material > > nrof 1 > > > > Index: arch/mapbuilding/building.trs > > diff -c arch/mapbuilding/building.trs:1.5 > > arch/mapbuilding/building.trs:1.6 > > *** arch/mapbuilding/building.trs:1.5 Thu Aug 18 > > 17:13:10 2005 > > --- arch/mapbuilding/building.trs Fri Nov 4 > > 20:58:40 2005 > > *************** > > *** 11,16 **** > > --- 11,19 ---- > > arch building_wall > > chance 25 > > more > > + arch building_wall2 > > + chance 20 > > + more > > arch building_vertical_gate > > chance 10 > > more > > > > Index: arch/mapbuilding/mbdwall_0.base.111.png > > Do I have to update code for this to work, or just the > archtypes? There was a problem trying to use the floors and walls in the new /brest/apartments/brest_town_house. Ryo_ supplied a fix (hopefully) in cvs that resolves that. So, a recompile is required for that. But updating archetypes should be all one needs to get the new buildable walls. Those seem to work as desired. However, when I updated archetypes locally I also recompiled from cvs so I may be misunderstanding the process. Gene -- Mandriva Linux release 2006.0 (Official) for i586 16:53:13 up 10 days, 1:37, 13 users, load average: 0.66, 0.45, 0.30 ERA Computer Consulting - http://www.eracc.com/ eCS, Linux, FreeBSD, OpenServer & UnixWare resellers From nicolas.weeger at laposte.net Sun Nov 6 03:38:05 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun Nov 6 03:37:36 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: maps-bigworld/python/IPO In-Reply-To: <20051105140545.88427.qmail@web61014.mail.yahoo.com> References: <20051105140545.88427.qmail@web61014.mail.yahoo.com> Message-ID: <436DCEFD.4070707@laposte.net> Mitch Obrian a ?crit : > The package delevery is broken now? Why? When will it > be fixed if so? It works on my computer, with Python 2.4. Seems to have issues on Metalforge, didn't yet have time to check why. Ryo From fuchs.andy at gmail.com Sun Nov 6 16:30:50 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun Nov 6 16:31:50 2005 Subject: [crossfire] alchemy/alchemy In-Reply-To: <7903f03c0511051246g405410ddp402791a8da71dedb@mail.gmail.com> References: <7903f03c0511051246g405410ddp402791a8da71dedb@mail.gmail.com> Message-ID: I don't mind renaming the spell. Another issue, if i recall correctly is that some book(s) tell the player to use the alchemy "spell" on their cauldron, not the skill; this has caused some trouble to beginning players before. Refferences in these books should be changed. On 11/5/05, Brendan Lally wrote: > Currently there are two concepts within the game world called > 'alchemy', the first is a skill for the transformation of items, the > second (which I was just reminded of today, having forgotten of it due > to its general uselessness) is the spell alchemy which transforms > items into gold. > > These two things having the same name is confusing, so I propose that > one of them change their name. > > since alchemy.c is a file that deals with the skill alchemy, it would > be more consistent to rename the spell. I propose the name 'aura of > midas' although if someone else has another idea then that would be > fine too. > > If it were the case that it were decided to keep the name alchemy for > the spell, then notwithstanding the comment about source file names, > it would be equally straightforward to rename the alchemy skill. In > this case I would suggest something like apothecary as a suitable > replacement name. -- Andrew Fuchs From kbulgrien at att.net Sun Nov 6 22:15:33 2005 From: kbulgrien at att.net (Kevin Bulgrien) Date: Sun Nov 6 22:19:57 2005 Subject: [crossfire] Re: gcfclient cfsndserv_alsa9 with alsa 1.0.6 / 1.0.8 References: Message-ID: Kevin Bulgrien writes: > Does anyone actually have recent gcfclient sound that works? Updated info. On one machine at least, I found a module loading problem and since I fixed that, the sound server does not appear to crash any more. Also tried with Alsa 1.0.9. /dev/dsp works if I cat a sound file into it manually. Neither the OSS nor the alsa version of cfsndserv works. The server is no longer dying, but no sound comes out. The alsa oss compatibility module is loaded, so you would think things should work with at least on or the other of the drivers. I compiled with SOUND_DEBUG on and no error messages are generated. sound is turned on. Sometimes sound apps fail if artsd is running. It is not running during these tests. While the client is running /dev/dsp is busy. I wonder if the client is even sending sound requests at all. From kbulgrien at att.net Sun Nov 6 22:33:10 2005 From: kbulgrien at att.net (Kevin Bulgrien) Date: Sun Nov 6 22:33:57 2005 Subject: [crossfire] CVS 2005/11/06 gcfclient crashes while middle-clicking pouch Message-ID: It does not happen all the time, but several times tonight, with a client compiled with CVS as of today, I have had client crashes while middle clicking a pouch of Holding in a store. The crash always occurs when going from active open to active. The terminal says: libpng warning: Ignoring gAMA chunk with gamma=0 libpng warning: Ignoring gAMA chunk with gamma=0 Gdk-ERROR **: BadValue (integer parameter out of range for operation) serial 581698 error_code 2 request_code 26 minor_code 0 I am using a wheel mouse. Do not have more specific data. I suppose I could try running out of gdb... Kevin R. Bulgrien From kbulgrien at att.net Sun Nov 6 23:04:41 2005 From: kbulgrien at att.net (Kevin Bulgrien) Date: Sun Nov 6 23:07:57 2005 Subject: [crossfire] CVS 2005/11/06 gcfclient truncated "but you only have" message Message-ID: Running latest CVS, I see that at least some store messages are truncated at times. I am playing on MetalForge. I picked up an item, and tried to leave while not having enough money... --- That is flint and steel (unpaid) It is made of: iron. It weighs 0.300 kg. You reckon it is worth a moderate amount of platinum coins. It would cost you 239 platinum coins, 3 gold coins and 5 silver coins. flint and steel (unpaid) will cost you 239 platinum coins, 3 gold coins and 5 silver coins. You have 1 unpaid items that would cost you 239 platinum coins, 3 gold coins and 5 silver coins, but you only have Rune of Dragon's Breath killed ubelzauberer with fire. --- As you can see, it says "but you only have" without the amount I have listed. Kevin R. Bulgrien From kbulgrien at att.net Sun Nov 6 23:12:11 2005 From: kbulgrien at att.net (Kevin Bulgrien) Date: Sun Nov 6 23:12:37 2005 Subject: [crossfire] Selling price variance and buying price variance Message-ID: I do not get the purpose behind the fact that selling price of look is wildly different from store to store. At first I thought it might have something to do with the store having more of an interest in certain items, but now I am not so sure. It seems that the lighting emporium pays almost 4x for many items compared to some other stores. This was true of body parts, flint/steel, and weapons. This sort of defeats the purpose of the store that seems to be preferred for the selling of loot so that the nice store inventories do not get cluttered with sold loot since it pays less to sell it there than at the lighting emporium or the potion shop or whatever. I see this playing on metalforge. Have not been on-list for a while, so maybe this is old news, but it really seems not very desirable. It is also pretty weird to see flint and steel sold for well over 1000 plat in say the weapon store when you can walk over to the lighting emporium and get one for 260-ish. And, I say -ish, because in the store, each one has a different price... for my character, 239-265 or so. That seems bizarre. Why would the price not be the same for the same item in the same store? Kevin R. Bulgrien From kbulgrien at att.net Sun Nov 6 23:50:32 2005 From: kbulgrien at att.net (Kevin Bulgrien) Date: Sun Nov 6 23:53:59 2005 Subject: [crossfire] Re: gcfclient cfsndserv_alsa9 with alsa 1.0.6 / 1.0.8 References: Message-ID: In the following, /dev/dsp is shown to be used. And, in fact, during this session /dev/dsp is busy. [ INFO ] (Client Version) GTK Unix Client 1.8.0 [ INFO ] (gtk::init_cache_data) Init Cache [ INFO ] (common::raiseChild) Raising /home/games/bin/cfsndserv with flags 7 [ INFO ] (Child17954::/home/games/bin/cfsndserv::1) $Id: cfsndserv.c,v 1.7 2005/02/14 05:42:01 mwedel Exp $ [ INFO ] (Child17954::/home/games/bin/cfsndserv::1) cfsndserv compiled for OSS sound system [ INFO ] (Child17954::/home/games/bin/cfsndserv::2) Settings: bits: 8, unsigned, mono, frequency: 11025, device: /dev/dsp [ INFO ] (Child17954::/home/games/bin/cfsndserv::2) bits: 8, unsigned, mono, freq: 11025, smpl_size: 1, 0level: 128 [ INFO ] (common::VersionCmd) Playing on server type Crossfire Server [WARNING ] (common::SetupCmd) Server returned FALSE on setup command sexp [ INFO ] (gtk::load_a_font) Loaded font -*-fixed-medium-r-*-*-*-120-*-*-*-*-iso8859-*. [ INFO ] (gtk::load_a_font) Loaded font -*-fixed-bold-r-*-*-*-120-*-*-*-*-iso8859-*. [ INFO ] (gtk::load_a_font) Loaded font -*-fixed-medium-o-*-*-*-120-*-*-*-*-iso8859-*. [ INFO ] (commands.c) addme_success received. libpng warning: Ignoring gAMA chunk with gamma=0 [ INFO ] (gtk::event_loop) gtk_main exited, returning from event_loop $ After closing the client, this yields sound: [krb@krayhome ~]$ cat .crossfire/sounds/Missed.raw >/dev/dsp From kbulgrien at att.net Sun Nov 6 23:52:05 2005 From: kbulgrien at att.net (Kevin Bulgrien) Date: Mon Nov 7 00:01:58 2005 Subject: [crossfire] Re: CVS 2005/11/06 gcfclient crashes while middle-clicking pouch References: Message-ID: Kevin Bulgrien writes: > It does not happen all the time, but several times tonight, with a client > compiled with CVS as of today, I have had client crashes while middle > clicking a pouch of Holding in a store. The crash always occurs when > going from active open to active. Ok, not always... sometimes going from active to active open. From fuchs.andy at gmail.com Mon Nov 7 09:44:42 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Mon Nov 7 09:46:06 2005 Subject: [crossfire] Re: gcfclient cfsndserv_alsa9 with alsa 1.0.6 / 1.0.8 In-Reply-To: References: Message-ID: AFAIK, sound support is mostly broken right now. -- Andrew Fuchs From brenlally at gmail.com Mon Nov 7 10:07:16 2005 From: brenlally at gmail.com (Brendan Lally) Date: Mon Nov 7 10:08:06 2005 Subject: [crossfire] Selling price variance and buying price variance In-Reply-To: References: Message-ID: <7903f03c0511070807t5f742bf6x49d0760bf0192305@mail.gmail.com> On 11/7/05, Kevin Bulgrien wrote: > I do not get the purpose behind the fact that selling price of look is wildly > different from store to store. > > At first I thought it might have something to do with the store having more > of an interest in certain items, but now I am not so sure. It is. > It seems that the lighting emporium pays almost 4x for many items compared to > some other stores. This was true of body parts, flint/steel, and weapons. Yeah, I made a mistake adding the header for that shop, left off a minus sign, making it a very /good/ place to sell those items, instead of somewhere that isn't so good. (incidentally, I posted it to the crossfire-maps maling list, and no one called me on it....). I've updated CVS to use a more reasonable value. > It is also pretty weird to see flint and steel sold for well over 1000 plat in > say the weapon store when you can walk over to the lighting emporium and get > one for 260-ish. yes, that is the other consequence of me goofing with the header. > And, I say -ish, because in the store, each one has a > different price... for my character, 239-265 or so. That seems bizarre. Why > would the price not be the same for the same item in the same store? This is because there is an arbitrary adjustment to price based on the item count and map name, it is in the range of +-5% it is designed to allow otherwise identical shops to give a small variation in price. Possibly it shouldn't apply to shops selling items, only buying them? From mikeeusaaa at yahoo.com Mon Nov 7 07:13:46 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Mon Nov 7 12:10:35 2005 Subject: [crossfire] Python does not work one iota Message-ID: <20051107131347.51883.qmail@web61015.mail.yahoo.com> I just updated cat2 and python doesn't work. Metalforge apparently has this problem as well. What's going on? __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com From mikeeusaaa at yahoo.com Mon Nov 7 07:17:36 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Mon Nov 7 12:10:38 2005 Subject: [crossfire] works now Message-ID: <20051107131737.53186.qmail@web61016.mail.yahoo.com> NM python now works... how am I going to convert my maps to the new python tho? __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com From nicolas.weeger at laposte.net Mon Nov 7 16:49:08 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon Nov 7 16:50:13 2005 Subject: [crossfire] works now In-Reply-To: <20051107131737.53186.qmail@web61016.mail.yahoo.com> References: <20051107131737.53186.qmail@web61016.mail.yahoo.com> Message-ID: <436FD9E4.3040807@laposte.net> Mitch Obrian a ?crit : > NM python now works... how am I going to convert my > maps to the new python tho? Instead of using "event_apply" or "event_say" as a field, add in the inventory a new object of arch "event_say" or "event_apply", and fill fields as required (look at IPO for example) To convert scripts, the basic rule is: if you had CFPython.SomeAction(Map or Player, Arguments), change it to Map or Player.SomeAction(Arguments) Ryo From mwedel at sonic.net Tue Nov 8 00:49:48 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Nov 8 00:50:22 2005 Subject: [crossfire] Selling price variance and buying price variance In-Reply-To: <7903f03c0511070807t5f742bf6x49d0760bf0192305@mail.gmail.com> References: <7903f03c0511070807t5f742bf6x49d0760bf0192305@mail.gmail.com> Message-ID: <43704A8C.5010202@sonic.net> Brendan Lally wrote: >> And, I say -ish, because in the store, each one has a >> different price... for my character, 239-265 or so. That seems bizarre. Why >> would the price not be the same for the same item in the same store? > > This is because there is an arbitrary adjustment to price based on the > item count and map name, it is in the range of +-5% it is designed to > allow otherwise identical shops to give a small variation in price. > > Possibly it shouldn't apply to shops selling items, only buying them? How does it do that? does it just randomize the price in the query strings (if so, how does that remain consistent), or does it change the actual objects value? If the later, I'd suggest changing it - I'd hate to have 15 of the 'same' item that don't merge because of minor variations in the price. From brenlally at gmail.com Tue Nov 8 03:53:16 2005 From: brenlally at gmail.com (Brendan Lally) Date: Tue Nov 8 03:54:24 2005 Subject: [crossfire] Selling price variance and buying price variance In-Reply-To: <43704A8C.5010202@sonic.net> References: <7903f03c0511070807t5f742bf6x49d0760bf0192305@mail.gmail.com> <43704A8C.5010202@sonic.net> Message-ID: <7903f03c0511080153i178113eo5c2f6712704ad669@mail.gmail.com> On 11/8/05, Mark Wedel wrote: > Brendan Lally wrote: > > This is because there is an arbitrary adjustment to price based on the > > item count and map name, it is in the range of +-5% it is designed to > > allow otherwise identical shops to give a small variation in price. > > > > Possibly it shouldn't apply to shops selling items, only buying them? > > How does it do that? does it just randomize the price in the query strings > (if so, how does that remain consistent), or does it change the actual objects > value? It is the price returned by query_cost that changes. lines 295-300 server/shop.c /* we will also have an extra 0-5% variation between shops of the same type * for valuable items (below a value of 50 this effect wouldn't be very * pointful, and could give fun with rounding. */ if(who->map->path!=NULL && val > 50) val=(sint64)val+0.05*(sint64)val*cos(tmp->count+strlen(who->map->path)); making this not apply to a shop when it sells items, is as simple as adding an '&& flag == F_SELL' to the if statement. From yann.chachkoff at myrealbox.com Tue Nov 8 03:12:17 2005 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Tue Nov 8 05:20:25 2005 Subject: [crossfire] Python does not work one iota In-Reply-To: <20051107131347.51883.qmail@web61015.mail.yahoo.com> References: <20051107131347.51883.qmail@web61015.mail.yahoo.com> Message-ID: <200511081012.24415.yann.chachkoff@myrealbox.com> Le Lundi 7 Novembre 2005 14:13, Mitch Obrian a ?crit : > I just updated cat2 and python doesn't work. > Metalforge apparently has this problem as well. > What's going on? > Recent massive changes in the plugin architecture. Changes committed to the CVS on October, 18th[1]. The final patch was announced on October, 15th[2]. I am not aware of a CFPython-related bug on mf, as I have seen no such message on the mailing list or on the Bug-tracker. If you were speaking about the "unresolved symbol" problem when loading plugin_python.so, it has already been "solved": plugin_python.so is the 1.x plugin that needs to be removed from lib/crossfire when upgrading. It has been replaced by cfpython.so. You'll have to provide more details about what doesn't work (error messages, steps to reproduce the problem, logs, etc) if you want me/us to work on a bugfix. As far as I can tell, Python does work (at least it seems to on my system). Note that if you have custom-made maps that are not part of CVS and used the 1.x plugin interface, you'll have to convert the event hooks. See doc/Developers/python for more details. [1]: http://sourceforge.net/mailarchive/forum.php?thread_id=8657598&forum_id=33257 and friends. [2]: http://shadowknight.real-time.com/pipermail/crossfire/2005-October/009445.html > > > __________________________________ > Yahoo! FareChase: Search multiple travel sites in one click. > http://farechase.yahoo.com > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -- Yann Chachkoff ----------------------- Garden Dwarf's Best Friend ----------------------- GPG Key : http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 -------------- 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/20051108/b8bdfbc4/attachment.pgp From mikeeusaaa at yahoo.com Tue Nov 8 07:14:01 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Tue Nov 8 10:04:42 2005 Subject: [crossfire] Python does not work one iota In-Reply-To: <200511081012.24415.yann.chachkoff@myrealbox.com> Message-ID: <20051108131401.50637.qmail@web61016.mail.yahoo.com> Cyling the server again fixed the problem. --- Yann Chachkoff wrote: > Le Lundi 7 Novembre 2005 14:13, Mitch Obrian a ?crit > : > > I just updated cat2 and python doesn't work. > > Metalforge apparently has this problem as well. > > What's going on? > > > Recent massive changes in the plugin architecture. > Changes committed to the > CVS on October, 18th[1]. The final patch was > announced on October, 15th[2]. > > I am not aware of a CFPython-related bug on mf, as I > have seen no such message > on the mailing list or on the Bug-tracker. If you > were speaking about the > "unresolved symbol" problem when loading > plugin_python.so, it has already > been "solved": plugin_python.so is the 1.x plugin > that needs to be removed > from lib/crossfire when upgrading. It has been > replaced by cfpython.so. > > You'll have to provide more details about what > doesn't work (error messages, > steps to reproduce the problem, logs, etc) if you > want me/us to work on a > bugfix. > > As far as I can tell, Python does work (at least it > seems to on my system). > Note that if you have custom-made maps that are not > part of CVS and used the > 1.x plugin interface, you'll have to convert the > event hooks. See > doc/Developers/python for more details. > > [1]: > http://sourceforge.net/mailarchive/forum.php?thread_id=8657598&forum_id=33257 > > and friends. > [2]: > http://shadowknight.real-time.com/pipermail/crossfire/2005-October/009445.html > > > > > > __________________________________ > > Yahoo! FareChase: Search multiple travel sites in > one click. > > http://farechase.yahoo.com > > > > _______________________________________________ > > crossfire mailing list > > crossfire@metalforge.org > > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > -- > Yann Chachkoff > ----------------------- > Garden Dwarf's Best Friend > ----------------------- > GPG Key : > http://keyserver.veridis.com:11371/export?id=9080288987474372064 > Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 > AAB9 844D 25E0 > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com From mikeeusaaa at yahoo.com Tue Nov 8 07:14:56 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Tue Nov 8 10:04:45 2005 Subject: [crossfire] Selling price variance and buying price variance In-Reply-To: <7903f03c0511080153i178113eo5c2f6712704ad669@mail.gmail.com> Message-ID: <20051108131457.54252.qmail@web61011.mail.yahoo.com> I think the variance is a good thing. Please keep it. --- Brendan Lally wrote: > On 11/8/05, Mark Wedel wrote: > > Brendan Lally wrote: > > > This is because there is an arbitrary adjustment > to price based on the > > > item count and map name, it is in the range of > +-5% it is designed to > > > allow otherwise identical shops to give a small > variation in price. > > > > > > Possibly it shouldn't apply to shops selling > items, only buying them? > > > > How does it do that? does it just randomize the > price in the query strings > > (if so, how does that remain consistent), or does > it change the actual objects > > value? > > It is the price returned by query_cost that changes. > > lines 295-300 server/shop.c > /* we will also have an extra 0-5% variation between > shops of the same type > * for valuable items (below a value of 50 this > effect wouldn't be very > * pointful, and could give fun with rounding. > */ > if(who->map->path!=NULL && val > 50) > > val=(sint64)val+0.05*(sint64)val*cos(tmp->count+strlen(who->map->path)); > > making this not apply to a shop when it sells items, > is as simple as > adding an '&& flag == F_SELL' to the if statement. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com From mikeeusaaa at yahoo.com Tue Nov 8 07:23:34 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Tue Nov 8 10:04:47 2005 Subject: [crossfire] New brest buildings Message-ID: <20051108132334.57989.qmail@web61011.mail.yahoo.com> The new yellow brest entrance building doesn't seem to go with the brest style. Perhapse change it to something more bresty? Also I think I will make a townhouse arch for brest as we only have a blue topped one. __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs From mikeeusaaa at yahoo.com Tue Nov 8 07:25:39 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Tue Nov 8 10:04:50 2005 Subject: [crossfire] Call to Map Message-ID: <20051108132539.25474.qmail@web61022.mail.yahoo.com> We really need more new maps and quests. Please. __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From eracclists at bellsouth.net Tue Nov 8 11:30:03 2005 From: eracclists at bellsouth.net (ERACC) Date: Tue Nov 8 11:30:31 2005 Subject: [crossfire] New brest buildings In-Reply-To: <20051108132334.57989.qmail@web61011.mail.yahoo.com> References: <20051108132334.57989.qmail@web61011.mail.yahoo.com> Message-ID: <200511081130.04678.eracclists@bellsouth.net> On Tuesday 08 November 2005 07:23 am Mitch Obrian wrote: > The new yellow brest entrance building doesn't seem to > go with the brest style. Perhapse change it to > something more bresty? Not enough "Bresty" looking buildings. I didn't want to use one that already existed in Brest. Maybe you could recolor that one and make a new "Bresty" looking version. ;-) > Also I think I will make a townhouse arch for brest as > we only have a blue topped one. Works for me. If you do them, I will use them to replace the ones I used. Just let me know what arch names to find when making the requested change. Gene -- Mandriva Linux release 2006.0 (Official) for i586 11:26:05 up 12 days, 20:10, 14 users, load average: 0.52, 0.44, 0.29 ERA Computer Consulting - http://www.eracc.com/ eCS, Linux, FreeBSD, OpenServer & UnixWare resellers From brenlally at gmail.com Thu Nov 10 18:29:52 2005 From: brenlally at gmail.com (Brendan Lally) Date: Thu Nov 10 18:31:23 2005 Subject: [crossfire] jcrossclient lives. Message-ID: <7903f03c0511101629i4b25ffadgd4887bfe67095cc@mail.gmail.com> As those of you who follow #crossfire on freenode will be aware, I have recently taken over Phil Brown's jcrossclient project, and started updating it to make it work again with modern servers. I have tonight uploaded a new version of jcrossclient to the sourceforge page I created for it a few days ago. It can be found https://sourceforge.net/projects/jcrossclient/ This is the first new version to be released in four and a half years. In keeping with the previous numbering system, this is version 1.0-alpha-2. Please note that this /is/ an alpha release, and therefore should not be considered suitable for use as a main client (yet). If you play using this client, and get killed due to a bug, I will not be held responsible. Major changes of note since the previous release include: * Support for PNG images (and removal of xpm support) * Support for big images on the map view * Support for scaled big images in the ground view window ( as seen at https://sourceforge.net/project/screenshots.php?group_id=152431) * Numberpad now works for control * Names in the inventory window are no longer corrupted. * default view size is 15x15 * Removal of fatigue bar Known Bugs: * Command window is a bit, interesting, and sometimes throws exceptions if the commands are malformated. Unlike other crossfire clients, jcrossclient requires commands to be prefixed by ' and say commands to be prefixed by " * Main window doesn't get created at the correct size, and must be manually re-sized to expose the stat bars. * Map updates are somewhat slow, even on my AMD64 system, and the display can flicker if it has lots of activity (like rapid movement). I hope to address these issues over the coming weeks, most noticably the map update speed/smoothess issue, as well as continuing to add support for more of the newer features that the server can provide (such as new_draw_info_ext support). From lalo.martins at gmail.com Fri Nov 11 03:33:31 2005 From: lalo.martins at gmail.com (Lalo Martins) Date: Fri Nov 11 03:37:35 2005 Subject: [crossfire] weather, lattitude, town location, and the world Message-ID: Now that some people seem to be working on salvaging the weather system... I remember one thing that was somewhat polemic about it, was the choice of two *corners* of the map for the poles (nw and se IIRC), rather than the north and south as would seem more reasonable. This does incidentally work remarkably well for Wolfsburg, which ends up a hot, but miserably rainy town - as would be expected of a pirate port. Scorn is also suitably temperate, and the "mushroom peninsula" is tropical enough for its swamp. However, it can be argued that Brest/Britany is warmer than it should. And I haven't yet seen mikeusa's new region. Another problem of this approach is that it assumes we're looking at the complete planet; however, some devs have expressed the view that this is but one continent. The plaque in Lone Town's "dragon" entrance claims Pupland is an island (which actually kind of shocked me, I always thought it was the name of the nation, but I digress). And the Empire supposedly originated from another continent, with which we lost contact eventually for unknown reasons. So before the weather system is made usable, it would IMHO be a good idea to make a decision about where "our" continent is located on the planet. Given the distribution of cities, I would expect it to be in the southern hemisphere; although this would kind of spoil it for the "mushroom peninsula", it makes sense for all towns. Of use here could be Brendan's recent mathematical unit rationalization: - 1 outdoor square = 1 chain - the continent is approximately 1500 chains from N to S and from W to E; about 18 miles, or 30 km. - Earth (for comparison) is about 992716 chains from N to S (12409 miles, 19970 km), and 1992112 chains around the equator (24901 miles, 40075 km). - So if Bigworld is more or less the same size as Earth (and Brendan is correct), then this continent occupies about 0.075% of the W-E circumference, and about 0.15% of the distance between poles. - For another comparison, the Hawaiian island of O'ahu (where Honolulu is located) is about 2500 chains W-E (32 miles, 51km) and 3280 chains (41 miles, 66km). Since it's not as neatly square-ish as "our" continent, we can say they have roughly the same area. Hmm. Maybe "bigworld" is not big at all :-P Brendan's calculations still make sense to me generally, except that now I'm thinking about one-chain-wide mountains and finding them a bit silly. But that can pass, since those are relatively rare. On the other hand, fantasy worlds don't *have* to be the same size as Earth. (They don't even have to be the same shape... a disc, with the "pole" at the center, or a ring, or even the "normal" shape but with us in the inside rather than outside, are all heard of; and many fantasy worlds are simply flat - some discoid, some rectangular. So there. But we'd better stick with almost-spherical, if for no other reason, because changing the shape would probably require rethinking part of the weather code. On the other hand, a rectangular flat world avoids problems of projection, in case we end up mapping the whole surface.) For consistency reasons (since we don't have contact with other continents, and what with dragons and magic, I believe we have more than enough "technology" to do that), I can see two possibilities: 1 - the world is *much* smaller than Earth - the maps we have (in /world) cover from 10% to half its area. People don't go to the "old continent" because they don't want to (maybe they're afraid of the "old empire", or maybe the "old empire" indeed has powerful defenses, or maybe it was overtaken by monsters.) 2 - the world is mostly water-covered; there may be other inhabited continents out there, but the chance of a traveller actually finding it is so small, that nobody bothers to try. Nobody knows exactly where the "old empire" is supposed to be; if anyone ever found it, they didn't come back. The world could still be somewhat smaller than Earth, just to give us enough weather variation in our continent; if we make the world 1% the dimensions of Earth, then our continent would be proportionally about the size of Australia. (I'd make it slightly bigger than that; what about 15000 chains from pole to pole - so our continent is a neat exact 10% - and 32000 around the equator?) 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.martins@gmail.com GNU: never give up freedom http://www.gnu.org/ From yann.chachkoff at myrealbox.com Fri Nov 11 04:29:14 2005 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Fri Nov 11 04:29:34 2005 Subject: [crossfire] jcrossclient lives. In-Reply-To: <7903f03c0511101629i4b25ffadgd4887bfe67095cc@mail.gmail.com> References: <7903f03c0511101629i4b25ffadgd4887bfe67095cc@mail.gmail.com> Message-ID: <200511111129.23032.yann.chachkoff@myrealbox.com> Just a small question: Why hasn't been jcrossclient made part of the Crossfire project, but is being maintained separately ? It seems a bit strange to me, especially since there is obviously no licencing issue. Le Vendredi 11 Novembre 2005 01:29, Brendan Lally a ?crit : > As those of you who follow #crossfire on freenode will be aware, I > have recently taken over Phil Brown's jcrossclient project, and > started updating it to make it work again with modern servers. > > I have tonight uploaded a new version of jcrossclient to the > sourceforge page I created for it a few days ago. > > It can be found https://sourceforge.net/projects/jcrossclient/ > > This is the first new version to be released in four and a half years. > > In keeping with the previous numbering system, this is version 1.0-alpha-2. > > Please note that this /is/ an alpha release, and therefore should not > be considered suitable for use as a main client (yet). If you play > using this client, and get killed due to a bug, I will not be held > responsible. > > Major changes of note since the previous release include: > > * Support for PNG images (and removal of xpm support) > > * Support for big images on the map view > > * Support for scaled big images in the ground view window ( as seen at > https://sourceforge.net/project/screenshots.php?group_id=152431) > > * Numberpad now works for control > > * Names in the inventory window are no longer corrupted. > > * default view size is 15x15 > > * Removal of fatigue bar > > Known Bugs: > * Command window is a bit, interesting, and sometimes throws > exceptions if the commands are malformated. Unlike other crossfire > clients, jcrossclient requires commands to be prefixed by ' and say > commands to be prefixed by " > > * Main window doesn't get created at the correct size, and must be > manually re-sized to expose the stat bars. > > * Map updates are somewhat slow, even on my AMD64 system, and the > display can flicker if it has lots of activity (like rapid movement). > > > I hope to address these issues over the coming weeks, most noticably > the map update speed/smoothess issue, as well as continuing to add > support for more of the newer features that the server can provide > (such as new_draw_info_ext support). > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -- Yann Chachkoff ----------------------- Garden Dwarf's Best Friend ----------------------- GPG Key : http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 -------------- 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/20051111/65910d03/attachment.pgp From antonoussik at gmail.com Fri Nov 11 05:15:13 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Fri Nov 11 05:15:35 2005 Subject: [crossfire] weather, lattitude, town location, and the world In-Reply-To: References: Message-ID: On 11/11/05, Lalo Martins wrote: > Now that some people seem to be working on salvaging the weather system... > > I remember one thing that was somewhat polemic about it, was the choice > of two *corners* of the map for the poles (nw and se IIRC), rather than > the north and south as would seem more reasonable. Yes, it made the poles smaller, and the equator larger, as should be on a circle-shaped thing it tried to emulate. Of course if you stuck the diagonal ends together you would end up with something relembling two cones put end to end, but it is a far better approximation to a globe than a cyllinder. > This does incidentally work remarkably well for Wolfsburg, which ends up > a hot, but miserably rainy town - as would be expected of a pirate port. > Scorn is also suitably temperate, and the "mushroom peninsula" is > tropical enough for its swamp. However, it can be argued that > Brest/Britany is warmer than it should. And I haven't yet seen > mikeusa's new region. > > Of use here could be Brendan's recent mathematical unit rationalization: > - 1 outdoor square = 1 chain > - the continent is approximately 1500 chains from N to S and from W to > E; about 18 miles, or 30 km. > - Earth (for comparison) is about 992716 chains from N to S (12409 > miles, 19970 km), and 1992112 chains around the equator (24901 miles, > 40075 km). > - So if Bigworld is more or less the same size as Earth (and Brendan is > correct), then this continent occupies about 0.075% of the W-E > circumference, and about 0.15% of the distance between poles. > - For another comparison, the Hawaiian island of O'ahu (where Honolulu > is located) is about 2500 chains W-E (32 miles, 51km) and 3280 chains > (41 miles, 66km). Since it's not as neatly square-ish as "our" > continent, we can say they have roughly the same area. I agree that Brendan's calculations make a lot of sense, and we are pretending that we live on a planet whilst hardly occupying an island, unless the planet is very very small, which means it is very dense and quite close to the sun to get its heat. Since there is a lot of radiation on it, there are many mutations, which lead to some strange monsters we seem to be encountering. As for an athmosphere... the planet is probably very dense. :) > Hmm. Maybe "bigworld" is not big at all :-P Brendan's calculations > still make sense to me generally, except that now I'm thinking about > one-chain-wide mountains and finding them a bit silly. But that can > pass, since those are relatively rare. Such rock formations may actually be possible, wih a hard surface and wind and such. Since the planet is not Earth and since we are willing to accept teleportation and beds to reality, then why not small naturally occuring rock formations? > On the other hand, fantasy worlds don't *have* to be the same size as > Earth. (They don't even have to be the same shape... a disc, with the > "pole" at the center, or a ring, or even the "normal" shape but with us > in the inside rather than outside, are all heard of; and many fantasy > worlds are simply flat - some discoid, some rectangular. So there. But > we'd better stick with almost-spherical, if for no other reason, because > changing the shape would probably require rethinking part of the weather > code. On the other hand, a rectangular flat world avoids problems of > projection, in case we end up mapping the whole surface.) On a scale a player would be playing at a 2D approximation would suffice. If a whole surface is mapped, it would probably be best to store tiles as 2D polar coordinates on the surface of a sphere, and when a player enters worldmap extract and send the appropriate coordinate tiles to the player. That way only the parts of the hugemap that players are on would need to be stored in memory. On the other hand the data structure we would need to store tile coordinates and code to approximate them to generate a 2D projection of what player sees may be both CPU and memory consuming. Then seas could be auto-generated depending on the altitude, and global warming/cooling flooding/deserting/freezing could take its normal cause. Having a true globe would open up new weather and other effects, such as calculating weather by determining the amount of light that hits the surface by using ray tracing algorithm, and from there calculating how weather changes. This could result in a very realistic weather model, but probably too computationally intensive for an adventure game (not a weather, economy, eco-system simulator with elements of real time strategy, sim city, the sims, and tux racer). However you would then be able to set rotation speed, sun brightnes, and planetary mass to inflence all other game elements in a consistent fashion. Umm, you probably can already with minor modifications. > For consistency reasons (since we don't have contact with other > continents, and what with dragons and magic, I believe we have more than > enough "technology" to do that), I can see two possibilities: > > 1 - the world is *much* smaller than Earth - the maps we have (in > /world) cover from 10% to half its area. People don't go to the "old > continent" because they don't want to (maybe they're afraid of the "old > empire", or maybe the "old empire" indeed has powerful defenses, or > maybe it was overtaken by monsters.) Seems reasonable. From time to time you can even introduce random attacks by somewhat powerful monstes from old empire who try to take over your continent to re-inforce the belief. Also this model does not violate the current weather system in any way, so I like it. Besides the planet that is 80mi in circumferance is still a whole deal bigger with what the little prince had to make do with :-) > 2 - the world is mostly water-covered; there may be other inhabited > continents out there, but the chance of a traveller actually finding it > is so small, that nobody bothers to try. Nobody knows exactly where the > "old empire" is supposed to be; if anyone ever found it, they didn't > come back. The world could still be somewhat smaller than Earth, just > to give us enough weather variation in our continent; if we make the > world 1% the dimensions of Earth, then our continent would be > proportionally about the size of Australia. (I'd make it slightly > bigger than that; what about 15000 chains from pole to pole - so our > continent is a neat exact 10% - and 32000 around the equator?) This model as I understand it would need some modification to the weather code, to get rid of the extremes we seem to be suffering at the poles and the equator region. From lalo.martins at gmail.com Fri Nov 11 06:31:48 2005 From: lalo.martins at gmail.com (Lalo Martins) Date: Fri Nov 11 06:37:36 2005 Subject: [crossfire] Re: weather, lattitude, town location, and the world In-Reply-To: References: Message-ID: And so says Anton Oussik on 11/11/05 19:15... > This model as I understand it would need some modification to the > weather code, to get rid of the extremes we seem to be suffering at > the poles and the equator region. ultimately, what we can do is discuss and raise pros and cons; the final decision (in the crossfire model) is up to whoever is actually working on the weather code. That said, I'm not discarding options that requires changes to the weather code, because it's generally agreed that the weather system as it currently stands is *broken* - fun, but broken :-) so the whole point is that changes are being made anyway, therefore, it's probably the best time to think about this stuff. 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.martins@gmail.com GNU: never give up freedom http://www.gnu.org/ From temitchell at sympatico.ca Fri Nov 11 09:14:16 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Fri Nov 11 09:15:38 2005 Subject: [crossfire] Re: weather, lattitude, town location, and the world In-Reply-To: References: Message-ID: <4374B548.5000907@sympatico.ca> One long held belief I have had concerning the weather code is that we shouldn't be trying to model two entire hemispheres. We should place the existing bigworld map in either the 'northern' or 'southern' hemisphere of the planet where the pole is at one edge and the equator (or even a tropic) at another. This still gives an entire range of climate but doubles the size of the zones which would help I believe. It also means one day long in the future we could add another continent. For now, we could add some virtual terrain for the other hemisphere or do something like mirror the existing data to avoid a huge 'flat data' spot in the missing hemisphere. -tm Lalo Martins wrote: >And so says Anton Oussik on 11/11/05 19:15... > > >>This model as I understand it would need some modification to the >>weather code, to get rid of the extremes we seem to be suffering at >>the poles and the equator region. >> >> > >ultimately, what we can do is discuss and raise pros and cons; the final >decision (in the crossfire model) is up to whoever is actually working >on the weather code. > >That said, I'm not discarding options that requires changes to the >weather code, because it's generally agreed that the weather system as >it currently stands is *broken* - fun, but broken :-) so the whole point >is that changes are being made anyway, therefore, it's probably the best >time to think about this stuff. > >best, > Lalo Martins >-- > From mikeeusaaa at yahoo.com Fri Nov 11 07:04:06 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Nov 11 12:43:09 2005 Subject: [crossfire] Re: weather, lattitude, town location, and the world In-Reply-To: Message-ID: <20051111130406.30892.qmail@web61014.mail.yahoo.com> It's not really broken at all... it works fine on my server and that's on level 5 :). The poles should be extremely cold IMHO. --- Lalo Martins wrote: > And so says Anton Oussik on 11/11/05 19:15... > > This model as I understand it would need some > modification to the > > weather code, to get rid of the extremes we seem > to be suffering at > > the poles and the equator region. > > ultimately, what we can do is discuss and raise pros > and cons; the final > decision (in the crossfire model) is up to whoever > is actually working > on the weather code. > > That said, I'm not discarding options that requires > changes to the > weather code, because it's generally agreed that the > weather system as > it currently stands is *broken* - fun, but broken > :-) so the whole point > is that changes are being made anyway, therefore, > it's probably the best > time to think about this stuff. > > 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.martins@gmail.com > GNU: never give up freedom > http://www.gnu.org/ > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs From mikeeusaaa at yahoo.com Fri Nov 11 07:03:45 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Nov 11 12:43:11 2005 Subject: [crossfire] Re: weather, lattitude, town location, and the world In-Reply-To: Message-ID: <20051111130345.24162.qmail@web61024.mail.yahoo.com> It's not really broken at all... it works fine on my server and that's on level 5 :). --- Lalo Martins wrote: > And so says Anton Oussik on 11/11/05 19:15... > > This model as I understand it would need some > modification to the > > weather code, to get rid of the extremes we seem > to be suffering at > > the poles and the equator region. > > ultimately, what we can do is discuss and raise pros > and cons; the final > decision (in the crossfire model) is up to whoever > is actually working > on the weather code. > > That said, I'm not discarding options that requires > changes to the > weather code, because it's generally agreed that the > weather system as > it currently stands is *broken* - fun, but broken > :-) so the whole point > is that changes are being made anyway, therefore, > it's probably the best > time to think about this stuff. > > 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.martins@gmail.com > GNU: never give up freedom > http://www.gnu.org/ > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From mikeeusaaa at yahoo.com Fri Nov 11 07:14:20 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Nov 11 12:43:15 2005 Subject: [crossfire] CVS doesn't work for me again. Message-ID: <20051111131420.85979.qmail@web61021.mail.yahoo.com> This happenes every month... cvs sucks: mikeeusa@cvs.sourceforge.net's password: cvs checkout: warning: cannot write to history file /cvsroot/crossfire/CVSROOT/history: Read-only file system cvs checkout: Updating arch cvs checkout: failed to create lock directory for `/cvsroot/crossfire/arch' (/cvsroot/crossfire/arch/#cvs.lock): Read-only file system cvs checkout: failed to obtain dir lock in repository `/cvsroot/crossfire/arch' cvs [checkout aborted]: read lock failed - giving up __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From alex_sch at telus.net Fri Nov 11 13:31:39 2005 From: alex_sch at telus.net (Alex Schultz) Date: Fri Nov 11 13:33:34 2005 Subject: [crossfire] Re: weather, lattitude, town location, and the world In-Reply-To: <20051111130345.24162.qmail@web61024.mail.yahoo.com> References: <20051111130345.24162.qmail@web61024.mail.yahoo.com> Message-ID: <4374F19B.9090005@telus.net> Mitch Obrian wrote: >It's not really broken at all... it works fine on my >server and that's on level 5 :). > It's not broken in the sense that it runs. However it's scale is way off, if the scale was right, scorn would instead of being patchy rain, have larger areas of rain, and the chance of there being a sunny day in scorn is much greater. At the current scale, the weather has too much granularity, wet areas are wet, dry are dry, etc. however the chance of there being no rain or snow anywhere in scorn at a given time is too low, because though small patches may be without rain/snow, patches of random sunniness should cover larger areas, at least as big as all of scorn usually. (and my sunniness, I don't mean map brightness, I mean lack of rain/snow at a time) Alex Schultz From brenlally at gmail.com Fri Nov 11 16:13:30 2005 From: brenlally at gmail.com (Brendan Lally) Date: Fri Nov 11 16:13:43 2005 Subject: [crossfire] jcrossclient lives. In-Reply-To: <200511111129.23032.yann.chachkoff@myrealbox.com> References: <7903f03c0511101629i4b25ffadgd4887bfe67095cc@mail.gmail.com> <200511111129.23032.yann.chachkoff@myrealbox.com> Message-ID: <7903f03c0511111413k62b1b38ax4e2ec8ceecbf4f5c@mail.gmail.com> On 11/11/05, Yann Chachkoff wrote: > Just a small question: Why hasn't been jcrossclient made part of the Crossfire > project, but is being maintained separately ? It seems a bit strange to me, > especially since there is obviously no licencing issue. There is also no code shared between the two. Whereas the cfclient/gcfclient/scfclient and gcfclient2 are all written in C, using the same code in common/ jcrossclient doesn't. Everything is written in java (or with the newer parts in a mutated form of java that is pretending to be C, but that is more an issue of my coding style). Also the eventual goal is different. I intend to modernise the featureset of jcrossclient, to match up to current servers, but after that, I intend to turn it into a web applet, so that crossfire servers can offer a way to play on them with a web browser using a java plugin (mikee has already told me that he will do this with cat2, once it is working) This is still a couple of months away, but even so, it is the nature of such a goal that the release schedule will be different for jcrossclient compared to crossfire as a whole (and, at least initially, I expect be having a release every week or two as I try to stabalise towards a 1.0 release. - having these releases announced in connection with the main crossfire project may very easily cause confusion, especially since the version numbering is different (look at the number of questions that occured around the time of the 1.7.1 cfclient/gcfclient release). One final point, the controls are subtly different, and the nature of awt is such that it would be very hard to get it to mimic the gtk clients behaviour in all respects, as such it is likely that there will need to remain seperate control documentation, which again is harder to differentiate in a single project. Do not think however that this means that there will not be significant design and code overlaps, I have already ported/mutilated some code from gcfclient for the map1a parser, I would like to think that in future such a transfer could also happen the other way, although that is not likely to be until there is more code to borrow. From brenlally at gmail.com Fri Nov 11 17:06:34 2005 From: brenlally at gmail.com (Brendan Lally) Date: Fri Nov 11 17:07:44 2005 Subject: [crossfire] weather, lattitude, town location, and the world In-Reply-To: References: Message-ID: <7903f03c0511111506h58465613m921a18ea9c102756@mail.gmail.com> On 11/11/05, Anton Oussik wrote: > On 11/11/05, Lalo Martins wrote: > > Hmm. Maybe "bigworld" is not big at all :-P Brendan's calculations > > still make sense to me generally, except that now I'm thinking about > > one-chain-wide mountains and finding them a bit silly. But that can > > pass, since those are relatively rare. > > Such rock formations may actually be possible, wih a hard surface and > wind and such. Since the planet is not Earth and since we are willing > to accept teleportation and beds to reality, then why not small > naturally occuring rock formations? These /do/ exist in the real world, a quick google turned up http://home.bawue.de/~jjk/travel/Urlaub%202002/Canyonlands/Needles%202.png They don't look like they occupy much more than a tenth of an acre. Of course, arguably they should be called rock formations, and not mountains, but that is a different point. Personally I would say that if bigworld were not already established, it would be nicer to use a height map, so that each square would have a height associated with it, and then whether they are hill, mountain, plain, river or desert could be inferred from the height values (the areas that cities are currently on would need to be flat, with a depression to the side with between them and the nearest sea facing mountains, to redirect the resulting river). This would have the added advantage of reducing the size of the bigworld maps download, although at a cost of slower startup time. Note that I don't actually suggest this is done, but merely seek to describe how it might work. Effectively to go from a height map to terrain, you would need to determine a coastline (being areas that have height <0) determine the water absorption, (inversely proportional to depth and distance from shore should be a reasonable approximation) and then propagate water along a path roughly parrallel to the coastline, losing water with a rate given by grad(height), low flat areas inland would be deserts under that model, unless there was a small lake in which case an oasis would form, if there were a mountain range then, there would be a watershed given by the peak, so that a river would form along the path that involves the quickest drop to sea level. if the mountains are not very high, then water would flow down the other side too, creating savannah or temperate forests (based on temperature) the rivers being created there would create areas of river delta, with either swamps/rainforest or bogs/farmland (depending on temperature, or local rainfall?) If this were done in a way that avoided the use of random numbers, this would still be a fixed value, and it might even be possible to set exits to go for 'nearest accessible square of arch' - for example a mountain cave might be set to be placed on the nearest mountain square to its current location (probably only 4-5 squares away, unless the heightmap is altered substantially). From lalo.martins at gmail.com Fri Nov 11 22:08:31 2005 From: lalo.martins at gmail.com (Lalo Martins) Date: Fri Nov 11 22:13:54 2005 Subject: [crossfire] Re: weather, lattitude, town location, and the world In-Reply-To: <7903f03c0511111506h58465613m921a18ea9c102756@mail.gmail.com> References: <7903f03c0511111506h58465613m921a18ea9c102756@mail.gmail.com> Message-ID: And so says Brendan Lally on 11/12/05 07:06... > Personally I would say that if bigworld were not already established, > it would be nicer to use a height map, so that each square would have > a height associated with it We do have an "elevation" attribute in each floor object of outdoors maps. 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.martins@gmail.com GNU: never give up freedom http://www.gnu.org/ From yann.chachkoff at myrealbox.com Sat Nov 12 01:23:03 2005 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sat Nov 12 01:23:52 2005 Subject: [crossfire] jcrossclient lives. Message-ID: <1131780183.c803883cyann.chachkoff@myrealbox.com> You missed my point. I wasn't suggesting that the JCrossclient should have been part of the CF client subtree (as the X11, GTK and GTK2 are), but siomply why the JCrossclient wasn't part of the main Crossfire tree, alongside the (C) client, the Java Editor, the server, or the map sets. Given that all other CF-related subprojects so far have all been integrated in a unique CVS root tree, I didn't get (and still don't) why it was different for JCrossclient. It would have allowed all CF developers to contribute to the Java client, instead of having to register a second time. From mwedel at sonic.net Sat Nov 12 01:45:13 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Nov 12 01:45:52 2005 Subject: [crossfire] weather, lattitude, town location, and the world In-Reply-To: <7903f03c0511111506h58465613m921a18ea9c102756@mail.gmail.com> References: <7903f03c0511111506h58465613m921a18ea9c102756@mail.gmail.com> Message-ID: <43759D89.7080108@sonic.net> Brendan Lally wrote: > On 11/11/05, Anton Oussik wrote: >> On 11/11/05, Lalo Martins wrote: >>> Hmm. Maybe "bigworld" is not big at all :-P Brendan's calculations >>> still make sense to me generally, except that now I'm thinking about >>> one-chain-wide mountains and finding them a bit silly. But that can >>> pass, since those are relatively rare. >> Such rock formations may actually be possible, wih a hard surface and >> wind and such. Since the planet is not Earth and since we are willing >> to accept teleportation and beds to reality, then why not small >> naturally occuring rock formations? > > These /do/ exist in the real world, a quick google turned up > http://home.bawue.de/~jjk/travel/Urlaub%202002/Canyonlands/Needles%202.png > > They don't look like they occupy much more than a tenth of an acre. > Of course, arguably they should be called rock formations, and not > mountains, but that is a different point. The other gotcha on those as related to crossfire is that if they are just spikes of rock, you'd walk around them, thus they should not adversely affect movement like mountains do. > > Personally I would say that if bigworld were not already established, > it would be nicer to use a height map, so that each square would have > a height associated with it, and then whether they are hill, mountain, > plain, river or desert could be inferred from the height values (the > areas that cities are currently on would need to be flat, with a > depression to the side with between them and the nearest sea facing > mountains, to redirect the resulting river). > > This would have the added advantage of reducing the size of the > bigworld maps download, although at a cost of slower startup time. The problem is that it is desirable in lots of cases to actually set up specific terrain. Way back when the bigworld was created, there were discussions related to making it more dynamic, but it was basically decided that having the map more static was desirable. that said, when the world was created, a perlin function was used to create an altitude map, and based an altitude, different terrain types were assigned. That of course isn't very realistic. Around here, we have coastal mountians that are only a few thousand feet high. And there are high forests. Crossfire is somewhat limited by only 1 aspect of terrain is available (we don't have forested mountains for example). All that said, if we were to create another continent and wanted to start with an automatic process, there are many improvments I can think of: 1) Create altitude map (with different seed of course) like did before. 2) Based on that altitude map, run weather on it for a long time (elevation <0 is of course see). This gets us rainfall & temperature for different spaces. Then with that, you can do most of what you state: With that info, you can then have some idea what goes on each space. Spaces with <5" rainfall would be desert/tundra (based on temperature). One could do some basic erosion. Water has to go somewhere, so that determines rivers, lakes, and marshes (lakes would basically be formed when the total water flowing into a set of spaces is above some amount and that set of space(s) is constrained by higher objects around that would hold the water. Mountains should probably be determined if the elevation is above some height. But low mountains are also possible, but that should be done based on different of elevation of neighboring spaces - if a space is say 1000' different in elevation from its neighbors, it is a mountain. similar for mountains, but no height - just height difference (in the 250-500' range?). Otherwise, type of terrain is determined by weather and rainfall. jungle requires high rainfall and warm temperatures, etc. From brenlally at gmail.com Sat Nov 12 07:54:00 2005 From: brenlally at gmail.com (Brendan Lally) Date: Sat Nov 12 07:55:58 2005 Subject: [crossfire] weather, lattitude, town location, and the world In-Reply-To: <43759D89.7080108@sonic.net> References: <7903f03c0511111506h58465613m921a18ea9c102756@mail.gmail.com> <43759D89.7080108@sonic.net> Message-ID: <7903f03c0511120554q12e6893bq7bb26ec1cf90aaf0@mail.gmail.com> On 11/12/05, Mark Wedel wrote: > Crossfire > is somewhat limited by only 1 aspect of terrain is available (we don't have > forested mountains for example). Forested mountains could exist in principle, it just requires someone to be able to draw alpine trees. > All that said, if we were to create another continent and wanted to start with > an automatic process, there are many improvments I can think of: > > 1) Create altitude map (with different seed of course) like did before. Actually, I think it might be preferable to create tectonic plate boundaries, and then generate heights from that, it would give a much greater concentration of mountains, without having them scattered everywhere (and impeding movement) It would also be more realistic. > 2) Based on that altitude map, run weather on it for a long time (elevation <0 > is of course see). The problem with that is that the same results aren't guarenteed, so if this is done once, and a mistake is made with a heightmap somewhere (a big mountain in the centre of navar, say) it could be difficult to run the weathermap to the same effect again after fixing it. > Water has to go somewhere, so that determines rivers, > lakes, and marshes (lakes would basically be formed when the total water flowing > into a set of spaces is above some amount and that set of space(s) is > constrained by higher objects around that would hold the water. This would also be limited by temperature, at lower temperatures, the amount of inflowing water needed is less, because less evaporation occurs. (this is a major part of the reason why there are so many lakes in scandinava). > Mountains should probably be determined if the elevation is above some height. > But low mountains are also possible, but that should be done based on > different of elevation of neighboring spaces - if a space is say 1000' different > in elevation from its neighbors, it is a mountain. > > similar for mountains, but no height - just height difference (in the 250-500' > range?). Well, if the surrounding area is high, and there is a line of low altitude, then you get a canyon, if the surrounding land is low, and there is a line of high altitude, then you get a mountain ridge. From brenlally at gmail.com Sat Nov 12 08:11:51 2005 From: brenlally at gmail.com (Brendan Lally) Date: Sat Nov 12 08:11:58 2005 Subject: [crossfire] jcrossclient lives. In-Reply-To: <1131780183.c803883cyann.chachkoff@myrealbox.com> References: <1131780183.c803883cyann.chachkoff@myrealbox.com> Message-ID: <7903f03c0511120611p65e4829m471aad5f87566e85@mail.gmail.com> On 11/12/05, Yann Chachkoff wrote: > You missed my point. I wasn't suggesting that the JCrossclient should have been >part of the CF client subtree (as the X11, GTK and GTK2 are), but siomply why the >JCrossclient wasn't part of the main Crossfire tree, alongside the (C) client, the Java >Editor, the server, or the map sets. > > Given that all other CF-related subprojects so far have all been integrated in a > unique CVS root tree, I didn't get (and still don't) why it was different for JCrossclient. > It would have allowed all CF developers to contribute to the Java client, instead of > having to register a second time. Three reasons: 1) It traditionally hasn't been, and I don't expect or rely on anyone else in the project to know enough about it to fix my bugs, at least not yet. I am only awake part of the day, and on #crossfire somewhat less, so at least in the medium term to be able to say to someone who might ask questions about it, 'this is not an official part of the crossfire project, ask cavehippo' is a useful thing. 2) Because I am not an admin of the crossfire project and therefore couldn't do file releases. (and as I previously stated, I will want to do them a lot over the next few months. 3) The way it is written, much of it is still fairly interconnected, there isn't as clear a seperation between the internal structure of the client and the interface, as there is with the main client. This and the fact that the entire source tree is currently 3524 source lines of code (compared with 5293 in the last relase 4 and a half years ago), so it would be very difficult to have multiple people work on subprojects of any size without treading on each other's toes. This does not mean I do not welcome any assistance, I do, and gladly, but for small patches the patch tracker is a better choice, and for large patches you /will/ need to coordinate with me anyway, at least until I stop having every class in a state of flux. (so far the only classes I haven't altered are VertPanel and PopWin, and I intend to deal with them shortly). Of course if sourceforge used a better source code management system, like subversion, this wouldn't be an issue. crossfire is a mature project, with a reasonable degree of stability, and jcrossclient isn't. At the point where I could say with reasonable certainty that there would be no need for releases more frequently than every server release, and that jcrossclient could be an optional extra for a server admin with a spare web server, then it could usefully be incorporated into the overall crossfire project. Until then, I don't see that as neccessary or beneficial. From leaf at real-time.com Sat Nov 12 14:59:29 2005 From: leaf at real-time.com (Rick Tanner) Date: Sat Nov 12 15:00:03 2005 Subject: [crossfire] jcrossclient lives. In-Reply-To: <7903f03c0511120611p65e4829m471aad5f87566e85@mail.gmail.com> References: <1131780183.c803883cyann.chachkoff@myrealbox.com> <7903f03c0511120611p65e4829m471aad5f87566e85@mail.gmail.com> Message-ID: <437657B1.2010209@real-time.com> Brendan Lally wrote: > > 2) Because I am not an admin of the crossfire project and therefore > couldn't do file releases. (and as I previously stated, I will want to > do them a lot over the next few months. Non-admins can do file releases. It's an option that can be toggled on/off by the project admins; either release tech and/or snapshop manager. From mwedel at sonic.net Sat Nov 12 15:21:44 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Nov 12 15:22:02 2005 Subject: [crossfire] weather, lattitude, town location, and the world In-Reply-To: <7903f03c0511120554q12e6893bq7bb26ec1cf90aaf0@mail.gmail.com> References: <7903f03c0511111506h58465613m921a18ea9c102756@mail.gmail.com> <43759D89.7080108@sonic.net> <7903f03c0511120554q12e6893bq7bb26ec1cf90aaf0@mail.gmail.com> Message-ID: <43765CE8.8050007@sonic.net> Brendan Lally wrote: > On 11/12/05, Mark Wedel wrote: >> Crossfire >> is somewhat limited by only 1 aspect of terrain is available (we don't have >> forested mountains for example). > > Forested mountains could exist in principle, it just requires someone > to be able to draw alpine trees. > >> All that said, if we were to create another continent and wanted to start with >> an automatic process, there are many improvments I can think of: >> >> 1) Create altitude map (with different seed of course) like did before. > > Actually, I think it might be preferable to create tectonic plate > boundaries, and then generate heights from that, it would give a much > greater concentration of mountains, without having them scattered > everywhere (and impeding movement) I believe there are other projects out there (not related to crossfire) about mimicing a planet creation process. If we were really serious, we should look at those. > > It would also be more realistic. > >> 2) Based on that altitude map, run weather on it for a long time (elevation <0 >> is of course see). > > The problem with that is that the same results aren't guarenteed, so > if this is done once, and a mistake is made with a heightmap somewhere > (a big mountain in the centre of navar, say) it could be difficult to > run the weathermap to the same effect again after fixing it. My point was that this would be done for a new continent. If that is the case, you start with a heightmap that looks reasonable (land mass about right shape, desired distribution, etc). You then run the weather on that, and with that, fill in the terrain. Then with that, you use that as the blank slate to start putting towns, dungeons, etc on. Having the above info actually makes some of that process easier - towns wouldn't be in the middle of a mountain range, but likely along the rivers, and most typical, at the river/sea junction. But point here is that this is still creating a map with actual forest spaces and whatnot - you use a dynamic process to create a static map. That said, if the same weather process is used to create this static map as that used in the game, then at least as the game runs, the weather would be consistent with the terrain. For example, right now, there are desert areas on the map, but with the weather code, I have no idea what level of rainfall they get, since the location of the desert was rather arbitrary set (lets put it here). Same for jungle & forest. > >> Water has to go somewhere, so that determines rivers, >> lakes, and marshes (lakes would basically be formed when the total water flowing >> into a set of spaces is above some amount and that set of space(s) is >> constrained by higher objects around that would hold the water. > > This would also be limited by temperature, at lower temperatures, the > amount of inflowing water needed is less, because less evaporation > occurs. (this is a major part of the reason why there are so many > lakes in scandinava). True. And if really clever, analysis of the rivers would lead to other terrain. Terrain that is very close to river/sea elevation would typically be swamp (river elevation in this case being the elevation of the river space compared to neighboring spaces). The amount of water flowing from the river relative to the number of spaces the river flows into would determine how big a lake gets (you could basically determine the depth of the lake). If it isn't very deep, or once again, relative to spaces next to the lake the altitude is about the same, you'd get marsh in those neighboring spaces. In geological terms, rivers will carve out valleys. So in those cases where a river flows into what would form a lake, see where the water would flow out and make some random determination if the ground in that area is hard (rock) or soft (earth/gravel/whatever), and thus a gorge would get eroded away to let the water out, and you don't have a lake anymore. > >> Mountains should probably be determined if the elevation is above some height. >> But low mountains are also possible, but that should be done based on >> different of elevation of neighboring spaces - if a space is say 1000' different >> in elevation from its neighbors, it is a mountain. >> >> similar for mountains, but no height - just height difference (in the 250-500' >> range?). > > Well, if the surrounding area is high, and there is a line of low > altitude, then you get a canyon, if the surrounding land is low, and > there is a line of high altitude, then you get a mountain ridge. Right, I mistyped in my second paragraph, I meant hills there. Hills would be terrain that changes altitude but not as drastically as mountain. Which makes sense - lots of mountain ranges have hills at the base of them From brenlally at gmail.com Sat Nov 12 21:30:27 2005 From: brenlally at gmail.com (Brendan Lally) Date: Sat Nov 12 21:32:06 2005 Subject: [crossfire] weather, lattitude, town location, and the world In-Reply-To: <43765CE8.8050007@sonic.net> References: <7903f03c0511111506h58465613m921a18ea9c102756@mail.gmail.com> <43759D89.7080108@sonic.net> <7903f03c0511120554q12e6893bq7bb26ec1cf90aaf0@mail.gmail.com> <43765CE8.8050007@sonic.net> Message-ID: <7903f03c0511121930o6ac80bbdx16e685ef6f97f80c@mail.gmail.com> On 11/12/05, Mark Wedel wrote: > Brendan Lally wrote: > > On 11/12/05, Mark Wedel wrote: > >> Crossfire > >> is somewhat limited by only 1 aspect of terrain is available (we don't have > >> forested mountains for example). > > > > Forested mountains could exist in principle, it just requires someone > > to be able to draw alpine trees. > > > >> All that said, if we were to create another continent and wanted to start with > >> an automatic process, there are many improvments I can think of: > >> > >> 1) Create altitude map (with different seed of course) like did before. > > > > Actually, I think it might be preferable to create tectonic plate > > boundaries, and then generate heights from that, it would give a much > > greater concentration of mountains, without having them scattered > > everywhere (and impeding movement) > > I believe there are other projects out there (not related to crossfire) about > mimicing a planet creation process. If we were really serious, we should look > at those. I did ask the freeciv developers on freenode about that point a few months back, they have a random world generator which creates tile based maps. However a lot of what they had was quite hardcoded, and they don't have a nice way to analyse the squares. - Plus the scale is much larger, millions of acres per square. This was just before their 2.0 release however, they map have something more hi-jackable now. > Then with that, you use that as the blank slate to start putting towns, > dungeons, etc on. Having the above info actually makes some of that process > easier - towns wouldn't be in the middle of a mountain range, but likely along > the rivers, and most typical, at the river/sea junction. That could work, particularly if canals were added later, so that boats could travel across much of the continent (your movement code reworking could make it possible then to have narrowboats to travel between cities). > But point here is that this is still creating a map with actual forest spaces > and whatnot - you use a dynamic process to create a static map. Yes, and thereafter are forced to use that static version to edit it, this is an issue if there is a change that would be easy to make with a heightmap, but which would require extensive modification otherwise. Incidentally, it also strikes me that the best way to get a height map would be from a grayscale image. - simply say that brightness is altitude, and then lots of adjustments could be made with the use of gimp filters. > That said, if the same weather process is used to create this static map as > that used in the game, then at least as the game runs, the weather would be > consistent with the terrain. For example, right now, there are desert areas on > the map, but with the weather code, I have no idea what level of rainfall they > get, since the location of the desert was rather arbitrary set (lets put it here). Also there aren't enough deserts, but that is another point altogether. > In geological terms, rivers will carve out valleys. So in those cases where a > river flows into what would form a lake, see where the water would flow out and > make some random determination if the ground in that area is hard (rock) or soft > (earth/gravel/whatever), and thus a gorge would get eroded away to let the water > out, and you don't have a lake anymore. The issue with doing that is that it would require playing with the sea levels as water evaporates, to compensate for the water falling as rain. As long as the world is mostly land, and not water, then that will be a significant effect. Furthermore, because in the real world, water will often drain through rock until it reaches an imporous layer, there is normally a water table rather than lots of water on the surface, creating vast swamps. It would be neccessary to account for this effect to avoid a disproportiate amount of swamp, maybe there would need to be two inputs then, elevation and geology? This would also improve lake formation, since it would simply be the point at which the water table intersects with the surrounding land. To get this to vary properly then, at least an approximation to measure groundwater flow would be needed. (probably the laplace approximation would be sufficiant, but I'd need to do some reading to check on that), hmm, hacking the weather code to include a water table would have some merit to it (for one thing, the quick hack would be to determine porous rock depth by archetype, so deserts might still get rain, but they would have lots of porous rock, so the water would never stay on the surface (yes, I realise that is not even vaguely what deserts actually are, but it would at least stop puddles forming....) From brenlally at gmail.com Sat Nov 12 21:52:02 2005 From: brenlally at gmail.com (Brendan Lally) Date: Sat Nov 12 21:52:06 2005 Subject: [crossfire] weather, lattitude, town location, and the world In-Reply-To: <43765CE8.8050007@sonic.net> References: <7903f03c0511111506h58465613m921a18ea9c102756@mail.gmail.com> <43759D89.7080108@sonic.net> <7903f03c0511120554q12e6893bq7bb26ec1cf90aaf0@mail.gmail.com> <43765CE8.8050007@sonic.net> Message-ID: <7903f03c0511121952h4b5de681u570f856313d2631a@mail.gmail.com> On 11/12/05, Mark Wedel wrote: > I believe there are other projects out there (not related to crossfire) about > mimicing a planet creation process. If we were really serious, we should look > at those. I just noticed this http://www.kde-apps.org/content/show.php?content=31243 on kde-apps, which may well be suitable. If only it didn't have such strange and bizzare dependancies.... From mikeeusaaa at yahoo.com Sun Nov 13 07:49:01 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sun Nov 13 10:37:42 2005 Subject: [crossfire] Could someone fix the dissapearing tile weather bug? (still has unfixed parts) In-Reply-To: <7903f03c0511121952h4b5de681u570f856313d2631a@mail.gmail.com> Message-ID: <20051113134901.50610.qmail@web61013.mail.yahoo.com> This is what happens now (some of it was fixed allready it seems, but this is the state now). Lets say you have this: ferns snow/puddle ground The ground will dissapear. __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From nicolas.weeger at laposte.net Sun Nov 13 12:29:52 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun Nov 13 12:30:17 2005 Subject: [crossfire] Could someone fix the dissapearing tile weather bug? (still has unfixed parts) In-Reply-To: <20051113134901.50610.qmail@web61013.mail.yahoo.com> References: <20051113134901.50610.qmail@web61013.mail.yahoo.com> Message-ID: <43778620.1060205@laposte.net> Mitch Obrian a ?crit : > This is what happens now (some of it was fixed > allready it seems, but this is the state now). > > Lets say you have this: > > ferns > snow/puddle > ground > > The ground will dissapear. As I said, I think it's related to the overlay loading. Try to change the following lines in object.c, insert_ob_in_map function originator->below = op; } else { /* If there are other objects, then */ if((! (flag & INS_MAP_LOAD)) && ((top=GET_MAP_OB(op->map,op->x,op->y))!=NULL)) { object *last=NULL; /* * If there are multiple objects on this space, we do some trickier handling. to originator->below = op; } else { /* If there are other objects, then */ if((top=GET_MAP_OB(op->map,op->x,op->y))!=NULL) { object *last=NULL; /* * If there are multiple objects on this space, we do some trickier handling. I'm not sure of side-effects, though.. Nicolas From mikeeusaaa at yahoo.com Sun Nov 13 13:55:50 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sun Nov 13 18:27:58 2005 Subject: [crossfire] Could someone fix the dissapearing tile weather bug? (still has unfixed parts) In-Reply-To: <43778620.1060205@laposte.net> Message-ID: <20051113195550.90770.qmail@web61011.mail.yahoo.com> Could you test it, now that I have users I don't want to possibly crash the server. --- Nicolas Weeger wrote: > Mitch Obrian a ?crit : > > This is what happens now (some of it was fixed > > allready it seems, but this is the state now). > > > > Lets say you have this: > > > > ferns > > snow/puddle > > ground > > > > The ground will dissapear. > > As I said, I think it's related to the overlay > loading. > > Try to change the following lines in object.c, > insert_ob_in_map function > > originator->below = op; > } else { > /* If there are other objects, then */ > if((! (flag & INS_MAP_LOAD)) && > ((top=GET_MAP_OB(op->map,op->x,op->y))!=NULL)) { > object *last=NULL; > /* > * If there are multiple objects on this space, > we do some trickier > handling. > > to > > originator->below = op; > } else { > /* If there are other objects, then */ > if((top=GET_MAP_OB(op->map,op->x,op->y))!=NULL) { > object *last=NULL; > /* > * If there are multiple objects on this space, > we do some trickier > handling. > > I'm not sure of side-effects, though.. > > Nicolas > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From nicolas.weeger at laposte.net Mon Nov 14 02:17:21 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon Nov 14 02:18:29 2005 Subject: =?iso-8859-1?b?UmU6IFtjcm9zc2ZpcmVdIENvdWxkIHNvbWVvbmUgZml4IHRoZSBk?= =?iso-8859-1?b?aXNzYXBlYXJpbmcgdGlsZSB3ZWF0aGVyIGJ1Zz8gKHN0aWxsIGhh?= =?iso-8859-1?b?cyB1bmZpeGVkIHBhcnRzKQ==?= Message-ID: > Could you test it, now that I have users I don't want > to possibly crash the server. I tested it locally, seemed fine. But I didn't really play with my change, and I have no idea what the side effects could be. Which is why I sent a mail on the list, in case some other people knew better :) Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From kirschbaum at myrealbox.com Mon Nov 14 15:19:13 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Mon Nov 14 15:21:06 2005 Subject: [crossfire] Weather bug, continued In-Reply-To: <436CDFCD.3000008@laposte.net> References: <436CDFCD.3000008@laposte.net> Message-ID: <20051114211913.GA30525@kirschbaum.myrealbox.com> Nicolas Weeger wrote: [...] > My proposed check is to change insert_ob_in_map for: > > originator->below = op; > } else { > /* If there are other objects, then */ > if((top=GET_MAP_OB(op->map,op->x,op->y))!=NULL) { > object *last=NULL; > /* > * If there are multiple objects on this space, we do some trickier > handling. > > ie search floor & such all the time. The code after handles INS_MAP_LOAD > and INS_ABOVE_FLOOR_ONLY flags. I still cannot follow all the code that are done while loading maps. But since the fix you propose here just reverses a part of the patch to accelerate map loading (see cvs diff -r 1.100 -r 1.101 common/object.c), it should not break too much. But reversing it will probably make map loading slow again. Therefore: would it be possible to limit this processing for overlay maps only? I.e. use something like if ((!(flag&INS_MAP_LOAD) || ) && top = ...) instead of the original version if (!(flag&INS_MAP_LOAD) && top = ...) > Btw it looks strange to me that an overlay is always on top. This problem should be solved with the above proposal, too: objects from the overlay map are merged correctly, but the original map is loaded with all the checks skipped. From mwedel at sonic.net Tue Nov 15 01:45:35 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Nov 15 01:44:50 2005 Subject: [crossfire] weather, lattitude, town location, and the world In-Reply-To: <7903f03c0511121952h4b5de681u570f856313d2631a@mail.gmail.com> References: <7903f03c0511111506h58465613m921a18ea9c102756@mail.gmail.com> <43759D89.7080108@sonic.net> <7903f03c0511120554q12e6893bq7bb26ec1cf90aaf0@mail.gmail.com> <43765CE8.8050007@sonic.net> <7903f03c0511121952h4b5de681u570f856313d2631a@mail.gmail.com> Message-ID: <4379921F.6020500@sonic.net> Brendan Lally wrote: > On 11/12/05, Mark Wedel wrote: >> I believe there are other projects out there (not related to crossfire) about >> mimicing a planet creation process. If we were really serious, we should look >> at those. > > I just noticed this > http://www.kde-apps.org/content/show.php?content=31243 on kde-apps, > which may well be suitable. > > If only it didn't have such strange and bizzare dependancies.... Well, realistically, this isn't much an issue - I'm not seeing any immediate need for a new continent, and thus not any immediate need to look at this that hard. That said, the existing perlin function generator is probably one of those algorithyms it actually uses. If/when that times come, then we can perhaps start looking more seriously at what solution to use. From mwedel at sonic.net Tue Nov 15 02:05:19 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Nov 15 02:04:49 2005 Subject: [crossfire] weather, lattitude, town location, and the world In-Reply-To: <7903f03c0511121930o6ac80bbdx16e685ef6f97f80c@mail.gmail.com> References: <7903f03c0511111506h58465613m921a18ea9c102756@mail.gmail.com> <43759D89.7080108@sonic.net> <7903f03c0511120554q12e6893bq7bb26ec1cf90aaf0@mail.gmail.com> <43765CE8.8050007@sonic.net> <7903f03c0511121930o6ac80bbdx16e685ef6f97f80c@mail.gmail.com> Message-ID: <437996BF.1030503@sonic.net> > That could work, particularly if canals were added later, so that > boats could travel across much of the continent (your movement code > reworking could make it possible then to have narrowboats to travel > between cities). I'd personally think that canals on that scale would be more modern than what crossfire is really set in. However, connecting the cities via roads would certainly make sense. > >> But point here is that this is still creating a map with actual forest spaces >> and whatnot - you use a dynamic process to create a static map. > > Yes, and thereafter are forced to use that static version to edit it, > this is an issue if there is a change that would be easy to make with > a heightmap, but which would require extensive modification otherwise. I'd make the case that any changes via heightmap, when interacting with weather, would be fairly unpredictable. Heightmap has all sorts of different effects - changing the elevation of some spaces could result in a whole host of changes (rivers changing course, etc). > > Incidentally, it also strikes me that the best way to get a height map > would be from a grayscale image. - simply say that brightness is > altitude, and then lots of adjustments could be made with the use of > gimp filters. Maybe. It'd depend on the source of that grayscale image. If you just used general blur routines, then you'd just get a very aged world (gentle slopes). But typically you do want some extremes - ranges of high points. That said, may be able to hand draw your rough idea what the continent in gimp is, use blending, etc. >> In geological terms, rivers will carve out valleys. So in those cases where a >> river flows into what would form a lake, see where the water would flow out and >> make some random determination if the ground in that area is hard (rock) or soft >> (earth/gravel/whatever), and thus a gorge would get eroded away to let the water >> out, and you don't have a lake anymore. > > The issue with doing that is that it would require playing with the > sea levels as water evaporates, to compensate for the water falling as > rain. As long as the world is mostly land, and not water, then that > will be a significant effect. For simplicity, I'd say that is not necessary. We have a height map. At some level, we are making a decision at what altitude is sea level and what isn't. Saying sea level is 10' lower after weather iterations isn't likely to make any radical changes on the map, and if you really wanted to, could make that adjustment before running the weather code (it really comes down to how much water you want). We're not trying to mimic an entire planet creation - what we're really wanting to do is run the weather code to fill in some of the features. If we start worrying about sea level, then you could start making cases like lots of forest would reduce CO2 content, thus making the area colder. Its easier to just start with some constants, like sea level is X (on earth, only 3% of the water is fresh water, and of that 3%, 69% is locked as glacier and icecaps (I'd venture amount if glaciers is relatively low)). So if doing a continent not at the polar regions, only talking about maybe 1% of the water being on that continent? > > hmm, hacking the weather code to include a water table would have some > merit to it (for one thing, the quick hack would be to determine > porous rock depth by archetype, so deserts might still get rain, but > they would have lots of porous rock, so the water would never stay on > the surface (yes, I realise that is not even vaguely what deserts > actually are, but it would at least stop puddles forming....) There is certainly some evaporative effect. That said, I don't really know if we need to know how porous the rock is - I'd just assume go without that and see what we get. Swamp would more be determined by water sitting there, eg, ground is flat enough that the water doesn't really have anyplace to flow, and temperature is such that the water doesn't evaporate. Adding porous seems to add yet another complication which I'm not sure we need - we're not trying to perfectly imitate earth here, were just trying to get a system that seems to work good enough. I never really liked the puddles much - perhaps because they were just so oversized related to the actual terrain (in some cases, being the size of lakes). I personally don't think we need that visual indicator, but rather, knowing rainfall and potentially having terrain evolve (or more appropriate, grow plants and herbs) would be the more interesting bits. That's actually one reason I play without weather - I just found all the puddles to be visually distracting without adding much. From mwedel at sonic.net Tue Nov 15 02:24:35 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Nov 15 02:24:49 2005 Subject: [crossfire] weather, lattitude, town location, and the world In-Reply-To: References: Message-ID: <43799B43.5010203@sonic.net> Going back to the original topic: 1) I never envisioned the current scorn continent to be the entire world. To say it is 1/4 of the world, or perhaps even less than that, would be reasonable. Until going off the map wraps you around, no reason to ever say exactly what/where it is. For weather purposes, it does make sense. For weather purposes, I'd place it in one hemisphere, either north or south. 2) When I originally did the map, I did the basis that 1 space = 1 mile. So 2500x2500 is actually a good sized continent (the land mass is actually less - that 2500x2500 is entire map size, which includes oceans). I do realize that this scale doesn't work really well relative to other things, like size of towns, and chains does work good for those. But then as said, the world is effectively ridiculously small (its really just a small island). Once could just say this lack of coherent scale is part of the game - we already have 2 scales anyways. This is better than the old maps, where we had 3 scales (with the towns being 2x2 or 3x3 icons spaces you entered to get something like you see now). One consideration on scale is actual change of terrain. You could certainly say that the planet is very small (few hundred miles diameter). One problem doing that is it becomes much harder to try to compare with any earth like environment/features. For example, I'd think on such a relatively small worlds, the mountains and elevation changes as a whole would be much smaller (a 25000' mountain is now a significant variation in the spherical pureness). I also wonder how weather would work on such a world - would you really get storm systems that are just a few miles wide? Now I suppose you could just make the case that everything behaves like earth, but on 1/10th scale. So going back to the original conversation: Placing the poles at either the very north or very south work fine, and not at the corners. Unless the poles are actually included on the map, there is no reason to worry about the effect. For that matter, it is a fantasy world - can make the case that the world is in fact flat, and Sorig (or whoever) goes across the world as the sun. Over the course of the year, he changes his course back and forth. Areas far away from his traversal path would of course be cold. From the current map, it seems like the south area is quite chily, with the north area of the continent being a desert. So putting the continent in the southern hemisphere would seem to make sense. From lalo.martins at gmail.com Tue Nov 15 04:52:04 2005 From: lalo.martins at gmail.com (Lalo Martins) Date: Tue Nov 15 04:56:51 2005 Subject: [crossfire] Re: weather, lattitude, town location, and the world In-Reply-To: <437996BF.1030503@sonic.net> References: <7903f03c0511111506h58465613m921a18ea9c102756@mail.gmail.com> <43759D89.7080108@sonic.net> <7903f03c0511120554q12e6893bq7bb26ec1cf90aaf0@mail.gmail.com> <43765CE8.8050007@sonic.net> <7903f03c0511121930o6ac80bbdx16e685ef6f97f80c@mail.gmail.com> <437996BF.1030503@sonic.net> Message-ID: And so says Mark Wedel on 11/15/05 16:05... >> That could work, particularly if canals were added later, so that >> boats could travel across much of the continent (your movement code >> reworking could make it possible then to have narrowboats to travel >> between cities). > > I'd personally think that canals on that scale would be more modern > than what crossfire is really set in. Not really. The ancient Chinese did it, and Bigworld has powerful and (relatively) cheap magic to make up for the low tech. 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.martins@gmail.com GNU: never give up freedom http://www.gnu.org/ From brenlally at gmail.com Tue Nov 15 09:28:33 2005 From: brenlally at gmail.com (Brendan Lally) Date: Tue Nov 15 09:28:57 2005 Subject: [crossfire] Re: weather, lattitude, town location, and the world In-Reply-To: References: <7903f03c0511111506h58465613m921a18ea9c102756@mail.gmail.com> <43759D89.7080108@sonic.net> <7903f03c0511120554q12e6893bq7bb26ec1cf90aaf0@mail.gmail.com> <43765CE8.8050007@sonic.net> <7903f03c0511121930o6ac80bbdx16e685ef6f97f80c@mail.gmail.com> <437996BF.1030503@sonic.net> Message-ID: <7903f03c0511150728l51ccbe0bmfade22631bac265e@mail.gmail.com> On 11/15/05, Lalo Martins wrote: > And so says Mark Wedel on 11/15/05 16:05... > > I'd personally think that canals on that scale would be more modern > > than what crossfire is really set in. > > Not really. The ancient Chinese did it, and Bigworld has powerful and > (relatively) cheap magic to make up for the low tech. Also there are the Roman Canals, Foss Dyke was built in the second century, and is over 10 miles long (about the length of the continent at the moment) From elshar at cheekan.org Tue Nov 15 16:15:48 2005 From: elshar at cheekan.org (Michael) Date: Tue Nov 15 16:20:08 2005 Subject: [crossfire] alchemy/alchemy In-Reply-To: <7903f03c0511051246g405410ddp402791a8da71dedb@mail.gmail.com> References: <7903f03c0511051246g405410ddp402791a8da71dedb@mail.gmail.com> Message-ID: <437A5E14.5050100@cheekan.org> Sorry I'm so late on this. I agree completely, and I also agree that the spell should change. I don't think 'Aura of Midas' is a good name, it seems to imply that the user will have an Aura that imbues them with Midas-like properties.. Maybe "Midas' Touch", or "Transmutation" or "Transmute to Gold" or something? :) Oh, and I too have been bitten by the fact that both the spell and the skill are named the same. I remember casting alchemy on my cauldron once.. grrr... :P Elshar Brendan Lally wrote: > Currently there are two concepts within the game world called > 'alchemy', the first is a skill for the transformation of items, the > second (which I was just reminded of today, having forgotten of it due > to its general uselessness) is the spell alchemy which transforms > items into gold. > > These two things having the same name is confusing, so I propose that > one of them change their name. > > since alchemy.c is a file that deals with the skill alchemy, it would > be more consistent to rename the spell. I propose the name 'aura of > midas' although if someone else has another idea then that would be > fine too. > > If it were the case that it were decided to keep the name alchemy for > the spell, then notwithstanding the comment about source file names, > it would be equally straightforward to rename the alchemy skill. In > this case I would suggest something like apothecary as a suitable > replacement name. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From nicolas.weeger at laposte.net Sun Nov 20 03:49:49 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun Nov 20 03:50:14 2005 Subject: [crossfire] Introducing item fatigue Message-ID: <438046BD.4010103@laposte.net> Hello. I'd like to discuss adding item weariness / fatigue. Basically: each item has max fatigue points, which decrease at use (when attacking for weapon, when attacked for shield, when player walks for shoes, you get the idea) Of course when fatigue reaches 0 the item breaks and is unusable or simply disappears, and you have facilities to repair (maybe skills can be used for that too). Also fatigue reduces item bonus/attack/defense/... after some thresold (<50% of total fatigue points?). Comments, opinions, critisicm? :) Ryo From yann.chachkoff at myrealbox.com Sun Nov 20 06:55:16 2005 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sun Nov 20 06:56:16 2005 Subject: [crossfire] Introducing item fatigue In-Reply-To: <438046BD.4010103@laposte.net> References: <438046BD.4010103@laposte.net> Message-ID: <200511201355.23709.yann.chachkoff@myrealbox.com> Le Dimanche 20 Novembre 2005 10:49, Nicolas Weeger a ?crit : > Hello. > > I'd like to discuss adding item weariness / fatigue. > Basically: each item has max fatigue points, which decrease at use (when > attacking for weapon, when attacked for shield, when player walks for > shoes, you get the idea) > Of course when fatigue reaches 0 the item breaks and is unusable or > simply disappears, and you have facilities to repair (maybe skills can > be used for that too). > Also fatigue reduces item bonus/attack/defense/... after some thresold > (<50% of total fatigue points?). > > Comments, opinions, critisicm? :) > > Ryo > I already made a similar fatigue proposal in the past on the forums, in a discussion related to alchemy. You'll find the copy of my own view of the topic ( http://forum.metalforge.net/viewtopic.php?t=815&start=15 ) For those too lazy to read, here is a summary of what I suggested. Fatigue applied to objects: -------------------------- - The existence of temporary fatigue (that wears off naturally) and permanent fatigue (items requiring repairs); - Fatigue doesn't make items unusable, but make them more prone to fail/break, or less effective; Fatigue applied to players/monsters: ----------------------------------- - Every complex action generates an amount of fatigue proportional to its difficulty; - There is no permanent fatigue for players/monsters; - The fatigue value isn't clearly visible by the players, but only a hint of it is given ("You look tired", "You feel aware", etc); - Fatigue increases the randomness of effects or their precision, rather than the chance of them to backfire on you in a nasty way; - Some items could be used to restore fatigue more than HP/Food (ex: cup of coffee). **** A long cut'n'paste being better than a short answer, here it what I initially wrote: Fatigue of the Cauldron ----------------------- A cauldron is made of metal. You put it on fire, throw ingredients that react sometimes very savagely inside and apply magical forces as well on it whenever you use one for alchemy. It thus sounds reasonable that it slowly degrades with use up to a point it isn't reliable anymore. I see this as a two-fold process: - Temporary fatigue, caused for example by the cauldron becoming very hot. Those fatigue points would wear off after a given amount of time; - Permanent fatigue which represents irreversible damages caused by alchemical processes on the cauldron. Those don't wear off, unless you get the cauldron to somebody able to repair it. Fatigue by itself doesn't render the cauldron useless: it just increases the chances of it to be destroyed when cooking something in it, possibly with nasty effects (like sudden explosion). Note that this element could actually be used to offer a gradation in the prices: a cheap cauldron would be able to support only a limited amount of fatigue while a costly, luxury one would be able to endure much more. It also introduces another way to spend money (repairing/replacing your cauldron), making the creation of easy-to-make objects less profitable commercially speaking. Note that since fatigue is completely independent of the difficulty of a given recipe, it is a convenient way to balance some overused recipes. And it is explainable by in-game ideas as well: Water of the Wise may be very easy to cast, but it may require a very high temperature, thus causing a lot of fatigue to the cauldron. In my own idea, I'd say that an easy formula could cause a high amount of temporary fatigue, but little or no permanent one, thus harming only industrial alchemists. On the other hand, advanced alchemy could cause fewer temporary fatigue, but more permanent one, reflecting the difficulty of the process. Codewise, I think this is pretty similar to the grace stat - it is spent each time you use it, it slowly recharges itself, but it needs some work to get it fully back. I'd simply make it not visible by default - at most, somebody with the smithery skill could attempt to evaluate the level of fatigue of a cauldron, or a spell may do it as well. Or why not asking Mostrai ? Smile The important point to keep if this system ever becomes implemented is to make it general enough to be applied to other types of items and spells as well - There are other fields in which fatigue could possibly become an interesting addition in the future. Multiplying stats specific to a given skill isn't a good idea on the long run. I'm also against of a arbitrary limited lifespan for cauldrons - if you want to buy it and keep it forever unused in your appartments, it is your right. I see no way to justify their auto-destruction after only a short delay. Their total lifespan should depend on what you do with them, so occasional alchemists don't get harmed in the process. Finally, the question of a possible casting time came up; I'm basically against it, since a lot of legitimate players would probably find annoying to be forced to wait before casting again. Fatigue allows them to cast multiple times in a row - if they are ready to handle the risks involved. Now, what about the Alchemist's Fatigue I'd say that it should basically work as the temporary fatigue I wrote about just before. It slowly recharges over time when doing nothing tiresome. Every complex action (casting a spell, or slashing monsters) should create fatigue. Caster's fatigue shouldn't increase the dangerousity level of the alchemical attempt, but instead its randomness: the more tired you are, the higher the chances of making an error in the process and thus the bigger the randomization of the results. Caster's fatigue helps fighting the case of scripters using several cauldrons alternatively to "let them cool down" - the caster him/herself will have to "cool down" as well if he wants to still be able to make useful work. This system has a kind of drawback, though: no longer you can safely play with alchemy whenever you want and especially after having emptied a couple of dungeons full of monsters. It forces you to planify your future actions. I'm not sure all players would easily agree with that. As the Cauldron Fatigue, I think the value of this stat shouldn't be clearly visible to the player - at most, he/she should get an evaluation of it, possibly false under some circumstances (drinking alcohol, for example). Some items could help fighting fatigue (like the coffee cup), too. So now, I ask to seasoned players their opinion about the fatigue idea: - Do you think it is an acceptable solution ? - If not, what are the possible issues you see ? - If not, what is your own proposal to solve the problem ? If players agree to spend a couple of minutes of their time to answer those, then the future system will probably be satisfying for most of them. It is up to you now, as I've written enough for today Smile -- Yann Chachkoff ----------------------- Garden Dwarf's Best Friend ----------------------- GPG Key : http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 -------------- 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/20051120/55e02f50/attachment.pgp From lalo.martins at gmail.com Sun Nov 20 07:51:01 2005 From: lalo.martins at gmail.com (Lalo Martins) Date: Sun Nov 20 07:54:17 2005 Subject: [crossfire] Re: Introducing item fatigue In-Reply-To: <200511201355.23709.yann.chachkoff@myrealbox.com> References: <438046BD.4010103@laposte.net> <200511201355.23709.yann.chachkoff@myrealbox.com> Message-ID: And so says Yann Chachkoff on 11/20/05 20:55... > - Every complex action generates an amount of fatigue proportional to its > difficulty; ... > A cauldron is made of metal. You put it on fire, throw ingredients that react > sometimes very savagely inside and apply magical forces as well on it > whenever you use one for alchemy. It thus sounds reasonable that it slowly > degrades with use up to a point it isn't reliable anymore. I see this as a > two-fold process: On the other hand, if the cauldron lasts long enough, it becomes "seasoned" - better than a new one. The same would apply for shoes, tools, and even some weapons. This thought about item fatigue, combined with the former quote about creature fatigue, suggests that maybe experience could be tied to fatigue. I don't know how exactly to do it in terms of rules, but basically, if you "fatigue" your cauldron and then take proper care of it (recovering the fatigue), it gains some "experience". For creatures, it's much simpler; the experience you get should be proportional to the fatigue, which is already covered in your idea. 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.martins@gmail.com GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Wed Nov 23 00:45:21 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Nov 23 00:45:15 2005 Subject: [crossfire] Re: Introducing item fatigue In-Reply-To: References: <438046BD.4010103@laposte.net> <200511201355.23709.yann.chachkoff@myrealbox.com> Message-ID: <43841001.3010703@sonic.net> Lalo Martins wrote: > And so says Yann Chachkoff on 11/20/05 20:55... >> - Every complex action generates an amount of fatigue proportional to its >> difficulty; > ... >> A cauldron is made of metal. You put it on fire, throw ingredients that react >> sometimes very savagely inside and apply magical forces as well on it >> whenever you use one for alchemy. It thus sounds reasonable that it slowly >> degrades with use up to a point it isn't reliable anymore. I see this as a >> two-fold process: > > On the other hand, if the cauldron lasts long enough, it becomes > "seasoned" - better than a new one. The same would apply for shoes, > tools, and even some weapons. In some cases, may be reasonable (repeated heating/cooling of some objects does make them stronger). But something like shoes will never last for ever. They do get broken in (more comfortable). But I'd argue that if you do something that stresses the shoes and they survive, that more indicates it is a well made/high quality pair. In any manufacturing, especially that using natural goods, you are going to get some variation in quality. One could see this in terms of a blacksmith. In some cases, he might get a quantity of quality metal - the goods produced by the metal will last longer and be better quality. In other cases, the metal may have some impurities that are not readily noticed, but cause weaknesses. There is also the variation of just the skill of the workman. However, one can't really discover what case you have until some amount of use. So in a sense, if it survives, it may more be proving that it was a good batch of material. All that said, some things, like orc weapons, would have a fairly low quality. In terms of the fatigue rules, it could mean that they have already suffered a fair amount of fatigue. However, the one problem this leads to is collecting those items. I really don't want to have 200 different long swords in my inventory after looting a dungeon because each has slight differences in fatigue. So I would suggest that a limited number of levels (maybe 10) be set, so it reduces clutter (perfect shape, excellent, good, average, mediocre, poor, broken, etc). I'd also say that adding temporary fatigue for objects makes things relatively complicated and/or annoying. In the cauldron case, it just means I have to wait however long for the cauldron to cool. While realistic, from a game play perspective, not particular interesting to play. Or maybe it means I have 5 cauldrons to shuffle through. From a programming perspective, it gets complicated on how items loose that fatigue. For players, its easy - they are living objects, so whenever they get their hp back or whatever, get some fatigue back. But most objects don't have speed. But the fact that some do mean you just can't give them speed and take it away - doing so would likely break some objects. Not that this couldn't be handled in some way, but nothing obvious comes to mind right now. From mikeeusaaa at yahoo.com Wed Nov 23 11:14:19 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Wed Nov 23 11:58:52 2005 Subject: [crossfire] Weather bug status? Message-ID: <20051123171419.6645.qmail@web61017.mail.yahoo.com> Weather bug status? Also I noticed in azamuindo(sp) (japan area) the weather has swallowed up 3 of the 1x1 houses there. If anyone wants to see, come on Cat2. __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com From nicolas.weeger at laposte.net Wed Nov 23 17:02:52 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed Nov 23 17:03:26 2005 Subject: [crossfire] Weather bug status? In-Reply-To: <20051123171419.6645.qmail@web61017.mail.yahoo.com> References: <20051123171419.6645.qmail@web61017.mail.yahoo.com> Message-ID: <4384F51C.4020804@laposte.net> Mitch Obrian a ?crit : > Weather bug status? Same as last time. Ryo From leaf at real-time.com Wed Nov 23 18:11:21 2005 From: leaf at real-time.com (Rick Tanner) Date: Wed Nov 23 18:13:16 2005 Subject: [crossfire] Weather bug status? In-Reply-To: <4384F51C.4020804@laposte.net> References: <20051123171419.6645.qmail@web61017.mail.yahoo.com> <4384F51C.4020804@laposte.net> Message-ID: <43850529.1080106@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Weeger wrote: > Mitch Obrian a ?crit : > >>Weather bug status? > > Same as last time. Latest update (2005-Nov-01) on SF Bug Tracker, http://sourceforge.net/tracker/index.php?func=detail&aid=1155590&group_id=13833&atid=113833 They were unable to duplicate the problem. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDhQUphHyvgBp+vH4RAh/eAJoCLWeeg+CTdGc+qJ4h25sRJysX/wCfV0ti ch8/OhyD+n4ndVA+ZRnEVv4= =/U22 -----END PGP SIGNATURE----- From mikeeusaaa at yahoo.com Wed Nov 23 20:03:23 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Wed Nov 23 20:15:28 2005 Subject: [crossfire] Weather bug status? In-Reply-To: <43850529.1080106@real-time.com> Message-ID: <20051124020323.63914.qmail@web61016.mail.yahoo.com> Come on cat2 and I'll show anyone the dissapeared houses. Also the stuff dissapearing underneath weather that's underneath a wall or building ... has that been fixed? --- Rick Tanner wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Nicolas Weeger wrote: > > Mitch Obrian a ?crit : > > > >>Weather bug status? > > > > Same as last time. > > Latest update (2005-Nov-01) on SF Bug Tracker, > http://sourceforge.net/tracker/index.php?func=detail&aid=1155590&group_id=13833&atid=113833 > > They were unable to duplicate the problem. > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - > http://enigmail.mozdev.org > > iD8DBQFDhQUphHyvgBp+vH4RAh/eAJoCLWeeg+CTdGc+qJ4h25sRJysX/wCfV0ti > ch8/OhyD+n4ndVA+ZRnEVv4= > =/U22 > -----END PGP SIGNATURE----- > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ From nicolas.weeger at laposte.net Sat Nov 26 08:47:56 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat Nov 26 08:47:21 2005 Subject: [crossfire] Idea for skills Message-ID: <4388759C.40509@laposte.net> Hello. Here's an idea concerning skills: add a "cap level without doing a quest". For instance (levels are random numbers): a player could level up to 15 in one handed weapons. Then he'd need to complete a quest to be able to get to 25, then another for 40, and so on. The aim would be to force players to explore the world, to find those quests to reach higher levels. Of course the quests should be designed to be do-able with level ~15 / 25 / 40 one-handed weapon. Ryo From mikeeusaaa at yahoo.com Sat Nov 26 10:17:55 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat Nov 26 16:56:17 2005 Subject: [crossfire] Idea for skills In-Reply-To: <4388759C.40509@laposte.net> Message-ID: <20051126161755.96199.qmail@web61019.mail.yahoo.com> This might be good _if_ new quests were created for the uncapping. We could also do, rather then a hard cap, if you don't have the cap quested off it becomes 4x more difficult to level past the cap (you need to aquire 4x more points) or maybe 8x? --- Nicolas Weeger wrote: > Hello. > > Here's an idea concerning skills: add a "cap level > without doing a quest". > For instance (levels are random numbers): a player > could level up to 15 > in one handed weapons. Then he'd need to complete a > quest to be able to > get to 25, then another for 40, and so on. > > The aim would be to force players to explore the > world, to find those > quests to reach higher levels. Of course the quests > should be designed > to be do-able with level ~15 / 25 / 40 one-handed > weapon. > > Ryo > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ From yann.chachkoff at myrealbox.com Sun Nov 27 02:35:04 2005 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sun Nov 27 02:35:23 2005 Subject: [crossfire] Idea for skills In-Reply-To: <4388759C.40509@laposte.net> References: <4388759C.40509@laposte.net> Message-ID: <200511270935.05272.yann.chachkoff@myrealbox.com> I don't really like that idea. Sure, the intend - force people to explore the world furthermore - is good. But I see little justification of forcing them to make a given quest to increase their level. Arbitrarily capping the levels looks very artificial to me. On the other hand, I think that a similar principle (make some quests a "must do" to go further) could be used to unlock other quests and areas. Such a system would be easy to justify scenaristically-wise and would achieve the same result without artificially bending the skills/levels system, or requiring changes to the code. It would mean that a geographical redistribution of the quests would have to be done at some point, and/or that "locks" would have to be put to prevent access to higher-level quests. But all this sounds like map-making job, which I see as a better (or cleaner ?) way to go than creating another special-case to rules in the code. I tend to think that the whole problem of people not exploring the world all comes down to the quests structure and locations: people don't explore because they have no reasons to do it, and because travelling without encountering anything is just plain boring. I'm far from being convinced that we'd solve that problem with another piece of code - I think that improving *maps* would lead to more satisfying solutions. So, my opinion: - No to artificial capping of levels; - Yes to "capping" of quests and areas access, unlocking them by finishing some "key quests". Le Samedi 26 Novembre 2005 15:47, Nicolas Weeger a ?crit : > Hello. > > Here's an idea concerning skills: add a "cap level without doing a quest". > For instance (levels are random numbers): a player could level up to 15 > in one handed weapons. Then he'd need to complete a quest to be able to > get to 25, then another for 40, and so on. > > The aim would be to force players to explore the world, to find those > quests to reach higher levels. Of course the quests should be designed > to be do-able with level ~15 / 25 / 40 one-handed weapon. > > Ryo > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -- Yann Chachkoff ----------------------- Garden Dwarf's Best Friend ----------------------- GPG Key : http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 -------------- 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/20051127/647aa0b9/attachment.pgp From nicolas.weeger at laposte.net Sun Nov 27 03:44:01 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun Nov 27 03:45:23 2005 Subject: [crossfire] Idea for skills In-Reply-To: <200511270935.05272.yann.chachkoff@myrealbox.com> References: <4388759C.40509@laposte.net> <200511270935.05272.yann.chachkoff@myrealbox.com> Message-ID: <43897FE1.6090005@laposte.net> > Sure, the intend - force people to explore the world furthermore - is good. > But I see little justification of forcing them to make a given quest to > increase their level. Arbitrarily capping the levels looks very artificial to > me. It could be seen as "you can't learn more by yourself, you need to be taught by a master of arts to learn new techniques" :) Ryo From nicolas.weeger at laposte.net Sun Nov 27 12:44:12 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun Nov 27 12:45:24 2005 Subject: [crossfire] Idea for skills In-Reply-To: <43897FE1.6090005@laposte.net> References: <4388759C.40509@laposte.net> <200511270935.05272.yann.chachkoff@myrealbox.com> <43897FE1.6090005@laposte.net> Message-ID: <4389FE7C.3080803@laposte.net> Btw, it could be used for "secondary" skills (alchemy, woodsman, ...) skills only, not main combat ones. This way no penalty for fighters/wizards, just for players wanting to do other things than combat :) Ryo From mikeeusaaa at yahoo.com Sun Nov 27 09:31:05 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sun Nov 27 13:24:18 2005 Subject: [crossfire] Crossedit strips out shop headers (could somebody fix?) Message-ID: <20051127153105.62560.qmail@web61014.mail.yahoo.com> Crossedit strips out shop headers (could somebody fix?) __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From mikeeusaaa at yahoo.com Sun Nov 27 09:32:52 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sun Nov 27 13:24:22 2005 Subject: [crossfire] Idea for skills In-Reply-To: <200511270935.05272.yann.chachkoff@myrealbox.com> Message-ID: <20051127153252.15640.qmail@web61019.mail.yahoo.com> There should be NO redistribution of the quests IMHO. If you want more quests in an area do what I'm doing and make more (I'm working on a navar quest). If you don't make more quests you don't have a right to complain about a lack of quests in an area IMHO. --- Yann Chachkoff wrote: > I don't really like that idea. > > Sure, the intend - force people to explore the world > furthermore - is good. > But I see little justification of forcing them to > make a given quest to > increase their level. Arbitrarily capping the levels > looks very artificial to > me. > > On the other hand, I think that a similar principle > (make some quests a "must > do" to go further) could be used to unlock other > quests and areas. Such a > system would be easy to justify scenaristically-wise > and would achieve the > same result without artificially bending the > skills/levels system, or > requiring changes to the code. > > It would mean that a geographical redistribution of > the quests would have to > be done at some point, and/or that "locks" would > have to be put to prevent > access to higher-level quests. > > But all this sounds like map-making job, which I see > as a better (or > cleaner ?) way to go than creating another > special-case to rules in the code. > I tend to think that the whole problem of people not > exploring the world all > comes down to the quests structure and locations: > people don't explore > because they have no reasons to do it, and because > travelling without > encountering anything is just plain boring. I'm far > from being convinced that > we'd solve that problem with another piece of code - > I think that improving > *maps* would lead to more satisfying solutions. > > So, my opinion: > - No to artificial capping of levels; > - Yes to "capping" of quests and areas access, > unlocking them by finishing > some "key quests". > > Le Samedi 26 Novembre 2005 15:47, Nicolas Weeger a > ?crit : > > Hello. > > > > Here's an idea concerning skills: add a "cap level > without doing a quest". > > For instance (levels are random numbers): a player > could level up to 15 > > in one handed weapons. Then he'd need to complete > a quest to be able to > > get to 25, then another for 40, and so on. > > > > The aim would be to force players to explore the > world, to find those > > quests to reach higher levels. Of course the > quests should be designed > > to be do-able with level ~15 / 25 / 40 one-handed > weapon. > > > > Ryo > > > > _______________________________________________ > > crossfire mailing list > > crossfire@metalforge.org > > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > -- > Yann Chachkoff > ----------------------- > Garden Dwarf's Best Friend > ----------------------- > GPG Key : > http://keyserver.veridis.com:11371/export?id=9080288987474372064 > Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 > AAB9 844D 25E0 > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From mwedel at sonic.net Sun Nov 27 21:26:54 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Nov 27 21:26:32 2005 Subject: [crossfire] Idea for skills In-Reply-To: <4389FE7C.3080803@laposte.net> References: <4388759C.40509@laposte.net> <200511270935.05272.yann.chachkoff@myrealbox.com> <43897FE1.6090005@laposte.net> <4389FE7C.3080803@laposte.net> Message-ID: <438A78FE.8000905@sonic.net> Nicolas Weeger wrote: > Btw, it could be used for "secondary" skills (alchemy, woodsman, ...) > skills only, not main combat ones. This way no penalty for > fighters/wizards, just for players wanting to do other things than combat :) But I then wonder if an actual cap on exp/skills is needed, or if it would be good enough to give exp bonuses in specific skills for specific quests. You could see a grandmaster of alchemy saying something like 'fetch me .... and I'll teach you more about alchemy', and if the player does so, he gets an exp reward. And make the reward good enough that it is worth it for players to do the quest vs sitting in their apartment trying to make things (this would obviously be based on the difficulty of quest - low level quests would give little exp, more difficult quests more exp). some, like I mention above, could be pretty easily done (you really just need to put that alchemist in the town, and perhaps modify some existing maps to include the special items he wants. A simple example could be him wanting the heart of the goblin chief - thats just modifying that map to have both a heart and head of the chief). Other cases could be shrines/altars which when applied give the reward. These can thus be put in dungeons. I think this would actually add a little more interest - a lot of the maps are really only 1 dimensional, in that you are going the map for some specific purpose, and that's it. Doing a map and finding it has an alchemist laboratory and you get bonus exp would sort of add that 'oh, that's cool' type of thing since you may not have been expecting it. That said, I don't think there is any built in mechanism within the game to give exp rewards? You can do it via plugin of course, but wonder if putting it in the core server would make it used more. From mikeeusaaa at yahoo.com Sun Nov 27 21:12:47 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sun Nov 27 21:36:31 2005 Subject: [crossfire] Idea for skills In-Reply-To: <4389FE7C.3080803@laposte.net> Message-ID: <20051128031247.65563.qmail@web61025.mail.yahoo.com> If this is done it should be a "soft" cap IMHO. (if you don't have the cap removed it is 4x harder (or 8x?) to advance (you need 4x more points to advance to the next level then you normally would). --- Nicolas Weeger wrote: > Btw, it could be used for "secondary" skills > (alchemy, woodsman, ...) > skills only, not main combat ones. This way no > penalty for > fighters/wizards, just for players wanting to do > other things than combat :) > > Ryo > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ From yann.chachkoff at myrealbox.com Mon Nov 28 02:22:10 2005 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Mon Nov 28 02:23:24 2005 Subject: [crossfire] Idea for skills Message-ID: <1133166130.c8136d5cyann.chachkoff@myrealbox.com> >There should be NO redistribution of the quests IMHO. >If you want more quests in an area do what I'm doing >and make more (I'm working on a navar quest). If you >don't make more quests you don't have a right to >complain about a lack of quests in an area IMHO. First, I have the right to complain to whatever pleases me - who are you to dictate what I should think ? Second, notice that I was actually not speaking about a lack in *quantity*, but about a lack of proper *geographical distribution*. My idea was simply that each area would only contain quests of a given difficulty range (for example, Scorn would have level 1-15 ones, Brest level 15-30, Navar 30-45, etc), so that the player would be practically forced to travel at some point. Note that I am not considering this as a rigid system - Scorn could contain high-level quests for example, but access to them should then be dependent on the previous completion of a quest located in another area. From mikeeusaaa at yahoo.com Mon Nov 28 07:07:25 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Mon Nov 28 10:15:27 2005 Subject: [crossfire] Idea for skills In-Reply-To: <1133166130.c8136d5cyann.chachkoff@myrealbox.com> Message-ID: <20051128130725.52763.qmail@web61016.mail.yahoo.com> Why do we want to force players to travel everywhere? People in the middle ages didn't travel much, and those that did didn't travel to every nook. A player shouldn't have to travel to every nook in the world if he doesn't want to, currently player's do now travel because equal ammenities are in other cities now, Cat2 has a great distribution of players (some in scorn, a bunch in brest, a few in navar, some in nurenburg, and one in azamuindo (the japanese are). Also as one has no "right" to complain who gained office in their country if they didn't bother to vote, in my opinion, people who don't make quests shouldn't be asking for the redistribution of present quests. Quests are made for the area they are made for in mind, also this isn't zelda... we aren't looking for "the player should have to go through all theses levels in sequence and should beable to complete it in X hours". What we need is more quests, more maps. Please make some, we need more more more /me froths. (We really do need more, there are many many empty buildings also, esp Darcap, there are also tons of empty log houses in brest). --- Yann Chachkoff wrote: > >There should be NO redistribution of the quests > IMHO. > >If you want more quests in an area do what I'm > doing > >and make more (I'm working on a navar quest). If > you > >don't make more quests you don't have a right to > >complain about a lack of quests in an area IMHO. > > First, I have the right to complain to whatever > pleases me - who are you to dictate what I should > think ? > > Second, notice that I was actually not speaking > about a lack in *quantity*, but about a lack of > proper *geographical distribution*. My idea was > simply that each area would only contain quests of a > given difficulty range (for example, Scorn would > have level 1-15 ones, Brest level 15-30, Navar > 30-45, etc), so that the player would be practically > forced to travel at some point. > > Note that I am not considering this as a rigid > system - Scorn could contain high-level quests for > example, but access to them should then be dependent > on the previous completion of a quest located in > another area. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From mikeeusaaa at yahoo.com Tue Nov 29 16:04:59 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Tue Nov 29 16:16:36 2005 Subject: [crossfire] Crossedit strips out shop headers (could somebody fix?) In-Reply-To: <20051127153105.62560.qmail@web61014.mail.yahoo.com> Message-ID: <20051129220459.53323.qmail@web61022.mail.yahoo.com> bump --- Mitch Obrian wrote: > Crossedit strips out shop headers (could somebody > fix?) > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From mwedel at sonic.net Wed Nov 30 02:20:01 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Nov 30 02:19:26 2005 Subject: [crossfire] Crossedit strips out shop headers (could somebody fix?) In-Reply-To: <20051129220459.53323.qmail@web61022.mail.yahoo.com> References: <20051129220459.53323.qmail@web61022.mail.yahoo.com> Message-ID: <438D60B1.7060901@sonic.net> Mitch Obrian wrote: > bump Just tried this. crossedit didn't strip out any shop headers for me. is your crossedit (and more importantly, the common directory it is building with) latest CVS? That the crossedit seems to write the headers in different order than say the java edit (or however the headers were put in), so thus, doing a diff I see: *** armourshop 3 Oct 2005 03:05:22 -0000 1.3 --- armourshop 30 Nov 2005 08:15:00 -0000 *************** *** 1,15 **** arch map - region scorn name armourshop msg Creator: Email: Date: Fri Oct 15 13:50:25 1993 endmsg - hp 14 - stand_still 1 - shopitems armour:50;shield:50;helmet:40;cloak:40;boots:40;gloves:40;bracers:50 ;girdle:50;*:-50 - shopmax 2000 end arch shop_empty end --- 1,18 ---- arch map name armourshop + fixed_resettime 1 + difficulty 1 + region scorn + shopitems armour:50;shield:50;helmet:40;cloak:40;boots:40;gloves:40;bracers:50 ;girdle:50;*:-50; + shopmax 2000 + width 16 + height 16 + enter_x 14 msg Creator: Email: Date: Fri Oct 15 13:50:25 1993 endmsg end arch shop_empty end But the order of the headers isn't important (or if they are, the common/map.c file needs to be fixed, since the same routine is being used to save the temp maps) From mikeeusaaa at yahoo.com Wed Nov 30 09:16:30 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Wed Nov 30 11:26:13 2005 Subject: [crossfire] Crossedit strips out shop headers (could somebody fix?) In-Reply-To: <438D60B1.7060901@sonic.net> Message-ID: <20051130151630.89988.qmail@web61015.mail.yahoo.com> Mine isn't the latest CVS, CVS doesn't compile on my laptop system anymore so Cave had to compile it for me. Could you test changing some things in the map and saving? It might strip it out then? --- Mark Wedel wrote: > Mitch Obrian wrote: > > bump > > Just tried this. crossedit didn't strip out any > shop headers for me. is your > crossedit (and more importantly, the common > directory it is building with) > latest CVS? > > That the crossedit seems to write the headers in > different order than say the > java edit (or however the headers were put in), so > thus, doing a diff I see: > > *** armourshop 3 Oct 2005 03:05:22 -0000 1.3 > --- armourshop 30 Nov 2005 08:15:00 -0000 > *************** > *** 1,15 **** > arch map > - region scorn > name armourshop > msg > Creator: > Email: > Date: Fri Oct 15 13:50:25 1993 > endmsg > - hp 14 > - stand_still 1 > - shopitems > armour:50;shield:50;helmet:40;cloak:40;boots:40;gloves:40;bracers:50 > ;girdle:50;*:-50 > - shopmax 2000 > end > arch shop_empty > end > --- 1,18 ---- > arch map > name armourshop > + fixed_resettime 1 > + difficulty 1 > + region scorn > + shopitems > armour:50;shield:50;helmet:40;cloak:40;boots:40;gloves:40;bracers:50 > ;girdle:50;*:-50; > + shopmax 2000 > + width 16 > + height 16 > + enter_x 14 > msg > Creator: > Email: > Date: Fri Oct 15 13:50:25 1993 > endmsg > end > arch shop_empty > end > > But the order of the headers isn't important (or > if they are, the common/map.c > file needs to be fixed, since the same routine is > being used to save the temp maps) > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ From mikeeusaaa at yahoo.com Wed Nov 30 10:43:32 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Wed Nov 30 11:26:17 2005 Subject: [crossfire] Set traps skill (please make it server config-able (on/off). Message-ID: <20051130164332.56383.qmail@web61025.mail.yahoo.com> The set traps skill is currently inopreative because idiot nebs on metalforge (or whatever the big server was in the 1.0 days) killed themselves with it because they were retarded morons. This should be made into a server variable in the config file by default it will be off settrapsskill off (or 0) but a server admin (such as me with Cat2) could set it on if desired (this is something my users want). __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ From nicolas.weeger at laposte.net Wed Nov 30 16:35:40 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed Nov 30 16:35:26 2005 Subject: [crossfire] Crossedit strips out shop headers (could somebody fix?) In-Reply-To: <20051129220459.53323.qmail@web61022.mail.yahoo.com> References: <20051129220459.53323.qmail@web61022.mail.yahoo.com> Message-ID: <438E293C.5010702@laposte.net> > bump Hey please remember we're all volunteers here :) We need time to fix things, sometimes a week or more. Nicolas From mikeeusaaa at yahoo.com Wed Nov 30 18:02:58 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Wed Nov 30 18:11:47 2005 Subject: [crossfire] Crossedit strips out shop headers (could somebody fix?) In-Reply-To: <438E293C.5010702@laposte.net> Message-ID: <20051201000258.80264.qmail@web61016.mail.yahoo.com> /me checks his paystub. "Crossfire INC, Nigeria" They swear the payments will be sent to my bank account next month... every month :(. (:P) --- Nicolas Weeger wrote: > > bump > > Hey please remember we're all volunteers here :) > We need time to fix things, sometimes a week or > more. > > Nicolas > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ From mwedel at sonic.net Wed Nov 30 23:59:10 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Nov 30 23:59:27 2005 Subject: [crossfire] Crossedit strips out shop headers (could somebody fix?) In-Reply-To: <20051130151630.89988.qmail@web61015.mail.yahoo.com> References: <20051130151630.89988.qmail@web61015.mail.yahoo.com> Message-ID: <438E912E.50909@sonic.net> Mitch Obrian wrote: > Mine isn't the latest CVS, CVS doesn't compile on my > laptop system anymore so Cave had to compile it for > me. Could you test changing some things in the map and > saving? It might strip it out then? Then update to latest CVS, as it works there. Running old versions, especially those that predate changes, is sure not to work. I did load a map, make a change, and save it, and headers were intact. If you're going to report bugs, please make sure you are running CVS first, or at least try it on CVS. After all, the problem is only going to be fixed in CVS anyways, so you're going to have to figure out someway to get CVS working if it was in fact broken.