From nicolas.weeger at laposte.net Mon Jan 1 07:05:34 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Mon, 1 Jan 2007 14:05:34 +0100 Subject: [crossfire] Release of 1.10 soon. In-Reply-To: <459591ED.6040504@sonic.net> References: <459591ED.6040504@sonic.net> Message-ID: <200701011405.34449.nicolas.weeger@laposte.net> Le vendredi 29 d?cembre 2006 23:08, Mark Wedel a ?crit?: > I'd like to make a 1.10 release of crossfire sometime soon. So if you > have bugs you're currently fixing, getting those fixes in now would be > good. > > If you are aware of any unreported bugs, please report them now. If you > need time to fix some bugs, please also let me know. Given the rate at which bugs are corrected lately, i'd say to wait ~2 weeks, and we'll have a nice clean tracker :) Nicolas From nicolas.weeger at laposte.net Mon Jan 1 10:05:06 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Mon, 1 Jan 2007 17:05:06 +0100 Subject: [crossfire] New feature for scrolls and spellbooks Message-ID: <200701011705.06178.nicolas.weeger@laposte.net> Hello. Just implemented the feature request: add blessings and curses to scrolls More details here: https://sourceforge.net/tracker/index.php?func=detail&aid=656191&group_id=13833&atid=363833 (that was the ancestor of all feature requests, may it rest in peace) The effects I made are: For scrolls: * a cursed/damned scroll will do a random spell failure, at least mana drain or worse * a blessed one has a 10% chance of not turning to dust For spellbooks: * a blessed spellbook gives +5 level for learning the spell * a cursed/damned will make a random scroll failure * a damned has a 20% chance of making the player forget the spell Note that those cursed/damned/blessed can appear in shops too - should probably be fixed. Also, price isn't adapted for blessed scrolls. Parameters like probability or apparition & such should probably be adapted, too. Nicolas From nicolas.weeger at laposte.net Mon Jan 1 15:14:01 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Mon, 1 Jan 2007 22:14:01 +0100 Subject: [crossfire] New feature for scrolls and spellbooks In-Reply-To: <200701011705.06178.nicolas.weeger@laposte.net> References: <200701011705.06178.nicolas.weeger@laposte.net> Message-ID: <200701012214.01319.nicolas.weeger@laposte.net> > Just implemented the feature request: add blessings and curses to scrolls > More details here: > https://sourceforge.net/tracker/index.php?func=detail&aid=656191&group_id=1 >3833&atid=363833 Forgot to tell: as part of that implementation, i changed the behaviour for scroll/spellbook reading failure. The behaviour was inconsistent, in the sense that if "spell failure effects" was turned off in configuration, some failures did mana draon, others, because too powerful (mana storm, confusion, paralyse), didn't do anything. I changed the behaviour so that at least mana drain occurs - seems more coherent that way. Nicoals From info at knutshome.de Tue Jan 2 01:13:42 2007 From: info at knutshome.de (K. Ahlers) Date: Tue, 02 Jan 2007 08:13:42 +0100 Subject: [crossfire] Alex, the general Message-ID: <459A0626.7030406@knutshome.de> To explain the problem I paste an excerpt from the crossfire-IRC-channel: 11:00:18 < Luziferus> hrm... does anyone here know whether "Alex, the general" or related general settings was changed? 11:00:20 < Rednaxela> (be sure you're reporting the bugs you don't fix of course ;-)) 11:01:49 < Luziferus> in other times i was killing him within seconds and now... bashing him for 5 minutes: no effect, cursing and then bashing him: no effect, cursing and firing 4 meteor-swarms on him: no effect 11:02:18 < Luziferus> it seems that someone made him untouchable 11:03:07 < Luziferus> everything around him is dead but he is alive... 11:03:26 < Luziferus> flu, typhoid, leproxy, heavy wounds: still alive 11:04:14 < Luziferus> so my strongest magical / non magical weapons cant kill him... 11:04:31 < gros|coding> Is he at least damaged ? 11:05:00 < Luziferus> dont know... i get messages as if i hit him but i cant see any effekt 11:05:26 < Luziferus> only the leproxy forces him to leave skin flakes 11:05:54 < gros|coding> Well, there used to be a spell (or was it a skill) that allowed to roughly detect the state of a monster 11:06:11 < Luziferus> hmmm... 11:06:31 < Luziferus> i know what you mean but i dont know the name 11:06:43 < Luziferus> and if i remember right i cant cast it 11:07:18 < Luziferus> *dont know the name right now 11:07:35 < gros|coding> Anyway, try to ask this on the mailing list, maybe it is a side effect of a recent code change. Greetings Knut -- E-Mail: info at knutshome.de Homepage: www.knutshome.de PGP-Key: 337FE274 Jabber: Luzifer at knutshome.de From subs at eracc.com Tue Jan 2 11:08:51 2007 From: subs at eracc.com (ERACC Subscriptions) Date: Tue, 2 Jan 2007 11:08:51 -0600 Subject: [crossfire] Alex, the general In-Reply-To: <459A0626.7030406@knutshome.de> References: <459A0626.7030406@knutshome.de> Message-ID: <200701021108.52380.subs@eracc.com> On Tuesday 02 January 2007 01:13 am K. Ahlers wrote: > To explain the problem I paste an excerpt from the crossfire-IRC-channel: > > 11:00:18 < Luziferus> hrm... does anyone here know whether "Alex, the > general" or related general settings was changed? > 11:00:20 < Rednaxela> (be sure you're reporting the bugs you don't fix > of course ;-)) > 11:01:49 < Luziferus> in other times i was killing him within seconds > and now... bashing him for 5 minutes: no effect, cursing and then > bashing him: no effect, cursing > and firing 4 meteor-swarms on him: no effect > 11:02:18 < Luziferus> it seems that someone made him untouchable [...] Depends on /which/ "Alex, the general" you mean. There are two maps with that character. One is "pup_land/kurte/eureca_road3" and the other is "pup_land/hq". In one of the maps he is rather weak. In the other he is +100 physical and +100 fire. So, you would not damage him with physical and fire on that map. Recent changes to fix a bug with 'curse' make it where monsters are now more resistant to curse and to disease if they are a custom monster with custom resistances. Prior to this a bug in the code caused custom monsters to revert to the plain old original archetype and lose all their custom resistances. This new effect is intended but will make it necessary to fix some monsters and change strategy for others. In this case "Alex, the general" does not need fixing ... you need a new strategy. :-) Gene Alexander -- ERA Computers & Consulting We can provide you with VoIP phone service for your home and/or business. Our VoIP phone service has FREE long distance in the USA and Canada! Contact us! Voice messages: 1(731)256-0973 - FAX & Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] From alex_sch at telus.net Wed Jan 3 00:45:52 2007 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 02 Jan 2007 23:45:52 -0700 Subject: [crossfire] Duplicate code Message-ID: <459B5120.6060605@telus.net> Hi, I just ran some duplicate code checking stuff over the cf code base, and made a little report of some of the more significant cases. Perhaps we should store this list on the wiki or something so people can easily check off dealing with aspects? Alex Schultz random_roll() at line 66 in common/utils.c random_roll65() at line 111 in common/utils.c Some duplicated code. Not sure at a glance if it can be merged. ---- roll_stats() at line 821 in server/player.c swap_stat() at line 872 in server/player.c swap_stat() seems to duplicate some code for resetting some things like level. To me this looks redundent. ---- *_onion() in random_maps/room_gen_onion.c Some code in for those functions is duplicated. May be possible to merge, but not certain of how useful/practical it would be in this case. ---- find_skill_by_name() at line 147 in server/skill_util.c find_skill_by_number() at line 197 in server/skill_util.c Code to find the correct skilltool object is duplicated. That should probably be moved to it's own function. ---- line 306 in include/global.h line 8 in include/xdir.h Handling for HAVE_DIRENT_H is in both. Should be removed from one. ---- fire_bolt() at line 304 in server/spell_attack.c fire_bullet() at line 629 in server/spell_attack.c Identical 14 line code block used for handling reflecting bullets and bolts. Should probably be moved into it's own function. ---- socket/*.c In many places there are significant amounts of duplicated code to send or recieve similarly formatted commands. Perhaps more helper functions for socket stuff is in order? Not much that could be done other than add some more helper functions which isn't a high priority. ---- kill_player() at line 2677 in server/player.c kill_player() at line 2900 in server/player.c Identical 17 line code chunks used for removing poisoning and confusion, once for in battlefields and once for outside. A seperate function should be made for this. Perhaps a two functions, one for poison and one for confusion. ---- line 111 in common/init.c line 696 in include/spellist.h spellpathnames is defined identically in each. It should only be defined in one. Probably best to remove it from init.c ---- various functions in server/weather.c Various functions meant to be called from weather_effect() start nearly identically for quite a few lines. Perhaps could be improved a little. ---- get_pet_enemy() in server/pets.c Between lines 184 and 219 and between lines 115 and 150 are duplicated. Probably easily solvable by making a function to search given coords for a valid enemy ---- cast_change_ability() in server/spell_effect.c cast_bless() in server/spell_effect.c cast_curse() in server/spell_attack.c All duplicate many lines of code for force insertion. From mwedel at sonic.net Wed Jan 3 02:38:01 2007 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 03 Jan 2007 00:38:01 -0800 Subject: [crossfire] Duplicate code In-Reply-To: <459B5120.6060605@telus.net> References: <459B5120.6060605@telus.net> Message-ID: <459B6B69.5010406@sonic.net> Alex Schultz wrote: > Hi, > > I just ran some duplicate code checking stuff over the cf code base, and > made a little report of some of the more significant cases. Perhaps we > should store this list on the wiki or something so people can easily > check off dealing with aspects? Some quick notes, without digging in too deeply on these: > > Alex Schultz > > random_roll() at line 66 in common/utils.c > random_roll65() at line 111 in common/utils.c > Some duplicated code. Not sure at a glance if it can be merged. Actually, that is random_roll64(). In practice, all calls to random_roll() could just be replaced with calls to random_roll64(), which the extra bits on the 64 bit version most likely being dropped (think that is what happens if you cast a larger size to a smaller). It is possible that the 64 bit version is more costly, cpu wise, than the 32 bit version. Probably not an issue. > ---- > roll_stats() at line 821 in server/player.c > swap_stat() at line 872 in server/player.c > swap_stat() seems to duplicate some code for resetting some things > like level. To me this looks redundent. Hopefully, at some point, those just completely go away with client side player creation, so I wouldn't be too concerned about cleaning those up. > ---- > find_skill_by_name() at line 147 in server/skill_util.c > find_skill_by_number() at line 197 in server/skill_util.c > Code to find the correct skilltool object is duplicated. That should > probably be moved to it's own function. > ---- yes - I'd say the main portion is a little further down - the code that actually readies the skill_tool and finds the name, etc. Since that is about 20 lines that is the same. The block within the for loop doesn't seem to make sense - that is just a single line that does the same thing - putting that in a function wouldn't be that useful. The rest of the for loop itself probably can't be changed much, since it is comparing different things (number vs name). > line 306 in include/global.h > line 8 in include/xdir.h > Handling for HAVE_DIRENT_H is in both. Should be removed from one. Doing a quick grep, it doesn't appear xdir.h is in fact used by anything. So that file could just get deleted and it shouldn't affect anything. > ---- > fire_bolt() at line 304 in server/spell_attack.c > fire_bullet() at line 629 in server/spell_attack.c > Identical 14 line code block used for handling reflecting bullets > and bolts. Should probably be moved into it's own > function. yes - reflect_object() may make sense. > ---- > socket/*.c > In many places there are significant amounts of duplicated code to > send or recieve similarly formatted commands. Perhaps > more helper functions for socket stuff is in order? Not much that > could be done other than add some more helper functions > which isn't a high priority. Some of that could also be because of different revisions of similar commands (item, item1, etc). If the old ones are removed, that may clean things up bit. At some point, it becomes harder to figure out if a bunch of: if (protocol) ... else if (protocol2) if (protcol3) Type of things become cleaner with that type of logic, or just duplicating the similar code elsewhere but not having those if's is clearer (so you can just read down the function and see very clearly what it is doing). > ---- > kill_player() at line 2677 in server/player.c > kill_player() at line 2900 in server/player.c > Identical 17 line code chunks used for removing poisoning and > confusion, once for in battlefields and once for outside. A > seperate function should be made for this. Perhaps a two functions, > one for poison and one for confusion. Probably even better is one function that takes an option on what to remove, and then returns true/false based on of it actually does anything. This might also be useful in some of the healing and praying over altar code also. > ---- > line 111 in common/init.c > line 696 in include/spellist.h > spellpathnames is defined identically in each. It should only be > defined in one. Probably best to remove it from init.c Actually, except for that array, there is nothing in the spellist.h file that is actually used anymore. Doing a quick grep shows that spellist.h isn't being used by any function, so could also just get deleted. Otherwise, having duplicate initializers in .h files tend to result in duplicate symbols (the linker doesn't care/know that they are the same value) - that can be avoid by declaring them static, but then the data is being reproduced in every file, increasing file size some (and compilers will often complain about static values no being used also) From nicolas.weeger at laposte.net Wed Jan 3 11:55:47 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Wed, 3 Jan 2007 18:55:47 +0100 Subject: [crossfire] Code Doxygenification In-Reply-To: <458DE41C.3070106@telus.net> References: <458DE41C.3070106@telus.net> Message-ID: <200701031855.47182.nicolas.weeger@laposte.net> Hello. Having thought some, I suggest we try to have all documentation (including the doc/Developers directory) regrouped into Doxygen. Unless I'm mistaking, we can ask Doxygen to include some information from external sources, so it shouldn't be hard to merge eg object types, and such. Also, stuff like what one fields does exactly (example: sp is used as spellpoints, but also as exit coordinate) should be directly in the code I think. Having only one documentation entry point is IMO what we should aim for. Nicolas From info at knutshome.de Thu Jan 4 01:10:21 2007 From: info at knutshome.de (K. Ahlers) Date: Thu, 04 Jan 2007 08:10:21 +0100 Subject: [crossfire] Alex, the general In-Reply-To: <200701021108.52380.subs@eracc.com> References: <459A0626.7030406@knutshome.de> <200701021108.52380.subs@eracc.com> Message-ID: <459CA85D.4090101@knutshome.de> ERACC Subscriptions wrote: > On Tuesday 02 January 2007 01:13 am > K. Ahlers wrote: > >> To explain the problem I paste an excerpt from the crossfire-IRC-channel: >> >> 11:00:18 < Luziferus> hrm... does anyone here know whether "Alex, the >> general" or related general settings was changed? >> 11:00:20 < Rednaxela> (be sure you're reporting the bugs you don't fix >> of course ;-)) >> 11:01:49 < Luziferus> in other times i was killing him within seconds >> and now... bashing him for 5 minutes: no effect, cursing and then >> bashing him: no effect, cursing >> and firing 4 meteor-swarms on him: no effect >> 11:02:18 < Luziferus> it seems that someone made him untouchable > [...] > > Depends on /which/ "Alex, the general" you mean. There are two maps with that > character. One is "pup_land/kurte/eureca_road3" and the other is > "pup_land/hq". In one of the maps he is rather weak. In the other he is +100 > physical and +100 fire. So, you would not damage him with physical and fire > on that map. Recent changes to fix a bug with 'curse' make it where monsters > are now more resistant to curse and to disease if they are a custom monster > with custom resistances. Prior to this a bug in the code caused custom > monsters to revert to the plain old original archetype and lose all their > custom resistances. This new effect is intended but will make it necessary to > fix some monsters and change strategy for others. In this case "Alex, the > general" does not need fixing ... you need a new strategy. :-) i mean the alex in "hq (/pup_land/hq) in pupland" - some time ago i could really kill him with the axe _without_ magic in seconds (Dam+168) but now its not possible to kill him... but its needed for another part of that map. Knut -- E-Mail: info at knutshome.de Homepage: www.knutshome.de PGP-Key: 337FE274 Jabber: Luzifer at knutshome.de From kirschbaum at myrealbox.com Thu Jan 4 16:38:32 2007 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Thu, 4 Jan 2007 23:38:32 +0100 Subject: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire: [5296] server In-Reply-To: References: Message-ID: <20070104223832.GA16831@kirschbaum.myrealbox.com> Crossfire CVS repository messages. wrote: > Revision: 5296 > http://svn.sourceforge.net/crossfire/?rev=5296&view=rev > Author: qal21 > Date: 2007-01-04 00:53:58 -0800 (Thu, 04 Jan 2007) > > Log Message: > ----------- > Apply patch #1627442 by Aaron Baugher, to fix bug #1551735. Works by using a key_value of divine_giver_name to objects that are given by a god. [...] > Modified: server/trunk/server/gods.c > =================================================================== > --- server/trunk/server/gods.c 2007-01-03 21:03:42 UTC (rev 5295) > +++ server/trunk/server/gods.c 2007-01-04 08:53:58 UTC (rev 5296) > @@ -207,6 +207,57 @@ > } > > /** > + * follower_remove_given_items() I wonder if it is correct to include the function name here -- wouldn't it be used as the function (brief) description in the Doxygen output? [...] > + * @param pl > + * the player object > + * > + * @param op > + * the object to be searched for items The implementation allows for NULL pl or op parameters, so this IMO should be documented (or preferably not checked at all if passing NULL values is not intended). [...] > + for (tmp = op->inv; tmp != NULL; tmp = next) { > + next = tmp->below; /* backup in case we remove tmp */ > + > + const char* given_by = get_ob_key_value(tmp, "divine_giver_name"); Declaring a variable intermixed with statements is not allowed in Ansi C89 (which is to my understanding what the server code should be). > + if(given_by == god->name){ This probably will not work: when loading from a file, I think the stored values will not be shared strings. I.e., this check probably will work until the player logs out. But after re-login it may fail. [...] > + free_object(tmp); /* free object */ IMO this is a useless comment and should be removed: the comment does not contain additional information to what the code says. From nicolas.weeger at laposte.net Sat Jan 6 02:15:10 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 6 Jan 2007 09:15:10 +0100 Subject: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire: [5296] server In-Reply-To: <20070104223832.GA16831@kirschbaum.myrealbox.com> References: <20070104223832.GA16831@kirschbaum.myrealbox.com> Message-ID: <200701060915.10944.nicolas.weeger@laposte.net> > > + if(given_by == god->name){ > > This probably will not work: when loading from a file, I think the stored > values will not be shared strings. I.e., this check probably will work > until the player logs out. But after re-login it may fail. This should work, as the god's name is a shared string, and the given_by (returned from key_value) is one too :) Nicolas From cher at riedquat.de Sat Jan 6 06:20:20 2007 From: cher at riedquat.de (Christian Hujer) Date: Sat, 6 Jan 2007 13:20:20 +0100 (MET) Subject: [crossfire] CIA - The open source informant Message-ID: <200701061256.30706.cher@riedquat.de> Hi devs, in Gridarta and JAPI, I've found "CIA - The open source informant being" a useful service: http://cia.navi.cx/ E.g. http://cia.navi.cx/stats/project/gridarta E.g. http://cia.navi.cx/stats/author/christianhujer It's easy to activate. In SF's Subversion configuration, activate the CIA hook script called "ciabot_svn.py". Just a reminder, in case you find this is a useful service. Cu :) -- Christian Hujer Free software developer mailto:cher at riedquat.de http://www.riedquat.de/ PGP Fingerprint: 03DE 4B72 4E57 A98D C79B 24A5 212E 0217 0554 CCAB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070106/fd61dba2/attachment.pgp From nicolas.weeger at laposte.net Sun Jan 7 07:00:16 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 7 Jan 2007 14:00:16 +0100 Subject: [crossfire] New plugin: cflogger Message-ID: <200701071400.16577.nicolas.weeger@laposte.net> Hello. I just committed a new plugin, an event logger to an sqlite3 database. Logged events: * players join/leave/creation/quit * map load/unload/reset/enter/leave * kills, whenever a player is concerned * ingame/real time links with some details. The idea is to gather statistics, to display on a web page or put in ingame newspapers (on which i'm working now ^_-). Note that the plugin is not yet part of the autobuild process, because I couldn't figure out how to add a --enable-cflogger switch to configure, or a test for sqlite3. Any auto[conf|make] wizard around to help? :) Warning: the database size may grow a lot, you'll have to check manually. Note also that you can access the database (through command-line sqlite3 for instance) while the server is running, sqlite3 handles that nicely :) Nicolas From antonoussik at gmail.com Mon Jan 8 06:11:07 2007 From: antonoussik at gmail.com (Anton Oussik) Date: Mon, 8 Jan 2007 12:11:07 +0000 Subject: [crossfire] Improved/redone client. In-Reply-To: <453C3A4E.1020002@ancilla.ca> References: <452A040C.20105@sonic.net> <453C3A4E.1020002@ancilla.ca> Message-ID: > Standardize on 19x19 map size. Good idea, and scale tiles accordingly otherwise. Would probably want to make a 16x16, 64x64, and possibly a 128x128 tileset in that case. Or just try to use OpenGL to scale tiles appropriately. > Make client fullscreen. I have mixed feelings about this one. I would run it windowed, but I know for a fact that many Windows-using people expect a full screen app from a "game" they would consider playing. I experimented on some Windows users and a private server a few months back, and they all wanted full screen and preferred gtk-v1 client, as it could display more information to the user at the same time. So, if the game UI is "geeky", it is only in the sense that CF uses the OSes standard UI elements, and users expect shiny UI in a game. > Improve client UI From nicolas.weeger at laposte.net Sat Jan 13 18:19:41 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 14 Jan 2007 01:19:41 +0100 Subject: [crossfire] New standalone program: mapper Message-ID: <200701140119.42326.nicolas.weeger@laposte.net> Hello. I just committed a program to generate map information suitable for website display. The program is utils/mapper.c, since it isn't (yet) included in the build process you should compile it with: gcc mapper.c -I../include ../common/libcross.a ../socket/libsocket.a -o mapper -lm -lgd You need GD (graphics library) installed to correctly build, and obviously Crossfire sources, built and installed, including installed maps. You can then simply run it (from the utils directory), and it will generate the following files: * one HTML file per map, with Crossfire's directory structure * for each map, one real-size picture and one small size * one file for each region * one global map index * one region index * the world map, 3 formats: raw world map, world map with region information, and raw region information Note that it can take 30 minutes or more to generate all pictures - subsequent runs should be faster, as pictures are only regenerated if the map is older than the picture. Since this program browses maps from the first map, only maps linked from there will be processed (for instance, the.HallOfDMs is not processed). Maps are generated as the server sees them, that is with weather effects if enabled, treasures and so on instead of markers, The program uses templates, stored in the utils/templates subdirectory. Information is available in mapper.c's header, feel free to ask if not clear enough :) If someone could tweak the build process to build (and install?) that program, that would be great! Note that I called the file 'mapper.c', but I have no objection to having it renamed to something else more linked to Crossfire :) Bugs and such can be reported to the tracker or on the list, or directly to my mail. Nicolas From nicolas.weeger at laposte.net Sat Jan 13 18:44:44 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 14 Jan 2007 01:44:44 +0100 Subject: [crossfire] New standalone program: mapper In-Reply-To: <200701140119.42326.nicolas.weeger@laposte.net> References: <200701140119.42326.nicolas.weeger@laposte.net> Message-ID: <200701140144.44764.nicolas.weeger@laposte.net> Some more info I missed :) From a map, the program follows: * linked maps * exits, including teleporters * end maps for random exits - random maps themselves will not be generated It will not follow exits through plugins or such :) No additional information about a map square (monster, treasure, hidden exit ...) is generated, because I felt it would give too much information. Map is, roughly, what a player would see, darkness removed. The map picture itself will contain zones normally invisible to players (think hidden mechanism and such, surrounded by a blocked zone). This is because the program merely displays all squares, without checking if they are reachable or not by a player (something that makes generation much harder as you'd need to check all maps to search exits to certain zones, and process all squares recursively and such - but that could be an interesting exercise ^_-). There are issues with layer ordering - some monsters can appear under fog or such. Also, Titans and coins (silver or platinum, not sure) have issues (missing square for Titan, distorded pic for coin). A known effect is that, if you put a map limit, region information on the world map will probably be wrong - this is because the text position depends on all maps in region, something the program can't figure if it doesn't process all maps. The program generates .html files, but should be able to generate other formats (.xml or whatever) without too much hassle (templates should be flexible enough). Changing .html everywhere should be a good start :) The code can use much factoring - duplicated information, redundant strcpy all around, and such. I'll work on that later on :) Also I may add a configuration file, and more options for flexibility (don't generate index, ...). If you find map generation too slow, you can replace gdImageCopyResampled with gdImageCopyResized on line 757 - resulting small pic will be uglier, but generation should be faster. Reciprocately, you can do the opposite on line 1081 to have a nicer world map. (in a close future there will be a parameter for that, too ;p) As a nice side effect, it's easier to find: * exits leading nowhere (program will display that, including square with broken exit) * unknown archetypes (use the -showmaps flag to see which map this happens in) Nicolas From antonoussik at gmail.com Sun Jan 14 12:54:07 2007 From: antonoussik at gmail.com (Anton Oussik) Date: Sun, 14 Jan 2007 18:54:07 +0000 Subject: [crossfire] Wraith patch committed. Please test. Message-ID: The wraith patch has been merged into the source tree. It will most likely need some tweaking to make it balanced, most notably the strength of the feed skill and proportion of that returned to the player as hp/food: on one hand we want it to be possible to survive by feeding off things, on the other hand we do not want to be able to go run-feeding through hordes of orcs at level 1. Please test it and comment on changes to it you would like to see. The details of the patch and the patch itself can be found here: https://sourceforge.net/tracker/index.php?func=detail&aid=1382884&group_id=13833&atid=313833 From nicolas.weeger at laposte.net Mon Jan 15 17:05:37 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Tue, 16 Jan 2007 00:05:37 +0100 Subject: [crossfire] New spells: curse item / bless item ; also change spell name matching for cast Message-ID: <200701160005.38029.nicolas.weeger@laposte.net> Hello. I just implemented partially the feature request https://sourceforge.net/tracker/index.php?func=detail&aid=656194&group_id=13833&atid=363833 (it should be possible to bless and curse items). I added 2 new spells, 'curse item' and 'bless item', that do what you'd expect. Bless will make the item god-given, to avoid abuse. Spells require much grace, and are level 50. Note that curse will merely set the cursed flag, but won't change weight / stats / whatever. I closed the request, which still has a suggestion for 2 matching skills, because i'm not sure such skills are interesting. I also fear they would be abused. Of course one should feel free to implement that :) As part of that commit, I changed the name matching for 'cast ': if a perfect match is found, return it, else return if only one good match, else don't return anything. And if player asks for 'long spell', don't match 'long' :) Nicolas From nicolas.weeger at laposte.net Mon Jan 15 17:39:57 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Tue, 16 Jan 2007 00:39:57 +0100 Subject: [crossfire] New spells: curse item / bless item ; also change spell name matching for cast In-Reply-To: <200701160005.38029.nicolas.weeger@laposte.net> References: <200701160005.38029.nicolas.weeger@laposte.net> Message-ID: <200701160039.57927.nicolas.weeger@laposte.net> Forgot to tell: for now, those spells are not available, as they are not part of any quest/treasure list. I hope someone will feel like using those a quest-item ;) Nicolas From bencha1969 at yahoo.fr Tue Jan 16 12:32:34 2007 From: bencha1969 at yahoo.fr (=?ISO-8859-1?Q?beno=EEt?=) Date: Tue, 16 Jan 2007 19:32:34 +0100 Subject: [crossfire] New spells: curse item / bless item ; also change spell name matching for cast In-Reply-To: <200701160005.38029.nicolas.weeger@laposte.net> References: <200701160005.38029.nicolas.weeger@laposte.net> Message-ID: <45AD1A42.7000102@yahoo.fr> Nicolas Weeger (Laposte) a ?crit : > Hello. > > I just implemented partially the feature request > https://sourceforge.net/tracker/index.php?func=detail&aid=656194&group_id=13833&atid=363833 > (it should be possible to bless and curse items). > > I added 2 new spells, 'curse item' and 'bless item', that do what you'd > expect. > > Bless will make the item god-given, to avoid abuse. > > Spells require much grace, and are level 50. > > > Note that curse will merely set the cursed flag, but won't change weight / > stats / whatever. > > > I closed the request, which still has a suggestion for 2 matching skills, > because i'm not sure such skills are interesting. I also fear they would be > abused. Of course one should feel free to implement that :) > > > As part of that commit, I changed the name matching for 'cast ': > if a perfect match is found, return it, else return if only one good match, > else don't return anything. And if player asks for 'long spell', don't > match 'long' :) > > > Nicolas > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > ___________________________________________________________________________ Yahoo! Mail r?invente le mail ! D?couvrez le nouveau Yahoo! Mail et son interface r?volutionnaire. http://fr.mail.yahoo.com From subs at eracc.com Tue Jan 16 17:13:22 2007 From: subs at eracc.com (ERACC Subscriptions) Date: Tue, 16 Jan 2007 17:13:22 -0600 Subject: [crossfire] New spells: curse item / bless item ; also change spell name matching for cast In-Reply-To: <200701160039.57927.nicolas.weeger@laposte.net> References: <200701160005.38029.nicolas.weeger@laposte.net> <200701160039.57927.nicolas.weeger@laposte.net> Message-ID: <200701161713.23599.subs@eracc.com> On Monday 15 January 2007 05:39 pm Nicolas Weeger (Laposte) wrote: > Forgot to tell: for now, those spells are not available, as they are not > part of any quest/treasure list. > > I hope someone will feel like using those a quest-item ;) > > Nicolas OOOOoooo! New spells for quest items. I may have to put those on some *hard* maps somewhere. :-) Of course if another mapper gets to it first feel free to go ahead, don't wait for me to do it. ;-) Gene Alexander -- ERA Computers & Consulting We can provide you with VoIP phone service for your home and/or business. Our VoIP phone service has FREE long distance in the USA and Canada! Contact us! Voice messages: 1(731)256-0973 - FAX & Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] From cher at riedquat.de Thu Jan 18 11:29:25 2007 From: cher at riedquat.de (Christian Hujer) Date: Thu, 18 Jan 2007 18:29:25 +0100 (MET) Subject: [crossfire] CIA - The open source informant In-Reply-To: <200701061256.30706.cher@riedquat.de> References: <200701061256.30706.cher@riedquat.de> Message-ID: <200701181803.46803.cher@riedquat.de> P.S.: Today Micah has added a new service to CIA. It is now possible to have a CIA-Bot join an IRC-Channel (e.g. #crossfire at Freenode) and automatically post all commits there. I've already configured this for the projects that I'm working on and that use CIA already. P.P.S.: My original post was meant as a suggestion to activate the Subversion CIA commit hook for Crossfire at Sourceforge. On Saturday 06 January 2007 13:20 Christian Hujer wrote: > Hi devs, > > > in Gridarta and JAPI, I've found "CIA - The open source informant being" a > useful service: http://cia.navi.cx/ > E.g. http://cia.navi.cx/stats/project/gridarta > E.g. http://cia.navi.cx/stats/author/christianhujer > > It's easy to activate. In SF's Subversion configuration, activate the CIA > hook script called "ciabot_svn.py". > > Just a reminder, in case you find this is a useful service. > > Cu :) -- Christian Hujer Free software developer mailto:cher at riedquat.de http://www.riedquat.de/ PGP Fingerprint: 03DE 4B72 4E57 A98D C79B 24A5 212E 0217 0554 CCAB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070118/6890d9e0/attachment.pgp From lalo.martins at gmail.com Fri Jan 19 10:07:48 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Sat, 20 Jan 2007 00:07:48 +0800 Subject: [crossfire] CIA - The open source informant References: <200701061256.30706.cher@riedquat.de> <200701181803.46803.cher@riedquat.de> Message-ID: On Thu, 18 Jan 2007 18:29:25 +0100, Christian Hujer wrote: > Today Micah has added a new service to CIA. It is now possible to have a > CIA-Bot join an IRC-Channel (e.g. #crossfire at Freenode) and automatically > post all commits there. Have I just crossed into an alternate reality? As far as I remember, this feature was the original purpose of the original CIA, years ago! :-) (When Micah wrote it to watch PicoGUI's SVN and asked for suggestions to name it...) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From cher at riedquat.de Fri Jan 19 16:28:18 2007 From: cher at riedquat.de (Christian Hujer) Date: Fri, 19 Jan 2007 23:28:18 +0100 (MET) Subject: [crossfire] CIA - The open source informant In-Reply-To: References: <200701061256.30706.cher@riedquat.de> <200701181803.46803.cher@riedquat.de> Message-ID: <200701192302.23760.cher@riedquat.de> Hi, On Friday 19 January 2007 17:07 Lalo Martins wrote: > On Thu, 18 Jan 2007 18:29:25 +0100, Christian Hujer wrote: > > Today Micah has added a new service to CIA. It is now possible to have a > > CIA-Bot join an IRC-Channel (e.g. #crossfire at Freenode) and > > automatically post all commits there. > > Have I just crossed into an alternate reality? As far as I remember, this > feature was the original purpose of the original CIA, years ago! :-) > (When Micah wrote it to watch PicoGUI's SVN and asked for suggestions to > name it...) Before, only Micah could configure bots. He received so many requests for bots or new configs that he obviously couldn't reply / support them any longer. Now, everybody can register at cia.navi.cx and configure the bots himself via a web interface. Cu :) -- Christian Hujer Free software developer mailto:cher at riedquat.de http://www.riedquat.de/ PGP Fingerprint: 03DE 4B72 4E57 A98D C79B 24A5 212E 0217 0554 CCAB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070119/55b0acd7/attachment.pgp From lalo.martins at gmail.com Sat Jan 20 02:26:04 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Sat, 20 Jan 2007 16:26:04 +0800 Subject: [crossfire] CIA - The open source informant References: <200701061256.30706.cher@riedquat.de> <200701181803.46803.cher@riedquat.de> <200701192302.23760.cher@riedquat.de> Message-ID: On Fri, 19 Jan 2007 23:28:18 +0100, Christian Hujer wrote: > Before, only Micah could configure bots. He received so many requests for bots > or new configs that he obviously couldn't reply / support them any longer. > Now, everybody can register at cia.navi.cx and configure the bots himself via > a web interface. aaah, now THAT'S lovely :-) thanks for clearing it up. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From nicolas.weeger at laposte.net Sat Jan 20 15:41:33 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 20 Jan 2007 22:41:33 +0100 Subject: [crossfire] Armour restriction / girdle Message-ID: <200701202241.33310.nicolas.weeger@laposte.net> Hello. A change made girdles be considered armours for the 'no armour' god restriction. This is a really heavy change, especially for dragons or fireborns, so I unilaterally reverted it :) If we really want to make girdles not wearable when no armour is set, i think there should be some compensation for some classes :) Nicolas From nicolas.weeger at laposte.net Sat Jan 20 17:34:33 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 21 Jan 2007 00:34:33 +0100 Subject: [crossfire] Casting when confused Message-ID: <200701210034.33811.nicolas.weeger@laposte.net> Hello. I implemented the feature request #656195: More effects of confusion. See details at https://sourceforge.net/tracker/index.php?func=detail&aid=656195&group_id=13833&atid=363833 Now casting when confused can have 3 effects: * one item is transformed temporarily to flowers * 2 random statistics are temporarily swapped * a random spell is cast. A new force type is introduced, FORCE_TRANSFORMED_ITEM, which does some magic when it expires to restore item. Nicolas From nicolas.weeger at laposte.net Sat Jan 20 17:40:39 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 21 Jan 2007 00:40:39 +0100 Subject: [crossfire] Crossfire bots Message-ID: <200701210040.39372.nicolas.weeger@laposte.net> Hello. Concerning feature request "Newbie Bot - help those noobs :)" https://sourceforge.net/tracker/index.php?func=detail&aid=765770&group_id=13833&atid=363833 is there such a bot currently? I know of 2 bots scripts at least, Seer and Zebulon. Could they be adapted to such a request? (this request, at least of a bot giving advice, is quite interesting imo) Of course, we could make the newbie area more mandatory, too :) Nicolas From alex_sch at telus.net Sat Jan 20 23:40:27 2007 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 20 Jan 2007 22:40:27 -0700 Subject: [crossfire] Armour restriction / girdle In-Reply-To: <200701202241.33310.nicolas.weeger@laposte.net> References: <200701202241.33310.nicolas.weeger@laposte.net> Message-ID: <45B2FCCB.7010803@telus.net> Nicolas Weeger (Laposte) wrote: > Hello. > > A change made girdles be considered armours for the 'no armour' god > restriction. > This is a really heavy change, especially for dragons or fireborns, so I > unilaterally reverted it :) > > If we really want to make girdles not wearable when no armour is set, i think > there should be some compensation for some classes :) > > Nicolas The change that caused this, actually fixed a bug where no_armour was *completely* ignored when players equipped things, thus making gods banning amour pointless. My fix made players and monsters, under all conditions, treat no_armour and no_shield consistently. While I agree that it's too harsh for no_armour gods to block girdles, I'm somewhat concerned at how your change breaks consistency. IMHO the real fix to both issues at once would be a flag to allow banning of equipping specific object type/subtype combinations, which would be much more flexible and allow consistency while not being unfair for no_armour gods. Alex Schultz From alex_sch at telus.net Sat Jan 20 23:49:34 2007 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 20 Jan 2007 22:49:34 -0700 Subject: [crossfire] Crossfire bots In-Reply-To: <200701210040.39372.nicolas.weeger@laposte.net> References: <200701210040.39372.nicolas.weeger@laposte.net> Message-ID: <45B2FEEE.5020808@telus.net> Nicolas Weeger (Laposte) wrote: > Concerning feature request "Newbie Bot - help those noobs :)" > https://sourceforge.net/tracker/index.php?func=detail&aid=765770&group_id=13833&atid=363833 > > is there such a bot currently? > > I know of 2 bots scripts at least, Seer and Zebulon. Could they be adapted to > such a request? > (this request, at least of a bot giving advice, is quite interesting imo) > Personally, I think this could be better implemented as a server-side script than a bot, however the base concept seems interesting. > Of course, we could make the newbie area more mandatory, too :) IMHO also a good idea and perhaps even somewhat necessary. Alex Schultz From nicolas.weeger at laposte.net Sun Jan 21 01:50:25 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 21 Jan 2007 08:50:25 +0100 Subject: [crossfire] Armour restriction / girdle In-Reply-To: <45B2FCCB.7010803@telus.net> References: <200701202241.33310.nicolas.weeger@laposte.net> <45B2FCCB.7010803@telus.net> Message-ID: <200701210850.25653.nicolas.weeger@laposte.net> > The change that caused this, actually fixed a bug where no_armour was > *completely* ignored when players equipped things, thus making gods > banning amour pointless. My fix made players and monsters, under all > conditions, treat no_armour and no_shield consistently. While I agree > that it's too harsh for no_armour gods to block girdles, I'm somewhat > concerned at how your change breaks consistency. IMHO the real fix to Hum, why is my change not treating consistently? (real question, wondering ;p) > both issues at once would be a flag to allow banning of equipping > specific object type/subtype combinations, which would be much more > flexible and allow consistency while not being unfair for no_armour gods. Yes, that could be interesting to be able to precisely forbid some items. Nicolas From alex_sch at telus.net Sun Jan 21 02:05:47 2007 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 21 Jan 2007 01:05:47 -0700 Subject: [crossfire] Armour restriction / girdle In-Reply-To: <200701210850.25653.nicolas.weeger@laposte.net> References: <200701202241.33310.nicolas.weeger@laposte.net> <45B2FCCB.7010803@telus.net> <200701210850.25653.nicolas.weeger@laposte.net> Message-ID: <45B31EDB.5080709@telus.net> Nicolas Weeger (Laposte) wrote: >> While I agree >> that it's too harsh for no_armour gods to block girdles, I'm somewhat >> concerned at how your change breaks consistency. IMHO the real fix to >> > > Hum, why is my change not treating consistently? > (real question, wondering ;p) > The praying and monster code also reference the same checks for no_armour and no_shield if I recall, and I think you just made it inconsistent with no_armour/no_shield code for those. ;-) Alex From kirschbaum at myrealbox.com Sun Jan 21 05:42:44 2007 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sun, 21 Jan 2007 12:42:44 +0100 Subject: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire: [5334] server/trunk In-Reply-To: References: Message-ID: <20070121114244.GA23314@kirschbaum.myrealbox.com> Crossfire CVS repository messages. wrote: > Log Message: > ----------- > Implement feature request #656195: More effects of confusion. [...] > Modified: server/trunk/include/spells.h [...] > + flower = create_archetype("flowers_permanent"); > + > + if (QUERY_FLAG(item, FLAG_APPLIED)) > + manual_apply(op, item, AP_NOPRINT | AP_IGNORE_CURSE | AP_UNAPPLY); > + remove_ob(item); [...] > + case FORCE_TRANSFORMED_ITEM: > + /* The force is into the item that was created */ > + if (op->env != NULL && op->inv != NULL) { > + object* inv = op->inv; > + object* pl = get_player_container(op); > + remove_ob(inv); > + inv->weight = (inv->nrof ? (sint32)(op->env->weight / inv->nrof) : op->env->weight); > + if (op->env->env) { > + insert_ob_in_ob(inv, op->env->env); > + if (pl) { > + esrv_send_item(pl, inv); > + draw_ext_info_format(NDI_UNIQUE, 0,pl, > + MSG_TYPE_ITEM, MSG_TYPE_ITEM_CHANGE, > + "Your %s recovers its original form.", > + "Your %s recovers its original form.", > + query_short_name(inv)); This code seems to neglect applied cursed items when the spell effect wears off: I think it might be possible to unwear such items by forcing spell failures until the cursed item was transformed into a flower. Is this an intended feature? From nicolas.weeger at laposte.net Sun Jan 21 06:09:32 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 21 Jan 2007 13:09:32 +0100 Subject: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire: [5334] server/trunk In-Reply-To: <20070121114244.GA23314@kirschbaum.myrealbox.com> References: <20070121114244.GA23314@kirschbaum.myrealbox.com> Message-ID: <200701211309.33006.nicolas.weeger@laposte.net> > This code seems to neglect applied cursed items when the spell effect > wears off: I think it might be possible to unwear such items by forcing > spell failures until the cursed item was transformed into a flower. Is > this an intended feature? Yes, I voluntarily don't check for cursed items. After all, magic slashback can have some fun properties :) But feel free to change my code - it's a first draft, which can certainly be much improved (if you got more fun ideas, feel free!) Nicolas From nicolas.weeger at laposte.net Sun Jan 21 06:10:29 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 21 Jan 2007 13:10:29 +0100 Subject: [crossfire] Armour restriction / girdle In-Reply-To: <45B31EDB.5080709@telus.net> References: <200701202241.33310.nicolas.weeger@laposte.net> <200701210850.25653.nicolas.weeger@laposte.net> <45B31EDB.5080709@telus.net> Message-ID: <200701211310.29325.nicolas.weeger@laposte.net> > The praying and monster code also reference the same checks for > no_armour and no_shield if I recall, and I think you just made it > inconsistent with no_armour/no_shield code for those. ;-) Hum, is it possible to fix monster code to have that coherent? I looked, and it seems it's only one line to change (around monster.c:1161), or am I missing something? Nicolas From nicolas.weeger at laposte.net Sun Jan 21 17:15:12 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Mon, 22 Jan 2007 00:15:12 +0100 Subject: [crossfire] New apply flag Message-ID: <200701220015.12378.nicolas.weeger@laposte.net> Hello. 'apply' command now accepts a new flag, '-b', which means to look for items on the ground or in the currently opened container. It'll work like other items, find best match and such. Nicolas From mwedel at sonic.net Sun Jan 21 23:41:40 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 21 Jan 2007 21:41:40 -0800 Subject: [crossfire] Armour restriction / girdle In-Reply-To: <45B2FCCB.7010803@telus.net> References: <200701202241.33310.nicolas.weeger@laposte.net> <45B2FCCB.7010803@telus.net> Message-ID: <45B44E94.7060305@sonic.net> Alex Schultz wrote: > The change that caused this, actually fixed a bug where no_armour was > *completely* ignored when players equipped things, thus making gods > banning amour pointless. My fix made players and monsters, under all > conditions, treat no_armour and no_shield consistently. While I agree > that it's too harsh for no_armour gods to block girdles, I'm somewhat > concerned at how your change breaks consistency. IMHO the real fix to > both issues at once would be a flag to allow banning of equipping > specific object type/subtype combinations, which would be much more > flexible and allow consistency while not being unfair for no_armour gods. IMO, the armor subtypes (girdle, cloak, boots, shield, helmet) should just go away. They are left over from before the body code was added - back in the day, the type of the object determined where it was equipped, and limited the player/monster to just one of each type, save for rings, which were coded for two. The no armor/no shield had pretty easy checks against this. However, the control on that, as seen now, isn't very specific. IIRC, some of the races had no armor in part as balance, but part of it was also a reasoning that a suit of chain armor wouldn't fit on a dragon, etc. However, that all or nothing then doesn't explain things like cloaks as well (if you have a neck, you could do a cloak, etc). So that's the history lesson. On to current times: In the present code, the actual equip logic doesn't care what the object type is, as long as the player has the necessary body slot. So I could make a custom object, give it the ring type, and set it up to go on the body instead of the finger, and this would work even if the character is denied armor use by his god. Now good arguments could be made on both sides of if this should be allowed or not. However, whatever side is chosen as correct, it does tend to illustrate the point that the actual type of the object isn't particular relevant. This list of what is or is not armor as far as the 'can use armor' flag is somewhat arbitrary, and still may not prevent armor like items from being used. So what would probably be clearest is that all the current armor subtypes (including probably rings) should be collapsed into 1 type, with perhaps 3 subtypes: 1 - shield 2 - armor like device, as far as equipping is concerned 3 - other - no restriction to equipping then, down the road, if changes are needed, it is simple archetype updates. IT also means that if new flags are added (can't use metal armor), it simple matter of updating the archetypes with a few lines of code is all that is needed - in the current methodology, you couldn't do a no metal armor, because there is no way to differentiate that type (but as I type this, it may be better to do the subtype as flags, with 0 being no restrictions, and the other bits being specific restrictions. Then, adding further granularity or restrictions would be easier - following some game examples, one could add heavy/medium/light armor types, or the no metal, etc). From mwedel at sonic.net Sun Jan 21 23:52:31 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 21 Jan 2007 21:52:31 -0800 Subject: [crossfire] Crossfire bots In-Reply-To: <45B2FEEE.5020808@telus.net> References: <200701210040.39372.nicolas.weeger@laposte.net> <45B2FEEE.5020808@telus.net> Message-ID: <45B4511F.5010701@sonic.net> Alex Schultz wrote: > Nicolas Weeger (Laposte) wrote: >> Concerning feature request "Newbie Bot - help those noobs :)" >> https://sourceforge.net/tracker/index.php?func=detail&aid=765770&group_id=13833&atid=363833 >> >> is there such a bot currently? >> >> I know of 2 bots scripts at least, Seer and Zebulon. Could they be adapted to >> such a request? >> (this request, at least of a bot giving advice, is quite interesting imo) >> > Personally, I think this could be better implemented as a server-side > script than a bot, however the base concept seems interesting. Yes - doing it as a bot would seem pretty hard, as what is mentioned in the bug report are some things that it may be harder for the bot to identify. > >> Of course, we could make the newbie area more mandatory, too :) > IMHO also a good idea and perhaps even somewhat necessary. As I mentioned, that would seem like a good idea. Some other random ideas: - Give all character 5 or so food to start out with so they will have a while before they need to get some more. - Maybe give them so low power (like 10 hp) healing potions - Looking at the 2 beginner maps, they don't go over some of the more basic points of the game, as mention in the tracker item: - nothing about eating food (and the fact that monster remains can typically be eaten also - Nothing at all about using shops. A very small shop, with perhaps a basic detect curse/detect magic/identify altar on the map, with some cursed/magic items on that map for them to use/try out (maybe make those altars very cheap, but make this map a 1 way journey - once you exit, you can't get back) - Maybe some mention about chat/shout and the etiquette on using the - Not sure if explicitly mentioned in any of the maps, but the fact that just standing around will regain hp/sp It seems the beginner maps otherwise cover basic of attack, traps, spells, so those points are covered. From aaron at baugher.biz Mon Jan 22 08:04:14 2007 From: aaron at baugher.biz (Aaron Baugher) Date: Mon, 22 Jan 2007 08:04:14 -0600 Subject: [crossfire] Crossfire bots In-Reply-To: <45B4511F.5010701@sonic.net> (Mark Wedel's message of "Sun, 21 Jan 2007 21:52:31 -0800") References: <200701210040.39372.nicolas.weeger@laposte.net> <45B2FEEE.5020808@telus.net> <45B4511F.5010701@sonic.net> Message-ID: <86irezb1k1.fsf@cail.baugher.biz> Mark Wedel writes: > Alex Schultz wrote: >> Nicolas Weeger (Laposte) wrote: >>> Of course, we could make the newbie area more mandatory, too :) >> IMHO also a good idea and perhaps even somewhat necessary. > As I mentioned, that would seem like a good idea. > > Some other random ideas: I like all those; a few more: First of all, combine the Beginner houses and newbiehouse into one area in some way, since now they duplicate some things but not others, and newbies might be confused into thinking that completing one makes the other unnecessary. Make the Newbie portal in the Nexus go directly to this combined area (to newbiehouse or directly into Beginner1), and make the sign pointing the way to Scorn more serious about warning newbies that they REALLY should go the other way first. If the Beginner houses are kept (and any unique features from newbiehouse incorporated into them), put them in an out-of-the-way area of Scorn, perhaps down a fenced-off alley in the SE corner. Put Beginner1 at the far end of the alley, then a magic mouth saying "Let's see what's in this next building," then Beginner2, etc. Force the player exiting Beginner1 to at least walk over the other Beginner houses and be told about them before venturing into the rest of Scorn. Or as someone else suggested, put a password in each house, and require those passwords to exit into the world. The exit from Beginner1 could put the player inside Beginner2, and so on, through however many Beginner houses there end up being, but that could be very inconvenient for experienced players with new characters. Still, it would only have to be traversed once with each character. Make the Beginner maps more linear, with hallways forcing the player to at least pass by all the signs, instead of a wide hallway that allows the player to wander and miss signs and do things out of order. Perhaps add a magic mouth once in a while reminding the player to read the next sign or do something in particular. > - Looking at the 2 beginner maps, they don't go over some of the > more basic points of the game, as mention in the tracker item: > - nothing about eating food (and the fact that monster remains > can typically be eaten also Yes, I had no idea about this for a long time. When I accidentally ate some because it was on top of a chest or stairs when I hit 'apply, the message about how bad it tasted made me think it was harmful -- not just potentially poisonous, but always bad to eat. > - Nothing at all about using shops. A very small shop, with > perhaps a basic detect curse/detect magic/identify altar on the map, > with some cursed/magic items on that map for them to use/try out > (maybe make those altars very cheap, but make this map a 1 way > journey - once you exit, you can't get back) I like this idea. If the beginner area were off-world like newbiehouse or somehow inaccessible, with an exit to Scorn, characters could only pass through it once, so very cheap tables wouldn't be a problem there. (An aside: I think maybe money-changing altars should be changed to tables, to eliminate any confusion with god altars. When I was a newbie, I was unsure at times whether an unfamiliar type of altar would offend my god.) > - Maybe some mention about chat/shout and the etiquette on using > the Also some mention of the mail and bulletin board at the post offices for communication, to encourage in-character communication and discourage the use of chat for everything. -- Aaron -- http://aaron.baugher.biz/ From fuchs.andy at gmail.com Mon Jan 22 14:49:39 2007 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Mon, 22 Jan 2007 15:49:39 -0500 Subject: [crossfire] Crossfire bots In-Reply-To: <200701210040.39372.nicolas.weeger@laposte.net> References: <200701210040.39372.nicolas.weeger@laposte.net> Message-ID: <1169498987.5670.13.camel@outhouse> On Sun, 2007-01-21 at 00:40 +0100, Nicolas Weeger (Laposte) wrote: > Hello. > > Concerning feature request "Newbie Bot - help those noobs :)" > https://sourceforge.net/tracker/index.php?func=detail&aid=765770&group_id=13833&atid=363833 > > is there such a bot currently? > > I know of 2 bots scripts at least, Seer and Zebulon. Could they be adapted to > such a request? > (this request, at least of a bot giving advice, is quite interesting imo) Possibly Seer, but your other idea seems a bit more user friendly. > Of course, we could make the newbie area more mandatory, too :) I would rather see this happen, than to have a bot do it. Possibly evolve the tutorial map into a quest (more in the sense of role playing). It would also be nice if we used the animator plugin to give the player a little bit of back story about the game world (an other suggestion in that feature request), after someone finishes setting their character up. Players who seem to have a difficult time after the tutorial, could be marked (through the use of a script, and a logger), while various npcs distributed across the world attempt to give tips to the player loosely relating to the problem the player was marked with. -- Andrew Fuchs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070122/87ed6098/attachment.pgp From leaf at real-time.com Mon Jan 22 16:08:54 2007 From: leaf at real-time.com (Rick Tanner) Date: Mon, 22 Jan 2007 16:08:54 -0600 Subject: [crossfire] Crossfire bots In-Reply-To: <1169498987.5670.13.camel@outhouse> References: <200701210040.39372.nicolas.weeger@laposte.net> <1169498987.5670.13.camel@outhouse> Message-ID: <45B535F6.9050200@real-time.com> Andrew Fuchs wrote: > On Sun, 2007-01-21 at 00:40 +0100, Nicolas Weeger (Laposte) wrote: >> >> I know of 2 bots scripts at least, Seer and Zebulon. Could they be adapted to >> such a request? >> (this request, at least of a bot giving advice, is quite interesting imo) > > Possibly Seer, but your other idea seems a bit more user friendly. Seer is really cfbot, which can be found here: http://www.suckfuell.net/jochen/software.html#cfbot "cfbot is a perl script that logs into a crossfire game server and logs kills and other statistical information that the other players can query." The script would need some additional enhancements to function as a "guide" for new players, if it would work for this at all. It might be better to find a different approach - which it seems like the thread is heading towards anyway. ;-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070122/b1ed8797/attachment.pgp From cher at riedquat.de Wed Jan 31 14:33:26 2007 From: cher at riedquat.de (Christian Hujer) Date: Wed, 31 Jan 2007 21:33:26 +0100 Subject: [crossfire] Data File (Maps, Archetypes) Encodings Message-ID: <200701312133.32097.cher@riedquat.de> Hello dear co-devs. We have a common problem with the text encodings of data files. Examples: * Daimonin used (until a few minutes ago) the ISO paragraph character 0xA7 for separating a map's sound spec from its name. * Daimonin uses the ISO degree character 0xB0 for highlights in messages. * Crossfire uses the a circumflex character 0xE2 for the name of a wine in map /maps/scorn/houses/house3.bas2. This leads to some problems. * Crossfire x11 client displays 0xE2 as a circumflex. * Crossfire gtk client displays 0xE2 as ? (tested by Ragnor). For both projects, it makes sense to rethink the file formats. I see three possible solutions: 1. Use US-ASCII text only. That means, only data files with bytes 0x13, 0x20-0x7E are valid. Pro: easy Pro: stable Pro: no changes required. Con: very limited solution 2. Use ISO-8859-15 text. That means, bytes 0x13, 0x20-0x7E, 0xA0-0xFF are valid. Pro: easy Con: clients need special handling for non-ascii chars if they are UTF-8 aware and run on UTF-8 systems (e.g. gtk client). Con: limited solution 3. Use UTF-8 text. That means, only valid UTF-8 streams with Unicodes u0013, u0020-u007E, u00A0-... are valid. Pro: future-proof Pro: Allows full unicode (e.g. Chinese chars if somebody likes, or even klingon if the underlying system supports it). Con: clients need special handling. Con: Windows users or users of other ancient OS editions with no good UTF-8 support will have more problems than with ISO-8859-15. I see two places, where the encoding needs to be specified: * Data files * Network protocol My favorite solution would be 3. UTF-8, followed by 1. US-ASCII. I dislike 2. ISO-8859-15 very much. What do you think? -- Christian Hujer Free software developer mailto:cher at riedquat.de http://www.riedquat.de/ PGP Fingerprint: 03DE 4B72 4E57 A98D C79B 24A5 212E 0217 0554 CCAB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070131/fc022c35/attachment.pgp