From crossfire-devel at archives.real-time.com Sat Nov 1 09:00:56 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:31 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: <3FA21807.5040006@sonic.net> References: <200310301109.25120.won_fang@yahoo.com.au> <3FA21807.5040006@sonic.net> Message-ID: <200311011601.15476.tchize@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Vendredi 31 Octobre 2003 09:06, Mark Wedel a ?crit : > David Seikel wrote: > > Do we have a method for parts of the big world to be more or less > > allocated to map developers? For instance, the guy that added the ring > > mountain would probably get upset if someone added an easy route through > > them. I would like to grab the north end of the large forest, south of > > the road from Scorn to Navar, and develop it further. The south end is > > for those that mentioned they would like to develop things in a large > > forest. > > Only real method is to post what your intention is and see if anyone > screams. > > Having someone own a portion of the map is problematic - hard to know if > they are still active, etc. and plus as a collaborative effort, someone > owning some piece isn't really right. > I'll add this: the most easy way it to add you nick / name / email and a small message to the infos on the maps your are handling. This would warn other people about your current and future intentions on the map and IMO is the easiest way (every serious mapmaker check the mapinfo before doing some modifications in it and, as mwedel said, it's collaborative work). Also having your email in mapinfo helps bug reporting from players. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/o8qsHHGOa1Q2wXwRAuEpAJ42GyF5v2o4uYBAOukNvgX4O/o9FgCffdMS idrwpTcTzMuJyMC3PTKTIWk= =eGfh -----END PGP SIGNATURE----- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Nov 1 23:16:56 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:31 2005 Subject: [CF-Devel] New skills bug: god-given resistances disappear In-Reply-To: <20031029220239.1fcbd72d.kstenger@montevideo.com.uy> References: <3F8ECFF8.50801@laposte.net> <20031017203448.0a3baa90.kstenger@montevideo.com.uy> <3F9CA625.1010606@sonic.net> <20031029220239.1fcbd72d.kstenger@montevideo.com.uy> Message-ID: <3FA49348.4040906@sonic.net> Karla Stenger wrote: >>>But on the same example another weird thing happened... the rod was never >>>actually "charged", this are the dumps of the rod and the wand in case they >>>are worth for something: >> >> The dump doesn't do a lot of good. What is really needed is to know >> where/how >>those wands/rods were created. It's possible that there is some setup that is >>resulting in the randomitems for the rod/wand not being called as it should. > > > > They where all bought in the wands store in lake city, cant remember it's name > now, but if i remember well none of them was charged, or maybe one was? couldnt > really say by now. This is fixed in CVS. Turns out where the rod came from didn't really make a difference after all. Note that the fix is to fix how rods are generated (with respect to how many charges they hold relative to the spells they cast). given the current archs, it basically means that a light rod can cast 5 spells before it needs to rest, and a heavy rod 20 spells (but that might be a bit high). Note that since this is a change in the generation logic, it means rods that have already been created through whatever means will still be broken. I'd suggest you just sells those off. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 2 17:14:52 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:31 2005 Subject: [CF-Devel] editor request. Message-ID: <3FA58FEC.2030107@sonic.net> Note sure how hard this would be in the java editor, but it'd be nice if the in the object selection pane that it indented or otherwise did something to make it a little more obvious when an object is inside another object (probably ideal would be to use the treemodel java object). If you're dealing with some level of inventories, the current display can be a bit confusing. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 2 18:31:33 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:31 2005 Subject: [CF-Devel] Mosely's books bug In-Reply-To: <3F88D1FE.1080405@sonic.net> References: <3F87B22A.9010607@laposte.net> <3F88D1FE.1080405@sonic.net> Message-ID: <3FA5A1E5.9040406@sonic.net> Mark Wedel wrote: > Nicolas Weeger wrote: > >> Hello. >> >> On Metalforge's test server, crossfire.metalforge.net, the books in >> Mosely's Magic Books are broken. >> Prayer books are fine, but books in shelves are seen as (null) (null) >> Prolly something related to new skill code... > > > More so the spell code. > > Old spell books for wizards were of one type. There are now 4 types. > I believe it is really just a simple matter of updating the map with the > new book arches. > > This would break backwards compatability for this map - as of now, to > my knowledge, all maps currently in CVS will work with both 1.5 and CVS > code it. Should probably just tag the map directory and get on with > fixing up things like that. Just a note that mosely's magic books map is now fixed in CVS for the new spell code. Only fixed the bigworld version. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 2 23:17:42 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:31 2005 Subject: [CF-Devel] Mosely's books bug In-Reply-To: <3FA5A1E5.9040406@sonic.net> References: <3F87B22A.9010607@laposte.net> <3F88D1FE.1080405@sonic.net> <3FA5A1E5.9040406@sonic.net> Message-ID: On Sun, 2 Nov 2003, Mark Wedel wrote: > > Just a note that mosely's magic books map is now fixed in CVS for the new > spell code. > > > Only fixed the bigworld version. > > 1. Still looks broken to me: a. Cause Critical Wounds is god-given (sorig) so shouldn't be there b. The spellbook has level 0?! and is called "singularity"? c. The arch "book" does not exist. They should be cleric/pyro or evoker_book. d. I think randomitems should be "none" e. Prices are not consistent. 2. The same has to be done for the quest spells: tower of stars: comet Lake_Country DA (hanuk): comet swarm Peter M's DragonQuest: dragonbreath,large icestorm,ball lightning mak/chaos/fallen : color spray 3. In maps-bigworld/HallOfSelection all exits now point to: /start/Nexus . But there is no cvs entry for it. 4. small thing in lib/treasures line 3846 arch cleric_book should be arch cleric_book_l1 so paladins will get a level 1 spell as startequip. I just created an account of sourceforge: gwahli So if you want me to do it myself... Bernd Edler _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 2 23:06:36 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:31 2005 Subject: [CF-Devel] Fast worldmap rendering script Message-ID: <20031103050636.GA29723@crystal> Hi all, I got frustrated over the current combine.pl (both because of the speed and the way I configured my window manager which makes it necessary to click 900 times to render the entire world map, once for each time it runs CFJavaEditor), so I decided to write a script specifically designed for fast rendering of the world map. The script is attached with this mail. Its output isn't 100% accurate, mainly because it assigns colors using some heuristics based on the arch of each square rather than deriving it from the pixmaps; however, that means you can tweak it to color different archs so that they show up prominently. The default color settings in the script shows all (non-covered) exits as bright purple and walls as white, which makes cities very visible. Smaller exits are prominently marked if you magnify the image. Floors show up as dark grey, which makes roads show up clearly against the background. I've also made impassable mountains show up as a different color (light brown); the circle of the Brittany ice crown mountains is very clear under magnification. You could change the colors so that terrain features are faint, and exits are bright dots; this is a good way to scan an area to see if somebody else has taken it. :-P Anyway, the script is quite configurable from the command-line (except for the colors--that's next on the TODO list if people are interested--in the meantime, you can just edit the script, the values are in normalized RGB format, each value is between 0 and 1). You can render small portions of the map so that it's even faster. There's an option to overlay a grid on the map---invaluable for finding out which file contains that bit of interesting terrain you want to make a new map in. (Another TODO list item is to label the map grid with coordinates, but that's a bit complicated since I'd have to deal with fonts.) You can run the script with --help to see all the available options. The default output format is PPM (mainly because it's so easy to write from a Perl script), but if you have ImageMagick installed, just specify --outfile with the extension you want (e.g. --outfile=map.gif) and the script will use 'convert' to convert the image at the end. I realized after I wrote the script that somebody else apparently has done the same; but I thought I'd share it anyway, in case somebody else like me has a slower machine and doesn't have gobs of free memory to afford starting/stopping CFJavaEditor several hundred times in a row. I haven't figured out how to only update small portions of the image, which would make it even faster. It might be possible to directly edit the generate image, perhaps. Anyway, I hope somebody will find this script useful. Feedback is welcome. :-) T -- After listening at length to the discontent that you have just respectfully expressed against my verbal capabilities, I am afraid that I must unfortunately bring it to your attention that I am, in fact, NOT verbose. -------------- next part -------------- A non-text attachment was scrubbed... Name: fastmap.pl Type: application/x-perl Size: 12420 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20031103/3947930e/fastmap.bin -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 3 01:04:18 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:31 2005 Subject: [CF-Devel] server error: Unrecognized string Message-ID: I encountered a problem which i can reproduce 100 %, but still could not trace: Whenever i create a new character whose class gets a spellbook as start-equip, the server is caught in an infinite loop. As the last message from the server is: "Unrecognized string: arch dungeon_magic" , one might think the lexx created loader.c is broken. So I tested rebuilding loader.c with my bison-1.875. Although the created files differ quite a bit, the server does behave the same. The parser seems to crash on the very first arch after the map header - independent of map. But classes without spellbooks eg. barbarian/warrior/monk etc. do not crash my server. OK, they do too... but only after entering/leaving several different maps. The "spellbook" classes always crash my server when stepping on the player-changer. Thus, i think something goes wrong creating "randomitems". I attached a server log (not very helpful I'm afraid.) system : Linux 2.4.22 compiler: gcc-3.3.2 Bernd Edler -------------- next part -------------- Reading bmaps from /tmp/crossfire/crossfire-CVS/test/share/crossfire/bmaps...done (got 4534/4535/4535) Reading faces from /tmp/crossfire/crossfire-CVS/test/share/crossfire/faces...done Reading smooth from /tmp/crossfire/crossfire-CVS/test/share/crossfire/smooth...done (got 77 smooth entries) Reading animations from /tmp/crossfire/crossfire-CVS/test/share/crossfire/animations...done. got (862) Reading archetypes from /tmp/crossfire/crossfire-CVS/test/share/crossfire/archetypes... arch-pass 1... Adding friendly object Evil Master, Bonehead. done Setting up archetable...done loading treasure... done arch-pass 2... done done Reading attack messages from /tmp/crossfire/crossfire-CVS/test/share/crossfire/attackmess...got 260 messages in 19 categories. Reading clockdata from /tmp/crossfire/crossfire-CVS/test/var/crossfire/clockdata...todtick=70529 Reading material type data from /tmp/crossfire/crossfire-CVS/test/share/crossfire/materials...Done. Welcome to CrossFire, v1.5.0 Copyright (C) 1994 Mark Wedel. Copyright (C) 1992 Frank Tore Johansen. Reading artifacts from /tmp/crossfire/crossfire-CVS/test/share/crossfire/artifacts...Object NULL seems to have too low item power? 27 > 4 Object NULL seems to have too low item power? 21 > 8 done. Reading races from /tmp/crossfire/crossfire-CVS/test/share/crossfire/races... Resetting race to undead from Wraith for archetype Wraith Resetting race to faerie from elf for archetype elf Resetting race to reptile from Quetzalcoatl for archetype quetzalcoatl Resetting race to fire_elemental from fireborn for archetype fireborn Resetting race to human from barbarian for archetype barbarian Resetting race to human from cleric for archetype cleric Resetting race to human from mage for archetype mage Resetting race to human from ninja for archetype ninja Resetting race to human from priest for archetype priest Resetting race to human from swashbuckler for archetype swashbuckler Resetting race to human from thief for archetype thief Resetting race to human from viking for archetype viking Resetting race to human from warrior for archetype warrior Resetting race to human from wizard for archetype wizarddone. Initializing gods...done. Initializing reading data...Reading messages from /tmp/crossfire/crossfire-CVS/test/share/crossfire/messages...done. Reading bookarch from /tmp/crossfire/crossfire-CVS/test/var/crossfire/bookarch... book archives(used/avail): (0/924) done. init_mon_info() got 301 monsters Done Reading alchemical formulae from /tmp/crossfire/crossfire-CVS/test/share/crossfire/formulae...done. Checking formulae lists...done. Initialize new client/server data Loading image file /tmp/crossfire/crossfire-CVS/test/share/crossfire/crossfire.0 Loading image file /tmp/crossfire/crossfire-CVS/test/share/crossfire/crossfire.1 Initializing plugins : Waiting for connections... BUG: process_events(): Object without map or inventory is on active list: mobility (0) clean_friendly_list: Removed 1 bogus links CS: connection from client of type < GTK Unix Client 1.6.0> Get SetupCmd:: map1acmd 1 sound 1 sexp 1 darkness 1 newmapcmd 1 faceset 0 facecache 1 exp64 1 itemcmd 2 SendBack SetupCmd:: setup map1acmd 1 sound 1 sexp FALSE darkness 1 newmapcmd 1 faceset 0 facecache 1 exp64 1 itemcmd 2 Get SetupCmd:: mapsize 13x13 SendBack SetupCmd:: setup mapsize 13x13 Get SetupCmd:: faceset 0 SendBack SetupCmd:: setup faceset 0 Trying to load map /tmp/crossfire/crossfire-CVS/test/share/crossfire/maps/HallOfSelection. load_original_map: /HallOfSelection (0) enter_map: supplied coordinates are not within the map! (/HallOfSelection: -1, -1) make_path_tofile /tmp/crossfire/crossfire-CVS/test/var/crossfire/players/testplayer... give_initial_items: Removing duplicate object sorcerer's spellbook Trying to load map /tmp/crossfire/crossfire-CVS/test/share/crossfire/maps/city/city. load_original_map: /city/city (0) Unrecognized string: arch dungeon_magic SIGINT received. Emergency saves disabled, no save attempted Cleaning up... Saving map /HallOfSelection Player on map that is being saved -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 3 00:13:10 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:31 2005 Subject: [CF-Devel] Mosely's books bug In-Reply-To: References: <3F87B22A.9010607@laposte.net> <3F88D1FE.1080405@sonic.net> <3FA5A1E5.9040406@sonic.net> Message-ID: <3FA5F1F6.9080100@sympatico.ca> Bernd Edler wrote: >3. In maps-bigworld/HallOfSelection all exits now point to: >/start/Nexus . >But there is no cvs entry for it. > > Looks like it is there in the repository. Did you do a cvs update -d ? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 3 01:52:04 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:31 2005 Subject: [CF-Devel] server error: Unrecognized string In-Reply-To: References: Message-ID: <3FA60924.8090000@sonic.net> Bernd Edler wrote: > I encountered a problem which i can reproduce 100 %, but still > could not trace: > > Whenever i create a new character whose class gets a spellbook > as start-equip, the server is caught in an infinite loop. > > As the last message from the server is: > "Unrecognized string: arch dungeon_magic" , > one might think the lexx created loader.c is broken. > So I tested rebuilding loader.c with my bison-1.875. > Although the created files differ quite a bit, the server does > behave the same. > The parser seems to crash on the very first arch after the map header > - independent of map. > But classes without spellbooks eg. barbarian/warrior/monk etc. do not > crash my server. > OK, they do too... but only after entering/leaving several different maps. > The "spellbook" classes always crash my server when stepping on the > player-changer. > > Thus, i think something goes wrong creating "randomitems". > > I attached a server log (not very helpful I'm afraid.) > > system : Linux 2.4.22 > compiler: gcc-3.3.2 don't use gcc 3.3.2 Sounds like you are encountering a bug that was already reported: http://sourceforge.net/tracker/index.php?func=detail&aid=807828&group_id=13833&atid=113833 Not a bug with crossfire, but a bug with the compiler. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 3 05:25:27 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:31 2005 Subject: [CF-Devel] server error: Unrecognized string In-Reply-To: <3FA60924.8090000@sonic.net> References: <3FA60924.8090000@sonic.net> Message-ID: On Sun, 2 Nov 2003, Mark Wedel wrote: > > don't use gcc 3.3.2 > > Sounds like you are encountering a bug that was already reported: > http://sourceforge.net/tracker/index.php?func=detail&aid=807828&group_id=13833&atid=113833 > > Not a bug with crossfire, but a bug with the compiler. > Yes, as I scanned the bug list on sourceforge.net i missed it. I didn't see the filter default is to show only "open" bugs. Using gcc 3.0.4 for crossfire has solved that problem. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 3 05:10:56 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:31 2005 Subject: [CF-Devel] Mosely's books bug In-Reply-To: <3FA5F1F6.9080100@sympatico.ca> References: <3F87B22A.9010607@laposte.net> <3F88D1FE.1080405@sonic.net> <3FA5A1E5.9040406@sonic.net> <3FA5F1F6.9080100@sympatico.ca> Message-ID: On Mon, 3 Nov 2003, todd wrote: > Looks like it is there in the repository. Did you do a cvs update -d ? > Yes, I did. But i should have done a cvs checkout. Looks like update does not look for new files. BE _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 3 09:51:43 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:32 2005 Subject: [CF-Devel] Mosely's books bug In-Reply-To: References: <3F87B22A.9010607@laposte.net> <3F88D1FE.1080405@sonic.net> <3FA5A1E5.9040406@sonic.net> <3FA5F1F6.9080100@sympatico.ca> Message-ID: <3FA6798F.9080407@sympatico.ca> Bernd Edler wrote: > On Mon, 3 Nov 2003, todd wrote: > > >>Looks like it is there in the repository. Did you do a cvs update -d ? >> > > Yes, I did. > But i should have done a cvs checkout. > Looks like update does not look for new files. > > BE update with the -d switch does grab new directories. I always use this (-dP actually to prune empty ones too) and it seems to work well. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 3 15:09:04 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:32 2005 Subject: [CF-Devel] Patch submission: 'tell' improvement, round 2 Message-ID: <3FA6C3F0.2010103@laposte.net> Hello. Tweaked my 'tell' improvement command, so it uses the ANSI strncasecmp function instead of the evil ms-only one. Here's the patch, feel free to tweak it. I'll commit it in a week if no one objects :) Nicolas 'Ryo' -------------- next part -------------- Index: server/c_chat.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/c_chat.c,v retrieving revision 1.15 diff -u -r1.15 c_chat.c --- server/c_chat.c 28 Jul 2003 05:19:35 -0000 1.15 +++ server/c_chat.c 3 Nov 2003 21:00:02 -0000 @@ -147,18 +147,20 @@ snprintf(buf,MAX_BUF-1, "%s tells you: %s",op->name, msg); - for(pl=first_player;pl!=NULL;pl=pl->next) - if(strncasecmp(pl->ob->name,name,MAX_NAME)==0) { + pl = find_player_partial_name( name ); + if ( pl ) + { new_draw_info(NDI_UNIQUE | NDI_ORANGE, 0, pl->ob, buf); new_draw_info_format(NDI_UNIQUE | NDI_ORANGE, 0, op, - "You tell %s: %s", name, msg); + "You tell %s: %s", pl->ob->name, msg); /* Update last_tell value [mids 01/14/2002] */ strcpy(pl->last_tell, op->name); return 1; - } - new_draw_info(NDI_UNIQUE, 0,op,"No such player."); + } + + new_draw_info(NDI_UNIQUE, 0,op,"No such player or ambiguous name."); return 1; } Index: include/sproto.h =================================================================== RCS file: /cvsroot/crossfire/crossfire/include/sproto.h,v retrieving revision 1.96 diff -u -r1.96 sproto.h --- include/sproto.h 13 Sep 2003 05:01:34 -0000 1.96 +++ include/sproto.h 3 Nov 2003 21:03:01 -0000 @@ -474,6 +474,7 @@ int summon_object(object *op, object *caster, object *spell_ob, int dir); /* player.c */ player *find_player(char *plname); +player* find_player_partial_name( char* plname ); void display_motd(object *op); int playername_ok(char *cp); int add_player(NewSocket *ns); Index: server/player.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/player.c,v retrieving revision 1.137 diff -u -r1.137 player.c --- server/player.c 17 Oct 2003 17:24:53 -0000 1.137 +++ server/player.c 3 Nov 2003 21:03:34 -0000 @@ -51,6 +51,27 @@ return NULL; } +player* find_player_partial_name( char* plname ) + { + player* pl; + player* found = NULL; + size_t namelen = strlen( plname ); + for ( pl = first_player; pl != NULL; pl = pl->next ) + { + if ( strlen( pl->ob->name ) < namelen ) + continue; + + if ( !strncasecmp( pl->ob->name, plname, namelen ) ) + { + if ( found ) + return NULL; + + found = pl; + } + } + return found; + } + void display_motd(object *op) { char buf[MAX_BUF]; FILE *fp; -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 3 15:15:12 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:32 2005 Subject: AW: [CF-Devel] editor request. In-Reply-To: <3FA58FEC.2030107@sonic.net> Message-ID: Yes, found it confusing too... The problem with the treemodel is, that its a bit bulky then in the small panel there - even with my 1280x1024 resolution. When i make maps, i find the a to large "below" panel disturbing. Perhaps a intelligent color table can help? > > > Note sure how hard this would be in the java editor, but it'd > be nice if the > in the object selection pane that it indented or otherwise did > something to make > it a little more obvious when an object is inside another object > (probably ideal > would be to use the treemodel java object). > > If you're dealing with some level of inventories, the current > display can be a > bit confusing. > > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 3 15:43:36 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:32 2005 Subject: [CF-Devel] 'levels' variable question Message-ID: <3FA6CC08.6040302@laposte.net> Fun stuff in the code: common/exp.c:32 sint64 *levels; common/living.c:162 extern uint64 *levels; I think the definition should be fixed in living.c to match that of exp.c Weird though: under Windows, compilation error on living.c:1553 & 1554 (expmul * levels[level]), for a non-implemented __int64 (aka uint64) to double conversion. But forcing conversion to signed int64, linking is fine even if 'levels' is not defined coherently... (uint64 in one file, sint64 in another...) Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Nov 1 22:55:21 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:32 2005 Subject: [CF-Devel] Re: onefang bug fixes In-Reply-To: <22520.1066209319@www63.gmx.net> References: <20031015064016.76303.qmail@web21302.mail.yahoo.com> <22520.1066209319@www63.gmx.net> Message-ID: <200311021418.01810.won_fang@yahoo.com.au> On Wed, 15 Oct 2003 07:15 pm, Andreas Vogl wrote: > The whole "Club of Night mark" thing is not going to > work. You are handing immunities to the player and > expect him to walk out over your inv_checkers nicely and > give it all back. There are hundreds of ways how players > can get out of your disco room without loosing the mark, > the most obvious is dying. The immunities were to stop the patrons from dying due to the lighting effects being produced by things like lightning spells. I have not wrapped my head around the new spell code yet, but there could be a way to make lighting effects not dangerous. That would make the immunities no longer required. There are disadvantages when wearing the "Club of Night" mark, they will remain B-). > The shops being too big and selling reserved spells has > already been mentioned I think. It was the library that had reserved spells. The new spell and skill code will probably make the library useless as it is anyway. During the earlier discussion I pointed out that those spells that I knew were reserved were not in the library. > I have furthermore noticed that there are anvils for > power dragonmails in IceCastle which don't require money > payment (only charge the 60 dragonscales). > To get there, one needs a "onefang" slaying which I couldn't > figure out how to get. That is because it is impossible to get "onefang" slaying, which is entirely deliberate. It is reserved for Prince onefang, the owner of the castle. He can go to places that others cannot, if you look carefully, you will note secret passages all over the castle. The library with the reserved spells is only accessible by one of these secret passages. On my server I play him as a NPC, other server operators can simple not move his player file out of the map directory and into the players directory. As for Power Dragonmail anvils requiring money, no one mentioned that they have to require money. If that is the case, then that should be in the arch, or at least mentioned in the docs. I note that all other Power Dragonmail anvils already in the maps also don't require money. You have to kill a lot of dragons to get 60 dragon scales, and dragons aren't easy to kill. On the other hand, if you are capable of killing that many dragons, you probably don't need Power Dragon Mail. It's all well and good to say "Power Dragonmail anvils must charge money", "some spells are reserved, don't supply them", and "some monsters are reserved, don't use them", but us newbie map makers don't know these things, since they are not mentioned in the map making guide or other documentation. I made a good faith effort to find out about reserved spells and replace them with "censored" signs in my library, then made sure that players can't get there without DM help anyway. I even went as far as chaining the spellbooks down, to prevent theft, making them weight a lot, marking them as god given, and surrounding the entrance with blocking inv_checkers to prevent unauthorized entry. It should be obvious that I didn't intend players to just walk in and grab a complete set of spell books to use as they wanted. I haven't even mentioned the difficulty in finding the castle, or getting there once you know where it is. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Nov 1 23:18:41 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:32 2005 Subject: onefang bug fixes Was: [CF-Devel] Forgotten child In-Reply-To: <3F9CBC9E.2040004@sonic.net> References: <20031015064016.76303.qmail@web21302.mail.yahoo.com> <3F9CBC9E.2040004@sonic.net> Message-ID: <200310311952.36230.won_fang@yahoo.com.au> I'm gonna respond to some of my own stuff as well as Mark's comments. Executive summary - Don't worry about it, everything is fine. Or, as we say here in Australia, "She'll be right mate." On Mon, 27 Oct 2003 04:35 pm, Mark Wedel wrote: > David Seikel wrote: > > BTW, I wasn't too sure about one of the inv checker bug fixes I > > submitted. (This is from memory, I am currently not at my own computer). I am now at my own computer, and I have plenty of time to look at source code. > > As far as I can remember, inv checkers was a recomended way of stopping a > > particular race (player race or monster race) from going someplace. In Naturally, I cannot find that recomendation now, I read it in the docs somewhere, honest B-). However, inv_checkers look like the only way of having a no_pass that is based on some condition. > Well, looking at the code currently in CVS, the problem really seems to > be that the check_inv bails out if the triggerer is not a player. check_inv() does bail if the triggerer is not a player, but the actual checking work is done by check_inv_recursive(), which is called from other places. Notably check_inv_recursive() is called from blocked_link() in maps.c, and that does apply to monsters. > However, I'm not sure how an inventory checker can be used to control the > trail of ants - the inventory checker doesn't limit where they can go, > other than being connected to some other object (say a gate or whatever) > which limits where they go. inv_checker can have no_pass set, and this can be combined with match / no match to control access in a conditional way. That is, pass only if the inv_checker matches, or pass only if the inv_checker doesn't match. > I wouldn't really see why the order we are checking would make any > difference. And looking at the code right now, it seems to check the player > object before checking for matching objects in the inventory. When I made the change oh so many moons ago, it wasn't that things where in the wrong order, it was that the player/monster object check wasn't done at all. Looking at the CVS code right now, the change I made (checking the player/monster object) is in fact there. One less bug for me to double check B-). As for importance of order, I also doubt if it makes any difference, but since the general way it works is to check containers, then check the contents of the containers, and recurse down, I figured checking the player/monster first as the container of everything else was the obvious way to do it. > so I'm not really sure what is trying to get fixed here/what is currently > broken, aside from perhaps the fact that the player check is still there. This has turned out to be a storm in a tea cup. The bug fix I was referring to had already made it into CVS, so I can cross that off my list of bug fixes to be double checked against CVS. To summarise - check_inv() and blocked_link() both use check_inv_recursive() to see if the inv_checker is triggered. While check_inv() only applies to players, blocked_link() applies to monsters and players. My bug fix (part of my initial bug fix package before I had CVS access) was to check_inv_recursive() and the patch had already been applied to CVS (complete with the comment I wrote) by someone else, probably you. inv_checkers with no_pass set will block unless check_inv_recursive() returns a match. inv_checkers with no_pass and last_sp set will block unless check_inv_recursive() returns no match. Thus inv_checkers are the only reliable way I could see to have a conditional no_pass that didn't require a door. I needed a reliable way to confine ants to a certain area of a map, while allowing all others to move around freely. This was an open area, there are no walls I could put doors into. I had seen a recomendation that inv_checkers are the way to do it, so I ringed my area with appropriate inv_checkers (no_pass if matching 'ant'). This didn't work, there were ants everywhere, I fixed it and it was included in my batch of patches. To put it another way, if you cannot carry an ant with you across a place blocked by an inv_checker, then an ant itself should not be able to cross under it's own power. To put it a third way (haven't tested this by the way) if you cannot carry an arrow across an inv_checker, you should not be able to throw / fire it across. There where other bugs in inv_checkers, I fixed a bunch of them. For instance, you are supposed to be able to setup an inv_checker that will remove the matched item, but random items where removed under some conditions. Really upset me the first few times when I found that random items where going AWOL, including super powerful magic items I went to a lot of trouble to collect. Lucky it was my test server and I had backups of all data files, so I restored the player file and went in search of the theif B-). On the other hand, with the last CVS code I grabbed, the inv_checkers I use for testing crash the server. My inv_checker bug fixes have not all been applied, or they ended up in the wrong place due to the massive code changes you mentioned, or there are new inv_checker bugs, or some evil combination of these things. I should put together an inv_checker test plan and debugging map. Back to the bug double checking... _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Nov 1 23:05:23 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:32 2005 Subject: [CF-Devel] Java editor and elevation. In-Reply-To: <200310281233.10198.won_fang@yahoo.com.au> References: <200310281233.10198.won_fang@yahoo.com.au> Message-ID: <200311021505.23382.won_fang@yahoo.com.au> Just talking to myself again B-). On Tue, 28 Oct 2003 12:33 pm, David Seikel wrote: > While testing, I noticed that the smoothing code overlays on top of the > player sometimes. I'll investigate further and get back to you. When I noticed that on Tuesday, I didn't know where in the BigWorld I was at the time, just that it was somewhere in the large forest. Today I went and walked all over the forest, looking for problems, keeping track of where I was so I could fire up the editor and fix them, and couldn't find that problem again. I did find two trees I had forgotten to put grass under though, so expect a CVS commit any minute now. Might have just been a glitch, or something that got fixed between my last two CVS updates. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 3 18:18:13 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:32 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: <3FA13A96.4040509@sympatico.ca> References: <200310301109.25120.won_fang@yahoo.com.au> <3FA13A96.4040509@sympatico.ca> Message-ID: <200310310947.16475.won_fang@yahoo.com.au> Tried to send this with the image attached. I don't think it was any bigger than the last time, but it bounced as being too big this time. On the other hand, I rrealised after sending it that I had not fully updated the image, and sent another one. Guess it will bounce soon as well. On the gripping hand, there was the recent post of the fast image generator, which takes some shortcuts. If people still want the image, I can find a web server somewhere to put it or I can stick it into CVS. On Fri, 31 Oct 2003 02:21 am, Todd Mitchell wrote: > You did a nice graphic of the bigworld map before - can you easily run > another? I would like to see an updated picture with this forest, the > ring mountains and the greening/ mountain changes I committed some time > ago. Your wish is my command B-). If you check my entry in the crossfire DEVELOPERS file, I mention that I will do "visualisations" which means I will work on some nice tools to create this sort of graphics. The one I am sending was created with my modified version of combine.pl (then scaled down with GIMP). One of the modifications is to overlay a grid showing the map borders, I haven't sentthat version of the piccy, but I wil if you ask. Some of you may have seen my weather visualisation code, very handy for debugging the weather code. As for how easy it is, I was updating the picture while I was making my changes, so that I could see the overall picture B-). For you I just needed to take the image I created at the time and scale it down. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 3 19:35:36 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:32 2005 Subject: [CF-Devel] Java editor and elevation. In-Reply-To: <19597.1067591860@www63.gmx.net> References: <200310301000.54849.won_fang@yahoo.com.au> <19597.1067591860@www63.gmx.net> Message-ID: <200311041135.36846.won_fang@yahoo.com.au> On Fri, 31 Oct 2003 07:17 pm, Andreas Vogl wrote: > The reason you didn't find an ArchObject.setAttributeString() or > ArchObject.removeAttribute() function is that all data the > editor handles in a special way is parsed out of the attribute > text and kept in seperate (more convenient) datastructures. I did notice that, but did it this way to be the least invasive. > Doing this with the height information (e.g. parse it into an int > array in CMapModel) would probably have benefits, as you would > never loose the data, and also could make special visual views > like a "heightmap" without delays from parsing. > OTOH, it would require much more work, and among other concerns > height would then need a seperate input field somewhere. I also thought of doing that. I'll add it to the bottom of my (rather lengthy) TODO list. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 3 19:42:24 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:32 2005 Subject: [CF-Devel] Java editor and elevation. In-Reply-To: <19597.1067591860@www63.gmx.net> References: <200310301000.54849.won_fang@yahoo.com.au> <19597.1067591860@www63.gmx.net> Message-ID: <200311041142.24225.won_fang@yahoo.com.au> On Fri, 31 Oct 2003 07:17 pm, Andreas Vogl wrote: > in reply to David Seikel: > > Thank you for explaining your changes. > I think you can commit it. OK, committed, I think, there have been some strange network problems today. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 3 20:24:20 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:32 2005 Subject: onefang bug fixes Was: [CF-Devel] Forgotten child In-Reply-To: <200310311952.36230.won_fang@yahoo.com.au> References: <20031015064016.76303.qmail@web21302.mail.yahoo.com> <3F9CBC9E.2040004@sonic.net> <200310311952.36230.won_fang@yahoo.com.au> Message-ID: <200311041224.20382.won_fang@yahoo.com.au> Here I am, talking to myself again. On Sun, 2 Nov 2003 03:18 pm, David Seikel wrote: > On the other hand, with the last CVS code I grabbed, the inv_checkers I use > for testing crash the server. My inv_checker bug fixes have not all been > applied, or they ended up in the wrong place due to the massive code > changes you mentioned, or there are new inv_checker bugs, or some evil > combination of these things. I should put together an inv_checker test > plan and debugging map. > > Back to the bug double checking... Just finished all my bug patch double checking, the results - All my inv_checker bug fixes are already in CVS, so the above mentioned problem is some new inv_checker bug, or an old one uncovered by other changes, I'll track it all down and fix inv_checkers for good B-). My scroll bug fix was spotted by someone else, so the bug was fixed in CVS, but in a slightly different way. While I didn't do a line by line double check of my weather code changes (they are huge), someone must have dragged in at least some of those changes and then modified them further. I'll have to run the weather system for a while to see how well it works now. The modifications I spotted are to do with the writing of the properly formatted date to an external file, I need it for my web pages that include that at the top, but I guess no one else needs that and it was removed. That particular modification relied on a patch to the time time code, that patch was included in my post, but not applied. No biggie, it wasn't a bug fix, just a nice feature I wanted to use. My skill patches are now redundant anyway, since skills are completely different. It wasn't a bug fix, just a suggested tweaking. I will have to create a new character and play through the new skills code to get a feel for it. So, I'll get stuck into inv_checker debugging in a serious way, and keep an eye on the weather B-). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 3 21:56:32 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:33 2005 Subject: [CF-Devel] server error: Unrecognized string In-Reply-To: <3FA60924.8090000@sonic.net> References: <3FA60924.8090000@sonic.net> Message-ID: <200311041356.32723.won_fang@yahoo.com.au> On Mon, 3 Nov 2003 05:52 pm, Mark Wedel wrote: > don't use gcc 3.3.2 > > Sounds like you are encountering a bug that was already reported: > http://sourceforge.net/tracker/index.php?func=detail&aid=807828&group_id=13 >833&atid=113833 > > Not a bug with crossfire, but a bug with the compiler. Has this been reported to / confirmed with the maintainers of gcc? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 4 20:16:07 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:33 2005 Subject: [CF-Devel] Some CVS bugs Message-ID: <20031105021607.GA31977@crystal> Hi, I'm not sure if these bugs have been fixed yet, but I noticed them on crossfire.metalforge (the one running CVS) and I thought I should bring them to people's attention: 1) Summoning runes and other spell-casting runes don't work anymore. This is with auto-generated traps such as trapped chests and doors. I'm not sure exactly which traps don't work; some spells seem to work but others don't. 2) My character managed to wear a piece of damned armour, and then subsequently remove it just by taking it off. I don't think this is supposed to happen. :-) 3) Cure confusion doesn't. Neither the spell nor the scroll works. The spell just consumes mana and does nothing. T -- I think the conspiracy theorists are out to get us... _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 4 21:52:27 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:33 2005 Subject: [CF-Devel] Some CVS bugs In-Reply-To: <20031105021607.GA31977@crystal> References: <20031105021607.GA31977@crystal> Message-ID: <1068004347.1609.3.camel@oberon.Kameria> On Tue, 2003-11-04 at 21:16, H. S. Teoh wrote: > Hi, I'm not sure if these bugs have been fixed yet, but I noticed them on > crossfire.metalforge (the one running CVS) and I thought I should bring > them to people's attention: > > 1) Summoning runes and other spell-casting runes don't work anymore. This > is with auto-generated traps such as trapped chests and doors. I'm not > sure exactly which traps don't work; some spells seem to work but others > don't. I have noticed that this happens to 'firewalls' and such too. I think the spell numbers have gotten messed up or something as now poision cloud spitters are firing fireballs and missile swarmers are shooting lightning. Also many NPCs who had spells in their inventory are now carrying around null arches like those found at mosely's books. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 4 21:43:18 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:33 2005 Subject: AW: [CF-Devel] editor request. In-Reply-To: References: Message-ID: <3FA871D6.70304@sonic.net> Michael Toennies wrote: > Yes, found it confusing too... > The problem with the treemodel is, that its a bit bulky then > in the small panel there - even with my 1280x1024 resolution. > When i make maps, i find the a to large "below" panel disturbing. > Perhaps a intelligent color table can help? could help. Even indenting the name or icon would be useful. Alternatively, another panel someplace that shows the the contents would also be OK (so that they are not on the map pane itself). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 4 21:51:13 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:33 2005 Subject: [CF-Devel] Re: onefang bug fixes In-Reply-To: <200311021418.01810.won_fang@yahoo.com.au> References: <20031015064016.76303.qmail@web21302.mail.yahoo.com> <22520.1066209319@www63.gmx.net> <200311021418.01810.won_fang@yahoo.com.au> Message-ID: <3FA873B1.9070306@sonic.net> David Seikel wrote: > On Wed, 15 Oct 2003 07:15 pm, Andreas Vogl wrote: > >>The whole "Club of Night mark" thing is not going to >>work. You are handing immunities to the player and >>expect him to walk out over your inv_checkers nicely and >>give it all back. There are hundreds of ways how players >>can get out of your disco room without loosing the mark, >>the most obvious is dying. > > > The immunities were to stop the patrons from dying due to the lighting effects > being produced by things like lightning spells. I have not wrapped my head > around the new spell code yet, but there could be a way to make lighting > effects not dangerous. That would make the immunities no longer required. > There are disadvantages when wearing the "Club of Night" mark, they will > remain B-). Haven't looked at the map, but with the new spell code, it should be very easy to make spell effects that aren't dangerous. I'm not 100% sure what will happen if the dam for a spell is listed at 0. There may be code in place which says always do at least 1 point of damage - I haven't double checked that. But the attacktype could also be changed (make the attacktype turn_undead for example, and it would be mostly harmless (wraiths and followers of that one god may have issues). > > As for Power Dragonmail anvils requiring money, no one mentioned that they > have to require money. If that is the case, then that should be in the arch, > or at least mentioned in the docs. I note that all other Power Dragonmail > anvils already in the maps also don't require money. You have to kill a lot > of dragons to get 60 dragon scales, and dragons aren't easy to kill. On the > other hand, if you are capable of killing that many dragons, you probably > don't need Power Dragon Mail. Difficulty on that was greatly reduced when dragon scales also show up on wyverns and some other less powerful dragons. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 4 22:00:31 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:33 2005 Subject: [CF-Devel] Java editor and image creation. In-Reply-To: <200310311841.38688.won_fang@yahoo.com.au> References: <200310311841.38688.won_fang@yahoo.com.au> Message-ID: <3FA875DF.5000409@sonic.net> David Seikel wrote: > The big problem with the combine.pl script used to create images of the big > world maps is the speed, it can take all day to generate the image. The > script writer thought of this and made sure that if you have already created > the images, it only processes the maps that have changed for subsequent runs. As the writer of that script, I know it takes a long time to run. But also figured that the number of times it would need to get updated isn't a lot, and I could run it at times I don't care about (overnight or whatever). My effort was also to make do with the code that was already mostly in place. Which meant not making a whole bunch of changes to the editor. Note also that the editor spits out the maps as they would appear - the script itself shrinks them down to size. Exactly what level of shrinkage would depend on the maps themselves. Eg, the undercity maps, which I believe are now tiled up, could probably be shrunk much less (it might be what, 400x400 spaces). So keep that in mind if you do something like allow the editor to make a combined image - one needs to somehow be able to say 'this is what size I want the final to be'. And also keep in mind the complication this may add - do you now need to write (or incorporate) in an image manipulation library to do that in the editor? Will that create any new dependencies in the editor? Certainly, pointing the editor at a map and saying 'I want how all this looks tiled together' would be quite nice. But you have to keep in mind the possible downsides - requiring users to download other software in order to run the editor probably will not fly. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 4 23:36:15 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:33 2005 Subject: [CF-Devel] patch:Bargaining experience Message-ID: With this patch, players can gain experience in bargaining skill. The malus for buy/sell is between 80%-20% (as before). The player gets one exp per gold coin he saved due to his cha and bargaining level. He gets one exp per platin coin he earns additionally. I set the reference price to be the one you get having cha = 7 and no bargaining skill. I made this asymmetric on purpose, as i wanted to encourage spending money. Can be made symmetric/easier/harder of course. Or,if we feel particularly nasty, we can even deny exp for selling. I set expmul 0 for bargaining skill, so it won't influence the overall experience. There was a bug with expmul in level_exp which is requires all the one-line diffs to fix. Bernd Edler -------------- next part -------------- A non-text attachment was scrubbed... Name: bargaining.tar.bz2 Type: application/octet-stream Size: 4022 bytes Desc: bargaining experience context diffs Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20031105/ee17e04c/bargaining.tar.obj -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 4 22:34:22 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:33 2005 Subject: [CF-Devel] Some CVS bugs In-Reply-To: <1068004347.1609.3.camel@oberon.Kameria> References: <20031105021607.GA31977@crystal> <1068004347.1609.3.camel@oberon.Kameria> Message-ID: <20031105043422.GB422@crystal> On Tue, Nov 04, 2003 at 10:52:27PM -0500, Todd Mitchell wrote: > On Tue, 2003-11-04 at 21:16, H. S. Teoh wrote: > > Hi, I'm not sure if these bugs have been fixed yet, but I noticed them on > > crossfire.metalforge (the one running CVS) and I thought I should bring > > them to people's attention: > > > > 1) Summoning runes and other spell-casting runes don't work anymore. This > > is with auto-generated traps such as trapped chests and doors. I'm not > > sure exactly which traps don't work; some spells seem to work but others > > don't. > > I have noticed that this happens to 'firewalls' and such too. I think > the spell numbers have gotten messed up or something as now poision > cloud spitters are firing fireballs and missile swarmers are shooting > lightning. [snip] Aha, would that explain why the path through the ice crown mountains have fireballs instead of snowstorms :-) T -- Lawyer: (n.) An innocence-vending machine, the effectiveness of which depends on how much money is inserted. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 4 22:32:57 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:33 2005 Subject: [CF-Devel] Java editor and image creation. In-Reply-To: <3FA875DF.5000409@sonic.net> References: <200310311841.38688.won_fang@yahoo.com.au> <3FA875DF.5000409@sonic.net> Message-ID: <20031105043257.GA422@crystal> On Tue, Nov 04, 2003 at 08:00:31PM -0800, Mark Wedel wrote: > David Seikel wrote: > > >The big problem with the combine.pl script used to create images of the > >big world maps is the speed, it can take all day to generate the image. > >The script writer thought of this and made sure that if you have already > >created the images, it only processes the maps that have changed for > >subsequent runs. > > As the writer of that script, I know it takes a long time to run. But > also figured that the number of times it would need to get updated isn't a > lot, and I could run it at times I don't care about (overnight or whatever). [snip] Did anyone check out the script I posted a few days ago? T -- "Uhh, I'm still not here." -- KD, while "away" on ICQ. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 4 22:38:54 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:33 2005 Subject: [CF-Devel] Some CVS bugs In-Reply-To: <20031105021607.GA31977@crystal> References: <20031105021607.GA31977@crystal> Message-ID: <20031105043854.GC422@crystal> On Tue, Nov 04, 2003 at 09:16:07PM -0500, H. S. Teoh wrote: [snip] > 2) My character managed to wear a piece of damned armour, and then > subsequently remove it just by taking it off. I don't think this is > supposed to happen. :-) [snip] OK, I just confirmed this with Gwahli on metalforge. Take any damned shield and wear it, then wear your normal shield. The damned shield comes off just like that. I didn't try it with other armour, but I know you can't take it off if it's a cursed/damned ring. The bug might also happen with other damned armour, I'm not sure. (Couldn't find damned armour lying around so I couldn't check.) Note that this doesn't work with cursed armour, it has to be damned. And also, another bug I noticed is that sometimes the clock says "xx minutes past 13 o'clock pm" or "xx minutes past 13 o'clock am". Do we have 26 hours a day in the CF world? :-) T -- Spaghetti code may be tangly, but lasagna code is just cheesy. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Nov 5 05:08:23 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:33 2005 Subject: [CF-Devel] Java editor and image creation. References: <3FA875DF.5000409@sonic.net> Message-ID: <11693.1068030503@www63.gmx.net> Mark wrote: > And also keep in mind the complication this may add - do you now need > to write (or incorporate) in an image manipulation library to do that in > the editor? Will that create any new dependencies in the editor? I hope this won't be neccessary. The editor already has a small library for creation of pngs, obviously. Resizing images is supported by the native java.awt.Image class ("getScaledInstance"). The image proccessing methods aren't exactly brilliant, but should be plenty good enough for downsizing. I tried it once and the result looked fine. The main work for improved tiled image generation will probably lie in the logic which must be added to handle this stuff. Basically a new map loading method should be written which doesn't actually open a map but rather loads it in the background, creates the image and closes again. Would be nice if it doesn't create a huge code overhead, but OTOH, since this code won't be used in normal editing mode, it's not much of a concern. AndreasV -- NEU F?R ALLE - GMX MediaCenter - f?r Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gru?, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse f?r Mail, Message, More! +++ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Nov 5 11:04:23 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:33 2005 Subject: [CF-Devel] Some CVS bugs In-Reply-To: <20031105043854.GC422@crystal> References: <20031105021607.GA31977@crystal> <20031105043854.GC422@crystal> Message-ID: <3FA92D97.3030502@sympatico.ca> > And also, another bug I noticed is that sometimes the clock says "xx > minutes past 13 o'clock pm" or "xx minutes past 13 o'clock am". Do we have > 26 hours a day in the CF world? :-) 28 actaully. 'noon' is at 14 o'clock I believe(That's not imperial military time either) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Nov 5 13:09:54 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:33 2005 Subject: [CF-Devel] Some CVS bugs In-Reply-To: <3FA92D97.3030502@sympatico.ca> References: <20031105021607.GA31977@crystal> <20031105043854.GC422@crystal> <3FA92D97.3030502@sympatico.ca> Message-ID: <20031105190954.GA10753@crystal> On Wed, Nov 05, 2003 at 12:04:23PM -0500, Todd Mitchell wrote: > >And also, another bug I noticed is that sometimes the clock says "xx > >minutes past 13 o'clock pm" or "xx minutes past 13 o'clock am". Do we have > >26 hours a day in the CF world? :-) > > 28 actaully. 'noon' is at 14 o'clock I believe(That's not imperial > military time either) [snip] Interesting. Is this intentional? :-) T -- A bend in the road is not the end of the road unless you fail to make the turn. -- Brian White _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Nov 8 09:37:52 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:33 2005 Subject: [CF-Devel] Ingame map customisation / building Message-ID: <3FAD0DD0.1080101@laposte.net> Hello. I went on implementing ingame map customisation/building (if anyone wants patches to test, just ask). It works correctly in most cases, but still has some glitches (like door sometimes seen as wall -> wall face is incorrect) The issue i'm running into is to correctly see if something is a wall, a gate, where buildable is acceptable, and so on. So here's what i plan on doing, for maps, or more precisely squares, you could build on: * for walls & floors, set the type as FLOOR or WALL (easiest way to correctly check if it's really a floor or a wall) * for walls, floors, buttons/pedestals, doors, gates (all items you could build/remove), use a subtype of for instance 1 (i think subtype is not used currently for those items) Of course, it'd be even more easy to have a 'buildable' flag, but i can survive without :) Comments? Criticism? Suggestions? Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 9 04:51:07 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:33 2005 Subject: [CF-Devel] More God-given present issues Message-ID: <3FAE1C1B.70202@laposte.net> Hello. Just restarted a char on crossfire.metalforge.net, and nifty bug: prayed one time on Gaea's altar, to become a fellower.... and i gained ALL her spells immediately!!!! Of course i can't use'em, but still, that's no fun.... Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 9 10:16:30 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:33 2005 Subject: [CF-Devel] More God-given present issues In-Reply-To: <3FAE1C1B.70202@laposte.net> References: <3FAE1C1B.70202@laposte.net> Message-ID: <3FAE685E.8000803@laposte.net> And as a side note: when i got Gaea's spells, i went to Valriel to test, had also all spells... but kept Gaea's!!! I then switched back to Gaea, but i still have Valriel's spells.... Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 9 09:53:27 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:34 2005 Subject: [CF-Devel] Client side improvements Message-ID: <3FAE62F7.7000109@laposte.net> Hello. I want to improve the client with things like macros, stuff like that. I wanted opinions on the following questions: * should i improve the 'common' client, or only a specific one? (i plan on improving at least gtk one, since that's the one i'm using) * is it better to have some script system, with client's specific language? or something like python/perl/your-language-here plugins, like for server? Of course those improvements will only use client's available information! Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 9 15:29:53 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:34 2005 Subject: [CF-Devel] Client side improvements In-Reply-To: <3FAE62F7.7000109@laposte.net> References: <3FAE62F7.7000109@laposte.net> Message-ID: <3FAEB1D1.5050505@sonic.net> Nicolas Weeger wrote: > Hello. > > I want to improve the client with things like macros, stuff like that. > > I wanted opinions on the following questions: > * should i improve the 'common' client, or only a specific one? (i plan > on improving at least gtk one, since that's the one i'm using) This depends on the nature of the change. The stuff in the common directly is not directly aware of the graphic system that is being used. So it can make calls to thing like 'update what the map looks like', but can't do things like 'draw a line for x1,y1 to x2,y2', unless appropriate callback is made into the specific graphic support area. that said, almost certainly, you'd do a mix - some data in the common area to process commands player may type, or grab information from server and potentially add new flags/bits of data to information that the graphic area may process. It is acceptable to not update all the possible graphic clients, however, if you are adding new callback routines, you need to at least put that stub in the other directories. > * is it better to have some script system, with client's specific > language? or something like python/perl/your-language-here plugins, like > for server? Well, what is the target audience? And what do you envision the scripts to do? If the target is for most any player to write simple scripts (if $hp<20% apply healing potion) then you may want a scripting language that is relatively simple and specially written (because a client interperted script coudl look up variables like $hp or what not directly). However, such a simple interface limits what scripts can do. If OTOH, you'd expect few people to write scripts, and more likely that they get destributed to other peoples (posting on net, whatever) then a more esoteric interface that is more powerful may not be as bad. But note that if you do something like use python or perl, you'd need to write some similar interface to what the server uses (dynamically loads the library, connects to certain events, whole bunch of wrapper functions needed to return information, etc). And at some level, I'm then concerned with the amount of extra code and complication that adds to the client. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 9 15:33:52 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:34 2005 Subject: [CF-Devel] Ingame map customisation / building In-Reply-To: <3FAD0DD0.1080101@laposte.net> References: <3FAD0DD0.1080101@laposte.net> Message-ID: <3FAEB2C0.2050505@sonic.net> Nicolas Weeger wrote: > Hello. > > I went on implementing ingame map customisation/building (if anyone > wants patches to test, just ask). > It works correctly in most cases, but still has some glitches (like door > sometimes seen as wall -> wall face is incorrect) > > The issue i'm running into is to correctly see if something is a wall, a > gate, where buildable is acceptable, and so on. > So here's what i plan on doing, for maps, or more precisely squares, you > could build on: > * for walls & floors, set the type as FLOOR or WALL (easiest way to > correctly check if it's really a floor or a wall) for floors, the FLAG_IS_FLOOR should already be set for all floor objects, so it shouldn't be necessary to change the type to floor. But if you want to, not a big deal I suppose. > * for walls, floors, buttons/pedestals, doors, gates (all items you > could build/remove), use a subtype of for instance 1 (i think subtype is > not used currently for those items) Please don't do that. While subtype may not be used right now, that doesn't mean it might not have a more useful purpose in the future. If you want to use it as a flag, add a new flag field. > Of course, it'd be even more easy to have a 'buildable' flag, but i can > survive without :) If that's what you want, add that field to the archs. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 9 16:54:17 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:34 2005 Subject: [CF-Devel] Client side improvements In-Reply-To: <3FAE62F7.7000109@laposte.net> References: <3FAE62F7.7000109@laposte.net> Message-ID: <200311091754.17656.aashenfe@plaind.com> I usualy use the gtk client, but if the common client can be updated it would be better in the long run. As far as scipting languages are concerned, I think perl/python are overkill for the client side. Some simple if, else, while, for statements would be nice. The 'if' statement should be able to check success. if (apply health potion) else cast heal endif Probably the best way to automate the client that would be easy for everybody to use would be a trigger mechanism. So I can add a trigger that runs the above script whenever my hitpoints fall below a certain point. The interface would be similar to setting up shortcut keys. As for other improvements to the client, a command history would be nice. So up and down arrow in the command window would cycle back and forth through history. Another nice feature to have (I'm not sure this is possible in the client) would be a more mud like command language. For instance take 'apply', and create more specific commands (eat, drink, enter/go,wear, wield,read,etc). They do the same exact thing as apply, but can only target certain item types. For example, a corpse is on the exit, I could use 'go' on the exit, and I apply the exit instead of the corpse. Currently, when I'm in a hurry to leave a room, I sometimes eat a corpse. Also some of the skills should have a command (ie,disarm,hide,pick,steal, meditate, etc). Just some ideas Adam On Sun November 9 2003 10:53 am, Nicolas Weeger wrote: > Hello. > > I want to improve the client with things like macros, stuff like that. > > I wanted opinions on the following questions: > * should i improve the 'common' client, or only a specific one? (i plan on > improving at least gtk one, since that's the one i'm using) > * is it better to have some script system, with client's specific language? > or something like python/perl/your-language-here plugins, like for server? > > Of course those improvements will only use client's available information! > > Nicolas 'Ryo' > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 9 17:34:26 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:34 2005 Subject: [CF-Devel] Client side improvements In-Reply-To: <200311091754.17656.aashenfe@plaind.com> References: <3FAE62F7.7000109@laposte.net> <200311091754.17656.aashenfe@plaind.com> Message-ID: <1068420866.945.6.camel@hawk> I have a working scripting interface for the client. It's mostly in the common code, and I put in the necessary hooks in the client-specific code. It creates a new process for each script that you want to run, and sends information to it on its stdin, and reads commands from its stdout. The script can send any command that you can manually send, it can request information from the client (stored information, like map data), and it can listen to commands that the client receives from the server (like hp changes). I've written a few scripts in Bash, such as one that invokes word of recall whenever my hp drop to less than 50%, as well as a very long one that cleans up my apartment. When I last discussed this here, I didn't get a strong message as to whether to check in my changes. A scripting interface is clearly something a number of players want, but it's also clearly something that gives players an advantage. Should I check it in? --PC _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 9 19:27:23 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:34 2005 Subject: [CF-Devel] Client side improvements In-Reply-To: <200311091754.17656.aashenfe@plaind.com> References: <3FAE62F7.7000109@laposte.net> <200311091754.17656.aashenfe@plaind.com> Message-ID: <3FAEE97B.7070108@sonic.net> Adam Ashenfelter wrote: > I usualy use the gtk client, but if the common client can be updated it would > be better in the long run. > > As far as scipting languages are concerned, I think perl/python are overkill > for the client side. Some simple if, else, while, for statements would be > nice. The 'if' statement should be able to check success. > > if (apply health potion) > else > cast heal > endif Well, it depends on what you mean by success. If you mean success in that we find a matching object and send it to the server or process, that is easy. If you mean success in that the server said it succeeded, what is much more difficult due to the time delay involved (this applies more to casting spells, where you might fumble it for example - there will definately be some lag between the client sending the command and the server getting the chance to execute it. > > > Probably the best way to automate the client that would be easy for everybody > to use would be a trigger mechanism. So I can add a trigger that runs the > above script whenever my hitpoints fall below a certain point. The interface > would be similar to setting up shortcut keys. Or it may be more flexible for the script to run every tick, and the script itself has its conditions and what to do. I say this in that if we start having C code in the client that is the condition for running the script, it starts to make more sense to just have likely actions of what to do when that happens, also in C code. One could for example have something like a 'hp < 20%' check in C code, but the client then has the list of objects/spells to cast (in order of preference) when that happens. Eg, have a little interface where you drag the potions/spells/whatever to for order to apply. When all of the first one run it, everything else moves up. But then I start having other concerns - under such a mechanism, players might start to ask 'well, I had this script set to apply healing potions, and I still had healing potions, yet I still died due to lack of hp'. And of course the real reason that happened is lag or whatever else, but try to start explaining that to players since it woudl appear like a built in feature which should do what you want to do. Anyways, if you had a script that was called every tick, and it had some number of preset known variables (hp, sp, grace, etc) then you could start doing things like: if (hp < 20) { do healing stuff } if (sp < 20) { do sp regen stuff} if (grace < 20) {do grace regen stuff } and so in, without having to insert hooks for all that into the client itself - the script itself becomes its own hook so to speak. This also has an interesting idea in that you can then have commands to run a special script instead of the normal one, eg, a 'prayer' regen script: if (grace > maxgrace) exit 1 else { do praying; exit 0} If the client sees the exit 1, it then stops running that script and then goes back to running the default script or something > > > As for other improvements to the client, a command history would be nice. So > up and down arrow in the command window would cycle back and forth through > history. That already exists for the gtk client. > > Another nice feature to have (I'm not sure this is possible in the client) > would be a more mud like command language. For instance take 'apply', and > create more specific commands (eat, drink, enter/go,wear, wield,read,etc). > They do the same exact thing as apply, but can only target certain item > types. For example, a corpse is on the exit, I could use 'go' on the exit, > and I apply the exit instead of the corpse. Currently, when I'm in a hurry > to leave a room, I sometimes eat a corpse. Also some of the skills should > have a command (ie,disarm,hide,pick,steal, meditate, etc). Well, that later case is really just binding keys to them. I suppose command aliases coudl also be done also, but not sure how bug adeal that really is (as said, I'd expect players to just bind keys to them). That said, apply of 'meta' types coudl be done, eg, 'apply food' vs 'apply floor', etc. The client could key in on the client types or something on what it thinks is food (eg, it wouldn't be perfect, as that booze could be poisonous or something). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 9 19:31:19 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:34 2005 Subject: [CF-Devel] Client side improvements In-Reply-To: <1068420866.945.6.camel@hawk> References: <3FAE62F7.7000109@laposte.net> <200311091754.17656.aashenfe@plaind.com> <1068420866.945.6.camel@hawk> Message-ID: <3FAEEA67.2040906@sonic.net> Preston Crow wrote: > I have a working scripting interface for the client. It's mostly in the > common code, and I put in the necessary hooks in the client-specific > code. > > It creates a new process for each script that you want to run, and sends > information to it on its stdin, and reads commands from its stdout. The > script can send any command that you can manually send, it can request > information from the client (stored information, like map data), and it > can listen to commands that the client receives from the server (like hp > changes). > > I've written a few scripts in Bash, such as one that invokes word of > recall whenever my hp drop to less than 50%, as well as a very long one > that cleans up my apartment. > > When I last discussed this here, I didn't get a strong message as to > whether to check in my changes. A scripting interface is clearly > something a number of players want, but it's also clearly something that > gives players an advantage. > > Should I check it in? That's a much better implementation, IMO, as now the scripting language is in whatever you want (I'd probably say that you then have to write a basic startup routine for each language that parses the data sent to it). Eg, your basic perl routine that parses all the data passed to it, or whatever. IT obviously gives some advantage. OTOH, without it, it is basically making things more difficult through obscurity. EG, right now, I could take the client source, and code in something that applies a healing potion if you hp are too low. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 9 23:41:25 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:34 2005 Subject: [CF-Devel] More God-given present issues In-Reply-To: <3FAE1C1B.70202@laposte.net> References: <3FAE1C1B.70202@laposte.net> Message-ID: <3FAF2505.3030704@sonic.net> Nicolas Weeger wrote: > Hello. > > Just restarted a char on crossfire.metalforge.net, and nifty bug: prayed > one time on Gaea's altar, to become a fellower.... and i gained ALL her > spells immediately!!!! > Of course i can't use'em, but still, that's no fun.... fixed in CVS. > And as a side note: when i got Gaea's spells, i went to Valriel to test, had also all spells... but kept Gaea's!!! > I then switched back to Gaea, but i still have Valriel's spells.... Also fixed in CVS. Problem being is that the bug would give you the spells you shouldn't have gotten, and also not marked them properly as god given spells, so when you switched again, the spells didn't get removed. However, there was a bug in the spell removal code where it could possibly not remove all the spells even if it was supposed to - if some of hte spells were next to each other in the inventory, it wouldn't remove the second one. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 10 01:51:23 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:34 2005 Subject: [CF-Devel] patch:Bargaining experience In-Reply-To: References: Message-ID: <3FAF437B.4090809@sonic.net> Bernd Edler wrote: > With this patch, players can gain experience in bargaining skill. > The malus for buy/sell is between 80%-20% (as before). > > The player gets one exp per gold coin he saved due to his cha and > bargaining level. > He gets one exp per platin coin he earns additionally. > I set the reference price to be the one you get having cha = 7 and no > bargaining skill. I'm still mixed on the idea of your charisma affecting the exp you get for bargaining. It seems that the bargaining skill should all be what counts. > There was a bug with expmul in level_exp which is requires all the > one-line diffs to fix. Unfortunately, that creates other problems. I don't think there are any race/classes that use it, but originally expmul was added as a value to set in a race/class to denote how much more/less exp they need for each level. This was meant to be another potential way to balance the classes. Obviously, there are other problems with the code as is currently in CVS, since it doesn't do the right thing with respect to skills with expmul that is not 1. Probably the right approach on that would be the code that calls level_exp() to do the expmul work, since anyplace that calls it should know if it is the player vs a skill. A few other notes: Rather than mucking with storing away charisma and resetting it, and likewise doing the same with the player inventory, query_cost() should instead be modified so that flag can also contain data like 'show baseline cost', which acts as if cha is 7 and no bargaining (just add that as a bitmask to existing values). That IMO is cleaner code. I'm always a bit concerned with mucking things like that - while unlikely, there could be conditions that cause the player to get saved out with those temporarily reset values (getting a sighup for example). It'd just generally seem that the code would be cleaner for the actually processing routine to use different values and not actually modify the player, even temporarily. Last note (to anyone really) - if you're posting diffs, and they are relatively small (like less than 50k), please just post them as an uncompressed attachment. It is much handier/easier to deal with if I can just see the diffs in my mail reader, vs having to save to disk, uncompress, untar, and then look at the files. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 10 01:57:45 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:34 2005 Subject: [CF-Devel] Re: [CF-maps] Fast worldmap rendering script In-Reply-To: <20031103050636.GA29723@crystal> References: <20031103050636.GA29723@crystal> Message-ID: <3FAF44F9.1090403@sonic.net> H. S. Teoh wrote: > Anyway, I hope somebody will find this script useful. Feedback is welcome. I coudl see the script useful. There isn't really anything bad about having different tools to do the same thing. I actually don't use the combined images much anyways, but whatever people find useful. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 10 02:13:49 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:34 2005 Subject: [CF-Devel] Ingame map customisation / building In-Reply-To: <3FAEB2C0.2050505@sonic.net> References: <3FAD0DD0.1080101@laposte.net> <3FAEB2C0.2050505@sonic.net> Message-ID: <3FAF48BD.2020902@laposte.net> > for floors, the FLAG_IS_FLOOR should already be set for all floor > objects, so it shouldn't be necessary to change the type to floor. But > if you want to, not a big deal I suppose. Let's say that adds one more check for building... I don't want players to totally mess the apartment :) As for walls, i don't think there currently is a way to correctly check for'em, so i'll use the 'WALL' type in #define Note: i won't alter archetypes for walls/floor, but rather change'em on the customizable map itself. This way, yet another check :) > Please don't do that. While subtype may not be used right now, that > doesn't mean it might not have a more useful purpose in the future. If > you want to use it as a flag, add a new flag field. > > If that's what you want, add that field to the archs. Ok, i'll add that flag. I don't think it'll be needed as part of the editor, though. Since building is restrained to unique maps, AND is a special feature... Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 10 02:25:53 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:34 2005 Subject: [CF-Devel] Client side improvements In-Reply-To: <3FAEB1D1.5050505@sonic.net> References: <3FAE62F7.7000109@laposte.net> <3FAEB1D1.5050505@sonic.net> Message-ID: <3FAF4B91.4090702@laposte.net> > This depends on the nature of the change. > > Well, what is the target audience? And what do you envision the > scripts to do? What I had in mind, but it may change based on what is discussed here, are things like: * conditions based on inventory's items' name, like: if ( has_item( 'scroll of word of recall' ) ) 'apply word of recall' else 'invoke word of recall' <- pretty easy to understand i guess * macros recording: ie just exit Scorn, 'record s2n', move to Navar, 'end'. Now you have a macro you can run with for instance 'run s2n' -> duplicates your trip from Scorn to Navar... Also something like 'runinv s2n' -> runs macro backwards (ie takes you from Navar to Scorn). Note this works because, right now, there is no random element involved in the trip.... * maybe stuff based on tiles. Like 'road follower' helper. When you move, checks the square you are on, and if square you are directing to isn't the same arch, look around for the same arch, and change direction as found (lets you follow roads easily) * also, obviously, things like auto-drinking & such.... Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 10 02:30:32 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:34 2005 Subject: [CF-Devel] Client side improvements In-Reply-To: <3FAEE97B.7070108@sonic.net> References: <3FAE62F7.7000109@laposte.net> <200311091754.17656.aashenfe@plaind.com> <3FAEE97B.7070108@sonic.net> Message-ID: <3FAF4CA8.6020004@laposte.net> > But then I start having other concerns - under such a mechanism, > players might start to ask 'well, I had this script set to apply healing > potions, and I still had healing potions, yet I still died due to lack > of hp'. And of course the real reason that happened is lag or whatever > else, but try to start explaining that to players since it woudl appear > like a built in feature which should do what you want to do. Then specify on script interface that scripts run locally. Thus if you lag, too bad! :) > Anyways, if you had a script that was called every tick, and it had > some number of preset known variables (hp, sp, grace, etc) then you > could start doing things like: Tick-based running seems like a good idea indeed. Would simplify things, and avoid all hooks. > Well, that later case is really just binding keys to them. I suppose > command aliases coudl also be done also, but not sure how bug adeal that > really is (as said, I'd expect players to just bind keys to them). Well yes, except it's easier to bind 'apply food' than 'apply apple or booze or cake or...' :) And, unless i'm mistaking, apply code for items on the floor takes the first appliable item. IE you can't say which item to apply - thus the exit fun things... How many died because they thought they had applied the exit, only to eat food / body part there was on the square? > That said, apply of 'meta' types coudl be done, eg, 'apply food' vs > 'apply floor', etc. The client could key in on the client types or > something on what it thinks is food (eg, it wouldn't be perfect, as that > booze could be poisonous or something). Could be based on item's type, probably... Of course that'd require server-side implementation. Just my 2 cents. Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 10 05:05:13 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:34 2005 Subject: [CF-Devel] patch:Bargaining experience In-Reply-To: <3FAF437B.4090809@sonic.net> References: <3FAF437B.4090809@sonic.net> Message-ID: On Sun, 9 Nov 2003, Mark Wedel wrote: > > I'm still mixed on the idea of your charisma affecting the exp you get for > bargaining. > I seems natural to me, as this is the way for all the other skills. If you have more strength, you can kill bigger monsters -> you make more experience -> easier to raise melee skills. So better bargain -> bigger archievement -> more experience. Of course, if i save money due to charisma, i may invest it in raising the skill. Then charisma would be at least indirectly useful for the skill. > > I don't think there are any race/classes that use it, but originally expmul > was added as a value to set in a race/class to denote how much more/less exp > they need for each level. I was not aware of that. > Probably the right approach on that would be the code that calls > level_exp() to do the expmul work, since anyplace that calls it should know if > it is the player vs a skill. > Depends on if either: a. The expmul of a player effect only overall exp. Then we can do it as suggested. b. Or the expmul also effect the needed experience in the skills. In this case the fuction must always factor in the player's expmul, but of course not the one of the skill. > Rather than mucking with storing away charisma and resetting it ... > just add that as a bitmask to existing > values. You are right. I will change that. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 10 04:00:20 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:34 2005 Subject: [CF-Devel] Re: onefang bug fixes In-Reply-To: <3FA873B1.9070306@sonic.net> References: <20031015064016.76303.qmail@web21302.mail.yahoo.com> <200311021418.01810.won_fang@yahoo.com.au> <3FA873B1.9070306@sonic.net> Message-ID: <200311102000.20859.won_fang@yahoo.com.au> On Wed, 5 Nov 2003 01:51 pm, Mark Wedel wrote: > I'm not 100% sure what will happen if the dam for a spell is listed at 0. > There may be code in place which says always do at least 1 point of damage Night clubbing is hard on the body B-). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 10 04:03:54 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:35 2005 Subject: [CF-Devel] Java editor and image creation. In-Reply-To: <20031105043257.GA422@crystal> References: <200310311841.38688.won_fang@yahoo.com.au> <3FA875DF.5000409@sonic.net> <20031105043257.GA422@crystal> Message-ID: <200311102003.54115.won_fang@yahoo.com.au> On Wed, 5 Nov 2003 02:32 pm, H. S. Teoh wrote: > Did anyone check out the script I posted a few days ago? I did, but I prefer to generate images based on the actual arch graphics. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 10 08:56:50 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:35 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: <200310301109.25120.won_fang@yahoo.com.au> References: <200310301109.25120.won_fang@yahoo.com.au> Message-ID: <200311110056.50639.won_fang@yahoo.com.au> On Thu, 30 Oct 2003 11:09 am, David Seikel wrote: > Any objections if I moved the Dark forest to the other side of the road? No one objected, so I will add the move to my TODO, a bit low down to give people more time to object. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 10 09:18:14 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:35 2005 Subject: [CF-Devel] Client side improvements In-Reply-To: <3FAEEA67.2040906@sonic.net> References: <3FAE62F7.7000109@laposte.net> <200311091754.17656.aashenfe@plaind.com> <1068420866.945.6.camel@hawk> <3FAEEA67.2040906@sonic.net> Message-ID: <1068477494.10733.12.camel@d5110227.lss.emc.com> On Sun, 2003-11-09 at 20:31, Mark Wedel wrote: > Preston Crow wrote: > > I have a working scripting interface for the client. It's mostly in the > > common code, and I put in the necessary hooks in the client-specific > > code. > > > > It creates a new process for each script that you want to run, and sends > > information to it on its stdin, and reads commands from its stdout. The > > script can send any command that you can manually send, it can request > > information from the client (stored information, like map data), and it > > can listen to commands that the client receives from the server (like hp > > changes). > > > > I've written a few scripts in Bash, such as one that invokes word of > > recall whenever my hp drop to less than 50%, as well as a very long one > > that cleans up my apartment. > > > > When I last discussed this here, I didn't get a strong message as to > > whether to check in my changes. A scripting interface is clearly > > something a number of players want, but it's also clearly something that > > gives players an advantage. > > > > Should I check it in? > > That's a much better implementation, IMO, as now the scripting language is in > whatever you want (I'd probably say that you then have to write a basic startup > routine for each language that parses the data sent to it). Eg, your basic perl > routine that parses all the data passed to it, or whatever. > > IT obviously gives some advantage. OTOH, without it, it is basically making > things more difficult through obscurity. EG, right now, I could take the client > source, and code in something that applies a healing potion if you hp are too low. It's now checked in. The documentation is mostly in a big comment block at the top of common/script.c. I'm sure that there's room for improvement, but it seems to be quite stable and useful for me. It's fairly low-level and exposes some of the client internals (especially when querying the map). --PC _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 10 09:21:20 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:35 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: <200311110056.50639.won_fang@yahoo.com.au> References: <200310301109.25120.won_fang@yahoo.com.au> <200311110056.50639.won_fang@yahoo.com.au> Message-ID: <20031110152120.GA12015@crystal> On Tue, Nov 11, 2003 at 12:56:50AM +1000, David Seikel wrote: > On Thu, 30 Oct 2003 11:09 am, David Seikel wrote: > > Any objections if I moved the Dark forest to the other side of the road? > > No one objected, so I will add the move to my TODO, a bit low down to give > people more time to object. [snip] While you're at it, I'd like to ask people if they think it makes sense to move the current Dark Forest map (the spiral one) into the bigworld itself? This comes back to what Mark said about having only two scales, an indoor scale and an outdoor scale. Currently, the temple in the center is another building that goes down yet another level of scale. All we have to do is to add more bits of forest to make the current map (more or less) circular, then we can plonk it onto the bigworld maps. This will make it more interesting to discover when players wander into it (what's behind these thick trees?). What do you think? T -- I haven't lost my mind: it's backed up on tapes -- CompuMan _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 10 09:45:23 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:35 2005 Subject: [CF-Devel] Re: [CF-maps] Fast worldmap rendering script In-Reply-To: <3FAF44F9.1090403@sonic.net> References: <20031103050636.GA29723@crystal> <3FAF44F9.1090403@sonic.net> Message-ID: <20031110154523.GA12178@crystal> On Sun, Nov 09, 2003 at 11:57:45PM -0800, Mark Wedel wrote: > H. S. Teoh wrote: > > > >Anyway, I hope somebody will find this script useful. Feedback is welcome. > > I coudl see the script useful. There isn't really anything bad about > having different tools to do the same thing. I actually don't use the > combined images much anyways, but whatever people find useful. [snip] Somebody raised the point that it might be good to actually base the generated images on actual tile pngs. This should be doable, if people are interested. I think that it is likely to be still much faster than restarting the JVM 900 times (for those of us who only want to glance at the bigworld map once in a while without having to maintain a cache of individual map images). I personally find it useful to see what my maps look like on the large scale. (E.g., the Great Dark Mire looks like an "eye" on the main continent because of the ring of water that separates the inner swamp from the outer swamp.) It's good for judging distances between landmarks; eg., I placed the (ex-)fishing village slightly NW of where I originally thought to put it, because otherwise it would be too close to another lake and wouldn't fit the storyline as well. T -- "Holy war is an oxymoron." -- Lazarus Long _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 10 12:26:19 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:35 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: <200310301109.25120.won_fang@yahoo.com.au> References: <200310301109.25120.won_fang@yahoo.com.au> Message-ID: <1068488779.533.56.camel@oberon.Kameria> > Basically, I want the north end to be elven managed forest, full of elves and > related creatures. Worshipers of Lythander are welcome, most others are > tolerated. > > Any objections if I moved the Dark forest to the other side of the road? The > Dragon Lord city is fine where it is, they have a history with the elf > prince, and I will be linking it into a part of the elf forest at some stage > (when I get it all working). As far as I am aware, no other maps are > affected. We should discuss this - I have been plugging slowly away at some elf works and if you have a grand master plan then I don't want to step on your toes. I have been fooling around with the area northeast of the big forest you added (I added more trees there and some rivers and stuff a while ago). I had planned on making a elf city one day but hidden and only accessable via random maps and secret ways in the forest (also connected to some different forests via the 'green way' or some such). I have no problem with your elf prince ideas but I could see some conflict if things got too grand. What I have done is made some random map styles for this and a dark forest arch which would represent 'old forest' - gateways to the 'green way'. These spots of dark forest are mostly chaotic wildlands but some paths lead to other areas and some paths lead to the elvish city of Nimlotha (the city of the twilight). Since this takes me a loooong time to do I don't want to hobble your development but I also don't want to come in one day and see that whole forest ringed with inventory checkers and keep out signs... One thing I don't want to see is large areas getting carved off by people as their personal territory since I think this will lead to large empty areas. I am not a huge fan of moving all maps to the bigworld just to save one level of scaling because when you think about it big world is not really that big and someday much of it will be crowded if all the outside maps are put there, and many of those maps are not designed for outside (weather, TOD, movement). With the way exits work there is currently (practically) infinite space for everyone to have their own personal development but there is not infinite space on the bigworld maps. Adding features and landscapes and adventures is a good thing (even very large features like a great forest or large swamp) during this early phase, but carving off your own little kingdom is not IMHO. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 10 13:42:41 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:35 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: <1068488779.533.56.camel@oberon.Kameria> References: <200310301109.25120.won_fang@yahoo.com.au> <1068488779.533.56.camel@oberon.Kameria> Message-ID: <20031110194241.GA14682@crystal> On Mon, Nov 10, 2003 at 01:26:19PM -0500, Todd Mitchell wrote: [snip] > With the way exits work there is currently (practically) infinite space > for everyone to have their own personal development but there is not > infinite space on the bigworld maps. There is still a lot of space left, though. Many, many islands of significant size that can be put to good use. Of course, if everybody started claiming different areas as their own territory, then this could get problematic. I think it'd be good to have designated areas (eg. this forest is elven region, these mountains are dire wolf/bear regions, etc.) > Adding features and landscapes and adventures is a good thing (even very > large features like a great forest or large swamp) during this early > phase, but carving off your own little kingdom is not IMHO. [snip] On that note, I'm wondering how much of the Great Swamp I should use for the quest I have in mind. Currently, the Outer Swamp is mostly available for use. I have no plans for them except for the ruined village and a small troll region where the Inner Swamp links to the rest of the world. My current plan is to reserve the Inner Swamp as part of the quest; however, this is a LARGE area, and I'm not sure if it's a good idea to dedicate all of it to just one quest. I'm not sure how else to do this, because crossing over to the Inner Swamp is an integral part of the quest. Any suggestions? T -- Many open minds should be closed for repairs. -- K5 user _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 10 15:31:19 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:36 2005 Subject: [CF-Devel] Ingame map 'building' / modification: full patch Message-ID: <3FB003A7.3030609@laposte.net> Hello. Finally completed & tweaked & 'nifted' my build patch. 2 files are attached: patch itself, and modified Scorn apartment, for testing purposes. Note: directly patches lib/archetype, didn't feel like making separate archs for now. And, hopefully, no newline issue :) To test, enter the apartment, pick gold, buy, pick diamonds, buy extender, apply it. You can build on the south wall (start by making floors). All builders work like a range attack. Apply/ready it, fire in the building direction. There are 2 different kind of items: builders & raw materials. Builders are tools to build, they don't disappear. Raw materials obviously disappear when building :) Still no shop to buy building items, need to dm-create'em, here's the details of what you can do: * build a floor. Archetypes 'builder_floor' & 'builder_material_floor' (pretty descriptive i guess). Uses one material per build. Can build on wall (will remove it), or existing floor (change archetype). Archetype of built floor determined by 'slaying' field. Will add walls if required to ensure player doesn't go in weird places (undefined space around apartment for instance) * build a wall. Archetypes 'builder_wall' & 'builder_material_wall'. One material per build, can build on floor (makes the wall) or existing wall (changes archetype). Archetype of built wall determined by 'slaying' field. * build a door. Archetypes 'builder_door' & 2 'builder_material_pedestal' or 'builder_material'button' (those 2 will merge at some point, just some fields difference). More tricky for doors. Will build a button/pedestal on player's standing spot, door in firing direction, another button/pedestal on other side of the door. Archetype of the door determined by 'slaying' of raw door, archetype of 'handler' (button/pedestal) by 'slaying' of raw 'handler'. If raw handler's Str is 1, handler is inserted below floor (thus 'builder_material_pedestal' has it set). Tries 10000 random connection values for one free, then bails out. Building does the following things, depending on what you build: * always check the map is unique * check you don't try to build outside the map * check the (new) flag 'FLAG_IS_BUILDABLE' / 'is_buildable' is set on building square(s) (1 for floor/walls, 3 for door) * make sure you have enough material to build * update walls around building spot if required To correctly identify walls/floors & such, i changed the type of walls in apartment around the building zone to '77' (WALL) for walls, '71' (FLOOR) for floors (note: JavaEditor correctly associated those types). Those flags must be set on buildable squares, else the functions return with a failure message. (security, to avoid any bug). Note that the WALL type should be set 2 squares around the walls you intend to let player remove (so that walls around are updated correctly) (check my modified map when in doubt) There are some issues with apartment as it's defined, concerning the 'blocked' view. If you build east, you'll hit a blocked view. You won't be able to build floor or wall, square will stay black. Not that a big issue. If/when this code makes it at some point, i suggest making a new apartment somewhere (Pupland? Lake County?). And making raw material expensive :) (or something you can only do with alchemy, some challenging thing). Also, I plan on adding other things to build, someday :) I hope you guys look at the code, since i hope it's included in the game at some point :) If you don't feel like patching your sources, grab me on the IRC channel & i'll open my test server so you can look (though timezone differences can make it harder). Nicolas 'Ryo' 'Kaori' -------------- next part -------------- arch map name apartments msg Creator: Christian Stieber Email: stieber@informatik.tu-muenchen.de Date: Fri Mar 27 16:41:54 1998 endmsg width 30 height 30 reset_timeout 1 end arch woodfloor unique 1 end arch wall_2_2_2 end arch woodfloor unique 1 y 1 end arch wall_2_1_1 y 1 end arch woodfloor unique 1 y 2 end arch wall_2_1_1 y 2 end arch woodfloor unique 1 y 3 end arch wall_2_1_1 y 3 end arch woodfloor unique 1 y 4 end arch wall_2_1_1 y 4 end arch woodfloor unique 1 y 5 end arch wall_2_1_1 y 5 end arch woodfloor unique 1 y 6 end arch wall_2_1_1 type 77 y 6 end arch woodfloor unique 1 y 7 end arch wall_2_1_1 type 77 y 7 end arch locked_door1 name woodfloor face woodfloor.111 msg endmsg slaying ExtendedApartmentKey blocksview 1 is_floor 1 y 7 end arch locked_door1 name wall face wall_7.111 msg endmsg slaying ExtendedApartmentKey y 7 end arch woodfloor unique 1 y 8 end arch locked_door1 msg endmsg slaying ExtendedApartmentKey y 8 end arch woodfloor unique 1 y 8 end arch wall_2_1_1 type 77 y 8 end arch woodfloor unique 1 y 9 end arch wall_2_2_1 type 77 y 9 end arch woodfloor unique 1 x 1 end arch wall_2_1_2 x 1 end arch woodfloor unique 1 x 1 y 1 end arch exit slaying /world/world_105_115 hp 1 sp 34 x 1 y 1 end arch woodfloor unique 1 x 1 y 2 end arch goldcoin nrof 10000 x 1 y 2 end arch goldfloor name Apartment costs 1000 gold slaying money food 10000 connected 1 x 1 y 3 end arch woodfloor unique 1 x 1 y 4 end arch igate_closed_1 speed 0.500000 resist_physical 30 connected 1 x 1 y 4 end arch woodfloor unique 1 x 1 y 5 end arch woodfloor unique 1 x 1 y 6 end arch bed_save x 1 y 6 end arch woodfloor unique 1 x 1 y 7 end arch locked_door1 name wall face wall_A.111 msg You need to buy the apartment extender to remove this wall endmsg slaying ExtendedApartmentKey blocksview 1 x 1 y 7 end arch woodfloor unique 1 x 1 y 8 end arch locked_door1 slaying ExtendedApartmentKey x 1 y 8 end arch woodfloor unique 1 x 1 y 8 end arch oakdoor name Pocket reality face chest_1.111 slaying Apartments1 hp 1 sp 1 unique 1 x 1 y 8 end arch woodfloor type 71 unique 1 is_buildable 1 x 1 y 9 end arch wall_2_1_2 type 77 is_buildable 1 x 1 y 9 end arch woodfloor unique 1 x 2 end arch wall_2_1_2 x 2 end arch wall_1_2 face wall_1_short.111 x 2 end arch pedestal resist_physical 30 resist_magic 30 resist_electricity 30 resist_cold 30 resist_confusion 30 resist_acid 30 connected 123 x 2 y 1 end arch woodfloor unique 1 x 2 y 1 end arch igate_closed_2 name Emergency exit speed 0.500000 resist_physical 30 resist_magic 30 resist_electricity 30 resist_cold 30 resist_confusion 30 resist_acid 30 connected 123 x 2 y 1 end arch woodfloor unique 1 x 2 y 2 end arch wall_1_1 x 2 y 2 end arch woodfloor unique 1 x 2 y 3 end arch wall_2_1_1 x 2 y 3 end arch woodfloor unique 1 x 2 y 4 end arch wall_1_2 x 2 y 4 end arch woodfloor unique 1 x 2 y 5 end arch woodfloor unique 1 x 2 y 6 end arch woodfloor unique 1 x 2 y 7 end arch locked_door1 name wall face wall_A.111 msg You need to buy the apartment extender to remove this wall endmsg slaying ExtendedApartmentKey blocksview 1 x 2 y 7 end arch woodfloor unique 1 x 2 y 8 end arch oakdoor name Pocket reality face chest_1.111 slaying Apartments2 hp 1 sp 1 unique 1 x 2 y 8 end arch woodfloor type 71 unique 1 is_buildable 1 x 2 y 9 end arch wall_2_1_2 type 77 is_buildable 1 x 2 y 9 end arch woodfloor unique 1 x 3 end arch wall_2_1_2 x 3 end arch pedestal resist_physical 30 resist_magic 30 resist_electricity 30 resist_cold 30 resist_confusion 30 resist_acid 30 connected 123 x 3 y 1 end arch woodfloor unique 1 x 3 y 1 end arch woodfloor unique 1 x 3 y 2 end arch woodfloor unique 1 x 3 y 3 end arch woodfloor unique 1 x 3 y 4 end arch woodfloor unique 1 x 3 y 5 end arch woodfloor unique 1 x 3 y 6 end arch woodfloor unique 1 x 3 y 7 end arch locked_door1 name wall face wall_A.111 msg You need to buy the apartment extender to remove this wall endmsg slaying ExtendedApartmentKey blocksview 1 x 3 y 7 end arch woodfloor unique 1 x 3 y 8 end arch oakdoor name Pocket reality face chest_1.111 slaying Apartments3 hp 1 sp 1 unique 1 x 3 y 8 end arch woodfloor type 71 unique 1 is_buildable 1 x 3 y 9 end arch wall_2_1_2 type 77 is_buildable 1 x 3 y 9 end arch woodfloor unique 1 x 4 end arch wall_2_1_2 x 4 end arch woodfloor unique 1 x 4 y 1 end arch woodfloor unique 1 x 4 y 2 end arch woodfloor unique 1 x 4 y 3 end arch woodfloor unique 1 x 4 y 4 end arch woodfloor unique 1 x 4 y 5 end arch woodfloor unique 1 x 4 y 6 end arch woodfloor unique 1 x 4 y 7 end arch locked_door1 name wall face wall_A.111 msg You need to buy the apartment extender to remove this wall endmsg slaying ExtendedApartmentKey blocksview 1 x 4 y 7 end arch woodfloor unique 1 x 4 y 8 end arch oakdoor name Pocket reality face chest_1.111 slaying Apartments4 hp 1 sp 1 unique 1 x 4 y 8 end arch woodfloor type 71 unique 1 is_buildable 1 x 4 y 9 end arch wall_2_1_2 type 77 is_buildable 1 x 4 y 9 end arch woodfloor unique 1 x 5 end arch wall_2_1_2 x 5 end arch woodfloor unique 1 x 5 y 1 end arch woodfloor unique 1 x 5 y 2 end arch woodfloor unique 1 x 5 y 3 end arch woodfloor unique 1 x 5 y 4 end arch woodfloor unique 1 x 5 y 5 end arch woodfloor unique 1 x 5 y 6 end arch woodfloor unique 1 x 5 y 7 end arch locked_door1 name wall face wall_A.111 msg You need to buy the apartment extender to remove this wall endmsg slaying ExtendedApartmentKey blocksview 1 x 5 y 7 end arch woodfloor unique 1 x 5 y 8 end arch oakdoor name Pocket reality face chest_1.111 slaying Apartments5 hp 1 sp 1 unique 1 x 5 y 8 end arch woodfloor type 71 unique 1 is_buildable 1 x 5 y 9 end arch wall_2_1_2 type 77 is_buildable 1 x 5 y 9 end arch woodfloor unique 1 x 6 end arch wall_2_1_2 x 6 end arch woodfloor unique 1 x 6 y 1 end arch woodfloor unique 1 x 6 y 2 end arch woodfloor unique 1 x 6 y 3 end arch woodfloor unique 1 x 6 y 4 end arch woodfloor unique 1 x 6 y 5 end arch woodfloor unique 1 x 6 y 6 end arch woodfloor unique 1 x 6 y 7 end arch locked_door1 name wall face wall_A.111 msg You need to buy the apartment extender to remove this wall endmsg slaying ExtendedApartmentKey blocksview 1 x 6 y 7 end arch woodfloor unique 1 x 6 y 8 end arch woodfloor type 71 unique 1 is_buildable 1 x 6 y 9 end arch wall_2_1_2 type 77 is_buildable 1 x 6 y 9 end arch woodfloor unique 1 x 7 end arch wall_2_1_2 x 7 end arch woodfloor unique 1 x 7 y 1 end arch woodfloor unique 1 x 7 y 2 end arch woodfloor unique 1 x 7 y 3 end arch woodfloor unique 1 x 7 y 4 end arch woodfloor unique 1 x 7 y 5 end arch woodfloor unique 1 x 7 y 6 end arch woodfloor unique 1 x 7 y 7 end arch locked_door1 name wall face wall_A.111 msg You need to buy the apartment extender to remove this wall endmsg slaying ExtendedApartmentKey blocksview 1 x 7 y 7 end arch woodfloor unique 1 x 7 y 8 end arch woodfloor type 71 unique 1 is_buildable 1 x 7 y 9 end arch wall_2_1_2 type 77 is_buildable 1 x 7 y 9 end arch woodfloor unique 1 x 8 end arch wall_2_1_2 x 8 end arch woodfloor unique 1 x 8 y 1 end arch woodfloor unique 1 x 8 y 2 end arch woodfloor unique 1 x 8 y 3 end arch woodfloor unique 1 x 8 y 4 end arch woodfloor unique 1 x 8 y 5 end arch woodfloor unique 1 x 8 y 6 end arch woodfloor unique 1 x 8 y 7 end arch locked_door1 name wall face wall_A.111 msg You need to buy the apartment extender to remove this wall endmsg slaying ExtendedApartmentKey blocksview 1 x 8 y 7 end arch woodfloor unique 1 x 8 y 8 end arch woodfloor type 71 unique 1 is_buildable 1 x 8 y 9 end arch wall_2_1_2 type 77 is_buildable 1 x 8 y 9 end arch woodfloor unique 1 x 9 end arch wall_2_1_2 x 9 end arch woodfloor unique 1 x 9 y 1 end arch woodfloor unique 1 x 9 y 2 end arch woodfloor unique 1 x 9 y 3 end arch woodfloor unique 1 x 9 y 4 end arch woodfloor unique 1 x 9 y 5 end arch woodfloor unique 1 x 9 y 6 end arch woodfloor unique 1 x 9 y 7 end arch locked_door1 name wall face wall_A.111 msg You need to buy the apartment extender to remove this wall endmsg slaying ExtendedApartmentKey blocksview 1 x 9 y 7 end arch woodfloor unique 1 x 9 y 8 end arch woodfloor type 71 unique 1 is_buildable 1 x 9 y 9 end arch wall_2_1_2 type 77 is_buildable 1 x 9 y 9 end arch woodfloor unique 1 x 10 end arch wall_2_1_2 x 10 end arch woodfloor unique 1 x 10 y 1 end arch woodfloor unique 1 x 10 y 2 end arch woodfloor unique 1 x 10 y 3 end arch woodfloor unique 1 x 10 y 4 end arch woodfloor unique 1 x 10 y 5 end arch woodfloor unique 1 x 10 y 6 end arch woodfloor unique 1 x 10 y 7 end arch locked_door1 name wall face wall_A.111 msg You need to buy the apartment extender to remove this wall endmsg slaying ExtendedApartmentKey blocksview 1 x 10 y 7 end arch woodfloor unique 1 x 10 y 8 end arch woodfloor type 71 unique 1 is_buildable 1 x 10 y 9 end arch wall_2_1_2 type 77 is_buildable 1 x 10 y 9 end arch woodfloor unique 1 x 11 end arch wall_2_1_2 x 11 end arch woodfloor unique 1 x 11 y 1 end arch woodfloor unique 1 x 11 y 2 end arch woodfloor unique 1 x 11 y 3 end arch woodfloor unique 1 x 11 y 4 end arch woodfloor unique 1 x 11 y 5 end arch woodfloor unique 1 x 11 y 6 end arch gem nrof 10000 x 11 y 6 end arch woodfloor unique 1 x 11 y 7 end arch locked_door1 name wall face wall_A.111 msg You need to buy the apartment extender to remove this wall endmsg slaying ExtendedApartmentKey blocksview 1 x 11 y 7 end arch woodfloor unique 1 x 11 y 8 end arch woodfloor type 71 unique 1 is_buildable 1 x 11 y 9 end arch wall_2_1_2 type 77 is_buildable 1 x 11 y 9 end arch woodfloor unique 1 x 12 end arch wall_2_1_2 x 12 end arch creator other_arch altar_none level 30 connected 3 x 12 y 1 end arch goldfloor name Drop 12 holy symbols for an altar slaying holy_symbol food 12 connected 3 x 12 y 1 end arch woodfloor unique 1 x 12 y 2 end arch woodfloor unique 1 x 12 y 3 end arch woodfloor unique 1 x 12 y 4 end arch woodfloor unique 1 x 12 y 5 end arch goldfloor name Pay 10000 diamonds slaying gem food 10000 connected 2 x 12 y 6 end arch woodfloor unique 1 x 12 y 7 end arch locked_door1 name wall face wall_A.111 msg You need to buy the apartment extender to remove this wall endmsg slaying ExtendedApartmentKey blocksview 1 x 12 y 7 end arch woodfloor unique 1 x 12 y 8 end arch locked_door1 name woodfloor face woodfloor.111 slaying ExtendedApartmentKey x 12 y 8 end arch woodfloor type 71 unique 1 is_buildable 1 x 12 y 9 end arch wall_2_1_2 type 77 is_buildable 1 x 12 y 9 end arch woodfloor unique 1 x 13 end arch wall_3_3 x 13 end arch woodfloor unique 1 x 13 y 1 end arch wall_2_1_1 x 13 y 1 end arch woodfloor unique 1 x 13 y 2 end arch wall_2_1_1 x 13 y 2 end arch woodfloor unique 1 x 13 y 3 end arch wall_2_1_1 x 13 y 3 end arch woodfloor unique 1 x 13 y 4 end arch wall_2_1_1 x 13 y 4 end arch woodfloor unique 1 x 13 y 5 end arch wall_1_2 x 13 y 5 end arch woodfloor unique 1 x 13 y 6 end arch igate_closed_2 speed 0.500000 resist_magic 30 connected 2 x 13 y 6 end arch woodfloor unique 1 x 13 y 7 end arch wall_1_1 x 13 y 7 end arch locked_door1 name woodfloor face woodfloor.111 msg endmsg slaying ExtendedApartmentKey blocksview 1 is_floor 1 x 13 y 7 end arch locked_door1 name wall face wall_C.111 msg endmsg slaying ExtendedApartmentKey x 13 y 7 end arch woodfloor unique 1 x 13 y 8 end arch locked_door1 slaying ExtendedApartmentKey x 13 y 8 end arch woodfloor unique 1 x 13 y 8 end arch wall_2_1_1 type 77 x 13 y 8 end arch woodfloor type 71 unique 1 x 13 y 9 end arch wall_3_1 type 77 x 13 y 9 end arch woodfloor unique 1 x 14 end arch wall_2_1_2 x 14 end arch check_inv slaying KurteKeyEureca no_pass 1 x 14 y 1 end arch cobblestones unique 1 x 14 y 1 end arch cobblestones unique 1 x 14 y 2 end arch locked_door1 face cobblesto2.111 msg Please say the pupland password. endmsg slaying SiegfriedKey201169 invisible 1 x 14 y 2 end arch whirlwind_exit name Nuernberg slaying /pup_land/nurnberg/city hp 25 sp 15 speed 0.000000 walk_on 0 fly_on 0 x 14 y 2 end arch cobblestones unique 1 x 14 y 3 end arch cobblestones unique 1 x 14 y 4 end arch cobblestones unique 1 x 14 y 5 end arch cobblestones unique 1 x 14 y 6 end arch whirlwind_exit name Brest slaying /world/world_107_123 hp 27 sp 30 speed 0.000000 walk_on 0 fly_on 0 x 14 y 6 end arch key2 name Apartment Extender face axe_2.111 slaying ExtendedApartmentKey x 14 y 6 end arch cobblestones unique 1 x 14 y 7 end arch whirlwind_exit name Lake Country slaying /world/world_109_126 hp 16 sp 19 walk_on 0 fly_on 0 speed 0.000000 x 14 y 7 end arch cobblestones unique 1 x 14 y 8 end arch woodfloor unique 1 x 14 y 9 end arch wall_2_1_2 type 77 x 14 y 9 end arch woodfloor unique 1 x 15 end arch wall_2_2_3 x 15 end arch woodfloor unique 1 x 15 y 1 end arch wall_2_1_1 x 15 y 1 end arch magic_ear msg @match Siegfried|siegfried Ok. Have fun! endmsg resist_magic 30 resist_electricity 30 resist_confusion 30 resist_ghosthit 30 connected 554 x 15 y 2 end arch woodfloor unique 1 x 15 y 2 end arch wall_2_1_1 x 15 y 2 end arch woodfloor unique 1 x 15 y 3 end arch wall_2_1_1 x 15 y 3 end arch woodfloor unique 1 x 15 y 4 end arch wall_2_1_1 x 15 y 4 end arch woodfloor unique 1 x 15 y 5 end arch wall_2_1_1 x 15 y 5 end arch woodfloor unique 1 x 15 y 6 end arch wall_2_1_1 x 15 y 6 end arch woodfloor unique 1 x 15 y 7 end arch wall_2_1_1 x 15 y 7 end arch woodfloor unique 1 x 15 y 8 end arch wall_2_1_1 type 77 x 15 y 8 end arch woodfloor unique 1 x 15 y 9 end arch wall_2_2_4 type 77 x 15 y 9 end arch blocked x 15 y 10 end arch blocked x 16 end arch blocked x 16 y 1 end arch blocked x 16 y 2 end arch blocked x 16 y 3 end arch blocked x 16 y 4 end arch blocked x 16 y 5 end arch blocked x 16 y 6 end arch blocked x 16 y 7 end arch blocked x 16 y 8 end arch blocked x 16 y 9 end arch blocked x 16 y 10 end arch cobblestones unique 1 x 17 end arch teleporter hp 14 sp 4 speed 0.000000 resist_magic 30 resist_electricity 30 resist_confusion 30 resist_ghosthit 30 connected 554 x 17 end arch key2 name Key to Nuernberg slaying SiegfriedKey201169 x 17 end -------------- next part -------------- A non-text attachment was scrubbed... Name: build.patch.gz Type: application/x-gzip-compressed Size: 6761 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20031110/6fc56f41/build.patch.bin -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 10 16:09:35 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:36 2005 Subject: [CF-Devel] Ingame map 'building' / modification: full patch In-Reply-To: <3FB003A7.3030609@laposte.net> References: <3FB003A7.3030609@laposte.net> Message-ID: <3FB00C9F.5000905@laposte.net> Of course forgot a few things: * added 2 new item types, 'BUILDER' (160) and 'MATERIAL' (161), with some subtypes (check define.h) * range stuff based on bow/rod/the like, but may have forgotten something, or missed functions... * wall connection logic based on random map's logic * prolly some other things, too... Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 10 22:43:15 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:36 2005 Subject: [CF-Devel] Client side improvements In-Reply-To: <3FAF4B91.4090702@laposte.net> References: <3FAE62F7.7000109@laposte.net> <3FAEB1D1.5050505@sonic.net> <3FAF4B91.4090702@laposte.net> Message-ID: <3FB068E3.201@sonic.net> Nicolas Weeger wrote: > What I had in mind, but it may change based on what is discussed here, are > things like: > > * conditions based on inventory's items' name, like: if ( has_item( 'scroll > of word of recall' ) ) 'apply word of recall' else 'invoke word of recall' > <- pretty easy to understand i guess Yeah - basic item checking code wouldn't be hard in any scripting method. > > * macros recording: ie just exit Scorn, 'record s2n', move to Navar, 'end'. > Now you have a macro you can run with for instance 'run s2n' -> duplicates > your trip from Scorn to Navar... Also something like 'runinv s2n' -> runs > macro backwards (ie takes you from Navar to Scorn). Note this works because, > right now, there is no random element involved in the trip.... This to me isn't really script related, or could easily be done without it. Eg, you could do something like 'begin_script far_trip' and the client just captures all the commands (basically, just appends them like a very long binding) until player does end_script. Lack of random element is sort of relative, eg, while there aren't monsters, there certainly could be players that get in the way. > > * maybe stuff based on tiles. Like 'road follower' helper. When you move, > checks the square you are on, and if square you are directing to isn't the > same arch, look around for the same arch, and change direction as found (lets > you follow roads easily) Ok, that requires a bit more work than any basic scripting thing, because now you need to start examining the spaces around the player to look for things of the same face. > Well yes, except it's easier to bind 'apply food' than 'apply apple or booze > or cake or...' And, unless i'm mistaking, apply code for items on the floor > takes the first appliable item. IE you can't say which item to apply - thus > the exit fun things... How many died because they thought they had applied > the exit, only to eat food / body part there was on the square? It would be a trivial change to have an apply_below. In fact, if the client tells the object to apply, it can apply any object on the ground (just like if you click on the exit object, you apply that and not the objects on top of it). Thus, if the client actually interperted the string given to apply and found an item of appropriate name, it could apply whatever properly. In fact, that has other advantages, in that if you apply something you don't have (or isn't around), the client can immediately tell you that, vs it going to the server and the server then telling you that you don't have it. > > Could be based on item's type, probably... > Of course that'd require server-side implementation. The client gets a client_type field - the client knows that field, as the name suggests, and can thus know that object X is of an edible nature. This can all be done on the client. I strongly suggest you read the protocol file, so you can see what the client knows and what it doesn't know. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 10 22:51:58 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:36 2005 Subject: [CF-Devel] patch:Bargaining experience In-Reply-To: References: <3FAF437B.4090809@sonic.net> Message-ID: <3FB06AEE.50609@sonic.net> Bernd Edler wrote: > > On Sun, 9 Nov 2003, Mark Wedel wrote: > > >> I'm still mixed on the idea of your charisma affecting the exp you get for >>bargaining. >> > > > I seems natural to me, as this is the way for all the other skills. > If you have more strength, you can kill bigger monsters -> > you make more experience -> easier to raise melee skills. > So better bargain -> bigger archievement -> more experience. But in some sense, the higher strength letting you kill more creatures is more a side effect. Having more hp, or sp, or whatever else lets you kill more creatures also. For some skills, a stat might give a bonus for the success of the skill, which also indirectly means you are more successful. But no longer is there code which straight out says 'if you have an 18 int, you get 10% more exp'. For bargaining, it is a bit odd, because there is no failure/success chance. However, one could certainly be added in - the level of the shop could be used as the basis of how hard it is to bargain against (better shop = harder bargaining). With that, the query_cost could then do something like always return the value of the item without any bargaining going into effect. Then when you buy/sell something, it could see if you were successful (and how successfull - higher success = more savings = more exp), and print out a message like 'you saved X gold through your clever bargaining'. And in that model, that characters charisma adjustment would aid in the chance of success. Note that you should never lose out because of bargaining - at worst, you may not save any money. > > Depends on if either: > > a. The expmul of a player effect only overall exp. > > Then we can do it as suggested. > > b. Or the expmul also effect the needed experience in the skills. > > In this case the fuction must always factor in the player's expmul, but of > course not the one of the skill. I think expmul predates the skill system, so not positive how it was envisioned. It may not be much an issue, since currently no classes/races use it. But as I think about it, it probably makes sense that it should also apply to skills. Thus, if you only used one skill, and it had the normal 1:1 ratio, you'd be second level in the skill and second overall level at the same time. Otherwise, if expmul was say 1.2, it would be odd in that you would be second level in the skill before second level overall. So it probably just makes sense to always pass in the players expmul value to level_exp() - there is no reason to pass in the one in the skill (don't know what I was thinking when i did that). The exp add/remove code knows about that and takes that into account. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 10 22:59:08 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:36 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: <20031110194241.GA14682@crystal> References: <200310301109.25120.won_fang@yahoo.com.au> <1068488779.533.56.camel@oberon.Kameria> <20031110194241.GA14682@crystal> Message-ID: <3FB06C9C.4000801@sonic.net> Just a note on moving maps to bigworld - I did this with a few, in that these were maps in which there was really just a little lead in map that lead to the actual entrance (tower of demonology comes to mind - putting that big tower on the old small maps would really be out of scale, but putting it there on the current map is OK). But in these cases, the map that was removed really had no part of the adventure on it. But in the case of the dark temple, the outdoor map is quite big, and quite full of monsters. If it was chopped down to a smaller size (and the generators removed), I wouldn't have much problem with it being put directly on bigworld map. By reasonable size, I'm thinking 15x15 at the largest. I'm not sure if that would have a big effect on the adventure itself - I have a feeling not really, in that a lot of that first map is the same creature over and over again, so if you can kill some of them, you can probably kill all of them. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 10 23:39:04 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:36 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: <3FB06C9C.4000801@sonic.net> Message-ID: On 11-Nov-03 Mark Wedel wrote: > I'm not sure if that would have a big effect on the adventure itself - I > have > a feeling not really, in that a lot of that first map is the same creature > over > and over again, so if you can kill some of them, you can probably kill all of > them. That area is one of the more popular areas in the game for players to make good phys exp in. Given it's popularity, I wouldn't be so quick to hack and slash the area apart like that. If you want to make it more realistic.. why not cut the maze up a little. Take the temple, surround it with something impassible on the bigworld, and make the only way in through the forest. So you basically have on the bigworld: XfX XtX XXX (f=forest t=temple) I don't remember off the top of my head, but the temple might be at the center of that spiral. If so, just change it so there are multiple entrances, and they put you in at different points in the outer loop. The center would exit you back out to the bigworld. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 11 00:00:41 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:36 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: References: Message-ID: <1068530441.533.183.camel@oberon.Kameria> On Tue, 2003-11-11 at 00:39, Tim Rightnour wrote: > On 11-Nov-03 Mark Wedel wrote: > > I'm not sure if that would have a big effect on the adventure itself - I > > have > > a feeling not really, in that a lot of that first map is the same creature > > over > > and over again, so if you can kill some of them, you can probably kill all of > > them. > > That area is one of the more popular areas in the game for players to make good > phys exp in. Given it's popularity, I wouldn't be so quick to hack and slash > the area apart like that. > > If you want to make it more realistic.. why not cut the maze up a little. Take > the temple, surround it with something impassible on the bigworld, and make the > only way in through the forest. So you basically have on the bigworld: > > XfX > XtX > XXX > > (f=forest t=temple) > > I don't remember off the top of my head, but the temple might be at the center > of that spiral. If so, just change it so there are multiple entrances, and > they put you in at different points in the outer loop. The center would exit > you back out to the bigworld. Then again if there isn't a need to chop it up - it could just be left as it is... It is reasonably popular map AFAIK. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 11 00:53:38 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:36 2005 Subject: [CF-Devel] Ingame map 'building' / modification: full patch In-Reply-To: <3FB003A7.3030609@laposte.net> References: <3FB003A7.3030609@laposte.net> Message-ID: <3FB08772.7020506@sonic.net> Some general notes: Consider using marked objects when determining what 'raw' item to use. Otherwise, if the player has multiple raw items of a type (lets suppose different styles), there is no way for the player to specify which to use, other than to drop the other types. Using marked objects fix that problem. I'm thinking that specific images for the builder types should be used - the images selected would seem a bit odd. seems to be a bit of redundant code to check to see if the direction is buildable - perhaps reduce that redundancy into one function like 'check_buildability(....)? That would seem to be useful if additional buildable options is added. Some notes more stylistically and not functional: Remember that the error messages are things that players see, so instead of saying things like "Invalid map or weird square?!?", just saying something like 'you can't build there'. In terms of block comments, please do: /* * this is * a block comment */ instead of /* some block comment */ Also, in terms of comparisons in if statements, have the variable first, and constant second if that is what the compare is against, eg, instead of if (4 == a) do if (a == 4) This includes comparisons against constants, eg if (op->type == WALL) not not WALL == op->type _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 11 01:37:20 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:36 2005 Subject: [CF-Devel] Some CVS bugs In-Reply-To: <20031105043854.GC422@crystal> References: <20031105021607.GA31977@crystal> <20031105043854.GC422@crystal> Message-ID: <3FB091B0.2020603@sonic.net> H. S. Teoh wrote: > On Tue, Nov 04, 2003 at 09:16:07PM -0500, H. S. Teoh wrote: > [snip] > >>2) My character managed to wear a piece of damned armour, and then >> subsequently remove it just by taking it off. I don't think this is >> supposed to happen. :-) > > [snip] > > OK, I just confirmed this with Gwahli on metalforge. Take any damned > shield and wear it, then wear your normal shield. The damned shield comes > off just like that. I didn't try it with other armour, but I know you > can't take it off if it's a cursed/damned ring. The bug might also happen > with other damned armour, I'm not sure. (Couldn't find damned armour lying > around so I couldn't check.) Note that this doesn't work with cursed > armour, it has to be damned. Fixed in CVS. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 11 01:58:15 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:36 2005 Subject: [CF-Devel] Some CVS bugs In-Reply-To: <1068004347.1609.3.camel@oberon.Kameria> References: <20031105021607.GA31977@crystal> <1068004347.1609.3.camel@oberon.Kameria> Message-ID: <3FB09697.6060206@sonic.net> Todd Mitchell wrote: > On Tue, 2003-11-04 at 21:16, H. S. Teoh wrote: > > I have noticed that this happens to 'firewalls' and such too. I think > the spell numbers have gotten messed up or something as now poision > cloud spitters are firing fireballs and missile swarmers are shooting > lightning. In theory, this should all work - there is table that maps the old spell numbers to the new object. However, it turns out that firewalls used 'dam' to denote the spell to cast, and not 'sp' like most objects. In any case, this is now fixed in CVS. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 11 03:12:55 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:36 2005 Subject: [CF-Devel] Ingame map 'building' / modification: full patch In-Reply-To: <3FB08772.7020506@sonic.net> References: <3FB003A7.3030609@laposte.net> <3FB08772.7020506@sonic.net> Message-ID: <3FB0A817.10106@laposte.net> Hello. > Some general notes: > > Consider using marked objects when determining what 'raw' item to use. > Otherwise, if the player has multiple raw items of a type (lets suppose > different styles), there is no way for the player to specify which to > use, other than to drop the other types. Using marked objects fix that > problem. Hum, will work for floors & walls, but not doors, since it requires 2 materials. But ok, can be done. > I'm thinking that specific images for the builder types should be used > - the images selected would seem a bit odd. Yes, i didn't want to mess with image files to create new pics, so i used current pics. I'll make something at the time i commit, if i ever commit :) > seems to be a bit of redundant code to check to see if the direction is > buildable - perhaps reduce that redundancy into one function like > 'check_buildability(....)? That would seem to be useful if additional > buildable options is added. Probably. But building functions don't always check the same thing, or keep some variables for later use (item below floor, for instance, when building a floor). > Some notes more stylistically and not functional: > > Remember that the error messages are things that players see, so instead > of saying things like "Invalid map or weird square?!?", just saying > something like 'you can't build there'. Those messages are supposed to never happen. If this message ever comes, it means there may be some issue with the map (or i forgot something in the tests, quite possible). For instance if you build a floor in a direction, there should _always_ be something there (wall, floor, anything). Because if nothing, it's an undefined square, and the player is standing next to it... > In terms of block comments, please do: > > /* > * this is > * a block comment > */ > > instead of > /* > some block > comment > */ Ok. > Also, in terms of comparisons in if statements, have the variable > first, and constant second if that is what the compare is against, eg, > instead of > > if (4 == a) > > do > > if (a == 4) > > This includes comparisons against constants, eg > > if (op->type == WALL) > > not not WALL == op->type Ok, even though i do this to avoid mistaking for the evil 'if (op->type = WALL)'. Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 11 08:01:41 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:36 2005 Subject: [CF-Devel] Fog sinks into swamp :-) Message-ID: <20031111140141.GA23597@crystal> Hi, I just found a bug in swamp.c. It doesn't check the flying flag on non-alive objects (such as fog), which means that fog sinks into the swamp rather quickly. :-P The diff for the fix appears below. T -- Hello? No, I'm not home. Would you like to leave me a message? --- server/swamp.c.ORIG 2003-11-11 08:58:02.000000000 -0500 +++ server/swamp.c 2003-11-11 08:54:04.000000000 -0500 @@ -77,7 +77,7 @@ } break; } - } else if (!QUERY_FLAG(above, FLAG_ALIVE)) { + } else if (!QUERY_FLAG(above, FLAG_ALIVE) && !QUERY_FLAG(above, FLAG_FLYING)) { if (rndm(0, 2) == 0) decrease_ob(above); } above = nabove; _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 11 09:55:25 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:36 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: <3FB06C9C.4000801@sonic.net> References: <200310301109.25120.won_fang@yahoo.com.au> <1068488779.533.56.camel@oberon.Kameria> <20031110194241.GA14682@crystal> <3FB06C9C.4000801@sonic.net> Message-ID: <20031111155525.GA29251@crystal> [BTW, no need to Cc: me on replies, I'm subscribed to both -devel and -maps.] On Mon, Nov 10, 2003 at 08:59:08PM -0800, Mark Wedel wrote: > > Just a note on moving maps to bigworld - > > I did this with a few, in that these were maps in which there was really > just a little lead in map that lead to the actual entrance (tower of > demonology comes to mind - putting that big tower on the old small maps > would really be out of scale, but putting it there on the current map is > OK). > > But in these cases, the map that was removed really had no part of the > adventure on it. > > But in the case of the dark temple, the outdoor map is quite big, and > quite full of monsters. The current Great Swamp maps also have a lot of monsters in the outdoor map, although they are restricted to the Inner Swamp. There are also a few monsters in the Outer Swamp, but not very many. I guess my question was whether it's appropriate to use up such a big area (the inner swamp covers almost an entire 50x50 map file) just for a single quest. > If it was chopped down to a smaller size (and the generators removed), I > wouldn't have much problem with it being put directly on bigworld map. By > reasonable size, I'm thinking 15x15 at the largest. [snip] Should I apply this limit to the Great Swamp maps as well? If people think it's too excessive to use up the entire Inner Swamp for one quest, I can move most of the stuff into sub-maps and open up more of the swamp for future development. One idea is to get rid of the current Inner/Outer swamp distinction (perhaps by building bridges to the Outer Swamp), and to restrict most of the planned submaps to the central island. The area can then be used for future quests as needed. I'll need to change the current quest story somewhat, but that's OK, it's not set in stone yet. :-) T -- "How are you doing?" "Doing what?" _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 11 23:36:08 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:36 2005 Subject: [CF-Devel] Ingame map 'building' / modification: full patch In-Reply-To: <3FB0A817.10106@laposte.net> References: <3FB003A7.3030609@laposte.net> <3FB08772.7020506@sonic.net> <3FB0A817.10106@laposte.net> Message-ID: <3FB1C6C8.2050903@sonic.net> Nicolas Weeger wrote: >> seems to be a bit of redundant code to check to see if the direction >> is buildable - perhaps reduce that redundancy into one function like >> 'check_buildability(....)? That would seem to be useful if additional >> buildable options is added. > > > Probably. But building functions don't always check the same thing, or > keep some variables for later use (item below floor, for instance, when > building a floor). Ok. I didn't look really close at the exact details, but it seemed to be some amount of duplication of 'is this within map bounds, is there a flag buildable, etc'. Maybe the amount to be reduced isn't so great. OTOH, perhaps a flag can be passed into the check function which also has some indication what to find and what to return. > Those messages are supposed to never happen. If this message ever comes, > it means there may be some issue with the map (or i forgot something in > the tests, quite possible). For instance if you build a floor in a > direction, there should _always_ be something there (wall, floor, > anything). Because if nothing, it's an undefined square, and the player > is standing next to it... If that's the case, then it should also generate a LOG() message. > Ok, even though i do this to avoid mistaking for the evil 'if (op->type > = WALL)'. gcc at least will catch those and print a warning. But it's just easier to me (and really in the style of the rest of the code) that the constant comes second. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 11 23:45:05 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:36 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: <20031111155525.GA29251@crystal> References: <200310301109.25120.won_fang@yahoo.com.au> <1068488779.533.56.camel@oberon.Kameria> <20031110194241.GA14682@crystal> <3FB06C9C.4000801@sonic.net> <20031111155525.GA29251@crystal> Message-ID: <3FB1C8E1.8020207@sonic.net> H. S. Teoh wrote: > [BTW, no need to Cc: me on replies, I'm subscribed to both -devel and > > The current Great Swamp maps also have a lot of monsters in the outdoor > map, although they are restricted to the Inner Swamp. There are also a few > monsters in the Outer Swamp, but not very many. I guess my question was > whether it's appropriate to use up such a big area (the inner swamp covers > almost an entire 50x50 map file) just for a single quest. That seems a bit big to place on the world maps. > > If people think it's too excessive to use up the entire Inner Swamp for > one quest, I can move most of the stuff into sub-maps and open up more of > the swamp for future development. One idea is to get rid of the current > Inner/Outer swamp distinction (perhaps by building bridges to the Outer > Swamp), and to restrict most of the planned submaps to the central island. > The area can then be used for future quests as needed. I'll need to > change the current quest story somewhat, but that's OK, it's not set in > stone yet. :-) Well, that's one concern - if large quest maps are placed directly on the world maps, that can really start to use up space (one may say that for the most part, the world is empty, so what's the big deal. But there are certainly limited areas of terrains of specific type). So such a big map could basically use up a large portion of the swamp, such that if someone wanted to do another swamp located adventure, not a lot of space left (or they basically end up being right next to each other. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Nov 12 00:29:02 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:37 2005 Subject: [CF-Devel] Fog sinks into swamp :-) In-Reply-To: <20031111140141.GA23597@crystal> References: <20031111140141.GA23597@crystal> Message-ID: <3FB1D32E.7080402@sonic.net> H. S. Teoh wrote: > Hi, I just found a bug in swamp.c. It doesn't check the flying flag on > non-alive objects (such as fog), which means that fog sinks into the swamp > rather quickly. :-P > > The diff for the fix appears below. committed to CVS. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Nov 12 00:40:34 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:37 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: <3FB1C8E1.8020207@sonic.net> References: <200310301109.25120.won_fang@yahoo.com.au> <1068488779.533.56.camel@oberon.Kameria> <20031110194241.GA14682@crystal> <3FB06C9C.4000801@sonic.net> <20031111155525.GA29251@crystal> <3FB1C8E1.8020207@sonic.net> Message-ID: <1068619234.836.32.camel@oberon.Kameria> > Well, that's one concern - if large quest maps are placed directly on the > world maps, that can really start to use up space (one may say that for the most > part, the world is empty, so what's the big deal. But there are certainly > limited areas of terrains of specific type). So such a big map could basically > use up a large portion of the swamp, such that if someone wanted to do another > swamp located adventure, not a lot of space left (or they basically end up being > right next to each other. I think it is the difference between a locale and an adventure. Having a locale like say Scorn or the Great Mire complete with special circumstances (say the Great Mire has a few nasty critters, Scorn has no magic...). These areas are interesting, can have 'features' like shops or bridges or packs of wolves or magic fountains or portals... and many different adventures could take place in them. On the other hand - with the exception of a few islands or smallish structures (ruins, towns, castles) most specific adventures should probably be off the map and accessed via buildings or doors or invisible exits(lots of ways to play with these, think of the old world maps). Of course there are probably exceptions to this but generally if there is a multi-map area like a forest or a desert or whatever then many specific adventures should be able to coexist and utilize the area atmosphere. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Nov 12 01:13:16 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:37 2005 Subject: [CF-Devel] Mosely's books bug In-Reply-To: References: <3F87B22A.9010607@laposte.net> <3F88D1FE.1080405@sonic.net> <3FA5A1E5.9040406@sonic.net> Message-ID: <3FB1DD8C.6000200@sonic.net> Bernd Edler wrote: > > > 1. Still looks broken to me: > a. Cause Critical Wounds is god-given (sorig) so shouldn't be there Yeah - see that now. In the old maps, there were 4 'causing' harm spell books, and so I just put 4 in there now. > b. The spellbook has level 0?! and is called "singularity"? don't see that. > c. The arch "book" does not exist. They should be cleric/pyro > or evoker_book. Don't see anything with just 'book' either. > d. I think randomitems should be "none" doesn't make a difference - if the book has an inventory set, randomitems isn't called. > e. Prices are not consistent. Well, the prices for books in that shop are different than in other shops - there is some premium to pay for them having most of the books in stock. > > > 2. > The same has to be done for the quest spells: > > tower of stars: comet > Lake_Country DA (hanuk): comet swarm > Peter M's DragonQuest: dragonbreath,large icestorm,ball lightning > mak/chaos/fallen : color spray Will fix. Need to fix inventory of some creatures also. > 4. small thing in lib/treasures line 3846 > arch cleric_book > should be > arch cleric_book_l1 > so paladins will get a level 1 spell as startequip. Will fix. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Nov 12 08:43:51 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:37 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: <3FB1C8E1.8020207@sonic.net> References: <200310301109.25120.won_fang@yahoo.com.au> <1068488779.533.56.camel@oberon.Kameria> <20031110194241.GA14682@crystal> <3FB06C9C.4000801@sonic.net> <20031111155525.GA29251@crystal> <3FB1C8E1.8020207@sonic.net> Message-ID: <20031112144351.GA8318@crystal> On Tue, Nov 11, 2003 at 09:45:05PM -0800, Mark Wedel wrote: > H. S. Teoh wrote: > >[BTW, no need to Cc: me on replies, I'm subscribed to both -devel and > > > > >The current Great Swamp maps also have a lot of monsters in the outdoor > >map, although they are restricted to the Inner Swamp. There are also a few > >monsters in the Outer Swamp, but not very many. I guess my question was > >whether it's appropriate to use up such a big area (the inner swamp covers > >almost an entire 50x50 map file) just for a single quest. > > That seems a bit big to place on the world maps. Actually, the quest maps themselves don't have to be that big; it's just that I was using the geographical features created by the script. I can certainly move the quest into submaps and leave more room for other quests. One concern then is that currently, the Inner Swamp is almost completely disconnected from the Outer Swamp; I guess that's OK as long as I provide a general access route to it? [snip] > Well, that's one concern - if large quest maps are placed directly on the > world maps, that can really start to use up space (one may say that for the > most part, the world is empty, so what's the big deal. But there are > certainly limited areas of terrains of specific type). So such a big map > could basically use up a large portion of the swamp, such that if someone > wanted to do another swamp located adventure, not a lot of space left (or > they basically end up being right next to each other. [snip] OK, I think I'll move the quest into submaps and leave most of the swamp open for future development. Should I leave the Inner Swamp the way it is, or should I make more connections to it? One idea is to leave it as it is, and put the more dangerous monsters inside, so that they are less likely to wander off the swamp and cause havoc elsewhere. I can even block it off completely and have the entrance as a submap with a warning sign. T -- Caffeine underflow. Brain dumped. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Nov 12 08:48:52 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:37 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: <1068619234.836.32.camel@oberon.Kameria> References: <200310301109.25120.won_fang@yahoo.com.au> <1068488779.533.56.camel@oberon.Kameria> <20031110194241.GA14682@crystal> <3FB06C9C.4000801@sonic.net> <20031111155525.GA29251@crystal> <3FB1C8E1.8020207@sonic.net> <1068619234.836.32.camel@oberon.Kameria> Message-ID: <20031112144852.GB8318@crystal> On Wed, Nov 12, 2003 at 01:40:34AM -0500, Todd Mitchell wrote: > > > Well, that's one concern - if large quest maps are placed directly on the > > world maps, that can really start to use up space (one may say that for the most > > part, the world is empty, so what's the big deal. But there are certainly > > limited areas of terrains of specific type). So such a big map could basically > > use up a large portion of the swamp, such that if someone wanted to do another > > swamp located adventure, not a lot of space left (or they basically end up being > > right next to each other. > > I think it is the difference between a locale and an adventure. Having > a locale like say Scorn or the Great Mire complete with special > circumstances (say the Great Mire has a few nasty critters, Scorn has no > magic...). These areas are interesting, can have 'features' like shops > or bridges or packs of wolves or magic fountains or portals... and many > different adventures could take place in them. How nasty can nasty be? :-) I've just made another monster, which is very deadly, and I'm wondering whether to leave it out in the open or keep it within a quest submap where innocent passers-by won't get mauled without warning. > On the other hand - with the exception of a few islands or smallish > structures (ruins, towns, castles) most specific adventures should > probably be off the map and accessed via buildings or doors or invisible > exits(lots of ways to play with these, think of the old world maps). Of > course there are probably exceptions to this but generally if there is a > multi-map area like a forest or a desert or whatever then many specific > adventures should be able to coexist and utilize the area atmosphere. [snip] I'm currently thinking of a Three Sisters Valley-style quest, where there are a bunch of locations in different spots on the swamp that you must visit. I guess this could co-exist with other (future) quests as long as there is no confusion of which map belongs to which quest. (If it comes down to it, it doesn't really matter; I just have to use locked doors with keys/special items to make sure that certain maps are accessible only if you're on that quest.) T -- Life would be easier if I had the source code. -- YHL _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Nov 12 13:29:22 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:37 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: <20031112144351.GA8318@crystal> References: <200310301109.25120.won_fang@yahoo.com.au> <1068488779.533.56.camel@oberon.Kameria> <20031110194241.GA14682@crystal> <3FB06C9C.4000801@sonic.net> <20031111155525.GA29251@crystal> <3FB1C8E1.8020207@sonic.net> <20031112144351.GA8318@crystal> Message-ID: <3FB28A12.2020703@sympatico.ca> > > Actually, the quest maps themselves don't have to be that big; it's just > that I was using the geographical features created by the script. I can > certainly move the quest into submaps and leave more room for other > quests. > > One concern then is that currently, the Inner Swamp is almost completely > disconnected from the Outer Swamp; I guess that's OK as long as I provide > a general access route to it? Why not leave some inner swamp islands disconnected and put nasty things on them - you can still get there by magic spell or portal on another map or secret ways or whatever. I don't think any monster (?) is too nasty/big really so long as there is: A) some indication of the danger and B) a way to stop them from wandering off into other areas C) no generators that can get out of control putting them on an island somewhere in the deep swamp is a good way to add some dangerous area for future adventure and keep control... _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Nov 12 16:50:41 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:37 2005 Subject: [CF-Devel] Ingame map 'building' / modification: full patch In-Reply-To: <3FB1C6C8.2050903@sonic.net> References: <3FB003A7.3030609@laposte.net> <3FB08772.7020506@sonic.net> <3FB0A817.10106@laposte.net> <3FB1C6C8.2050903@sonic.net> Message-ID: <3FB2B941.1000002@laposte.net> > Ok. I didn't look really close at the exact details, but it seemed to > be some amount of duplication of 'is this within map bounds, is there a > flag buildable, etc'. Maybe the amount to be reduced isn't so great. > OTOH, perhaps a flag can be passed into the check function which also > has some indication what to find and what to return. Actually, I rewrote a lot of code yesterday :) So it's better right now, i think... Patch will be submitted after some more tweaking, but maybe not too soon, want to implement much stuff before :) > If that's the case, then it should also generate a LOG() message. Duly noted. > gcc at least will catch those and print a warning. But it's just > easier to me (and really in the style of the rest of the code) that the > constant comes second. Ok, i guess it's just a matter of style :) Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Nov 12 17:14:59 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:37 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: <3FB28A12.2020703@sympatico.ca> References: <200310301109.25120.won_fang@yahoo.com.au> <1068488779.533.56.camel@oberon.Kameria> <20031110194241.GA14682@crystal> <3FB06C9C.4000801@sonic.net> <20031111155525.GA29251@crystal> <3FB1C8E1.8020207@sonic.net> <20031112144351.GA8318@crystal> <3FB28A12.2020703@sympatico.ca> Message-ID: <20031112231459.GA12593@crystal> On Wed, Nov 12, 2003 at 02:29:22PM -0500, Todd Mitchell wrote: [snip] > >One concern then is that currently, the Inner Swamp is almost completely > >disconnected from the Outer Swamp; I guess that's OK as long as I provide > >a general access route to it? > > Why not leave some inner swamp islands disconnected and put nasty things > on them - you can still get there by magic spell or portal on another > map or secret ways or whatever. I don't think any monster (?) is too > nasty/big really so long as there is: > A) some indication of the danger and > B) a way to stop them from wandering off into other areas > C) no generators that can get out of control OK, so I'm leaving the army of tentacles on the Eastern Inner Swamp (not sure about the serpmen, I think I'll relocate them), plus the nasty spotted tentacles on the north in the zig-zaggy marsh. > putting them on an island somewhere in the deep swamp is a good way to > add some dangerous area for future adventure and keep control... [snip] Right. Mmmm... I wonder where to put those giant leeches... :-P T -- What do you mean the Internet isn't filled with subliminal messages? What about all those buttons marked "submit"?? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu Nov 13 06:44:26 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:37 2005 Subject: [CF-Devel] patch:Bargaining experience In-Reply-To: <3FB06AEE.50609@sonic.net> References: <3FAF437B.4090809@sonic.net> <3FB06AEE.50609@sonic.net> Message-ID: On Mon, 10 Nov 2003, Mark Wedel wrote: > No longer is there code which straight out says > 'if you have an 18 int, you get 10% more exp'. > > For bargaining, it is a bit odd, because there is no failure/success chance. > However, one could certainly be added in - the level of the shop could be used > as the basis of how hard it is to bargain against (better shop = harder bargaining). > > With that, the query_cost could then do something like always return the value > of the item without any bargaining going into effect. Then when you buy/sell > something, it could see if you were successful (and how successfull - higher > success = more savings = more exp), and print out a message like 'you saved X > gold through your clever bargaining'. And in that model, that characters > charisma adjustment would aid in the chance of success. > Thus you say : 5% constant cha bargain -> more exp NOT ok. 10% chance of 50% bargain -> more exp IS ok. althogh the experience gained due to charisma is the same in both cases? Anyway, this new patch does not grant exp from charisma. And it does no longer meddle with the player's stats. One get's 1 exp per silver saved buying, and 1 exp per gold gained selling. The expmul issue seems to be solved of cvs. Although i'd rather change the gained exp, than the level requirements. If someone wanted to use expmul, he now has to make sure, not to step over maxint64 for maxlevel. OTOH, this way,a different expmul is more transparent to the players. -------------- next part -------------- *** include/define.h~ Thu Nov 13 11:35:18 2003 --- include/define.h Wed Nov 12 17:53:43 2003 *************** *** 603,608 **** --- 603,609 ---- #define F_BUY 0 #define F_SELL 1 #define F_TRUE 2 /* True value of item, unadjusted */ + #define F_BARGAIN 4/* combine with F_BUY or F_SELL to disable bargaining calc */ #define DIRX(xyz) freearr_x[(xyz)->direction] #define DIRY(xyz) freearr_y[(xyz)->direction] -------------- next part -------------- *** server/shop.c~ Thu Nov 13 12:13:51 2003 --- server/shop.c Wed Nov 12 19:45:13 2003 *************** *** 59,65 **** int query_cost(object *tmp, object *who, int flag) { int val; int number; /* used to better calculate value */ ! int charisma; if (tmp->type==MONEY) return (tmp->nrof * tmp->value); if (tmp->type==GEM) { --- 59,70 ---- int query_cost(object *tmp, object *who, int flag) { int val; int number; /* used to better calculate value */ ! int no_bargain; ! float diff; ! float ratio; ! ! no_bargain = flag & F_BARGAIN; ! if (no_bargain) flag = flag - F_BARGAIN; if (tmp->type==MONEY) return (tmp->nrof * tmp->value); if (tmp->type==GEM) { *************** *** 146,174 **** } } ! /* this modification is for merchant skill ! * now players with readied merchant skill get ! * more Cha up to the limit of modified Cha = 30. ! * -b.t. thomas@nomad.astro.psu.edu */ if (who!=NULL && who->type==PLAYER) { ! float diff; ! ! charisma = who->stats.Cha; /* used for SK_BARGAINING modification */ if (find_skill_by_number(who,SK_BARGAINING)) { ! charisma += (who->level+2)/3; ! if(charisma>30) charisma = 30; ! } ! if (cha_bonus[charisma]<=1.0) { ! LOG(llevError,"Illegal charisma bonus, %d <=1.0", cha_bonus[charisma]); ! diff=0.9; /*pretty bad case */ } else ! /* Diff is now a float between 0 and 1 */ ! diff=(cha_bonus[charisma]-1)/(1+cha_bonus[charisma]); ! /* we need to multiply these by 4.0 to keep buy costs roughly the same * (otherwise, you could buy a potion of charisma for around 400 pp. * Arguable, the costs in the archetypes should be updated to better --- 151,182 ---- } } ! /* This modification is for bargaining skill. ! * Now only players with max level in bargaining ! * AND Cha = 30 will get optimal price. ! * Thus charisma will never get useless. ! * -b.e. edler@heydernet.de */ if (who!=NULL && who->type==PLAYER) { ! ratio = 0.5; ! /* ratio determines how much of the price modification ! * will come from the basic stat charisma ! * the rest will come from the level in bargaining skill ! */ ! int lev_bargain = 0; if (find_skill_by_number(who,SK_BARGAINING)) { ! lev_bargain = find_skill_by_number(who,SK_BARGAINING)->level; } + if ( (no_bargain==0) && (lev_bargain>0) ) + diff = (0.8 - 0.6*((lev_bargain+settings.max_level*0.05) + /(settings.max_level*1.05))); else ! diff = 0.8; ! diff *= 1-ratio; ! /* Diff is now a float between 0.2 and 0.8 */ ! diff+=(cha_bonus[who->stats.Cha]-1)/(1+cha_bonus[who->stats.Cha])*ratio; /* we need to multiply these by 4.0 to keep buy costs roughly the same * (otherwise, you could buy a potion of charisma for around 400 pp. * Arguable, the costs in the archetypes should be updated to better *************** *** 325,334 **** --- 334,353 ---- int pay_for_item(object *op,object *pl) { int to_pay = query_cost(op,pl,F_BUY); object *pouch; + int saved_money; if (to_pay==0) return 1; if(to_pay>query_money(pl)) return 0; + /* We compare the paid price with the one for a player + * without bargaining skill. + * This determins the amount of exp (if any) gained for bargaining. + */ + saved_money = query_cost(op,pl,F_BUY | F_BARGAIN) - to_pay; + + if (saved_money > 0) + change_exp(pl,saved_money,"bargaining",SK_EXP_NONE); + to_pay = pay_from_container(op, pl, to_pay); for (pouch=pl->inv; (pouch!=NULL) && (to_pay>0); pouch=pouch->below) { *************** *** 517,522 **** --- 536,542 ---- object *tmp; object *pouch; archetype *at; + int extra_gain; if(pl==NULL||pl->type!=PLAYER) { LOG(llevDebug,"Object other than player tried to sell something.\n"); *************** *** 537,542 **** --- 557,572 ---- identify(op); return; } + /* We compare the price with the one for a player + * without bargaining skill. + * This determins the amount of exp (if any) gained for bargaining. + * exp/10 -> 1 for each gold coin + */ + extra_gain = i - query_cost(op,pl,F_SELL | F_BARGAIN); + + if (extra_gain > 0) + change_exp(pl,extra_gain/10,"bargaining",SK_EXP_NONE); + for (count=0; coins[count]!=NULL; count++) { at = find_archetype(coins[count]); if (at==NULL) LOG(llevError, "Could not find %s archetype", coins[count]); -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Nov 14 01:42:17 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:37 2005 Subject: [CF-Devel] patch:Bargaining experience In-Reply-To: References: <3FAF437B.4090809@sonic.net> <3FB06AEE.50609@sonic.net> Message-ID: <3FB48759.8020604@sonic.net> Bernd Edler wrote: > On Mon, 10 Nov 2003, Mark Wedel wrote: > > > Thus you say : > > 5% constant cha bargain -> more exp NOT ok. > > 10% chance of 50% bargain -> more exp IS ok. > > althogh the experience gained due to charisma is the same in both cases? Yeah, may not make a lot of sense. But probably the bigger issue is that I'd prefer for most skills to not be auto success, but instead have some chance of success/failure - more so for the other benefits, like being able to tune chances more (as per previous message about shop level or not). > > Anyway, this new patch does not grant exp from charisma. > And it does no longer meddle with the player's stats. > One get's 1 exp per silver saved buying, > and 1 exp per gold gained selling. looks good. Only thing I'd likely to do different is something like: flag &= ~F_BARGAIN instead of if (no_bargain) flag = flag - F_BARGAIN; but that is probably really just an issue of style. Perhaps also because depending on the quality of the compiler, my form should be a little faster, but given this function, not a big deal. The expmul issue seems to be solved of cvs. > Although i'd rather change the gained exp, than the level requirements. > If someone wanted to use expmul, he now has to make sure, not to step > over maxint64 for maxlevel. > OTOH, this way,a different expmul is more transparent to the players. Well, if the person is member of a party, can still be obvious. The other adjustment in that case is that all the loss functions need to take into account that difference. Eg, right now, if you chop 20% off, all works out ok. However, if you only give the player 80% (or whatever) of earned exp, and then chop of 20%, I think that hurts harder, so you'd really only want to the death penalty to be 16%. However, the numbers would hve to worked out, but it seems like that would be the case. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Nov 15 13:18:48 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:37 2005 Subject: [CF-Devel] Code documentation? Warnings cleaning? Message-ID: <3FB67C18.3060908@laposte.net> Hello. I was wondering if some documentation for the code was generated. Tools like doxygen are pretty useful, but i don't know if we use something or not? I'm not saying the code isn't clear, just that it could be worth doing some (inline) documentation :) Also, I'd like to clean warnings on server code. Windows compilation under Visual Studio produces a whole lot of warnings (around 500), most are I think harmless and could be fixed right away (like using 3.0 for initialisation of a constant instead of 3.0f), but some may just say there's something wrong. Arguably, Windows gives more errors than gcc, so maybe I won't try to clean everything, but other things may well be worth cleaning, imo. Of course, if I fix many things, I may just break something.... While I'll take the uttermost precaution when fixing, some apparently minor changes may have bad side effects... Any objections? Comments? Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Nov 15 16:32:49 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:37 2005 Subject: [CF-Devel] Code documentation? Warnings cleaning? In-Reply-To: <3FB67C18.3060908@laposte.net> References: <3FB67C18.3060908@laposte.net> Message-ID: <1068935569.547.2.camel@oberon.Kameria> http:/crossfire.real-time.com/code Still working on the stylesheet a bit however ;) On Sat, 2003-11-15 at 14:18, Nicolas Weeger wrote: > Hello. > > I was wondering if some documentation for the code was generated. Tools > like doxygen are pretty useful, but i don't know if we use something or not? > I'm not saying the code isn't clear, just that it could be worth doing > some (inline) documentation :) > > Also, I'd like to clean warnings on server code. Windows compilation > under Visual Studio produces a whole lot of warnings (around 500), most > are I think harmless and could be fixed right away (like using 3.0 for > initialisation of a constant instead of 3.0f), but some may just say > there's something wrong. Arguably, Windows gives more errors than gcc, > so maybe I won't try to clean everything, but other things may well be > worth cleaning, imo. > Of course, if I fix many things, I may just break something.... While > I'll take the uttermost precaution when fixing, some apparently minor > changes may have bad side effects... > Any objections? Comments? > > Nicolas 'Ryo' > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Nov 15 16:50:23 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:37 2005 Subject: [CF-Devel] Code documentation? Warnings cleaning? In-Reply-To: <1068935569.547.2.camel@oberon.Kameria> References: <3FB67C18.3060908@laposte.net> <1068935569.547.2.camel@oberon.Kameria> Message-ID: <3FB6ADAF.8010506@laposte.net> > http:/crossfire.real-time.com/code > > Still working on the stylesheet a bit however ;) My bad, didn't even check the project page..... sorry ^_^ Ok, so i guess we can add comments doxygen-like :) Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Nov 15 18:00:13 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:37 2005 Subject: [CF-Devel] Code documentation? Warnings cleaning? In-Reply-To: <3FB6ADAF.8010506@laposte.net> References: <3FB67C18.3060908@laposte.net> <1068935569.547.2.camel@oberon.Kameria> <3FB6ADAF.8010506@laposte.net> Message-ID: <1068940813.551.7.camel@oberon.Kameria> Well there is no link to this code section on the site, and this is being done manually at the moment on a semi-regular basis. I haven't run this by anyone for to officially support doxygen but just using the tool and sending the pages to Leaf. If you want to add special doxygen comments I would ask other deveolpers on the IRC first although if it isn't special 'doxygen only' comments I can't see why anyone would complain about more commenting. I like the pictures though - nice tool this doxygen. On Sat, 2003-11-15 at 17:50, Nicolas Weeger wrote: > > http:/crossfire.real-time.com/code > > > > Still working on the stylesheet a bit however ;) > > My bad, didn't even check the project page..... sorry ^_^ > Ok, so i guess we can add comments doxygen-like :) > > Nicolas 'Ryo' > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Nov 15 19:25:55 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:38 2005 Subject: [CF-Devel] Code documentation? Warnings cleaning? In-Reply-To: <3FB67C18.3060908@laposte.net> References: <3FB67C18.3060908@laposte.net> Message-ID: <3FB6D223.6070207@sonic.net> Nicolas Weeger wrote: > Hello. > > I was wondering if some documentation for the code was generated. Tools > like doxygen are pretty useful, but i don't know if we use something or > not? > I'm not saying the code isn't clear, just that it could be worth doing > some (inline) documentation :) Additional comments is never bad. It's just that generally, most developers have 'better' things to do than go through the code and write comments (at minimum, I'd say there are some sections of code that work, but which are really ugly and could be rewritten as a higher priority than writing comments). If there are specific questions about code, I'd hope people working on it would just ask - given the amount of code, a lot of work to document it all. However, if people need specific areas documented because they are working on it, something can be done. > > Also, I'd like to clean warnings on server code. Windows compilation > under Visual Studio produces a whole lot of warnings (around 500), most > are I think harmless and could be fixed right away (like using 3.0 for > initialisation of a constant instead of 3.0f), but some may just say > there's something wrong. Arguably, Windows gives more errors than gcc, > so maybe I won't try to clean everything, but other things may well be > worth cleaning, imo. > Of course, if I fix many things, I may just break something.... While > I'll take the uttermost precaution when fixing, some apparently minor > changes may have bad side effects... > Any objections? Comments? I'd like to ge a better idea of the nature of all those compiles. Perhaps an error log can be posted someplace? I'm a little concerned in that some of these could break compiling on unix. Eg, different API for windows or whatever else. It'd be a shame for you to fix all those, and then have them undone because it breaks it working on unix. Also, there are some number of errors that just can't be fixed/eliminated. Anything from loader.c, or the other .c files which are generated from .l files really can't be fixed. This is because it is code that lex generates which is resulting in the warnings. So having those files produce warnings is just a fact of life. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Nov 15 19:45:24 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:38 2005 Subject: [CF-Devel] Re: [CF-maps] map errors In-Reply-To: <3FB6D2FA.6010206@sonic.net> References: <3FB48813.30107@sonic.net> <20031114121820.GA7238@crystal> <3FB559E5.6090101@sympatico.ca> <3FB6D2FA.6010206@sonic.net> Message-ID: <3FB6D6B4.5080903@sympatico.ca> Mark Wedel wrote: > > Just a note on the map errors - my message was really just to raise > awareness, eg, people may not have realized there were problems there > or whatever. Ideally, it would be nice if there were no errors, but if > the errors are work in progress or not really errors, not that big a > deal. Actually I think it was great to do this. It would be great if we could make a few more scripts that would point out errors in the arches or in the maps or what not and run them once in a while to give folks a chance to clean up some stuff. I am afraid that I tend to work in spurts so sometimes stuff gets missed or left till next time. Another idea along this line maybe could be to mail out the various todo lists every once in a while so that they could be commented on and vetted and aired out. I have been meaning to make a TODO file for the arches and for the maps for a while now . This is what the wiki was supposed to be for but it never hurts to mail out a copy quarterly or something too. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Nov 15 20:24:11 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:38 2005 Subject: AW: [CF-Devel] Code documentation? Warnings cleaning? In-Reply-To: <3FB6D223.6070207@sonic.net> Message-ID: I had ported the source some times ago as you know and all i can say is that a warning free source is possible and it will benefits both plattforms. A source which compiles on different OS with different compilers will win in stability and not lose. At last for the daimonin server which is still in alot parts very near to cf it is a fact. If you want hold the loader.c in the source (what should not be like autconf.h too) then simply produce a loader_win.c for windows. A on windows with flex generated loader.c will run fine without any warnings. And note: loader.c is not a real source file - its a system depending generated file - loader.l is the source file. > I'm a little concerned in that some of these could break > compiling on unix. > Eg, different API for windows or whatever else. It'd be a shame > for you to fix > all those, and then have them undone because it breaks it working on unix. > > Also, there are some number of errors that just can't be > fixed/eliminated. > Anything from loader.c, or the other .c files which are generated > from .l files > really can't be fixed. This is because it is code that lex > generates which is > resulting in the warnings. So having those files produce > warnings is just a > fact of life. > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 16 02:44:46 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:38 2005 Subject: [CF-Devel] Code documentation? Warnings cleaning? In-Reply-To: <3FB6D223.6070207@sonic.net> References: <3FB67C18.3060908@laposte.net> <3FB6D223.6070207@sonic.net> Message-ID: <3FB738FE.5040704@laposte.net> > Additional comments is never bad. It's just that generally, most > developers have 'better' things to do than go through the code and write > comments (at minimum, I'd say there are some sections of code that work, > but which are really ugly and could be rewritten as a higher priority > than writing comments). > > If there are specific questions about code, I'd hope people working on > it would just ask - given the amount of code, a lot of work to document > it all. However, if people need specific areas documented because they > are working on it, something can be done. Well, I was thinking of doing in parallel documentation & warning cleaning. Like, fixing a few warnings in a function, if it has some comments at top make'em doxygen comments, else write a few lines (i guess documenting in this format isn't bad?). This way it'll be done small portion by small portion. > I'd like to ge a better idea of the nature of all those compiles. > Perhaps an error log can be posted someplace? I can mail you privately the full (or partial) warning compilation log. Or I could post it on the messageboard, or somewhere on the wiki? > I'm a little concerned in that some of these could break compiling on > unix. Eg, different API for windows or whatever else. It'd be a shame > for you to fix all those, and then have them undone because it breaks it > working on unix. This is something I plan on testing. Knoppix is there to lemme boot into Linux fast & make sure it compiles there too :) But yes, I will have to take much care. The black point I can see is: a minor fix, that compiles correctly, but breaks something later on (like: adding an explicit conversion in a signed/unsigned comparison by casting the unsigned to signed, which breaks because the default compiler behaviour was to convert signed to unsigned AND that was required by the code at that point...) > Also, there are some number of errors that just can't be > fixed/eliminated. Anything from loader.c, or the other .c files which > are generated from .l files really can't be fixed. This is because it > is code that lex generates which is resulting in the warnings. So > having those files produce warnings is just a fact of life. Granted, and I don't plan on fixing all those warnings in any case :) (fun lexx can't make warning-less code, but nothing's perfect, i guess :)) I don't mind some warnings, but right now, under Windows at least, there are just too many for my taste... And I'm afraid some hide real troubles, too... Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 16 17:21:16 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:38 2005 Subject: [CF-Devel] Code documentation? Warnings cleaning? In-Reply-To: <3FB738FE.5040704@laposte.net> References: <3FB67C18.3060908@laposte.net> <3FB6D223.6070207@sonic.net> <3FB738FE.5040704@laposte.net> Message-ID: <3FB8066C.2020006@sonic.net> Nicolas Weeger wrote: > Well, I was thinking of doing in parallel documentation & warning > cleaning. Like, fixing a few warnings in a function, if it has some > comments at top make'em doxygen comments, else write a few lines (i > guess documenting in this format isn't bad?). > This way it'll be done small portion by small portion. Seems to be Ok. I've only briefly looked at doxygen, and their suggested commenting style - I don't see anything terribly wrong with it, but at the same time, be aware that I wouldn't expect (nor require) that style to be followed by everyone. Eg, I'll personally just continue to do comments in the form I'm used to. > > I can mail you privately the full (or partial) warning compilation log. > Or I could post it on the messageboard, or somewhere on the wiki? You can mail it to me - that is fine. > This is something I plan on testing. Knoppix is there to lemme boot into > Linux fast & make sure it compiles there too :) > But yes, I will have to take much care. Everyone should also be aware that sourceforge offers a compile farm for its developers, so even if you don't have linux/whatever access, you can use the compile farm to test compliance. Only problem is that you then need to get your changes there somehow. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 16 18:56:07 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:38 2005 Subject: [CF-Devel] Some CVS bugs In-Reply-To: <20031105021607.GA31977@crystal> References: <20031105021607.GA31977@crystal> Message-ID: <3FB81CA7.9070208@sonic.net> H. S. Teoh wrote: > Hi, I'm not sure if these bugs have been fixed yet, but I noticed them on > crossfire.metalforge (the one running CVS) and I thought I should bring > them to people's attention: > > 1) Summoning runes and other spell-casting runes don't work anymore. This > is with auto-generated traps such as trapped chests and doors. I'm not > sure exactly which traps don't work; some spells seem to work but others > don't. Well, the summoning runes were broken in one way that is now fixed. In terms of traps, that seems to be more complicated - if a more definitive list of what traps don't work can be generated, that would be useful. > 3) Cure confusion doesn't. Neither the spell nor the scroll works. The > spell just consumes mana and does nothing. This is now fixed. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 16 19:43:06 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:38 2005 Subject: [CF-Devel] Patch: client display issues In-Reply-To: <20031026191014.GA27085@idefix2.dvlp.in-medias-res.com> References: <20031011224131.GA20847@idefix2.dvlp.in-medias-res.com> <3F8B9B70.7080804@sonic.net> <20031026191014.GA27085@idefix2.dvlp.in-medias-res.com> Message-ID: <3FB827AA.2060606@sonic.net> > > > >>>* client2.diff: This patch fixes the problem that multi-square objects >>> hide the player. >> >>I tried that - you basically reversed the order of display. I tried that >>to correct some display issues, but found it created other display issues. >>I think it related to if you have big objects stacking over each other, >>but maybe I tried that reversal before I made the other changes. > > > I was not able to reproduce this problem anymore, so I think this patch is > not needed anymore. (But if I understand the code correctly, the x11 and gtk > client differ: the x11 client will draw heads, then tails, but the gtk > client tails, then heads.) > > Andreas Kirschbaum wrote: > (Sorry for the late reply, I wasn't home for some time.) I'll apologize for the distance for this reply. I sort of put this on the back burner - not all that critical of a problem, compared to many others I was dealing with. > > > I agree with this explanation. Therefore my patch reversed the previous > (incorrect) fix. (My patch corrects the gtk client only, because in the x11 > client this problem had not been "fixed".) > > I still think this patch fixes a real problem (in the gtk client): You can > see the "ghost images" for example in /scorn/misc/beginners: open the bottom > gate and do not kill the kobold. Let the kobold follow you to the top of the > map. Run south until the kobold disappears from the top of the view. Go > (run) back to north: most of the time, the (gtk) client will display two > kobolds when it reappears. Yep - I agree with this, and will re-apply the patch that fixes the clear cell problem. That, combined with the patch in the server to correctly clear cells as they scroll into/out of view, means that I think putting that code back in makes sense. I can see that when spaces weren't being cleared on scroll, that doing that caused problems regarding the head of images. > While testing I found another (minor) display issue (in both the gtk and x11 > client): A player (or other objects) that is atop the bottom/right corner > of the palace in /pup_land/terminal disappears when other squares of the > palace are not visible: > > (P=palace, @=player, _=cobblestones, .=grass, ?=fog) > > ...._.... > ...?_.... > ..PPPP_.. > ..PPPP_.. > __PPP@___ > .._____.. > ...._.... > ...._.... > > Now the player is visible. When a fog enters the palace (or the player casts > holy word), the player disappears: > > ...._.... > ...._.... > ..P?PP_.. > ..PPPP_.. > __PPPP___ > .._____.. > ...._.... > ...._.... Yeah - I see that also - will attempt to fix. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 17 05:39:14 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:38 2005 Subject: [CF-Devel] Re: Code documentation? References: <1068935569.547.2.camel@oberon.Kameria> Message-ID: <5863.1069069154@www50.gmx.net> Todd Mitchell wrote: > http:/crossfire.real-time.com/code > > Still working on the stylesheet a bit however ;) Code documentation is always a good idea. Since the CFJavaEditor shows up on the link provided, this reminds me that the editor is pretty well documented in javadoc style. I don't have a problem with doxygen being used to format CFJavaEditor sources, however I would like developers who might be working on the java code to write javadoc comments (in case there is any difference, which I'm not sure about). Anyways, I have added a javadoc build target to to the ant build file for the editor. Javadocs can now be generated by the command "ant doc". As an example, javadocs from current CVS can be downloaded from: http://home.in.tum.de/~vogl/crossfire/CFJavaEditor_docs.zip (This is just a one-time example. I don't plan to update the link when code changes occur). AndreasV -- NEU F?R ALLE - GMX MediaCenter - f?r Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gru?, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse f?r Mail, Message, More! +++ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 17 07:34:02 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:38 2005 Subject: [CF-Devel] Flying monster stealing patch Message-ID: <20031117133402.GA11974@crystal> Hi all, After testing my new flying monster, Katia & I found out that it cannot steal because it's flying (pick_up() fails). In the process, we uncovered a bug in the stealing code, that tells the player something was stolen even if pick_up() subsequently fails. I tried to move the call to esrv_del_item to inside the if-statement that checks if the item was picked up, but it didn't work (apparently it's not as simple as I thought; if the thief wasn't a player, the if-statement fails). Perhaps Mark or somebody can figure out the correct fix for this bug. But anyway, it seems to be a bad limitation that flying monsters cannot steal; so I've patched pick_up() to allow pickup by flying monsters. The patch follows the end of this email. Levitating players still cannot pick up objects (and cannot steal either---not sure if that's a bug or a feature), but now flying monsters can pick up stuff and steal as well. I thought I'd bring it up for discussion before checking it into CVS. Thoughts? Objections? T -- A bend in the road is not the end of the road unless you fail to make the turn. -- Brian White Index: crossfire/server/c_object.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/c_object.c,v retrieving revision 1.54 diff -u -r1.54 c_object.c --- crossfire/server/c_object.c 27 Oct 2003 09:48:34 -0000 1.54 +++ crossfire/server/c_object.c 17 Nov 2003 13:27:36 -0000 @@ -556,8 +556,8 @@ * (sack, luggage, etc), tmp->env->env then points to the player (nested * containers not allowed as of now) */ - if(QUERY_FLAG(pl, FLAG_FLYING) && !QUERY_FLAG(pl, FLAG_WIZ) && - is_player_inv(tmp)!=pl) { + if (pl->type==PLAYER && QUERY_FLAG(pl, FLAG_FLYING) && + !QUERY_FLAG(pl, FLAG_WIZ) && is_player_inv(tmp)!=pl) { new_draw_info(NDI_UNIQUE, 0,pl, "You are levitating, you can't reach the ground!"); return; } _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 17 15:59:40 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:38 2005 Subject: [CF-Devel] Re: Code documentation? In-Reply-To: <5863.1069069154@www50.gmx.net> References: <1068935569.547.2.camel@oberon.Kameria> <5863.1069069154@www50.gmx.net> Message-ID: <3FB944CC.9010703@laposte.net> > Since the CFJavaEditor shows up on the link provided, > this reminds me that the editor is pretty well documented > in javadoc style. > I don't have a problem with doxygen being used to format > CFJavaEditor sources, however I would like developers who > might be working on the java code to write javadoc comments > (in case there is any difference, which I'm not sure about). doxygen will extract javadoc-style comments, that's an option :) http://www.stack.nl/~dimitri/doxygen/docblocks.html for all formats it supports (duplicated from other post, but well) > AndreasV Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 17 15:56:19 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:38 2005 Subject: [CF-Devel] Code documentation? Warnings cleaning? In-Reply-To: <3FB8066C.2020006@sonic.net> References: <3FB67C18.3060908@laposte.net> <3FB6D223.6070207@sonic.net> <3FB738FE.5040704@laposte.net> <3FB8066C.2020006@sonic.net> Message-ID: <3FB94403.1030701@laposte.net> 'lo > Seems to be Ok. I've only briefly looked at doxygen, and their > suggested commenting style - I don't see anything terribly wrong with > it, but at the same time, be aware that I wouldn't expect (nor require) > that style to be followed by everyone. Eg, I'll personally just > continue to do comments in the form I'm used to. Comments like: /** * this */ can be extracted automatically. Seems close enough to what is used in CF :) Of course if you want to start putting brief comments & full comments, it's slightly different. Of course you can do many other formats, if you want the full list check http://www.stack.nl/~dimitri/doxygen/docblocks.html And yes it can extract javadoc style comments. No, I don't expect everyone to follow, fine by me :) > Everyone should also be aware that sourceforge offers a compile farm > for its developers, so even if you don't have linux/whatever access, you > can use the compile farm to test compliance. Only problem is that you > then need to get your changes there somehow. Forgot the compile farm, haven't actually used it at all ^.^ But I think Knoppix, maybe with some virtual machine if i'm too lazy to reboot, will do the trick (that's what Knoppix is for, after all, no need to install :)) (will be faster for code transfer, maybe) Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 17 20:01:21 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:39 2005 Subject: [CF-Devel] rustmonster gfx Message-ID: I made a new graphic for the rustmonster. It's no masterpiece, but it is in the correct perspective for the base graphic set. (unlike the old one) The necromancer's pet is just a gray rustmonster, so I worked on it too. As the png's are only 350 bytes long, I just attached them. They are free to use of course. Bernd Edler -------------- next part -------------- A non-text attachment was scrubbed... Name: rustmonste.base.111.png Type: application/octet-stream Size: 349 bytes Desc: Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20031118/14802f26/rustmonste.base.111.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: rustmonste.base.112.png Type: application/octet-stream Size: 359 bytes Desc: Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20031118/14802f26/rustmonste.base.112.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: pet_necro.base.111.png Type: application/octet-stream Size: 354 bytes Desc: Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20031118/14802f26/pet_necro.base.111.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: pet_necro.base.112.png Type: application/octet-stream Size: 361 bytes Desc: Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20031118/14802f26/pet_necro.base.112.obj -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 17 19:46:56 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:39 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: <1068619234.836.32.camel@oberon.Kameria> Message-ID: <20031118014656.13761.qmail@web21311.mail.yahoo.com> I have read all the mail about the pros and cons of moving part of the Dark Forest into the big world. Currently I have just moved the entrance to the other side of the road, and made the surrounding flora thicker to match the place it came from. Oh, and changed the wording of the quest in Scorn to match it's new location. I won't commit these changes just yet, but I will seriously consider these suggestions and maybe implement some of them, then commit. With the Dark Forest on the other side of the road, it might make sense to expand some of it into the big world. I was gonna populate some of the large forest with some of the critters from the Dark Forest first level anyway. http://personals.yahoo.com.au - Yahoo! Personals New people, new possibilities. FREE for a limited time. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 17 19:52:42 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:39 2005 Subject: [CF-Devel] Re: [CF-maps] Fast worldmap rendering script In-Reply-To: <20031110154523.GA12178@crystal> Message-ID: <20031118015242.10154.qmail@web21301.mail.yahoo.com> --- "H. S. Teoh" wrote: > Somebody raised the point that it might be good to actually base the > generated images on actual tile pngs. This should be doable, if people > are interested. That was probably me. It's already on my TODO list. http://personals.yahoo.com.au - Yahoo! Personals New people, new possibilities. FREE for a limited time. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 17 20:01:27 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:39 2005 Subject: [CF-Devel] Ingame map 'building' / modification: full patch In-Reply-To: <3FB003A7.3030609@laposte.net> Message-ID: <20031118020127.15950.qmail@web21311.mail.yahoo.com> --- Nicolas Weeger wrote: > If/when this code makes it at some point, i suggest making a new > apartment somewhere (Pupland? Lake County?). And making raw material > expensive :) I'll look at adding this stuff to the apartments in my Ice Castle. http://personals.yahoo.com.au - Yahoo! Personals New people, new possibilities. FREE for a limited time. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 17 20:17:54 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:39 2005 Subject: [CF-Devel] Re: Code documentation? In-Reply-To: <5863.1069069154@www50.gmx.net> References: <1068935569.547.2.camel@oberon.Kameria> <5863.1069069154@www50.gmx.net> Message-ID: <1069121874.540.21.camel@oberon.Kameria> On Mon, 2003-11-17 at 06:39, Andreas Vogl wrote: > Code documentation is always a good idea. > > Since the CFJavaEditor shows up on the link provided, > this reminds me that the editor is pretty well documented > in javadoc style. > I don't have a problem with doxygen being used to format > CFJavaEditor sources, however I would like developers who > might be working on the java code to write javadoc comments > (in case there is any difference, which I'm not sure about). > > Anyways, I have added a javadoc build target to to the ant > build file for the editor. Javadocs can now be generated by > the command "ant doc". > > As an example, javadocs from current CVS can be downloaded from: > http://home.in.tum.de/~vogl/crossfire/CFJavaEditor_docs.zip > > (This is just a one-time example. I don't plan to update the link > when code changes occur). > > AndreasV > I was posting the source code via doxygen as a test trial but if people want to actually add more comments to the code because of this - this is good. Up till now I have just run doxygen against the raw source code but I can commit the doxyfiles used for each project (editor, server, client) to allow anyone to generate the documentation if this is wanted so that people can use the tool more. Really I haven't been around long enough to decide anything like that however. As far as I understand it it there is markup you can use which will appear as comments in plaintext but will be fancier or more featureful when running doxygen. The tool also will do other formats than html if this is desired. I have been maintining these things manually but I had planned on automating this if it was a popular feature - it is real easy to generate these code mini-sites once you have templates. You only need doxygen and graphviz and the sourcecode so it could be scheduled to run against a copy of CVS and served up automatically (say on sourceforge or real-time). As for javadoc comments, I am pretty sure that Doxygen can manage to do the right thing with javadoc type commenting (RTFM I expect of course - I haven't dome more than skim it really) so the two tools should be pretty cohabitable but I would suggest that some comment to this effect should be in the sourcecode or developer guide for the Java editor if there is a particular style or whatever of documenting desired. This would go for the CF developer guidelines too. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 17 21:32:19 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:39 2005 Subject: [CF-Devel] rustmonster gfx In-Reply-To: References: Message-ID: <1069126339.536.50.camel@oberon.Kameria> On Mon, 2003-11-17 at 21:01, Bernd Edler wrote: > I made a new graphic for the rustmonster. > It's no masterpiece, but it is in the correct perspective for the base > graphic set. (unlike the old one) > The necromancer's pet is just a gray rustmonster, so I worked on it too. > > As the png's are only 350 bytes long, I just attached them. > They are free to use of course. I like them. I'll commit these right away if you say ok - I noticed you didn't send two frames of the rustmonster so I made one to match from the necro but added a bit of leg motion. If you have no objections I'll add some extra motion to the pet_necro too (but diffrerent than the rustomnster). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 18 01:40:39 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:39 2005 Subject: [CF-Devel] Flying monster stealing patch In-Reply-To: <20031117133402.GA11974@crystal> References: <20031117133402.GA11974@crystal> Message-ID: <3FB9CCF7.8080903@sonic.net> H. S. Teoh wrote: > Hi all, > > After testing my new flying monster, Katia & I found out that it cannot > steal because it's flying (pick_up() fails). In the process, we uncovered > a bug in the stealing code, that tells the player something was stolen > even if pick_up() subsequently fails. I tried to move the call to > esrv_del_item to inside the if-statement that checks if the item was > picked up, but it didn't work (apparently it's not as simple as I thought; > if the thief wasn't a player, the if-statement fails). Perhaps Mark or > somebody can figure out the correct fix for this bug. Well, ideally, pick_up() returns status on if it works or not. Saving that, the following would need to be done: The tag of the object stored away (because pick_up could merge it with another). Check to see if tmp->env changes - if so, the object was stolen. This means storing the old ->env field away. If that succeeds, then send the esrv_del_item with the tag that was stored away. > > But anyway, it seems to be a bad limitation that flying monsters cannot > steal; so I've patched pick_up() to allow pickup by flying monsters. The > patch follows the end of this email. Levitating players still cannot > pick up objects (and cannot steal either---not sure if that's a bug or a > feature), but now flying monsters can pick up stuff and steal as well. I > thought I'd bring it up for discussion before checking it into CVS. I'm a little concerned on that - I'm not sure, but there could be some monsters out there that have flying set, that you really don't want picking something up. I'd be reluctant to make such a change due to possible undesirable side effects. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 18 02:00:47 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:39 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: <20031118014656.13761.qmail@web21311.mail.yahoo.com> References: <20031118014656.13761.qmail@web21311.mail.yahoo.com> Message-ID: <3FB9D1AF.206@sonic.net> David Seikel wrote: > I have read all the mail about the pros and cons of moving part of the Dark > Forest into the big world. Currently I have just moved the entrance to the > other side of the road, and made the surrounding flora thicker to match the > place it came from. Oh, and changed the wording of the quest in Scorn to > match it's new location. I won't commit these changes just yet, but I will > seriously consider these suggestions and maybe implement some of them, then > commit. With the Dark Forest on the other side of the road, it might make > sense to expand some of it into the big world. I was gonna populate some > of the large forest with some of the critters from the Dark Forest first > level anyway. I take it by saying 'you moved the entrance', this isn't the first map, but just the forest space itself? I don't have a problem with some relocation. However, the map itself, and monsters on it, is certainly not a low level map. So I'm a bit concerned about perhaps putting those monsters so close to a major road. I don't have that big a deal if players run into tough creatures if they go cross country, but I'd like the roads to be relatively safe (this doesn't mean no monsters at all, but they should be relatively weak mosnters). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 18 09:14:17 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:39 2005 Subject: =?iso-8859-1?Q?Re:_[CF-Devel]_Ingame_map_'building'_/_modification:_full_patch?= Message-ID: > I'll look at adding this stuff to the apartments in my Ice Castle. Well, actually I've again changed & tweaked building stuff... Current map constraints (flags on walls & floors & such) hold true, but items & such will change. So if you want to add a buildable apartment, i suggest you do a minimum size apartment (like 2 squares), and put buildable/wall/floor flags where needed, but don't yet use the items i have in my submitted patch. And yes, I should 1) stop changing my building method all the time 2) finish it & submit it :))) Nicolas 'Ryo' Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 18 09:47:30 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:39 2005 Subject: [CF-Devel] rustmonster gfx In-Reply-To: <1069126339.536.50.camel@oberon.Kameria> References: <1069126339.536.50.camel@oberon.Kameria> Message-ID: On Mon, 17 Nov 2003, Todd Mitchell wrote: > I'll commit these right away if you say ok I say OK. :-) > I noticed you didn't send two frames of the rustmonster I did send 4 pngs. 2x rusty + 2x pet. So maybe you should have a look at your mail reader / it's configuration. Could be, it doesn't show more than 3 attachments or something. > If you have no objections I'll add some > extra motion to the pet_necro too. I'm all for variety. Bernd Edler _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 18 11:47:53 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:39 2005 Subject: [CF-Devel] Patch: possible bugfix in client Message-ID: <20031118174753.GA31093@idefix2.dvlp.in-medias-res.com> While browsing through the code, I found some suspicious looking conditions: I think the attached patch fixes two typos in variable names. -------------- next part -------------- Index: gnome/map.c =================================================================== RCS file: /cvsroot/crossfire/client/gnome/map.c,v retrieving revision 1.2 diff -u -w -r1.2 map.c --- gnome/map.c 15 Jan 2002 07:32:59 -0000 1.2 +++ gnome/map.c 18 Nov 2003 16:55:30 -0000 @@ -321,7 +321,7 @@ { if( pl_pos.x + dx + mapx >= the_map.x || - pl_pos.y + dx + mapy >= the_map.y || + pl_pos.y + dy + mapy >= the_map.y || pl_pos.x + dx <= 0 || pl_pos.y + dy <= 0 ) { Index: gtk/map.c =================================================================== RCS file: /cvsroot/crossfire/client/gtk/map.c,v retrieving revision 1.17 diff -u -w -r1.17 map.c --- gtk/map.c 26 Oct 2003 11:43:55 -0000 1.17 +++ gtk/map.c 18 Nov 2003 16:55:32 -0000 @@ -226,7 +226,7 @@ { if( pl_pos.x + dx + use_config[CONFIG_MAPWIDTH] +2 >= the_map.x || - pl_pos.y + dx + use_config[CONFIG_MAPHEIGHT] +2 >= the_map.y || + pl_pos.y + dy + use_config[CONFIG_MAPHEIGHT] +2 >= the_map.y || pl_pos.x + dx -2 <= 0 || pl_pos.y + dy -2 <= 0 ) { -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 18 12:27:11 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:39 2005 Subject: [CF-Devel] rustmonster gfx In-Reply-To: <1069126339.536.50.camel@oberon.Kameria> References: <1069126339.536.50.camel@oberon.Kameria> Message-ID: <20031118182711.GD27656@crystal> On Mon, Nov 17, 2003 at 10:32:19PM -0500, Todd Mitchell wrote: > On Mon, 2003-11-17 at 21:01, Bernd Edler wrote: > > I made a new graphic for the rustmonster. > > It's no masterpiece, but it is in the correct perspective for the base > > graphic set. (unlike the old one) > > The necromancer's pet is just a gray rustmonster, so I worked on it too. [snip] Would it make sense to make a two-headed rustmonster for the necromancer's pet? It is that way in the classic image set, and I think it conveys the nastiness of the pet better. :-) T -- The peace of mind--from knowing that viruses which exploit Microsoft system vulnerabilities cannot touch Linux--is priceless. -- Frustrated system administrator. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 18 12:24:48 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:39 2005 Subject: [CF-Devel] Flying monster stealing patch In-Reply-To: <3FB9CCF7.8080903@sonic.net> References: <20031117133402.GA11974@crystal> <3FB9CCF7.8080903@sonic.net> Message-ID: <20031118182448.GC27656@crystal> On Mon, Nov 17, 2003 at 11:40:39PM -0800, Mark Wedel wrote: > H. S. Teoh wrote: > >Hi all, > > > >After testing my new flying monster, Katia & I found out that it cannot > >steal because it's flying (pick_up() fails). In the process, we uncovered > >a bug in the stealing code, that tells the player something was stolen > >even if pick_up() subsequently fails. I tried to move the call to > >esrv_del_item to inside the if-statement that checks if the item was > >picked up, but it didn't work (apparently it's not as simple as I thought; > >if the thief wasn't a player, the if-statement fails). Perhaps Mark or > >somebody can figure out the correct fix for this bug. > > Well, ideally, pick_up() returns status on if it works or not. In fact, I've done this fix, and it seems to work quite nicely, except that I forgot I needed to save backup values for the stolen item as you describe below. > Saving that, the following would need to be done: > The tag of the object stored away (because pick_up could merge it with > another). Ahh, I didn't think of that. > Check to see if tmp->env changes - if so, the object was stolen. > This means storing the old ->env field away. If that succeeds, then > send the esrv_del_item with the tag that was stored away. Given that I've changed pick_up() to return a true/false value indicating whether the pickup was successful, I probably don't need this anymore, right? Also, do you think it makes more sense to send esrv_del_item *inside* pick_up() or pick_up_item() instead? It would seem that fixing it once in pick_up() will save us the headache of fixing the 50 other places where pick_up() is called, which might have to do the same thing. (I don't know if there's any other place which needs to do this right now, but it's conceivable to happen in the future.) [snip] > >But anyway, it seems to be a bad limitation that flying monsters cannot > >steal; so I've patched pick_up() to allow pickup by flying monsters. The > >patch follows the end of this email. Levitating players still cannot > >pick up objects (and cannot steal either---not sure if that's a bug or a > >feature), but now flying monsters can pick up stuff and steal as well. I > >thought I'd bring it up for discussion before checking it into CVS. > > I'm a little concerned on that - I'm not sure, but there could be some > monsters out there that have flying set, that you really don't want picking > something up. I'd be reluctant to make such a change due to possible > undesirable side effects. [snip] Hmm, that's true. So then the question is, is it possible to have a flying monster that steals, and how would I do it? T -- If creativity is stifled by rigid discipline, then it is not true creativity. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 18 16:04:06 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:39 2005 Subject: [CF-Devel] rustmonster gfx In-Reply-To: <20031118182711.GD27656@crystal> References: <1069126339.536.50.camel@oberon.Kameria> <20031118182711.GD27656@crystal> Message-ID: <3FBA9756.5080403@sympatico.ca> > > Would it make sense to make a two-headed rustmonster for the necromancer's > pet? It is that way in the classic image set, and I think it conveys the > nastiness of the pet better. :-) > Two heads and longer horns? I'm all for a bit of diversity if they are easy to tell apart I think that's a good idea. I can make an attempt at this or I can wait for changes or I can commit what I have (I'll grab the pic I'm missing from the mailing list). I will leave it up to Bernd. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 18 19:39:16 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:39 2005 Subject: [CF-Devel] rustmonster gfx In-Reply-To: <20031118182711.GD27656@crystal> References: <1069126339.536.50.camel@oberon.Kameria> <20031118182711.GD27656@crystal> Message-ID: On Tue, 18 Nov 2003, H. S. Teoh wrote: > > Would it make sense to make a two-headed rustmonster for the necromancer's > pet? It is that way in the classic image set. > I was not aware of the graphics for the pet in the classic set. Looking at it now, it seems to me this picture rather belongs in the base set. After all,the perspective is the main conceptual difference between the two. I suggest to use this picture for both, until we have something adequate for the classic set. Bernd _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 18 21:58:46 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:40 2005 Subject: [CF-Devel] rustmonster gfx In-Reply-To: References: <1069126339.536.50.camel@oberon.Kameria> <20031118182711.GD27656@crystal> Message-ID: <1069214326.950.39.camel@oberon.Kameria> > I was not aware of the graphics for the pet in the classic set. > Looking at it now, it seems to me this picture rather belongs in the base > set. After all,the perspective is the main conceptual difference between > the two. > I suggest to use this picture for both, until we have something > adequate for the classic set. > > Bernd Well as far as I am concerned the classic set is a different perspective but also a different style which includes outlines and simpler colour scheme (more cartoony). Since your images were more my idea of the classic set BUT so are the ones in the classic set this is a bit weird. I think however that since your images are original (and cuter) while the others in the classic set were taken from the infamous RPG 8bit image set and can be found in other games - I would rather see your images in there. I will wait a bit on the pet_necro (actually I made a real mess of that one since the monster speed is so high the two heads were bobbling faster than a woodpecker on crack) till you decide but since the rustmonster is more clear cut IMHO I've done gone and committed this one. OK? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Nov 19 01:56:25 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:40 2005 Subject: [CF-Devel] Flying monster stealing patch In-Reply-To: <20031118182448.GC27656@crystal> References: <20031117133402.GA11974@crystal> <3FB9CCF7.8080903@sonic.net> <20031118182448.GC27656@crystal> Message-ID: <3FBB2229.1020006@sonic.net> H. S. Teoh wrote: > On Mon, Nov 17, 2003 at 11:40:39PM -0800, Mark Wedel wrote: >>Check to see if tmp->env changes - if so, the object was stolen. >>This means storing the old ->env field away. If that succeeds, then >>send the esrv_del_item with the tag that was stored away. > > > Given that I've changed pick_up() to return a true/false value indicating > whether the pickup was successful, I probably don't need this anymore, > right? Correct. > > Also, do you think it makes more sense to send esrv_del_item *inside* > pick_up() or pick_up_item() instead? It would seem that fixing it once in > pick_up() will save us the headache of fixing the 50 other places where > pick_up() is called, which might have to do the same thing. (I don't know > if there's any other place which needs to do this right now, but it's > conceivable to happen in the future.) Well, using pick_up in the stealing code is really a pretty bad hack. pick_up was obviously originally designed/coded to pick up items off the floor and move it to a creatures inventory. Thus, things like checking for fly, no_pick, etc. And for that case, it seems to work fine. The expectation for pick_up() that the object may be in another creatures inventory is odd I suppose it wouldn't hurt for pick_up to send the appropriate client/server command. > Hmm, that's true. So then the question is, is it possible to have a flying > monster that steals, and how would I do it? Well, as said above, pick_up was originally designed for picking things up from the ground, where such a change made sense. The best solution would be to pass another flag into pick_up() which could say to let flying creatures pick up the object. Or the simpler, but slightly more dangerous way, would be to clear the flag_flying before calling pick_up, and then re-setting it afterwards. But calling pick_up() may call fix_player() or otherwise update stats, which makes that not quite such a good method. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu Nov 20 23:26:47 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:40 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: <3FB9D1AF.206@sonic.net> References: <20031118014656.13761.qmail@web21311.mail.yahoo.com> <3FB9D1AF.206@sonic.net> Message-ID: <200311211526.47295.won_fang@yahoo.com.au> On Tue, 18 Nov 2003 06:00 pm, Mark Wedel wrote: > I take it by saying 'you moved the entrance', this isn't the first map, > but just the forest space itself? Yep. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Nov 21 14:20:07 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:40 2005 Subject: [CF-Devel] A few glitches Message-ID: <3FBE7377.6030604@laposte.net> Hello. Playing on crossfire.metalforge.net, i noticed the 'bomb' trap seem broken. I set off one, and nothing happened. Runes of create bomb are ok, though. Summoning runes are broken too. I think there is also a scroll-writing issue. From the code 'write_scroll' in skills.c, there is no check for the spell being written... So you can happily write down sanctuary, or any god-given spell! (i did _not_ succeed in writing one, too low literacy, but i had messages of reading the scroll while attempting to write it. Also the code is pretty straightforward) Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Nov 21 14:58:15 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:40 2005 Subject: [CF-Devel] A few glitches In-Reply-To: <3FBE7377.6030604@laposte.net> References: <3FBE7377.6030604@laposte.net> Message-ID: <1069448295.17036.11.camel@d5110227.lss.emc.com> One other interesting behaviour: I've long noticed that using the destruction spell will trigger nearby traps, but they go off not in their location, but in the caster's location. --PC _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Nov 22 12:25:19 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:40 2005 Subject: [CF-Devel] Skills bugs Message-ID: <3FBFAA0F.8000307@laposte.net> Hello. Found a weird bug today. I was playing in undead's quest, nice training place for a Gaea fellower. So i used holy word a lot, and also paralyze (against vampires). What happened a few times was the following: fire many holy words, get 'Gaea ignores your prayer', switch skills to paralyze (the message 'you ready the spell paralyze' correctly appears), but when i fire i get 'Gaea ignores your prayer' !!! And not once, every time. I have to switch again to paralyze to correctly fire that spell. Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Nov 22 12:30:34 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:40 2005 Subject: [CF-Devel] Forgot one Message-ID: <3FBFAB4A.5050504@laposte.net> Of course forgot to report a bug :) use_skill curse correctly shows cursed items, but won't give any exp... Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 23 04:38:41 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:40 2005 Subject: [CF-Devel] Patch: skill name when learning Message-ID: <3FC08E31.3040100@laposte.net> Here's a patch to fix a small glitch: when learning a skill, the server displays 'type bind ready_skill scroll of ' instead of using the skill's name. Fixed to use the skill's name ('skill') instead of the scroll's name :) Note: patch also fixes a bad windows newline that appeared last time i tweaked the file. Nicolas 'Ryo' -------------- next part -------------- Index: server/apply.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/apply.c,v retrieving revision 1.93 diff -u -r1.93 apply.c --- server/apply.c 11 Nov 2003 07:37:10 -0000 1.93 +++ server/apply.c 23 Nov 2003 10:35:23 -0000 @@ -1481,9 +1481,9 @@ case 1: new_draw_info_format(NDI_UNIQUE, 0,op,"You succeed in learning %s", - tmp->name); + tmp->skill); new_draw_info_format(NDI_UNIQUE, 0, op, - "Type 'bind ready_skill %s",tmp->name); + "Type 'bind ready_skill %s",tmp->skill); new_draw_info(NDI_UNIQUE, 0,op,"to store the skill in a key."); decrease_ob(tmp); return; @@ -1610,7 +1610,7 @@ spell = tmp->inv; if (!spell) { LOG(llevError,"apply_spellbook: Book %s has no spell in it!\n", tmp->name); - new_draw_info(NDI_UNIQUE, 0,op,"The spellbook symbols make no sense."); + new_draw_info(NDI_UNIQUE, 0,op,"The spellbook symbols make no sense."); return; } if (spell->level > (skop->level+10)) { -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 23 05:58:29 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:40 2005 Subject: [CF-Devel] Patch: sense curse / sense magic fix Message-ID: <3FC0A0E5.2090909@laposte.net> The 2 skills 'sense magic' and 'sense curse' don't work on item under the player, as opposed to other identifying skills. Here's a patch to fix that (imo the skills should be coherent & all check ground items). Nicolas 'Ryo' -------------- next part -------------- Index: server/skills.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/skills.c,v retrieving revision 1.43 diff -u -r1.43 skills.c --- server/skills.c 14 Nov 2003 07:53:08 -0000 1.43 +++ server/skills.c 23 Nov 2003 11:54:58 -0000 @@ -513,6 +513,17 @@ esrv_update_item(UPD_FLAGS, pl, tmp); success+= calc_skill_exp(pl,tmp, skill); } + + /* Check ground, too */ + for(tmp=get_map_ob(pl->map,pl->x,pl->y);tmp;tmp=tmp->above) + if (!QUERY_FLAG(tmp,FLAG_IDENTIFIED) && !QUERY_FLAG(tmp,FLAG_KNOWN_CURSED) + && (QUERY_FLAG(tmp,FLAG_CURSED) || QUERY_FLAG(tmp,FLAG_DAMNED)) && + tmp->item_power < skill->level) { + SET_FLAG(tmp,FLAG_KNOWN_CURSED); + esrv_update_item(UPD_FLAGS, pl, tmp); + success+= calc_skill_exp(pl,tmp, skill); + } + return success; } @@ -527,6 +538,16 @@ esrv_update_item(UPD_FLAGS, pl, tmp); success+=calc_skill_exp(pl,tmp, skill); } + + /* Check ground, too */ + for(tmp=get_map_ob(pl->map,pl->x,pl->y);tmp;tmp=tmp->above) + if(!QUERY_FLAG(tmp,FLAG_IDENTIFIED) && !QUERY_FLAG(tmp,FLAG_KNOWN_MAGICAL) + && (is_magical(tmp)) && tmp->item_power < skill->level) { + SET_FLAG(tmp,FLAG_KNOWN_MAGICAL); + esrv_update_item(UPD_FLAGS, pl, tmp); + success+=calc_skill_exp(pl,tmp, skill); + } + return success; } -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 23 03:21:52 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:40 2005 Subject: [CF-Devel] Ingame map 'building' / modification: full patch In-Reply-To: References: Message-ID: <200311231921.52377.won_fang@yahoo.com.au> On Wed, 19 Nov 2003 01:14 am, nicolas.weeger@laposte.net wrote: > > I'll look at adding this stuff to the apartments in my Ice > Castle. > > Well, actually I've again changed & tweaked building stuff... > Current map constraints (flags on walls & floors & such) hold > true, but items & such will change. > So if you want to add a buildable apartment, i suggest you do > a minimum size apartment (like 2 squares), and put > buildable/wall/floor flags where needed, but don't yet use the > items i have in my submitted patch. > > And yes, I should 1) stop changing my building method all the > time 2) finish it & submit it :))) It isn't high on my TODO list, so I am likely to wait until you have finished and submitted it. As for the size, Ice Castle apartments are quite large and luxurious penthouses, complete with staff quarters, running water, and a view. On the other hand, there are also smaller rooms on the other side of the castle that I could convert from inn style rooms to small, buildable apartments. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 24 01:56:51 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:40 2005 Subject: [CF-Devel] Sea access to Navar now open. Message-ID: <200311241756.51653.won_fang@yahoo.com.au> While I'm trying to commit this change (sourceforge seems a little recalcitrant at the moment) I might as well tell you lot about it. I have actually mentioned it before. It worried me that there is a port in Navar with lots of ships that will take you to other places via the sea, yet there is no actual sea access for Navar. The port is on that really big bay, but the bay is completely enclosed by land. Thus the ships must be dragged over land to get there. While there is historical precedent for dragging medium sized ships over land, I though it best if I just opened up a sea passage. Otherwise it would be too easy to keep the pirates out. And we all know that Navar needs it's pirates. In fact, to better support the pirates, we may need to open up a second passage to the sea, but I only did the one. A second passage will make an island out of the land between the two passages. I changed one tile from land to sea in world_126_116 to fix this little problem. I looked around to see if anybody else was building anything in that area, and it looks pristine. I hope that there is nothing that requires walking over that land tile, as now people will have to go the long way around. Damn, I'm still getting timeouts from SF, even though I wasted a lot of time writing more than I needed to in this email B-). So I guess you guys will see it whenever SF gets around to letting me commit. If that isn't this evening, it may have to wait a while. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 24 02:19:30 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:40 2005 Subject: [CF-Devel] Client side improvements In-Reply-To: <1068477494.10733.12.camel@d5110227.lss.emc.com> References: <3FAE62F7.7000109@laposte.net> <3FAEEA67.2040906@sonic.net> <1068477494.10733.12.camel@d5110227.lss.emc.com> Message-ID: <200311241819.30559.won_fang@yahoo.com.au> On Tue, 11 Nov 2003 01:18 am, Preston Crow wrote: > It's now checked in. > > The documentation is mostly in a big comment block at the top of > common/script.c. I'm sure that there's room for improvement, but it > seems to be quite stable and useful for me. Before trying to commit my last map change (still timing out BTW) I updated all the crossfire stuff from cvs. Now the clients won't compile. Lots of errors relating to the new scripting stuff I think. I noticed that common/script.* is actually there, so is it a case of something not committed properly in the scripting area? I quick look suggests to me that common/script.c is not actually being compiled, you probably forgot to commit the make file. Could you please fix it. I hope you have better luck than me committing. I get undefined references to the following - script_fdset script_process script_watch script_monitor_str script_monitor script_kill script_list script_init script_tell script_sync Of course, if this is simply because sourceforge crashed during my last update and I didn't notice, rather than just before I tried committing, you can ignore this B-). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 24 02:48:15 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:40 2005 Subject: [CF-Devel] Client side improvements In-Reply-To: <200311241819.30559.won_fang@yahoo.com.au> References: <3FAE62F7.7000109@laposte.net> <1068477494.10733.12.camel@d5110227.lss.emc.com> <200311241819.30559.won_fang@yahoo.com.au> Message-ID: <200311241848.16154.won_fang@yahoo.com.au> On Mon, 24 Nov 2003 06:19 pm, David Seikel wrote: > all the crossfire stuff from cvs. Now the clients won't compile. Lots of My silly mistake. Remember to run configure when new source files are added via CVS, as that should recreate the make files properly. Back to my regularly scheduled map hacking. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 24 03:33:52 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:40 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: <20031118014656.13761.qmail@web21311.mail.yahoo.com> References: <20031118014656.13761.qmail@web21311.mail.yahoo.com> Message-ID: <200311241933.52699.won_fang@yahoo.com.au> On Tue, 18 Nov 2003 11:46 am, David Seikel wrote: > I have read all the mail about the pros and cons of moving part of the Dark > Forest into the big world. Currently I have just moved the entrance to the > other side of the road, and made the surrounding flora thicker to match the > place it came from. Oh, and changed the wording of the quest in Scorn to > match it's new location. I won't commit these changes just yet, but I will > seriously consider these suggestions and maybe implement some of them, then > commit. With the Dark Forest on the other side of the road, it might make > sense to expand some of it into the big world. I was gonna populate some > of the large forest with some of the critters from the Dark Forest first > level anyway. The above changes have been committed. (Yeah, SF works again!) I also added a bat generator and death tree to the area surrounding the entrance to the Dark Forest, with some ordinary trees to disguise their presence. They don't move about at all, and never attacked me, but i have my suspicions that there is something broken about the monster moving code. I have not fenced them in, since they don't seem to move. Let me know if this is a problem, and I will fence them into the area with the trees. I am slightly worried that the death tree is level 13. However, there is only one of them and the Dark Forest is full of them, so it can act as a warning. Yes, I remembered to change the exit from the Dark Forest to match it's new location. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 24 08:56:34 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:40 2005 Subject: =?iso-8859-1?Q?Re:_[CF-Devel]_Ingame_map_'building'_/_modification:_full_patch?= Message-ID: Actually you can make a 'ready to build' apartment without waiting for my patch to be complete. I need to check some things, work on new map creation, things like that. Just a matter of taking the time, as usual :) Hum, just thought: since I introduced a new flag, 'is_buildable', for building, I don't know how Crossfire would react to seeing that flag in a map without knowing how to use it... ie make a map with that flag, will CF load it without complaining? If yes, you can ready the map. Else well, I'll need to finish it, or at least submit that new flag :) If I smack myself enough, I'll work on building soon. Besides, I can submit a patch without all bells & whistles, building can always be expanded after :) Right now, you can build walls, floors, buttons / doors / pedestals (connected, of course), and any other item doesn't requiring special things (tables, ...) Nicolas 'Ryo' Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 24 10:23:23 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:40 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: <200311241933.52699.won_fang@yahoo.com.au> References: <20031118014656.13761.qmail@web21311.mail.yahoo.com> <200311241933.52699.won_fang@yahoo.com.au> Message-ID: <3FC2307B.4000608@sympatico.ca> > > The above changes have been committed. (Yeah, SF works again!) I also added > a bat generator and death tree to the area surrounding the entrance to the > Dark Forest, with some ordinary trees to disguise their presence. They don't > move about at all, and never attacked me, but i have my suspicions that there > is something broken about the monster moving code. I have not fenced them > in, since they don't seem to move. Let me know if this is a problem, and I > will fence them into the area with the trees. > Maybe it was too dark? The world maps have day/night and sometimes in DM mode you might forget the time (I have had fun figuring that one out too many times :)). Some monsters can't see in the dark and even if they can their detection range is less. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 24 17:31:12 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:41 2005 Subject: [CF-Devel] New Crossfire commands patch. Message-ID: <200311241831.12716.aashenfe@plaind.com> I posted recently in a discussion about client scripting that it would be nice to have more specific versions of apply. Anyway, I thought I would give it a try, but on the server side. One of the best benefits of this is you can stand on an exit with a corpse over it, and use the go command to enter the exit without eating the corpse first. I'm hoping these commands will make the text interface a little more mud like. Also apply still works as it normally would. Here are the new commands. They work like apply, but skip items that don't match the correct type. eat - apply food items drink - apply drinkable items (booze, potions) read - apply readable items enter - apply an exit go - same as enter open - open a container (This doesn't open treasure chests yet) pull - apply lever or trigger push - same as pull activate - same as pull wear - wear somthing that isn't already on (armour,rings etc.) wield - wield something that isn't alread wielded. (weapons,bows etc.) unwear - take off something unwield - stop wielding something sleep - apply bed to reality A couple issues. I wasn't sure if poison should be drinkable or eatable, so it is both. I also made shields wieldable as well as wearable, but in my next patch I think they will be just wearable. I threw this together pretty fast (before work), and there are 2 sections of if statements that probably should be combined into one "if" statement each, or even a separate function. Also, I didn't get a lot of testing in. If anybody can think of any commands that would be nice let me know. I've probably missed a couple item types. Thanks Adam Ashenfelter -------------- next part -------------- A non-text attachment was scrubbed... Name: crossfire.diff Type: text/x-diff Size: 15144 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20031124/a33744aa/crossfire.bin -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 25 00:09:55 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:41 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: <200311241933.52699.won_fang@yahoo.com.au> References: <20031118014656.13761.qmail@web21311.mail.yahoo.com> <200311241933.52699.won_fang@yahoo.com.au> Message-ID: <3FC2F233.1020806@sonic.net> David Seikel wrote: > The above changes have been committed. (Yeah, SF works again!) I also added > a bat generator and death tree to the area surrounding the entrance to the > Dark Forest, with some ordinary trees to disguise their presence. They don't > move about at all, and never attacked me, but i have my suspicions that there > is something broken about the monster moving code. I have not fenced them > in, since they don't seem to move. Let me know if this is a problem, and I > will fence them into the area with the trees. Please remove the bat generator. There should be _no_ generators on the world map. The danger here is that the world tile in question is loaded, but no one really near by, and so those generators spawn potentially hundreds of monsters (or enough to at least by annoying). Note that death trees normally don't move about much as it. But as someone else mentioned, it could be darkness code, or even blocked forest spaces. > > I am slightly worried that the death tree is level 13. However, there is only > one of them and the Dark Forest is full of them, so it can act as a warning. And on the bright side, they don't move very fast either. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 25 00:14:13 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:41 2005 Subject: [CF-Devel] Ingame map 'building' / modification: full patch In-Reply-To: References: Message-ID: <3FC2F335.9060208@sonic.net> nicolas.weeger@laposte.net wrote: > Hum, just thought: since I introduced a new flag, > 'is_buildable', for building, I don't know how Crossfire would > react to seeing that flag in a map without knowing how to use > it... ie make a map with that flag, will CF load it without > complaining? If yes, you can ready the map. Else well, I'll > need to finish it, or at least submit that new flag :) the server should load it, but at the same time, spew out an error message for each such unknown variable in the map. In addition, the flag value is of course stripped off. Which means that when the map is saved, it will be saved without that that flag. this can be confusing in that if you say 'well, you can use it on map XYZ', but you introduced map XYZ a few weeks ago and some people have already entered it/whatever (so it is now their private map), it just won't work. And note that there is no in game way to rid yourself of your personal arpartment, save quit the character. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 25 00:22:21 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:41 2005 Subject: [CF-Devel] New Crossfire commands patch. In-Reply-To: <200311241831.12716.aashenfe@plaind.com> References: <200311241831.12716.aashenfe@plaind.com> Message-ID: <3FC2F51D.9010209@sonic.net> Adam Ashenfelter wrote: > I posted recently in a discussion about client scripting that it would be nice > to have more specific versions of apply. Anyway, I thought I would give it a > try, but on the server side. One of the best benefits of this is you can > stand on an exit with a corpse over it, and use the go command to enter the > exit without eating the corpse first. That's all nice and fine. But I'll state right now I'm not happy about that method - get information about the 'right' way to do it, and then go and do it the method that was not suggested as the way to go. Of course it may work. That isn't really the point. There is lots of code out there that may work, but doesn't belong here or there for various reasons. so I'll state it again - if you want this functionality, do it in the client. I'm not going to bother reviewing the code you attached for those reasons. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 25 02:41:03 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:41 2005 Subject: =?iso-8859-1?Q?Re:_[CF-Devel]_Ingame_map_'building'_/_modification:_full_patch?= Message-ID: I guess then I'll submit my patch soon :) It works pretty well. You can build floors, walls, buttons / pedestals / gates, and potentially any item not requiring special handling. Just need to make artifacts instead of hard-coded archetypes, maybe a shop to buy that stuff, and most important pictures :) Note that I can already submit patches, though you'll need to use DM's create function to make items. Nicolas 'Ryo' Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 25 10:42:48 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:41 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: <3FC2F233.1020806@sonic.net> Message-ID: On 25-Nov-03 Mark Wedel wrote: > The danger here is that the world tile in question is loaded, but no one > really near by, and so those generators spawn potentially hundreds of > monsters > (or enough to at least by annoying). I'm pretty sure the weather might cause this effect.. If it were a remote and untravelled section of the world, chances are they would flood the surrounding tiles. Given time of course. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 25 17:48:31 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:41 2005 Subject: [CF-Devel] New Crossfire commands patch. In-Reply-To: <3FC2F51D.9010209@sonic.net> References: <200311241831.12716.aashenfe@plaind.com> <3FC2F51D.9010209@sonic.net> Message-ID: <200311251848.31713.aashenfe@plaind.com> On Tue November 25 2003 1:22 am, Mark Wedel wrote: > That's all nice and fine. But I'll state right now I'm not happy about > that method - get information about the 'right' way to do it, and then go > and do it the method that was not suggested as the way to go. I'm unsure how to implement this in the client. Most of the client commands seem to be things like save window positions, and bind. Also, the client doesn't seem to have a function along the lines of "find_best_match". All the proper functions to do this stuff is already in the server, so it seemed a little difficult/wasteful to do it in the client. Besides, it was simpler to do it in the server, thats probably why I figured out how to do it. > Of course it may work. That isn't really the point. There is lots of code >out there that may work, but doesn't belong here or there for various >reasons. Anyway, it works for me. I cleaned up the code a little more, and figured out how to use diff -c in cvs, so if anybody is interested, the code is attached. Thanks Adam Ashenfelter -------------- next part -------------- A non-text attachment was scrubbed... Name: crossfire.diff Type: text/x-diff Size: 15026 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20031125/a90f079c/crossfire.bin -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Nov 26 09:18:45 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:41 2005 Subject: [CF-Devel] New Crossfire commands patch. In-Reply-To: <200311251848.31713.aashenfe@plaind.com> References: <200311241831.12716.aashenfe@plaind.com> <3FC2F51D.9010209@sonic.net> <200311251848.31713.aashenfe@plaind.com> Message-ID: <1069859924.25689.9.camel@d5110227.lss.emc.com> On Tue, 2003-11-25 at 18:48, Adam Ashenfelter wrote: > I'm unsure how to implement this in the client. Most of the client commands > seem to be things like save window positions, and bind. Also, the client > doesn't seem to have a function along the lines of "find_best_match". All > the proper functions to do this stuff is already in the server, so it seemed > a little difficult/wasteful to do it in the client. Besides, it was simpler > to do it in the server, thats probably why I figured out how to do it. I tend to agree that some functionality along those lines would be best in the server, but I think you took it too far. Multiple commands with the same purpose? Actually, all I would like to see in the server is an "apply_below" command, which would work exactly like the "apply" command, only it would consider objects that you are on top of instead of in your inventory. (Well, and perhaps an "apply_container" command to apply something in an open container.) A few commands have options like Unix command-line flags, so it could be done with flags on the normal apply command, but my instinct is that separate commands are less confusing. Of course, if you really want to do it in the client, you could write a script with my new scripting interface. :) --PC _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Nov 26 13:01:18 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:41 2005 Subject: [CF-Devel] New Crossfire commands patch. In-Reply-To: <1069859924.25689.9.camel@d5110227.lss.emc.com> References: <200311241831.12716.aashenfe@plaind.com> <200311251848.31713.aashenfe@plaind.com> <1069859924.25689.9.camel@d5110227.lss.emc.com> Message-ID: <200311261401.18394.aashenfe@plaind.com> On Wed November 26 2003 10:18 am, Preston Crow wrote: > I tend to agree that some functionality along those lines would be best > in the server, but I think you took it too far. Multiple commands with > the same purpose? Actually, all I would like to see in the server is an > "apply_below" command, which would work exactly like the "apply" > command, only it would consider objects that you are on top of instead > of in your inventory. (Well, and perhaps an "apply_container" command > to apply something in an open container.) Darn, I always take things too far. The commands don't have exactly the same purpose, you can't "pull" on a food item and expect to "eat" it. I bound a key to the "go" command, and I use it on exits (I haven't eaten a corpse since :) ). Also "wear, wield, unwear, unwield" are kind of nice since they they check the item ready state with -no -shell -like -flags. As far as the "apply_below" command, why do we need a new command for this? Just have the normal "apply" commands check below the player or in the current open container. The inventory would be checked first, and thus items from there would be applied first. I was thinking of trying this in the new commands. > A few commands have options like Unix command-line flags, so it could be > done with flags on the normal apply command, but my instinct is that > separate commands are less confusing. I don't think -flags or _'s are apropriate for a game. The crossfire command interface should be more natural language like, thus the new commands. Is it more nature to say "open sack", or "apply sack"? > Of course, if you really want to do it in the client, you could write a > script with my new scripting interface. :) > --PC > > Maybe the new commands would be helpful in the scripting interface?? Thanks Adam Ashenfelter _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Nov 28 02:02:47 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:41 2005 Subject: [CF-Devel] New Crossfire commands patch. In-Reply-To: <200311261401.18394.aashenfe@plaind.com> References: <200311241831.12716.aashenfe@plaind.com> <200311251848.31713.aashenfe@plaind.com> <1069859924.25689.9.camel@d5110227.lss.emc.com> <200311261401.18394.aashenfe@plaind.com> Message-ID: <3FC70127.508@sonic.net> Several notes: There is a lot of stuff currently in the server that arguably doesn't belong there, and a lot of the current apply logic is such a case. Remember, at one time, there wasn't a client/server model, but when one was made, all that code wasn't pulled out. So while there may be a lot of apply logic in the current server, it doesn't mean I want to see even more of it. Doing it on the client is in fact simpler in many ways - since the client is untrusted, it basically means you can process all the data the client knows about - you don't need to worry about floor processing, or 'does the player know about that bit of information' - if the client knows about it, it means the player knows about it. and in that regard, doing this in the client is quite easy - all the bits of data are there - client_type to know the type of object. Name of the object. You'd need to make up an item_matched_string function, but that would be pretty simple, simply because there are not as many cases to deal with. There is already a protocol command to say to apply a specific item. So once you figure out the tag of the item, simple matter of sending that protocol command. As said before, if you want to see this stuff committed into CVS, it will have to be done in the client. I care a lot less about code going into the client - maintaining it and keeping it bug free is much less important (IMO) for client side code than server side code. Now there are some things that simply can't be done in the client. But this is not one of them. Note there already is an 'inv' command on the client that dumps the player inventory. And the arguement that 'there aren't a lot of command like this on the client' is basically meaningless. If that arguement is used, then there will never be any such commands added to the client (no one takes the first step). Note it is also very easy to add pseudo bindings to commands on the client. Eg, if the player types 'eat', it can then do something like 'apply -t eat' to the server. However, that is more a point of referance, as that isn't what should be done in this case. What should be done in this case is really quite simple: Move the commands the client. The client can find the appropriate item type based on the client_id types, and then send the apply protocol command for that item. It really isn't going to be any harder to do it in the client than the server. And it belongs in the client. I'd note that if the 'apply' command was removed from the server when the client was split off, such that the client handled item matching for apply, there wouldn't be this discussion right now - it would have been obvious that the client was the correct place for this code. As said above, there is still a lot of code in the server which really should be in the client, and probably at some point would be. I don't want to see more code getting added to the server that would eventually need to get moved to the client anyways. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Nov 28 12:47:45 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:41 2005 Subject: [CF-Devel] Patch: collect_images.pl Message-ID: <3FC79851.6090101@laposte.net> Hello. Just a small patch to make lib/adm/collect_images.pl work under Windows. Basically just force the file mode to 'binary' using 'binarymode' (apparently Windows's default mode is not binary :)) Nicolas 'Ryo' -------------- next part -------------- Index: lib/adm/collect_images.pl =================================================================== RCS file: /cvsroot/crossfire/crossfire/lib/adm/collect_images.pl,v retrieving revision 1.6 diff -u -r1.6 collect_images.pl --- lib/adm/collect_images.pl 13 Sep 2003 05:02:06 -0000 1.6 +++ lib/adm/collect_images.pl 28 Nov 2003 18:44:26 -0000 @@ -55,6 +55,7 @@ $fh = $ESRV[$count]; open($fh, ">crossfire.$count") || die("Can't open crossfire.$count for write: $!\n"); + binmode( $fh ); } open(BMAPS,"bmaps.paths") || die("Can't open bmaps.paths: $!\n"); @@ -84,6 +85,7 @@ $length = -s "$filename"; if (open(FILE,"$filename")) { + binmode( FILE ); print $fh "IMAGE $num $length $file.$file1\n"; print "Error reading file $filename" if (!read(FILE, $buf, $length)); $position = tell $fh; -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Nov 28 12:58:51 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:41 2005 Subject: [CF-Devel] Patch: collect_images.pl In-Reply-To: <3FC79851.6090101@laposte.net> References: <3FC79851.6090101@laposte.net> Message-ID: <20031128185851.GA9186@crystal> On Fri, Nov 28, 2003 at 07:47:45PM +0100, Nicolas Weeger wrote: > Hello. > Just a small patch to make lib/adm/collect_images.pl work under Windows. > Basically just force the file mode to 'binary' using 'binarymode' > (apparently Windows's default mode is not binary :)) [snip] The basic problem is that Windows differentiates between text files (translate between \n and \r\n) and binary files, whereas UNIX doesn't. So "text mode" works just fine on binary files in UNIX, but breaks horribly under Windows (anything resembling \r\n gets mangled on read, and all \n gets mangled on write). Perl uses text mode by default, which is fine for UNIX, but breaks on Windows when you manipulate binary files. T -- Spaghetti code may be tangly, but lasagna code is just cheesy. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Nov 28 14:51:39 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:42 2005 Subject: [CF-Devel] Patch: collect_images.pl In-Reply-To: <20031128185851.GA9186@crystal> References: <3FC79851.6090101@laposte.net> <20031128185851.GA9186@crystal> Message-ID: <3FC7B55B.1070409@laposte.net> > The basic problem is that Windows differentiates between text files > (translate between \n and \r\n) and binary files, whereas UNIX doesn't. So > "text mode" works just fine on binary files in UNIX, but breaks horribly > under Windows (anything resembling \r\n gets mangled on read, and all \n > gets mangled on write). Perl uses text mode by default, which is fine for > UNIX, but breaks on Windows when you manipulate binary files. Ok, but does forcing binary mode, as my patch does, break under UNIX? Besides, for crossfire.[01] containing the whole PNGs, it's just weird to use TEXT mode, and not binary mode, even if it happens to work under UNIX :) > T Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Nov 28 15:24:16 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:42 2005 Subject: [CF-Devel] Patch: collect_images.pl In-Reply-To: <3FC7B55B.1070409@laposte.net> References: <3FC79851.6090101@laposte.net> <20031128185851.GA9186@crystal> <3FC7B55B.1070409@laposte.net> Message-ID: <20031128212416.GA10234@crystal> On Fri, Nov 28, 2003 at 09:51:39PM +0100, Nicolas Weeger wrote: > >The basic problem is that Windows differentiates between text files > >(translate between \n and \r\n) and binary files, whereas UNIX doesn't. So > >"text mode" works just fine on binary files in UNIX, but breaks horribly > >under Windows (anything resembling \r\n gets mangled on read, and all \n > >gets mangled on write). Perl uses text mode by default, which is fine for > >UNIX, but breaks on Windows when you manipulate binary files. > > Ok, but does forcing binary mode, as my patch does, break under UNIX? > Besides, for crossfire.[01] containing the whole PNGs, it's just weird to > use TEXT mode, and not binary mode, even if it happens to work under > UNIX :) [snip] As I said, under UNIX there is no difference at all between text and binary mode, so it doesn't break anything. T -- The way software works is not the same as the way it's *supposed* to work. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Nov 28 17:03:03 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:42 2005 Subject: [CF-Devel] Patch: map building, hopefully the stable one :) Message-ID: <3FC7D427.1080004@laposte.net> Hello. I finally finished basic map building stuff in a 'decent' way, so here it is :) Attached archive includes: * build.patch: patch for the code * build_map.c: new file, to be put into server/ subdirectory (or elsewhere, as long as you build it :) * mapbuilding: subdir that goes somewhere in your arch/ folder * apartments: modified version of Scorn's apartment * buildshop: hacked alchemy shop from Scorn for building material. Made to be linked from the shop just west of potions/alchemy shop I leave to you the procedure to patch & rebuild archs & thus. Note: my patch will not change autoconf/makefiles/... to build build_map.c, you may need to add it. Also, I didn't find how the 'artifacts' file is generated, so i just patched it directly (from /lib). To test the patch, you need to have a unique map with the correct flags: set 'is_buildable' (new flag) to all walls/floors the player will be able to build on. For those squares, set the type for walls to 'WALL' (type 77), floors to 'FLOOR' (71). Put the flag, without the 'is_buildable', on walls around the buildable zone (needed for correct wall connection, but not critical per se). Best way to quick preview is to use my modified apartment :) (south walls after extender are buildable, gold & diamonds included for faster testing) How building works ingame: You need a 'generic builder' (archetype 'building_builder'), and 'material of ' (archetype 'building_material' + artifact. Don't know how to create an artifact, btw). Either get'em from the shop (if you installed it), or switch to dm mode & create some. The builder acts like a range attack. You then need to 'mark the material you want to use. Right now, there are artifacts for: wood floor, basic wall, horizontal & vertical gate, pedestal, lever/button. Then it's a matter of firing in the desired direction :) Obviously one material is used per firing. Note: I patched the 'examine' command to add a message when something is buildable, to make it easy to see squares where it's allowed. Building is currently allowed: in unique maps only, not on the map's edges (as defined by the map's size, not the squares where the player can go), not under yourself, only on squares where all items have the 'is_buildable' flag set. Only exception is that you can build on marking runes, as they are used for some things. Floor building: you can build a floor on a wall, or existing floor. On a wall will remove existing wall, create walls and floor around affected square if required, and make sure walls are correctly connected. If walls are inserted, they will take the archetype of the removed wall, and also have a floor underneath (with your new archetype). Building on a square without a wall will simply replace the floor. You can replace even if there are items, as long as they are buildable. Wall building: you can build a wall on an existing wall, or a floor without any item. In both cases the affected square will end with a wall of the archetype defined in your marked material. Items requiring a connection (buttons, pedestals, gates, more later on maybe): before building, write a 'marking rune' on the target square. Put any name you want, then build the gate / lever / pedestal. All items built on a rune with the same name will be connected, thus act together. Pedestals are inserted below ground. All other items (none at present... feel free to tweak 'slaying' field of your material): just build :) To remove items: you need a 'generic destroyer' (archetype 'building_destroyer'), to be found in the shop. It will remove the first item starting from below, thus first pedestals (underground), then buttons, and so on. It will not remove walls. How it is implemented in the code: Three archetypes are defined: * building_builder * building_destroyer * building_material: 'abstract' archetype, must be associated with an artifact Builder & destroyer use the new type '160', with subtypes to distinguish (resp. 1 & 2). Material uses new type '161', with subtypes for: floor, wall, all other items. 'slaying' field is the built archetype. If ( Str == 1 ), item will be inserted below floor. Items of type 160 act as range attack, so the code has been tweaked for that. Also, 'treasure.c' has been changed to force the artifact generation for 'building_material' archetype (ie item type 161). When applying a 'builder'/'destroyer', sanity checks are done: unique map, not on map edge, not under yourself, the affected square is buildable (AND has valid object on it, just in case). If it's a 'destroyer', special function is called to remove the first object it finds. For builders, there are 3 functions: for walls, for floors, for all items. This last function creates built item, and uses its type field for special cases like gate, button (requiring a 'connection' to work properly). For connection values, the 'message' on the marking rune is checked. If it's been previously seen, returns the value associated. Else find a free connection value (1000 random retries, then failure), and store it as a 'force' in the player's inventory. The force's 'slaying' will contain the map path (to avoid conflicts between maps), 'msg' the name and 'path_attuned' the connection value. There are some helper functions, I think comments are good enough to understand what they do. Pics I made. Hammer & stove (hum, not sure that's the correct name, oh well) I digital camera'd & tweaked, other pics are built item's pic + stove's pic :) Also, prices and weights may need some adjustements. Random notes: * all inserted items get the 'is_buildable' flag * when inserting a floor, it gets the 'is_unique' flag * when removing a wall, walls around WITHOUT the 'is_buildable' flag may be affected, for correct visual connection. Flags are preserved, so hopefully isn't an issue. This is also why the 'WALL' type must be set around intended build area * 'generic' items get also the 'no_pick' flag * I think errors are checked, but some log messages may be missing (invalid archetype in 'slaying' field, stuff like that) * I may have requested a connection value for too many items (DOOR? CF_HANDLE?), it may need to be corrected Warning: the Scorn modified apartment is intended for demonstration purposes only. As it is currently, if a player builds east then north, towards the 'blocking view' items, s/he'll be able to build floors right next to this blocking view, thus stand on a square with a blocking view on the adjacent square. Probably not harmful, but not something we'd want. Also player could access the key for Pupland by building. There may be flaws/bugs in the code. I tested and it seems ok, but nobody's perfect, and it's well known that the one developing usually tests in a certain way so it works, but the first one to test without knowing how it's supposed to work will find The Big And Fatal Flaw (c) so obvious that the developer will smack his head wondering how he could have missed it :) Future improvements will, in a perfect world, include: * more artifacts, more things to build (potentially anything, adding special cases here and there when needed) * doors & keys, detectors with some special things (for access control, for instance) * teleporters, either to existing places OR to new maps * maybe magic mouths/ears * and why not monsters & such :) * also in stock player-owned shops, where others players could buy/sell * ability to change walls on map edge I do plan, at some point, to let people build maps others could go into. So the check for map's uniqueness could go at some point, or be conditioned by a flag / value in a certain field (to prevent building some things in non-unique maps, or in unique maps). (those are ideas that may or may not be implemented in the near or far future :)) Have fun testing, and thank you for reading everything ^_- Nicolas 'Ryo' -------------- next part -------------- A non-text attachment was scrubbed... Name: build.tar.gz Type: application/x-gzip-compressed Size: 18698 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20031129/8a77b5c3/build.tar.bin -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Nov 28 18:49:12 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:42 2005 Subject: [CF-Devel] New Crossfire commands patch. In-Reply-To: <3FC70127.508@sonic.net> References: <200311241831.12716.aashenfe@plaind.com> <200311261401.18394.aashenfe@plaind.com> <3FC70127.508@sonic.net> Message-ID: <200311281949.12953.aashenfe@plaind.com> On Fri November 28 2003 3:02 am, Mark Wedel wrote: > Several notes: > > There is a lot of stuff currently in the server that arguably doesn't > belong there, and a lot of the current apply logic is such a case. > One of the main disadvantages I see with putting these commands in the client is that there will be a lot more chances to break compatibility with the client. Lets say for instance we implement the new commands in the client. Then later on we create a new type of wearable item. Say a mask or whatever. Then "wear" and "unwear" would be broken in the clients for masks. Or a new flag "not owner" or something like that. Now "eat food" would not know to avoid food items my player doesn't own (a client side "apply" would also be broken in this case"). I can think of a lot more examples. Note: If the new commands should be in the client, then eventualy "get", "drop", and "apply" should be in the client as well, and would result in similar problems. What we would really be moving to the client would be a string match, and a type check for each candidate item. The server still needs to verify that we can (apply, drop, get) the item or we open up a lot of cheats. If what you really want to do, is offload this matching work to the client, then this is what I think should be done. 1. Client preparses command, and decides which item should be the target of the command. 2. The client sends the full command to the server and the item tag of the item that should be the target of the item. 3. The server receives the command and checks the client version. 4. If the client is new enough to handle this command, call the command with the item tag, if not reparse the string to make the correct decision. (The logic stays, but it is run less often) Thanks Adam Ashenfelter _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Nov 28 20:19:14 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:42 2005 Subject: [CF-Devel] Patch: collect_images.pl In-Reply-To: <20031128212416.GA10234@crystal> References: <3FC79851.6090101@laposte.net> <20031128185851.GA9186@crystal> <3FC7B55B.1070409@laposte.net> <20031128212416.GA10234@crystal> Message-ID: <3FC80222.9070204@sonic.net> H. S. Teoh wrote: > On Fri, Nov 28, 2003 at 09:51:39PM +0100, Nicolas Weeger wrote: > >>>The basic problem is that Windows differentiates between text files >>>(translate between \n and \r\n) and binary files, whereas UNIX doesn't. So >>>"text mode" works just fine on binary files in UNIX, but breaks horribly >>>under Windows (anything resembling \r\n gets mangled on read, and all \n >>>gets mangled on write). Perl uses text mode by default, which is fine for >>>UNIX, but breaks on Windows when you manipulate binary files. >> >>Ok, but does forcing binary mode, as my patch does, break under UNIX? >>Besides, for crossfire.[01] containing the whole PNGs, it's just weird to >>use TEXT mode, and not binary mode, even if it happens to work under >>UNIX :) > > [snip] > > As I said, under UNIX there is no difference at all between text and > binary mode, so it doesn't break anything. > Yep - I don't see any issue with commiting that patch. It should have no effect on the unix side of things. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Nov 28 20:29:15 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:43 2005 Subject: [CF-Devel] New Crossfire commands patch. In-Reply-To: <200311281949.12953.aashenfe@plaind.com> References: <200311241831.12716.aashenfe@plaind.com> <200311261401.18394.aashenfe@plaind.com> <3FC70127.508@sonic.net> <200311281949.12953.aashenfe@plaind.com> Message-ID: <3FC8047B.7030909@sonic.net> Adam Ashenfelter wrote: > On Fri November 28 2003 3:02 am, Mark Wedel wrote: > One of the main disadvantages I see with putting these commands in the client > is that there will be a lot more chances to break compatibility with the > client. > > Lets say for instance we implement the new commands in the client. Then later > on we create a new type of wearable item. Say a mask or whatever. Then > "wear" and "unwear" would be broken in the clients for masks. Or a new flag > "not owner" or something like that. Now "eat food" would not know to avoid > food items my player doesn't own (a client side "apply" would also be broken > in this case"). I can think of a lot more examples. That is sort of a straw case argument. If you add a new type, the server code would similarly need to be updated. In fact, given that the client uses the client_type field, it will actually work better. Look at the doc/Developers/objects, then specifically the client_type information. Client_types are put into broad numbers. Excerpt from that file: 270-279 Headwear (34) 270 artifact helmets (34) 271 Helmets (34) 272 turbans (34) 273 wigs (34) 275 eyeglasses (34) So suppose you add a new object - mask. you give it client type 276, and it works fine, because the client would know that objects in the 270-279 range are headware type items. > > Note: If the new commands should be in the client, then eventualy "get", > "drop", and "apply" should be in the client as well, and would result in > similar problems. Yep - those should be all client side also. Note that right now, if you apply an object in your inventory by clicking on it, the client sends the 'apply' protocol command, which is different than if you type apply. With that protocol command, it only sends the object id. The server then finds that object and makes sure it is something the client can apply (eg, in the players inventory, or on the same space). That sanity checking code is already in place (otherwise, a hacked client could try to apply items of tags that don't belong to it). Note also that if you click something to drop, a protocol command (moveitem I believe) is used to drop the objbect. It doesn't call the same drop that a player might type in. And same thing - the server does sanity checking to make sure it is something that can be dropped (not equipped, not locked, in the players inventory, etc). And all this code works just fine obviously. So if you did the client side apply, like I suggest, the server already has the code to do the sanity checking. > > What we would really be moving to the client would be a string match, and a > type check for each candidate item. The server still needs to verify that > we can (apply, drop, get) the item or we open up a lot of cheats. And as said, the server already has code in to make sure the object is something the player can deal with. > > If what you really want to do, is offload this matching work to the client, > then this is what I think should be done. > > 1. Client preparses command, and decides which item should be the target of > the command. > 2. The client sends the full command to the server and the item tag of the > item that should be the target of the item. > 3. The server receives the command and checks the client version. > 4. If the client is new enough to handle this command, call the command with > the item tag, if not reparse the string to make the correct decision. (The > logic stays, but it is run less often) Don't need to do any of that - built in apply command that only takes an item tag is already in the protocol, and already extensively used. So all you need to do is #1 - steps 2->4 are already done or not needed. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Nov 29 06:34:32 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:43 2005 Subject: [CF-Devel] Documenting the code, and cleaning warnings Message-ID: <3FC89258.4010801@laposte.net> Hello. Mark & I discussed the pros & cons of doing some code cleaning (mostly fixing types, like using short and not an int when a function expects a short, stuff like that). The result is that he doesn't mind cleaning, as long as I (or anyone else, for that matter) don't break anything. So I will slowly clean the code, and submit patches now & then. Since I'll skim part of the code, I feel like taking the time to put a few comments when a function doesn't have any. Would anyone mind if I wrote in doxygen-style? Or if I changed existing comments to be doxygen-usable? Basically, the doxygen style looks like: /** * Fixes walls around specified spot * * \param map is the map * \param x * \param y are the position to fix * * Basically it ensures the correct wall is put where needed. * * Note: x & y must be valid map coordinates. */ void fix_walls( struct mapdef* map, int x, int y ) First line is a brief description, rest should be easy to guess... This can be used to make 'nice' html/latex/other format documentation. Of course parameters & return values are not mandatory, though sometimes it's better to explain'em. What does everyone think? And no, I don't expect everyone to write comments like that, just saying I dont mind modifying existing ones to make documentation :) Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Nov 29 21:34:51 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:43 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: <3FC2307B.4000608@sympatico.ca> References: <20031118014656.13761.qmail@web21311.mail.yahoo.com> <200311241933.52699.won_fang@yahoo.com.au> <3FC2307B.4000608@sympatico.ca> Message-ID: <200311301334.52152.won_fang@yahoo.com.au> On Tue, 25 Nov 2003 02:23 am, Todd Mitchell wrote: > Maybe it was too dark? The world maps have day/night and sometimes in DM > mode you might forget the time (I have had fun figuring that one out too > many times :)). Some monsters can't see in the dark and even if they can > their detection range is less. One would assume that bats can see in the dark B-). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Nov 29 21:39:56 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:43 2005 Subject: [CF-Devel] Large forest in big world. In-Reply-To: <3FC2F233.1020806@sonic.net> References: <20031118014656.13761.qmail@web21311.mail.yahoo.com> <200311241933.52699.won_fang@yahoo.com.au> <3FC2F233.1020806@sonic.net> Message-ID: <200311301339.56651.won_fang@yahoo.com.au> On Tue, 25 Nov 2003 04:09 pm, Mark Wedel wrote: > Please remove the bat generator. Done. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Nov 29 23:08:39 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:43 2005 Subject: [CF-Devel] Documenting the code, and cleaning warnings In-Reply-To: <3FC89258.4010801@laposte.net> References: <3FC89258.4010801@laposte.net> Message-ID: <3FC97B57.6000508@sonic.net> Nicolas Weeger wrote: > > What does everyone think? > And no, I don't expect everyone to write comments like that, just saying > I dont mind modifying existing ones to make documentation :) I don't really mind the comments in that style. Note that for any functions/comments you do update, please make sure that they are accurate (I think they currently all are, but I could see if they were convereted to doxygen style, you are effectingly adding a timestamp of 'this comment was modified after 12/2003', and people would probably expect them to be more accurate, vs commentst hat might not have been modified in many years. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Nov 29 23:55:41 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:43 2005 Subject: [CF-Devel] A few glitches In-Reply-To: <3FBE7377.6030604@laposte.net> References: <3FBE7377.6030604@laposte.net> Message-ID: <3FC9865D.1000106@sonic.net> Nicolas Weeger wrote: > Hello. > > Playing on crossfire.metalforge.net, i noticed the 'bomb' trap seem > broken. I set off one, and nothing happened. Runes of create bomb are > ok, though. Summoning runes are broken too. Well, I just tried this out, and all seemed to work ok. I had made some changes to the summoning runes a little while back - possible that I hadn't updated that server. But the bomb stuff seems to be unchanged, yet I made a simple test map, put a chest there with a rune of create bomb in it, and sure enough, if I opened it, the bomb was created. > > I think there is also a scroll-writing issue. From the code > 'write_scroll' in skills.c, there is no check for the spell being > written... So you can happily write down sanctuary, or any god-given spell! > (i did _not_ succeed in writing one, too low literacy, but i had > messages of reading the scroll while attempting to write it. Also the > code is pretty straightforward) That is correct, and intentional. Since we currently only allow scrolls to be written (not spellbooks), this isn't that abusive. But the reason is more that it is much more difficult with the new spell code to tell if a spell is a special spell or not. In the old code, spells were just a table, and so very easy to tell the properties of a given spell (Eg, spell 56 may be cleric, and not normally found in scrolls, so disallow). The only way to really try and do that now days would be to traverse the treasurelists for the scroll and see if the spell in question shows up anyplace - if not, must be a special spell. OR alternatively, a flag could be used, like 'not_inscribable', and add that to the archs. But the question I guess really, is do people see this as being much an issue? I personally thought it may add some more player interaction (players trading scrolls back and forth for spells they normally could not get). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 30 00:41:51 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:43 2005 Subject: [CF-Devel] A few glitches In-Reply-To: <3FC9865D.1000106@sonic.net> References: <3FBE7377.6030604@laposte.net> <3FC9865D.1000106@sonic.net> Message-ID: <200311301641.52102.won_fang@yahoo.com.au> On Sun, 30 Nov 2003 03:55 pm, Mark Wedel wrote: > The only way to really try and do that now days would be to traverse the > treasurelists for the scroll and see if the spell in question shows up > anyplace - if not, must be a special spell. > > OR alternatively, a flag could be used, like 'not_inscribable', and add > that to the archs. > > But the question I guess really, is do people see this as being much an > issue? I personally thought it may add some more player interaction > (players trading scrolls back and forth for spells they normally could not > get). Remembering the flak I got when using special spells in my maps, I vote for having some real way of telling them apart. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 30 03:05:22 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:43 2005 Subject: [CF-Devel] Documenting the code, and cleaning warnings In-Reply-To: <3FC97B57.6000508@sonic.net> References: <3FC89258.4010801@laposte.net> <3FC97B57.6000508@sonic.net> Message-ID: <3FC9B2D2.60307@laposte.net> > I don't really mind the comments in that style. > > Note that for any functions/comments you do update, please make sure > that they are accurate (I think they currently all are, but I could see > if they were convereted to doxygen style, you are effectingly adding a > timestamp of 'this comment was modified after 12/2003', and people would > probably expect them to be more accurate, vs commentst hat might not > have been modified in many years. Sounds like a good idea, I'll make sure to follow that advice. I don't think anyone would mind if I commited comment changes directly without sending patches to mailing list? Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 30 03:03:38 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:43 2005 Subject: [CF-Devel] A few glitches In-Reply-To: <3FC9865D.1000106@sonic.net> References: <3FBE7377.6030604@laposte.net> <3FC9865D.1000106@sonic.net> Message-ID: <3FC9B26A.1010804@laposte.net> > Well, I just tried this out, and all seemed to work ok. > > I had made some changes to the summoning runes a little while back - > possible that I hadn't updated that server. But the bomb stuff seems to > be unchanged, yet I made a simple test map, put a chest there with a > rune of create bomb in it, and sure enough, if I opened it, the bomb was > created. I'll check bombs go off correctly next time i find a create bomb trap :) > That is correct, and intentional. > > Since we currently only allow scrolls to be written (not spellbooks), > this isn't that abusive. Hum, one could write a whole lot of scrolls, and that may give too many advantages to players... You could have scrolls of every special god's spell, some being pretty useful. Gaea's nightfall, for instance, you need many all right, but it's too easy, with let's say 10 per level, to destroy any level. Granted, that's a high level spell, so it'd take a while to write'em :) > But the reason is more that it is much more difficult with the new > spell code to tell if a spell is a special spell or not. In the old > code, spells were just a table, and so very easy to tell the properties > of a given spell (Eg, spell 56 may be cleric, and not normally found in > scrolls, so disallow). > > The only way to really try and do that now days would be to traverse > the treasurelists for the scroll and see if the spell in question shows > up anyplace - if not, must be a special spell. > > OR alternatively, a flag could be used, like 'not_inscribable', and add > that to the archs. Couldn't we use some unused field in the arthetype? Like 'weight', which probably isn't used for spells themselves? > But the question I guess really, is do people see this as being much an > issue? I personally thought it may add some more player interaction > (players trading scrolls back and forth for spells they normally could > not get). True, could be fun, one could make a whole lot of money :) Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 30 03:39:11 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:44 2005 Subject: [CF-Devel] A few glitches In-Reply-To: <3FC9865D.1000106@sonic.net> References: <3FBE7377.6030604@laposte.net> <3FC9865D.1000106@sonic.net> Message-ID: <3FC9BABF.3010400@laposte.net> Just found a rune of create bomb, set it off, no bomb... Maybe it's because crossfire.metalforge.net isn't up to date. Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 30 11:26:44 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:44 2005 Subject: [CF-Devel] Bug: dragon claws attack Message-ID: <3FCA2854.8050504@laposte.net> Hello. Just noticed, dragon don't have anymore fire/electric/cold/poison claws... I supposedly have fire and electric and poison, but still perceive self says only 'physical' as attack type... Nicolas 'Ryo' _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 30 19:52:58 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:44 2005 Subject: [CF-Devel] A few glitches In-Reply-To: <3FC9B26A.1010804@laposte.net> References: <3FBE7377.6030604@laposte.net> <3FC9865D.1000106@sonic.net> <3FC9B26A.1010804@laposte.net> Message-ID: <3FCA9EFA.1030204@sonic.net> Nicolas Weeger wrote: > > Hum, one could write a whole lot of scrolls, and that may give too many > advantages to players... You could have scrolls of every special god's > spell, some being pretty useful. Gaea's nightfall, for instance, you > need many all right, but it's too easy, with let's say 10 per level, to > destroy any level. Granted, that's a high level spell, so it'd take a > while to write'em :) nightfall might not be the best example. Because it is a spell with no duration, currently a player can already do that right now (cast as many nightfalls as you can, leave the map, pray, go back on the map and cast nightfall until completely dark). One could argue this is more a problem with the nightfall spell than the fact it can be put on scrolls. But certainly there are other spells where having a bunch might be a problem. It's my belief that all the special spells should still be balanced - they can be a bit more powerful, but it shouldn't be the case that the spell is twice as good (however you can quantitatively measure spells) than something else. Rather, they are special in that you only get them if you worship the appropriate god or do the appropriate quest. So having them in scroll form shouldn't really be a lot more abusive, unless the spell right now is out of balance. > Couldn't we use some unused field in the arthetype? Like 'weight', which > probably isn't used for spells themselves? Using unused fields is always problematic - first, its confusing. But more so, what is an unused field right now might become a used field later on. So its better to just set up an appropriate flag - easier to understand, and no worry down the road. Now at least for god given spells, I realized that it is easy to know if they were god given or normally learned. So it wouldn't be hard to make it so you can't inscribe god given spells. But something different, like a flag, would need to be added for those. Note also that with the new spell code, it is very easy to make spell derivations (it just a change in the object you put in a spellbook or the like). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 30 19:53:30 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:44 2005 Subject: [CF-Devel] Documenting the code, and cleaning warnings In-Reply-To: <3FC9B2D2.60307@laposte.net> References: <3FC89258.4010801@laposte.net> <3FC97B57.6000508@sonic.net> <3FC9B2D2.60307@laposte.net> Message-ID: <3FCA9F1A.4070701@sonic.net> Nicolas Weeger wrote: >> I don't really mind the comments in that style. >> >> Note that for any functions/comments you do update, please make sure >> that they are accurate (I think they currently all are, but I could >> see if they were convereted to doxygen style, you are effectingly >> adding a timestamp of 'this comment was modified after 12/2003', and >> people would probably expect them to be more accurate, vs commentst >> hat might not have been modified in many years. > > > Sounds like a good idea, I'll make sure to follow that advice. > I don't think anyone would mind if I commited comment changes directly > without sending patches to mailing list? > I don't think anyone would mind. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 30 22:55:20 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:44 2005 Subject: [CF-Devel] A few glitches In-Reply-To: <1069448295.17036.11.camel@d5110227.lss.emc.com> References: <3FBE7377.6030604@laposte.net> <1069448295.17036.11.camel@d5110227.lss.emc.com> Message-ID: <3FCAC9B8.5000207@sonic.net> Preston Crow wrote: > One other interesting behaviour: > > I've long noticed that using the destruction spell will trigger nearby > traps, but they go off not in their location, but in the caster's > location. I'm taking this to be that these are traps on doors? That's the only way I can see that happening. If that's the case, then the question might should - should destruction destroy doors? But looking at the code, it would seem the same thing would happen if you hit the doors with arrows, or any other range attack - the spring attack code just takes the trap and puts it where the plaeyr is, which is certainly a bug. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 30 23:34:59 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:44 2005 Subject: [CF-Devel] Forgot one In-Reply-To: <3FBFAB4A.5050504@laposte.net> References: <3FBFAB4A.5050504@laposte.net> Message-ID: <3FCAD303.2030709@sonic.net> Nicolas Weeger wrote: > Of course forgot to report a bug :) > use_skill curse correctly shows cursed items, but won't give any exp... I just tried this, and it worked for me. Note that you don't get a whole bunch of exp for sensing cursed items. So may be difficult you noticed. Also note that the exp reward will pretty much always be in multiples of 5. Which than also makes it more likely that you could get an even number of exp (100, 200, etc), and thus last two digits might not change, but the hundreds place did change, which may not be as noticable. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 30 23:41:31 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:44 2005 Subject: [CF-Devel] Bug: dragon claws attack In-Reply-To: <3FCA2854.8050504@laposte.net> References: <3FCA2854.8050504@laposte.net> Message-ID: <3FCAD48B.70006@sonic.net> Nicolas Weeger wrote: > Hello. > > Just noticed, dragon don't have anymore fire/electric/cold/poison > claws... I supposedly have fire and electric and poison, but still > perceive self says only 'physical' as attack type... Character file? It's hard to fix this without knowing whether the problem is that the character has actually lost those attacktypes, or if perceive self just isn't showing them properly. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 30 23:45:17 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:44 2005 Subject: [CF-Devel] Skills bugs In-Reply-To: <3FBFAA0F.8000307@laposte.net> References: <3FBFAA0F.8000307@laposte.net> Message-ID: <3FCAD56D.3060106@sonic.net> Nicolas Weeger wrote: > Hello. > > Found a weird bug today. > I was playing in undead's quest, nice training place for a Gaea fellower. > So i used holy word a lot, and also paralyze (against vampires). > What happened a few times was the following: fire many holy words, get > 'Gaea ignores your prayer', switch skills to paralyze (the message 'you > ready the spell paralyze' correctly appears), but when i fire i get > 'Gaea ignores your prayer' !!! And not once, every time. I have to > switch again to paralyze to correctly fire that spell. Fixed to CVS. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Nov 30 23:45:47 2003 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:55:44 2005 Subject: [CF-Devel] A few glitches In-Reply-To: <3FCAC9B8.5000207@sonic.net> References: <3FBE7377.6030604@laposte.net> <1069448295.17036.11.camel@d5110227.lss.emc.com> <3FCAC9B8.5000207@sonic.net> Message-ID: <3FCAD58B.9060805@sonic.net> Mark Wedel wrote: > Preston Crow wrote: > >> One other interesting behaviour: >> >> I've long noticed that using the destruction spell will trigger nearby >> traps, but they go off not in their location, but in the caster's >> location. > > > > I'm taking this to be that these are traps on doors? That's the only > way I can see that happening. > > If that's the case, then the question might should - should destruction > destroy doors? > > But looking at the code, it would seem the same thing would happen if > you hit the doors with arrows, or any other range attack - the spring > attack code just takes the trap and puts it where the plaeyr is, which > is certainly a bug. I've fixed this in CVS - trap will only hit the player if the player is next to where the trap is located. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel