From mwedel at sonic.net Mon Jul 1 02:21:11 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:32 2005 Subject: [CF-Devel] Re: Suggestions References: Message-ID: <3D2002E7.7050601@sonic.net> this was sent to me, thought I'd send the reply to the list since it didn't have a valid return address anyways. Chris TheMan wrote: > Hello. > He has told me that your organization accepts suggestions on > possible improvements. I realize this may be premature of me, > but from how I understand the nature of this game to be, I > thought I might suggest a couple of mechanics that you > probably won't, but hopefully will, find useful. > > I think this might already exist, but what about allowing for > contractual elements that would form players into "adventuring > companies" who would share the spoils of their conquest > according to an agreed-upon formula that, in practice, would > depend on the combat power contributed to the group. This, I > believe, would make for some great group play. There is the ability to form groups which share experience. I suppose that could be extended so that different people get different shares of the experience. The sharing of loots (treasure) is much more difficult. Cost on many things is variable, and probably only a small portion of loot is in actual money - most is is in items. My personal thought is that the players can make whatever agreements on the loot. The gaining of exp and how it is divied up is something that automatically happens through the server code. Treasure is all what people decide to pick up. It seems reasonable that that could be a more 'social' enforcement. Eg, the party agrees the treasure is split evenly, and if one member is apparantly ripping them off, the other party members can try for revenge or to get the money out or whatever else. > Another would be to have a sociological context, with elements > under the computer's control. What if someone was elected as > town mayor? They could potentially have control over > computer forces. This one's a little more ambitious, but there > you go. I think things have been slowly going in this direction. You could certainly add any number of elective offices. They are only really interesting if those offices have some powers, and those powers should still exist even if the mayor is not actively playing. Some simple things could be the mayor allowing/prohibiting spellcasting within the town, maybe having tax rates, entry fees, etc. However, I think if any of that is done, it should not be done in scorn. Perhaps navar city or santo dominion or whatever, but new players/characters should come into a place that is reasonably consistent. Of course, there is always the interesting idea of different starting locations. This could actually be synthesized pretty easily right now - the class changers could teleport the player to another map that then has different choices. OTOH, as said, I'd much rather change the character creation process to get rid of the hall of selection thing. From temitchell at sympatico.ca Mon Jul 1 13:20:14 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:32 2005 Subject: [CF-Devel] Re: Suggestions References: <3D2002E7.7050601@sonic.net> Message-ID: <000401c2212b$f20c5500$0a02a8c0@kameria> I do like the idea of different starting locations, especially since this will somewhat offset the aformentioned problem of having the maps used up so quickly. Having three or four starting towns and loosly arraying the maps in expanding zones of greater difficulty around them would be very useful in my opinion. Adding in wilderness encounters would also spice this up. There are always ships and caravans to traverse the wild safely for a price. Having players from different 'home towns' could be further leveraged by creating citizen papers and adjusting the costs of good and services higher when players visiting other locals (perhaps using some modification of the charisma/barter mechanics) of course you could always purchase citizen papers for other locals.... and some cities would have unique services...Players could possibly have their citizenship revoked by a city for crimes... Of course you would need more maps, especially of the Scorn nobility type. Laying the ground work for this would be good to do in conjunction with the world maps changes that are being done. ----- Original Message ----- From: "Mark Wedel" To: Sent: Monday, July 01, 2002 3:21 AM Subject: [CF-Devel] Re: Suggestions > > this was sent to me, thought I'd send the reply to the list since it didn't > have a valid return address anyways. > > > Chris TheMan wrote: > > > Hello. > > > > > > He has told me that your organization accepts suggestions on > > possible improvements. I realize this may be premature of me, > > but from how I understand the nature of this game to be, I > > thought I might suggest a couple of mechanics that you > > probably won't, but hopefully will, find useful. > > > > I think this might already exist, but what about allowing for > > contractual elements that would form players into "adventuring > > companies" who would share the spoils of their conquest > > according to an agreed-upon formula that, in practice, would > > depend on the combat power contributed to the group. This, I > > believe, would make for some great group play. > > > There is the ability to form groups which share experience. I suppose that > could be extended so that different people get different shares of the experience. > > The sharing of loots (treasure) is much more difficult. Cost on many things > is variable, and probably only a small portion of loot is in actual money - most > is is in items. > > My personal thought is that the players can make whatever agreements on the > loot. The gaining of exp and how it is divied up is something that > automatically happens through the server code. Treasure is all what people > decide to pick up. It seems reasonable that that could be a more 'social' > enforcement. Eg, the party agrees the treasure is split evenly, and if one > member is apparantly ripping them off, the other party members can try for > revenge or to get the money out or whatever else. > > > > > Another would be to have a sociological context, with elements > > under the computer's control. What if someone was elected as > > town mayor? They could potentially have control over > > computer forces. This one's a little more ambitious, but there > > you go. > > > I think things have been slowly going in this direction. You could certainly > add any number of elective offices. They are only really interesting if those > offices have some powers, and those powers should still exist even if the mayor > is not actively playing. Some simple things could be the mayor > allowing/prohibiting spellcasting within the town, maybe having tax rates, entry > fees, etc. > > However, I think if any of that is done, it should not be done in scorn. > Perhaps navar city or santo dominion or whatever, but new players/characters > should come into a place that is reasonably consistent. > > Of course, there is always the interesting idea of different starting > locations. This could actually be synthesized pretty easily right now - the > class changers could teleport the player to another map that then has different > choices. OTOH, as said, I'd much rather change the character creation process > to get rid of the hall of selection thing. > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From root at garbled.net Mon Jul 1 13:22:32 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:02:32 2005 Subject: [CF-Devel] Re: Suggestions In-Reply-To: <000401c2212b$f20c5500$0a02a8c0@kameria> Message-ID: On 01-Jul-02 Todd Mitchell wrote: > I do like the idea of different starting locations, especially since this > will somewhat offset the aformentioned problem of having the maps used up so > quickly. I tried this on the mud. 2 things happened: 1) Players bitched because we didn't let them pick where they started. 2) We fixed it and everyone picked midgaard. In the end, even with lots and lots of players.. everyone hangs out in the center of midgaard to be social. The fewer the players, the more pronounced the effect. IMHO, it was a monumental waste of time, because it took *forever* to fix the maps up to be properly balanced for it to work, and then ~nobody used it. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From mwedel at sonic.net Mon Jul 1 17:50:05 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:32 2005 Subject: [CF-Devel] Re: Suggestions References: Message-ID: <3D20DC9D.8030401@sonic.net> Tim Rightnour wrote: > On 01-Jul-02 Todd Mitchell wrote: > >>I do like the idea of different starting locations, especially since this >>will somewhat offset the aformentioned problem of having the maps used up so >>quickly. >> > > I tried this on the mud. 2 things happened: > > 1) Players bitched because we didn't let them pick where they started. > > 2) We fixed it and everyone picked midgaard. My personal thought was that the player would pick what starting location they wanted. Thus, if from past play experience they new town XYZ had a mayor they liked, they could choose to start there. Most people might choose scorn. > > In the end, even with lots and lots of players.. everyone hangs out in the > center of midgaard to be social. The fewer the players, the more pronounced > the effect. IMHO, it was a monumental waste of time, because it took *forever* > to fix the maps up to be properly balanced for it to work, and then ~nobody > used it. That is probably a bigger issue. As it is now, starting in navar city would be pointless - there are no low level (<5) dungeons about, so the character would have to go to scorn anyways. Adding low level dungeons to all the possible starting locations is certainly a lot of work. In some longer term, it may not be a terrible thing that if (big if) we get to the point where there are lots of dungeons that they get spread around more - have some low level dungeons in the other towns. But probably more relevant is that unless the different towns are sufficiently different, there won't be much point to start in one vs the other. From mwedel at sonic.net Mon Jul 1 18:15:20 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:32 2005 Subject: [CF-Devel] [Fwd: Re: DM command: freeze] References: <3D1BDAE6.3040806@sonic.net> <20020629170024.GA24909@mids.student.utwente.nl> Message-ID: <3D20E288.5070803@sonic.net> Joris Bontje wrote: > On Sat, Jun 29, 2002 at 08:51:59AM -0700, Tim Rightnour wrote: > >>[something about the jail command] >> > > Additionally special 'silence' floortiles can be added, who disallow the > command shout and tell. maybe say too, but then there is no way to > torture and interrogate prisoners. Actually may be easier to make some attributes, like no shouting, map attribute flags. In that way, the jail maps just has special values set in the header which correspond for the entire map. That is easier than putting a bunch of tiles down, and also faster within the code. Perhaps also have a no damage/no attack attribute, so even if you put two players in the same cell, they can't hurt each other. Note that some of these attributes could be useful on non jail maps, like the hall of selection. Make prison unique maps would be overkill - first, they would need to be per player unique maps if you wanted to make sure two players were not sharing the same cell. That makes things a lot trickier if the dm wants to visit the people in jail. Or even if just other players want to go through and see who is in jail. It'd probably be easier to make a special one way teleporter object that has a list of locations in its message pointer. It would go through that list and if the space is free, teleport the player there, if not, go to the next in its list, and so on. In any case, are there many times where there are multiple people in jail at the same time? Re form of jails file: The idea of putting it in the maps area is that way different map distibutions can more easily be used - its just a matter of untarring them. If it is in the installed shared area, it now means that the server has a notion of the maps that may be in use. But in any case, I was envisioning a jails file like: alias:map name:x:y sc1:/scorn/misc/jail:5:10 sc5:/scorn/misc/jail:10:10 nv1:/navar_city/misc/jail:8:12 or whatever else. So the dm would do something like 'jail mark sc1', which then dumps mark into /scorn/misc/jail at position 5,10. (sc1 is an abbreviation for scorn, 1 minute). aliases could be whatever, but it seems that short aliases would be idea. Perhaps extend that file to have a command, so if the dm just does 'jail', it basically dumps out that file so the dm has a better idea of the options (the comment may say 'scorn city jail, 1 minute'.) Idea being to make it easier on new dm's to know what they are doing. From mwedel at sonic.net Tue Jul 2 00:40:38 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:33 2005 Subject: [CF-Devel] Crossfire 1.3.0 released Message-ID: <3D213CD6.8050706@sonic.net> Crossfire 1.3.0 has been released. There are numerous bug fixes in this, as well as improved item handling code (better item sorting with new client, as well as proper naming of plural objects). Files released for this version: sums (bsd) filename 17699 1332 crossfire-1.3.0-arch.tar.bz2 52744 1427 crossfire-1.3.0-arch.tar.gz 56236 2869 crossfire-1.3.0-maps.tar.bz2 58818 4186 crossfire-1.3.0-maps.tar.gz 37910 996 crossfire-1.3.0.doc.tar.gz 50029 2861 crossfire-1.3.0.tar.bz2 64559 3191 crossfire-1.3.0.tar.gz 61233 380 crossfire-client-1.3.0.tar.gz 27814 1276 crossfire-client-images-1.3.0.tar.gz Sums (md5) bb53582498faafc9a2ced8f6af6d861b crossfire-1.3.0-arch.tar.bz2 579072ebf6aa99536e7fdfcd435976a4 crossfire-1.3.0-arch.tar.gz 5308e236b390eb011c8f28bccb52df56 crossfire-1.3.0-maps.tar.bz2 632420953861ca96fc56d437a28da36a crossfire-1.3.0-maps.tar.gz a682581581b95989ed9f93bc15161e7d crossfire-1.3.0.doc.tar.gz 5a1702e1605bd032510ee3aabba87880 crossfire-1.3.0.tar.bz2 d1b4a00121b2a42d56c63c43a1c41de2 crossfire-1.3.0.tar.gz fc4c91bcd66c53e8da8ef13ab9554b04 crossfire-client-1.3.0.tar.gz d0115d1e429116a42080b48ea8cdfae3 crossfire-client-images-1.3.0.tar.gz crossfire-client-1.3.0 is the client (X11) distribution - standard X11 and gtk interfaces are provided. Improved object handling is now supported, and extension for future map handling has been added. crossfire-client-images.1.3.0.tar.gz is a prebuilt image file for the client - downloading this file will reduce the amount of download that needs to happen during play if the -cache option is used. This file should be untarred in the ${prefix}/share/crossfire-client directory, where ${prefix} is the --prefix option given when configure is run. The default path is /usr/local/share/crossfire-client/. crossfire-1.3.0.tar.{gz/bz2} contains the server code with prebuilt archetype and image files. crossfire-1.3.0.arch.tar.{gz/bz2} contains the unpacked archetype changes. This is not needed if you only want to compile the server and play the game. crossfire-1.3.0-maps.tar.{gz/bz2} contains the maps. This is needed with the server distribution. crossfire-1.3.0.doc.tar.gz contains preformatted documentation. In this, you get the postscript spoiler and handbook, but you also get the html versions of both of those files with all the needed graphics - this is the only archive that has all the graphics pre-made. FOR FIRST TIME USERS: You will only need the appropriate server, map and client file. You do not need the arch file. You may wish to get a copy of the doc file. If you just want to play the game at some remote server, you need the client and perhaps the image archive file. Crossfire is avaible on the following ftp sites Primary: ftp://ftp.sourceforge.net/pub/sourceforge/crossfire (64.28.67.101) Secondary: ftp://ftp.real-time.com/pub/games/crossfire ftp://ftp.cs.city.ac.uk/pub/games/crossfire/ ftp://ftp.cs.titech.ac.jp/pub/games/crossfire ftp://mirror.aarnet.edu.au/games/roguelike/crossfire/ ftp://crossfire.futt.org//pub/crossfire The initial upload of this release is only made to sourceforge - it should show up on the mirrors shortly. Mark Wedel mwedel@sonic.net Complete changelog: server: socket/request.c: If players were using the original map command with an even map size, server would try to send too much data to client - checking in server would result in an abort. Modify code to now properly send right number of spaces. lib/Makefile.in: remove extraneous / in front of motd entry in file list. include/version.h: Update for version 1.3.0 Makefile.in: Update for version 1.3.0 lib/archetypes: rebuilt. MSW 2002-07-01 doc updates: Rebuild the doc files, but most of this is fixing some of the doc build stuff to correctly working with the new image set naming scheme and fixing some bugs. Some doc is certainly out of date - the playbook doesn't mention the classes for example. doc/handbook.ps, doc/spoiler.ps: rebuilt Note: all the doc/playbook changes also apply to the same files in doc/playbook-html. doc/playbook/Makefile.in, doc/playbook/makeps, doc/playbook/makeps.pl: replace the awk makeps script with the perl one. doc/playbook/items-extract: Don't show invisible items. doc/playbook/levels-extract: Update so that it properly finds the declaration of the levels in living.c doc/playbook/treas1-extract: Clear type when we get a new Object header. was resulting in duplicate entries for the characters. doc/playbook/treas2-extract: Don't include forces of the no_class_face_change as part of characters treasures doc/playbook-html/chap1.html: Update ftp site information. doc/spoiler/Makefile.in, doc/spoiler/makeps.pl, doc/spoiler/makeps: replace the awk makeps script with the perl one. doc/spoiler/items-extract: Add a space after the name match so that it won't match on the name_pl field. doc/spoiler-html/items-extract: Add a space after the name match so that it won't match on the name_pl field. doc/spoiler-html/makeps.pl: Update to handle new naming scheme for images. doc/spoiler-html/spoiler.html: rebuilt. lib/Makefile.in: Fix error in variable not being surrounded by parens. MSW 2002-06-30 server/rune.c: Fix bug that allowed players to use marking runes to create arbitrary objects by embedding a endmsg in the string. MSW 2002-06-26 lib/ban_file: Update comments to describe how it actually works. server/commands.c: Add some time cost to shout, say, and tell commands. This prevents abusive players from issuing huge number of these commands. MSW 2002-06-20 doc/playbook-html/Makefile.in: Remove some superfluous blank lines in the file. configure, configure.in, plugin/Makefile.in: Modify configure script to subtitute PLUGIN_TARGET, have plugin/Makefile not build/install plugin if necessary support libraries are not in place. common/item.c, include/material.h: Move the declaration/initialization of materialtype from material.h to item.c server/main.c: Modify crypt_string so that on Freebsd systems, it will use des_crypt if available, if not, won't encrypt. MSW 2002-06-18 TODO: Additional updates. Add support for loading the EMERGENCY_.. locations from a .emergency file in the map directory. This makes it easy to switch map distributions without the need to recompile. The emergency information is now stored in the settings structure. common/init.c: add EMERGENCY_ defines to default values in setting. Add init_emergency_mappath which loads the information. include/config.h: Remove NEW_WORLD_MAP definition, as it is no longer needed. Update some of the EMERGENCY_.. information as we don't need to include the information for the new world map. include/global.h: Add emergency_.. fields to settings structure. server/login.c, server/main.c, server/player.c: Update references from the EMERGENCY.. values to settings.emergency values. MSW 2002-06-15 lib/Makefile.in: modified so that it doesn't overwrite commonly customized files (eg, motd, dm_file, ban_file). These files will get installed on new installations. MSW 2002-06-14 common/item.c: break out monster description into describe_monster function from describe_item - the later was a really long function. Reveal weapon speed for identified weapons, spell point regen penalty and max speed for identified armor - this was discussed about 6 weeks ago. Clean up the code to reduce the number of redundant if statements and otherwise confusing code in describe_item. MSW 2002-06-14 configure.in, configure, plugin/Makefile, plugin/Makefile.in, plugin/Makefile.old: Modify the plugin module to gets its needed information from configure. configure.in modified to look for Python.h and to find the python library. plugin/Makefile.in is a new file. plugin/Makefile.old is the old plugin/Makefile (removed) - may be useful for sites where configure does not work for some reason. The use of --with-includes=-I/usr/include/python2.2 (or the like) will likely be needed for configure to find the Python.h file. Note - if you are doing a CVS update, you will need to re-run configure with the appropriate options for this change to take effect. MSW 2002-06-13 server/main.c: If on freebsd system, don't crypt the password. Crypt on freebsd behaves diferently, and since there is little reason to encrypt passwords, easier to just leave them decrypted. Fix for sourceforge bug 469017 MSW 2002-06-13 More minor changes, including a fix for the disappearing object bug - this was caused by the flag_links not getting updated the last time new flags were added. Problem probably only showed up now because loader.c wasn't rebuilt until recent changes. -- common/loader.c, common/loader.l: add extern to arch_init, when loading and get an object from a file, complain and ignore it if arch_init is not set (only time we should get object (vs arch) for names is when we load the archetypes file). Add missing entries to flag_links array. common/treasure.c: Fix code so that proper plural names are generated for custom items (potions, flesh items, etc). include/define.h: Add note about updating flag_links when NUM_FLAGS is increased. server/skills.c: don't let players steal from players with FLAG_WIZ set. MSW 2002-06-09 Mostly bugfixes. I'm not sure if this will fix the disappearing arch problem- none of the changes made in the original multiple name would seem to cause it, so hard to say if any of these changes may fix it. -- common/arch.c: Change get_archetype_by_name to be more efficient and not leak memory. Modify code that frees all archetype data to free the name_pl information. Make sure the clone.name_pl is set to NULL. When singularites are created, set the name_pl for them. common/loader.l, common/loader.c: Modify code that fixes up name_pl to be more correct when it fixes up name_pl for old objects. common/map.c: Modify load_map_header so that tile_paths will be normalized - need for editor to be able to load maps that have a multipart object that spans the maps. crossedit/Edit.c: Modify some calls of out_of_map to OUT_OF_REAL_MAP, since tiling code really isn't fully in place for the editor. Modify EditPerformFill so that it actually works and doesn't crash the editor. include/global.h: Move FREE_AND_COPY macro from loader.l to here so that all source code files can use it. lib/adm/map_info: Modify to actually be able to examine just a sub portion of the map directories, and not all of them. Don't always show the unused objects - information isn't very interesting if only a portion is being examined. Modify the exit examining code to properly deal with random maps (if there is a finalmap component, make sure that does exist.) Loade the bmaps file and not the faces file to find valid faces. plugin/plugin_python.c: Add missing %s that described what script was actually loaded. random_maps/special.c, server/alchemy.c, server/c_misc.c, server/gods.c, server/login.c, server/player.c, server/spell_effect.c: Set up proper name_pl value for code that changes the name of objects. server/apply.c: Use FREE_AND_COPY to set up names. Set up proper name_pl values for cases that change name. In apply_lighter, call fix_player if player is lighting an object in his inventory - necessary for the players glow_radius to get updated so the change actually takes effect. socket/request.c: Modify esrv_map_scroll so that it properly clears cells that are moving out of view - failure to do this was resulting in the map1a updating these spaces with empty faces. This was causing fog of war wackiness with the client. MSW 2002-06-06 common/button.c: Fix mood floor code - before, it was changing the moods of all sorts of objects (luggage, itself, etc). Now, it only changes objects above the floor, and only monsters. MSW 2002-05-31 Main change is the addition of name_pl and client_type to object structure. The name_pl contains the proper plural name instance - fixes problem of '2 tooths'. client_type is sent to the client so that client doesn't need to figure out sorting on its own. Client_type is an object attribute, so can be modified in maps to hide the real type. -- common/arch.c: item_matched_string() modified to use the name_pl field when trying to match names, and not to try to make the name plural itself. common/item.c: query_short_name(),query_base_name() modified to use name_pl instead of trying to make the name plural. common/loader.c, common/loader.l: Add code to load and save the name_pl value and client_type. Add logic when object is finished loading to set name_pl value to same as name or arch name if no name_pl is specified - this supports old maps/characters in which the objects dont have a name_pl field yet. Disable logic for need_an and need_ie flags since they are no longer needed. Fix bug that caused elevation not to get saved. common/object.c: Add client_type check for CAN_MERGE function. Add appropriate logice in functions to handle setting, clearing, and copying of name_pl values. Remove unused anim_... fields initialization. doc/Developers/objects: Add information about the name_pl field and client_type. doc/Developers/protocol: Remove item protocol command info - it has been obsoleted. Add information about item2 protocol command. include/define.h: Remote ST1_* values - they were not being used. comment out FLAG_AN and FLAG_NEED_IE values. include/newserver.h: Add itemcmd to socket structure - this is the version of the item protocol command that will be sent to the client. include/object.h: Add name_pl and client_type field to object structure. Remove unused anim_* values. lib/archetypes: rebuilt with new archetypes that contain client_type and name_pl information. lib/bmaps, lib/bmaps.paths, lib/crossfire.1, lib/crossfire.0, lib/faces: rebuilt. server/monster.c: Remove anim_ references that were not being used. socket/init.c: Initialize itemcmd version in the socket to 1. socket/item.c: Remove special handling for clients of old versions - all clients now have to be at least sc_version 1024 (which has been around for a long time). This simplifies a lot of the object code that deals with sending or not sending plural names to the client - now always send them. Change code that sends item to client to use the item revision (currently 1 or 2) that the client wants. If version 2, send along client_type information. socket/request.c: Handle 'itemcmd' parameter in setup command. Make sure it is in proper range. If client is very old (sc_version < 1024) tell them so. MSW 2002-05-30 crossedit/png.c, crossedit/xutil.c: Increase size of temporary buffers that are used when loading images - necessary to allow the editor to run without crashing. include/newserver.h: Remove quick_pos from the MapCell structure. server/main.c: Add code to set the coordinates to the EMERGENCY_X/Y values if using the EMERGENCY_MAP. socket/request.c: Fix code that was causing darkness to get repeatedly sent for some spaces. MSW 2002-05-19 The bulk of this commit is to modify the server to only send the lower rightmost part of multipart archetypes that use the same head. This allows support of big images in the client. common/arch.c: Modify first_arch_pass to figure out the tail_x/y values for multipart archs. Rename the prev variable to head, as that it really what it is. Remove quick_pos info. common/object.c: remove quick_pos info from object. doc/Developers/images: Add notes about using merged images. doc/Developers/protocol: Add information about the map1a command, which is used to for big image support. Remove map2 documentation. include/map.h: Add MAP_LAYERS define instead of using hardcoded value of 3. include/newserver.h: Change the MapCell to use MAP_LAYERS - saves considerable memory. Add defines for MAX_CLIENT_ map sizes. Remove map1cmd, map2cmd elements from socket structure - instead use enumeration of mapmode - only one map type will be used at any time by the client, so no reason to have individual elements - it also makes it easier to add new mapmode commands. include/object.h: remove quick_pos, update_tag from object structure. Add tail_x, tail_y values to archetype structure. include/player.h: Remove some now unused values from the player structure (drawn, floor, floor2, darkmask). These have been superseded by the map cells in the socket structure for quite a while. include/sockproto.h: rebuilt server/player.c: Remove code that initialized the drawn values in the player structure since they no longer exist. socket/init.c: Replace map1cmd, map2cmd elements in socket structure with mapmode element. Modify init_ericserver so that it properly passes an int when setting the SO_REUSERADDR field. socket/request.c: Modify code in SetUp function to use the new mapmode enumeration in the socket structure. Add support for map1acmd setup option. Throughout map code, replace MAXMAPCELLFACES with MAP_LAYERS. modify map_clearcell to take options for values to clear the cell to. Add have_head, check_head, and update_space commands - used with the map1 command to store and find head information. draw_client_map1 modified to support map1a extensions, as well as added logic for checking for heads in blocked and out of viewable map spaces. Some of the code is simplified by using the update_space function, since the logic for processing each layer was otherwise the same. remove draw_client_map2 function. esrv_map_scroll has same logic - some variables and code formatting changes. MSW 2002-05-18 server/login.c, server/c_misc.c: Don't save characters with 0 experience. This apparantly fixes some abuses. MSW 2002-05-18 server/attack.c: Don't generate PLAYER_KILL_PLAYER messages if kill happened on battleground. Also, datestamp the messages. MSW 2002-05-13 server/attack.c: Generate log message when a player kills another player - include the ip address of the killer to make it easier to add them to ban files. MSW 2002-05-06 Client changes: Add support for the 'item2' command. This lets us get the item type from the server so that we don't need to figure it out for ourselves. Also, remove support for the 'item' command - that has long since been obseleted by the 'item1' command. -- common/client.c: Remove 'item' from dispatch table, add 'item2'. Add 'itemcmd 2' as part of setup command we send to server. common/commands.c: Add handling for response of 'itemcmd' setup command from server. Remove ItemCmd() function. Add type to calls to update_item(). Change Item1Cmd() function to be called common_item_command() since both item1 and item2 use almost exactly the same logic. Add Item1Cmd() and Item2Cmd() which just call common_item_command() common/item.c: Init item types to 'NO_ITEM_TYPE'. Remove get_nrof() as it was no longer being used. Add type argument to set_item_values() and update_item(). Simplify code in case of name handling, since we know that we will be using at least the 'itemcmd'. Don't worry about getting proper nrof for the player object - its nrof isn't really meaningful anyways. common/item.h: Add #define NO_ITEM_TYPE. Update type field in item to be 16 bits. common/proto.h: rebuilt. MSW 2002-05-30 The bulk of this checkin adds support in the client for the map1a protocol command and the display of big images properly in the map window. A lot of code cleanup was also done however, including removal for the support of the 'map' (original) command. The map1 has been in the server code for quite a while. TODO: Update what needs to be done for the x11 client. common/client.c: Remove map command, add map1a command to dispatch table. Modify setup we send to server to always try to use the map1a command - there is no reason not to use it. common/client.h: Change some of the CONFIG_ values - basically, change it so that there is just one entry for lighting configuration, but it can have any number of values. Modify MapCell so that instead of having multiple arrays for the different values (faces, sizes), add a MapCellLayer structure that contains the specific face information for that layer. Move the PlayerPosition struct and value to this function so that more of the map decompress logic can be handled in the common code. Remove count value from MapCell since it wasn't really being used. common/commands.c: Add code to set the use_config[CONFIG_CACHE] value based on what we get back from the server. Add code to check the setup response for the for the map1a and map1 options. Add code to deal with expanding big images into appropriate spaces. Move some functions from the gui portion to (display_map_clearcell, set_map_face). Add code for map1_common function to deal with map1a extensions. common/external.h: Remove display_map_clearcell and set_map_face from list of external functions. Add get_map_image_size function. common/init.c: change some values of the config values. Update initialization of config values for lighting. common/proto.h: rebuilt. gtk/config.c: Add new button for lighting - best per pixel. Modify code to properly deal with how lighting preference is now stored. Add legacy support for loading of per_tile_lighting and per_pixel_lighting values from config file. Add diagnostic of bad value if selected map/width is out of range. gtk/gtkproto.h: rebuilt. gtk/gx11.c: Change formatting of draw_list. Modify it so that it adjusts the column/row width based on the largest image it needs to display - In this way, if a player stands on a big building, the entire building is displayed in the look list. add row_height and column_width values so we only need to call the function to change them if they are in fact different. Add +sdl command line option to disable sdl code. Modify gtk_draw_map to include redraw parameter. gtk/gx11.h: remove PlayerPosition structure. add row_height, column_width elements to itemlist structure. gtk/image.c: Add table that is used to determine the scaling used for big images in the look list - in this way, big images still appear big, but not necessary 2 or 3 times bigger. Modify create_and_rescale_image_from_data to use this logic. Add get_map_image_size which the common code uses to determine the number of spaces an image may be. gtk/map.c: remove display_map_clearcell and set_map_face functions - now in common code. Modify the dump map/darkness routines to use the new format of the MapCell structure. Modify set_darkness to only set adjoining spaces for needing an update if lighting type is set that needs this. Remove display_map_addbelow - only used for 'map' command. Modify logic of fog of war code to have it done all at display time - not when setting/clearin g a cells contents. Modify gtk_draw_map - this basically follows the same logic of sdl_draw_map - it is now better optimized to only draw the spaces that have changed, and not the entire map - this should improve performance considerably. gtk/sdl.c: Remove #if 0 around putpixel - used for best lighting. Change indention of init_SDL - modify it so that if just_lightmap is true, that really is the only thing that is changed. Modify per_pixel_light code to use both methods of per pixel lighting depending on player prefernce. Modify sdl_gen_map to properly handle draw portion of big images. x11/png.c: Add get_map_image_size function. x11/x11.c: modify display_mapcell_pixmap to use new format of MapCell structure. Remove reference to count in MapCell structure. x11/x11.h: Remove PlayerPosition information - now in common code. x11/x11proto.h: rebuilt. x11/xutil.c: Remove display_map_clearcell and set_map_face functions. Modify du mp map code for new MapCell structure layout. Remove display_map_addbelow funtion. From temitchell at sympatico.ca Tue Jul 2 19:37:05 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:33 2005 Subject: [CF-Devel] Crossfire 1.3.0 released References: <3D213CD6.8050706@sonic.net> Message-ID: <000801c22229$c1d720a0$0a02a8c0@kameria> FYI Well 1.3.0 seems to work ok with the DX client - I tried it on mids and everything was a go (I didn't do anything fancy however). From jbontje at suespammers.org Wed Jul 3 14:18:19 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:02:33 2005 Subject: [CF-Devel] Freshmeat announcement? Message-ID: <20020703191819.GA4624@mids.student.utwente.nl> Since we are 1.3.0 now, maybe another Freshmeat update should be done? That triggers porters to update etc. Freshmeat is still on 1.0.0 now. mids -- PGP Key: http://pgp.dtype.org:11371/pks/lookup?op=get&search=0xF19326A9 Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020703/7dbc5b75/attachment.pgp From muehlber at fh-brandenburg.de Fri Jul 5 08:49:02 2002 From: muehlber at fh-brandenburg.de (Jan Tobias Muehlberg) Date: Thu Jan 13 18:02:33 2005 Subject: [CF-Devel] Bug in Crossfire 1.3.0 Message-ID: <20020705154902.A9343@zeus.fh-brandenburg.de> Perhaps there is a bug in the new 1.3.0 server: Whenever I type "drop n " with n=1 only one of is droped. No problem so far. But for n>1 not only n of are droped. It seems that n items of everything I have at least n times, are droped. J. Tobias -- PGP/GnuPG public key: http://zeus.fh-brandenburg.de/~muehlber/muehlber.asc From mwedel at sonic.net Fri Jul 5 16:07:43 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:33 2005 Subject: [CF-Devel] Bug in Crossfire 1.3.0 References: <20020705154902.A9343@zeus.fh-brandenburg.de> Message-ID: <3D260A9F.7010509@sonic.net> Jan Tobias Muehlberg wrote: > > Perhaps there is a bug in the new 1.3.0 server: > Whenever I type "drop n " with n=1 only one of > is droped. No problem so far. But for n>1 not only n of are > droped. It seems that n items of everything I have at least n times, are > droped. Fixed in CVS. From mwedel at sonic.net Sun Jul 7 18:21:13 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:33 2005 Subject: [CF-Devel] Equipment musings Message-ID: <3D28CCE9.1020901@sonic.net> I'm currently implementing the ideas I sent to the list about a month ago - the item_power and the body location. In very quick summary, the body location is to give each race a set of locations on his body to equip stuff. Thus, a human has a torso, and armor uses the torso slot. However, a dragon doesn't have a torso, and thus can't wear armor (or at least human armor). This works out nicely - you can now more finely restricts what races can not can not wear (compared to the blanked can use armor flag). The one odd spot is bows/weapons/shields. You can also do things like give a fireborn 4 fingers so it can wear four rings. The way the code is you have 2 'arms' for the above mentioned item. A sword would use one, and a shield another. A bow uses both, requiring that you unequip your weapon and shield (as per discussions on the mailing list). Similarly, you can make 2 handed weapons that also require the removal of shield. This all works fine until you examine some of the strange interactions. A character that is prohibited from using weapons is really prohibited from melee weapons - it can still use bows. Thus, the dragon, monk, etc can fire that bow. For some races, this doesn't make too much sense - if the dragon can't use a weapon or shield because of his strange physiology, it doesn't make much sense that he can use a bow. My solution in that case is to just give him 0 'arm's, so he can't use bows, shields, or weapons. I think that is the right approach, but this obviously weakens him some. I think the can use weapon flag will still be needed for things like monks and/or worshippers of gaea. In my original thinking, the idea would be that you would just have the force object use up some of these locations. But a worshipper of gaea still needs to be allowed to use shields. So the can use weapon will be as it is now - a prohibition on melee weapons, but not range weapons. IMO, that isn't much a problem. The can_use_armor is more problematic. This is a case IMO where the force object should use up those body locations. This provides much finer grain of control (should a prohibition on armor really effect things like girdles? However, the problem with shields comes up again - you just can't reduce the body location, as the player could still choose to use a shield but without a weapon. The more I think about this, the more the idea of splitting the two arms apart makes more sense, eg, instead of having 'body_arms 2' for humanoids, have a 'body_weapon_arm 1' and 'body_shield_arm 1'. Things like bows or two handed weapons would then just use both of those locations. One reason this wasn't done was because of the idea of characters with two weapons (under current code, this won't be allowed because of the many problems it would cause). The alternative is to add a no_shield_flag to the various things that prohibit armor. I guess that isn't that hard. IT sort of gets away from the original idea in which item_type wouldn't be very important, eg, all items of all types have basically the same effects, and the body location information would just limit where the different things could get applied. I think that is probably what I will do for now. ITEM POWER: As part of these changes, I've decided to implement the item power idea I had. Basic summary was that each object would have an item_power rating, determined basically by how good it was, and your total equipment would have to be less than some value which is based on your overall level. Thus, first level characters wouldn't be able to use really great stuff, and even high level characters that have all the best artifacts would have to make choices on which to wear, as it won't be possible to wear all the best ones at the same time. This will make things harder, and from what I've seen, people generally think the high level stuff is too easy. The coding on this is actually pretty straightfoward. The hard part will be balancing. And more precisely, objects that have been created before this code goes into effect - for those objects, the computer calcuates the item_power (just as it would do for randomly created objects). The problem is that the calculation isn't very good right now when it comes to protections. In any case, my idea is to provide this information (examining an object will tell you its power rating, and the skills command will show you the total you have equipped. However, there won't be any prohibition enforced - you can still equip way more stuff than you should perhaps be allowed to. This will let us see how things are and tune them appropriately. Then some time in the future, the actual enforcement of these can be activated. -- I think both of these changes will make the game much more interesting - different races can really be much more different now, and many more ways to balance the races and classes. Hopefully, I'll have something to commit within a week. From temitchell at sympatico.ca Mon Jul 8 20:05:12 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:33 2005 Subject: [CF-Devel] scroll cases - 2 for a plattie! Message-ID: <001001c226e4$adbc6840$0a02a8c0@kameria> I created a scroll case arch container with 'race scrolls' and went through all the scroll type objects and added in 'race scrolls'. It works nicely holds around 30 scrolls and uses the rucksack png for now, but I was wondering if there was any hidden issues with adding 'race scrolls' to some of these arches (like the skills scrolls). I don't imagine there would be but thought I should check. If you want the arches they are at http://abraxis.sytes.net/CF/finished/arch - in the same folders they usually ship in. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020708/a9169a1c/attachment.htm From mwedel at sonic.net Mon Jul 8 23:21:13 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:33 2005 Subject: [CF-Devel] scroll cases - 2 for a plattie! References: <001001c226e4$adbc6840$0a02a8c0@kameria> Message-ID: <3D2A64B9.3050904@sonic.net> Todd Mitchell wrote: > I created a scroll case arch container with 'race scrolls' and went > through all the scroll type objects and added in 'race scrolls'. It > works nicely holds around 30 scrolls and uses the rucksack png for now, > but I was wondering if there was any hidden issues with adding 'race > scrolls' to some of these arches (like the skills scrolls). I don't > imagine there would be but thought I should check. > If you want the arches they are at > http://abraxis.sytes.net/CF/finished/arch - in the same folders they > usually ship in. Taking a very quick look at the code, it appears that there should be no problem with scrolls having a race. I'll grab the stuff you have sometime soon and put it in the main branch. From mwedel at sonic.net Fri Jul 12 01:53:34 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:33 2005 Subject: [CF-Devel] New Apply test server Message-ID: <3D2E7CEE.70504@sonic.net> I have set up a test server with the new body/apply code. It is tavern.santa-clara.ca.us. It is currently on the metaserver list. I've set this up to hopefully get some testing on this new code before I commit it. I've done some preliminary testing, but with the number of class/religion/race combinations, trying to cover all of those would be difficult. As the motd below says, I've populated the server from the player files on metalforge - this should give a good starting point of combinations that people can test against. For the most part, all the races are basically the same as they were (in terms of what they can equip). The one exception is the fireborn, which I've currently set up to be able to apply 4 rings and 2 amulets. Note that the item power code is also in place, but other than listing item power for differing objects, does not currently prevent players from applying things. Note that the server is running in a debugger, so if it crashes, it will be unavailble until I restart it. As said, I'd appreciate it for those of you who can to take 5-10 minutes and try differing things out - this will hopefully catch some of the worst bugs before I commit it into CVS. Thanks. Here is the MOTD from it: NOTICE: This is a test server for the new apply code. The server may be restarted without notice. Please do test out applying objects to make sure everything seems to work correctly. This server only has 128 kbs bandwidth, actually adventuring will likely be painful. That is not the purpose of this server! This server has been populated with the player files for metalforge.real-time.com to provide characters ready to test. Any changes made to these characters on this server (ie, adventuring) will get lost when the server is shut down. If you don't like these conditions, log off now. A few other notes: You can use the 'body command to see what slots your character has and how they are equipped. Some objects have been moved to the same slot, eg wands, rods, and horns all use the same inventory slot. So it is possible that old characters will be using more of these slots than they really have. See the 'applymode' help page. For other notes/questions, please see/use the crossfire-devel@lists.real-time.com mailing list. From root at garbled.net Sat Jul 13 10:50:57 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:02:33 2005 Subject: [CF-Devel] Equipment musings In-Reply-To: <3D28CCE9.1020901@sonic.net> Message-ID: On 07-Jul-02 Mark Wedel wrote: > For some races, this doesn't make too much sense - if the dragon can't use > a > weapon or shield because of his strange physiology, it doesn't make much > sense > that he can use a bow. My solution in that case is to just give him 0 > 'arm's, > so he can't use bows, shields, or weapons. I think that is the right > approach, > but this obviously weakens him some. Why not have the dragon "ship" with a pair of claws, that cannot be unwielded? This opens up the theoretical possibility of going to a dragon umm.. shop, and having your claws sharpened/impregnated with steel/etc. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From mwedel at sonic.net Sat Jul 13 23:32:25 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:33 2005 Subject: [CF-Devel] Equipment musings References: Message-ID: <3D30FED9.6000702@sonic.net> Tim Rightnour wrote: > On 07-Jul-02 Mark Wedel wrote: > >> For some races, this doesn't make too much sense - if the dragon can't use >>a >>weapon or shield because of his strange physiology, it doesn't make much >>sense >>that he can use a bow. My solution in that case is to just give him 0 >>'arm's, >>so he can't use bows, shields, or weapons. I think that is the right >>approach, >>but this obviously weakens him some. > > > Why not have the dragon "ship" with a pair of claws, that cannot be unwielded? > This opens up the theoretical possibility of going to a dragon umm.. shop, and > having your claws sharpened/impregnated with steel/etc. The code that will be checked in will make it extremely easy to add new body parts. In probably 10-20 lines of code (even documented where), you could add something like a 'body_dragon_claws' body location. Then it is just a matter of updating the dragon arch to actually have those claws, and creating some items for it to use. In practice, that could get done for all races that has strange physiologies - the Q could have a 'dragon torso', and thus need to go to hard to find places (or very expensive places) to buy armor that will fit on it. You could create 'dragon bows' for example that go on a slot that only dragon has. Its very extensible. However, such changes would need to have to be carefully thought out. The Q is a bit different of a race because it can't wear armor. If you now give the Q a dragon torso, dragon head, etc, and it is now able to wear armor analagous to the human, it isn't so special - especially if there is a 'dragon speciality shop' in town that sells that type of stuff. The Q would still be at somewhat a disadvantage simply because all the best artifact armor would still only be for humans. Of course, that lasts until someone decides to make really good artifact armor for the Q. However, it still does provide for many more areas of balance. Letting some races, like the fireborn, use more rings/amulets than a human normally could makes it a bit more different than the other races. And even in my Q example above, if carefully done, it would probably still be a good thing - being able to get some extra protection at low levels could be useful, as long as his choices are severely limited - it might give him a bit more chance of survival, or at least make survival a bit easier. From root at garbled.net Sun Jul 14 11:04:57 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:02:33 2005 Subject: [CF-Devel] Equipment musings In-Reply-To: <3D30FED9.6000702@sonic.net> Message-ID: On 14-Jul-02 Mark Wedel wrote: > The code that will be checked in will make it extremely easy to add new > body > parts. The point of the claws was to tie up the arms so you didn't have to perform a hack like "that dragon has zero arms". I can think of other uses for body location charts, for example, hacking an arm off, or critical hit messages that vary depending on the classifications of a target, (to avoid the message that says "you behead the amorphous blob"). --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From temitchell at sympatico.ca Sun Jul 14 12:01:27 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:33 2005 Subject: [CF-Devel] rodlike and wandlike items Message-ID: <000e01c22b58$1812d900$0a02a8c0@kameria> I was checking out the code that returns messages for rods and wands and horns (in player.c) because I wanted to make an item that recharged like a rod. Looking at the code the messages for ranged attacks are hard coded and there are case statements to spit them out depending on the item type. looks like this: case range_wand: for(weap=op->inv;weap!=NULL;weap=weap->below) if(weap->type==WAND&&QUERY_FLAG(weap, FLAG_APPLIED)) break; if(weap==NULL) { new_draw_info(NDI_UNIQUE, 0,op,"You have no wand readied."); op->contr->count_left=0; return; } if(weap->stats.food<=0) { play_sound_player_only(op->contr, SOUND_WAND_POOF,0,0); new_draw_info(NDI_UNIQUE, 0,op,"The wand says poof."); return; } if(cast_spell(op,weap,dir,op->contr->chosen_item_spell,0,spellWand,NULL)) { SET_FLAG(op, FLAG_BEEN_APPLIED); /* You now know something about it */ if (!(--weap->stats.food)) { object *tmp; if (weap->arch) { CLEAR_FLAG(weap, FLAG_ANIMATE); weap->face = weap->arch->clone.face; weap->speed = 0; update_ob_speed(weap); } if ((tmp=is_player_inv(weap))) esrv_update_item(UPD_ANIM, tmp, weap); } } case range_rod: case range_horn: for(weap=op->inv;weap!=NULL;weap=weap->below) if(QUERY_FLAG(weap, FLAG_APPLIED)&& weap->type==(op->contr->shoottype==range_rod?ROD:HORN)) break; if(weap==NULL) { char buf[MAX_BUF]; sprintf(buf, "You have no %s readied.", op->contr->shoottype == range_rod ? "rod" : "horn"); new_draw_info(NDI_UNIQUE, 0,op, buf); op->contr->count_left=0; return; } if(weap->stats.hpstats.sp].sp) { #if 0 LOG(llevDebug,"Horn/rod: %d < %d (%d)\n", weap->stats.hp, spells[weap->stats.sp].sp, weap->stats.sp); #endif play_sound_player_only(op->contr, SOUND_WAND_POOF,0,0); if (op->contr->shoottype == range_rod) new_draw_info(NDI_UNIQUE, 0,op,"The rod whines for a while, but nothing happens."); else new_draw_info(NDI_UNIQUE, 0,op, "No matter how hard you try you can't get another note out."); return; } if(cast_spell(op,weap,dir,op->contr->chosen_item_spell,0, op->contr->shoottype == range_rod ? spellRod : spellHorn,NULL)) { SET_FLAG(op, FLAG_BEEN_APPLIED); /* You now know something about it */ drain_rod_charge(weap); } return; I propose a small change here which I am not yet competent to execute. 1. Like to see two new item types - rodlike (for recharging items) and wandlike (for rechargable items). not sure what the best actual names should be... 'misc_rodlike' and 'misc_wandlike' ? 2. the player.c range code changed adding in a second case called 'range_misc_wandlike' to the wand portion and a third case called 'range_misc_rodlike' to the rod/horn portion which works off the else statement which will spit out generic messages like ' the %s seems to be out of juice' rather than the specific ones. In the wand section there would be an 'if - else' similar to the way the rod/horn section works, and for the rod/horn section there would be an 'if - if - else' if you get my drift here. something like this for wands case range_wand case range_misc_wandlike do this: if (op->contr->shoottype == range_wand) do this: else do this: do this: and this for rods/horns case range_rod case range_horn case range_misc_wandlike do this: if (op->contr->shoottype == range_rod) do this: if (op->contr->shoottype == range_horn) do this: else do this: do this: This I think would be pretty simple to change but then again there could be more to it than that since I am still puzzling my way along here. Any thoughts? It would allow for a whole bunch of new special items to be made which would be fun if not functionally too different.How about a magic stone of summoning or a teakettle of steambolt, or what I was trying to make 'Lythander's pipe of wonder' and 'Lythander's pipe of mass confusion' Just a suggestion. -tm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020714/665c23dd/attachment.html From mwedel at sonic.net Sun Jul 14 17:13:51 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:34 2005 Subject: [CF-Devel] Equipment musings References: Message-ID: <3D31F79F.4070306@sonic.net> Tim Rightnour wrote: > On 14-Jul-02 Mark Wedel wrote: > >> The code that will be checked in will make it extremely easy to add new >>body >>parts. > > > The point of the claws was to tie up the arms so you didn't have to perform a > hack like "that dragon has zero arms". I can think of other uses for body > location charts, for example, hacking an arm off, or critical hit messages that > vary depending on the classifications of a target, (to avoid the message that > says "you behead the amorphous blob"). Well, the change of body information wasn't really meant for stuff like the critical hit. But I see the point - if the information is there, use it. However, as it is now, there is no defined internal mapping - rather, there is table that contains the load/save names, as well as descriptive names for the locations. Their position in the table determines the position in the array the values are loaded in. So to use this for critical hits, the table probably needs to include another value, that contains information on of that part is something that could be taken out by a critical hit, and perhaps how critical a critical hit on it would be. For example, a critical hit can't really take out a skill slot or range slot. And a critical hit on the neck is very serious - much more so than one on a finger. It also gets more complicated, in that you have potential dependencies - if an arm is chopped of, then that also removes the ability to wear one ring, one brace, and one glove for example. However, that part wouldn't be too hard - unless a body part is directly connected to several others, you could just index one (eg, the shoulder points to arm, which points to wrist, which points to hand, which points to finger. So if the wrist is chopped off, thta then also includes the hand and finger, etc). But that is getting a bit beside the point of the current topic. When I wrote the code, I envisioned just not giving body parts to creates that don't have them, and not using force (or other objects) to use them up. Note also that such an approach makes for easier backward compatibility - for old players, they inherit the body information from the arch, so everything works. If force objects are used, then the load code has to check race, check to see if there is a force object, and insert an appropriate one. If new body parts are added which also races should have, this gets even more complicated. When we get to the point where this information will get used for other stuff, I think we should review the best way to do it. One of the points to doing this was to make it extensible for more body locations to get added, and I think that should happen - the game will have more flavor if for example that Quetzalcoutl has to buy different boots than other races. I should probably modify the artifacts file to let it modify the body part for items. Thus, you could have an artifact like: Object of dragons type boots body_foot 2 body_dragon_foot -2 end Where the body stuff in the object just modifies the basic version. Could also have things like 'armour of smallness', which halfling creatures need. From mwedel at sonic.net Sun Jul 14 17:20:34 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:34 2005 Subject: [CF-Devel] rodlike and wandlike items References: <000e01c22b58$1812d900$0a02a8c0@kameria> Message-ID: <3D31F932.6080502@sonic.net> Todd Mitchell wrote: > I was checking out the code that returns messages for rods and wands and > horns (in player.c) because I wanted to make an item that recharged like > a rod. Looking at the code the messages for ranged attacks are hard > coded and there are case statements to spit them out depending on the > item type. > looks like this: The question is what are you trying to do? > It would allow for a whole bunch of new special items to be made which > would be fun if not functionally too different.How about a magic stone > of summoning or a teakettle of steambolt, or what I was trying to make > 'Lythander's pipe of wonder' and 'Lythander's pipe of mass confusion' Note that just because an object is called 'rod' doesn't mean it has to look like a rod. You could have a magic stone of summoning, whose type is rod. In that way, it behaves exactly like a rod. Same can be true for wands (note staves are also of type wand). Note that with the new equipment change, rods/wands/horns all use the same range slot. I've made a trivial change so that if a wand or rod is out of charges, it is now like: new_draw_info_format(NDI_UNIQUE, 0,op,"The %s says poof.", query_base_name(item, 0)); new_draw_info_format(NDI_UNIQUE, 0,op, "The %s whines for a while, but nothing happens.", query_base_name(item,0)) Horns is still a hard coded case in which it says you can't get another note out. It should be mentioned except for that one message, horns and rods are pretty much functionally equivalant. So for what you want to do (lythanders pipe), probably just make them of type horn (I'm presuming they are things you blow through), and everything else should work - no other code change necessary. From temitchell at sympatico.ca Sun Jul 14 21:01:41 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:34 2005 Subject: [CF-Devel] rodlike and wandlike items References: <000e01c22b58$1812d900$0a02a8c0@kameria> <3D31F932.6080502@sonic.net> Message-ID: <000401c22ba3$9052bc00$0a02a8c0@kameria> ----- Original Message ----- From: "Mark Wedel" To: Sent: Sunday, July 14, 2002 6:20 PM Subject: Re: [CF-Devel] rodlike and wandlike items > Todd Mitchell wrote: > > I was checking out the code that returns messages for rods and wands and > > horns (in player.c) because I wanted to make an item that recharged like > > a rod. Looking at the code the messages for ranged attacks are hard > > coded and there are case statements to spit them out depending on the > > item type. > > looks like this: > > The question is what are you trying to do? > > > It would allow for a whole bunch of new special items to be made which > > would be fun if not functionally too different.How about a magic stone > > of summoning or a teakettle of steambolt, or what I was trying to make > > 'Lythander's pipe of wonder' and 'Lythander's pipe of mass confusion' > > Note that just because an object is called 'rod' doesn't mean it has to look > like a rod. You could have a magic stone of summoning, whose type is rod. In > that way, it behaves exactly like a rod. Since the messages were hardcoded and type specific I was proposing a (I thought) trivial change to address them. I had no problem making items based on the rod or wand type, but the messages were type specific (the pipe of mass wonder was based on the horn and would say "no matter how hard you try you can't get another note out" when it was out of power.) I was proposing a change to leave the type specific messages but have a generic instance for other items based on the type but not of the same appearance. You don't want your 'jewel of summoning' to say "the wand says poof" when it is out of charges or your 'snail idol of slow' to say "The rod whines for a while, but nothing happens." > Same can be true for wands (note staves are also of type wand). > > Note that with the new equipment change, rods/wands/horns all use the same > range slot. I've made a trivial change so that if a wand or rod is out of > charges, it is now like: > > new_draw_info_format(NDI_UNIQUE, 0,op,"The %s says poof.", > query_base_name(item, 0)); > new_draw_info_format(NDI_UNIQUE, 0,op, > "The %s whines for a while, but nothing happens.", > query_base_name(item,0)) > > Horns is still a hard coded case in which it says you can't get another note > out. It should be mentioned except for that one message, horns and rods are > pretty much functionally equivalant. > > So for what you want to do (lythanders pipe), probably just make them of type > horn (I'm presuming they are things you blow through), and everything else > should work - no other code change necessary. No the pipe was the smoking kind. I knew you were changing the ranged code so though I should bring this up. If you have modified the code to make these messages more generic already then great. From mwedel at sonic.net Sun Jul 14 23:08:23 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:34 2005 Subject: [CF-Devel] rodlike and wandlike items References: <000e01c22b58$1812d900$0a02a8c0@kameria> <3D31F932.6080502@sonic.net> <000401c22ba3$9052bc00$0a02a8c0@kameria> Message-ID: <3D324AB7.2080901@sonic.net> Todd Mitchell wrote: > > Since the messages were hardcoded and type specific I was proposing a (I > thought) trivial change to address them. > I had no problem making items based on the rod or wand type, but the > messages were type specific > (the pipe of mass wonder was based on the horn and would say "no matter how > hard you try you can't get another note out" when it was out of power.) I > was proposing a change to leave the type specific messages but have a > generic instance for other items based on the type but not of the same > appearance. You don't want your 'jewel of summoning' to say "the wand says > poof" when it is out of charges or your 'snail idol of slow' to say "The rod > whines for a while, but nothing happens." I'd prefer not to have another item type just to print some slightly different messages. Such a change may not be quite as simple as you may thing - all code instances that use type of ROD or WAND also need to get updated, not just that small snippet (this is for things like apply, monsters, identify, etc). I'd much rather just change that small area of code to do some more generic message. At least for wands, it now goes 'the goes poof', so that should be generic enough. Likewise, for rods, it says 'the whines for a while'. Perhaps for horns, maybe something like 'no matter how hard you try, you can't blow through the ?' presumably, anything of type horn is something you blow in, so should be generic enough? From pstolarc at theperlguru.com Tue Jul 16 06:03:50 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:34 2005 Subject: [CF-Devel] rodlike and wandlike items In-Reply-To: <3D324AB7.2080901@sonic.net> References: <000e01c22b58$1812d900$0a02a8c0@kameria> <3D31F932.6080502@sonic.net> <000401c22ba3$9052bc00$0a02a8c0@kameria> <3D324AB7.2080901@sonic.net> Message-ID: Mark Wedel wrote: >... > I'd prefer not to have another item type just to print some slightly different >messages. Such a change may not be quite as simple as you may thing - all code >instances that use type of ROD or WAND also need to get updated, not just that >small snippet (this is for things like apply, monsters, identify, etc). > > I'd much rather just change that small area of code to do some more generic >message. At least for wands, it now goes 'the goes poof', so that should >be generic enough. Likewise, for rods, it says 'the whines for a while'. > > Perhaps for horns, maybe something like 'no matter how hard you try, you can't >blow through the ?' presumably, anything of type horn is something you >blow in, so should be generic enough? I'm not familiar with the server code, but maybe something like: "The %s whines for a while, but nothing happens", sItem Or even more generic: "You try to use the %s, but nothing happens.", sItem -Philip (Work has gotten in the way of things, but, yes, I still plan to finish the SDL client.) From temitchell at sympatico.ca Tue Jul 16 14:24:04 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:34 2005 Subject: [CF-Devel] rodlike and wandlike items References: <000e01c22b58$1812d900$0a02a8c0@kameria> <3D31F932.6080502@sonic.net> <000401c22ba3$9052bc00$0a02a8c0@kameria> <3D324AB7.2080901@sonic.net> Message-ID: <001101c22cfe$59b2ca80$0802a8c0@ott.ca.dmr> The horn is just an item copy of a rod is it not? By making the messages for rods and wands more generic you have solved the issue. No need to vanilla the horn message now, just use the rod item if you want a more generic message. Since adding in more items is backwards thinking (I didn't think of the other code for identify or creature use, although isn't that what happened with the horn being made a seperate item in the first place?) it makes sense to have the messages more generic, but not to make a generic message for horns since they are ok now and it is nice to have some different messages for a bit of colour. I thought that by making generic types for recharging and rechargable items you could have your generic messages and keep the special messages for wands, rods, and horns - but the better way is to keep te items and make the messages more generic for wider application. ----- Original Message ----- From: To: Sent: Tuesday, July 16, 2002 7:03 AM Subject: Re: [CF-Devel] rodlike and wandlike items > Mark Wedel wrote: > > >... > > I'd prefer not to have another item type just to print some slightly different > >messages. Such a change may not be quite as simple as you may thing - all code > >instances that use type of ROD or WAND also need to get updated, not just that > >small snippet (this is for things like apply, monsters, identify, etc). > > > > I'd much rather just change that small area of code to do some more generic > >message. At least for wands, it now goes 'the goes poof', so that should > >be generic enough. Likewise, for rods, it says 'the whines for a while'. > > > > Perhaps for horns, maybe something like 'no matter how hard you try, you can't > >blow through the ?' presumably, anything of type horn is something you > >blow in, so should be generic enough? > > I'm not familiar with the server code, but maybe something like: > "The %s whines for a while, but nothing happens", sItem > > Or even more generic: > "You try to use the %s, but nothing happens.", sItem > > -Philip > (Work has gotten in the way of things, but, yes, I still plan to finish the > SDL client.) > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From mwedel at sonic.net Tue Jul 16 23:18:28 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:34 2005 Subject: [CF-Devel] rodlike and wandlike items References: <000e01c22b58$1812d900$0a02a8c0@kameria> <3D31F932.6080502@sonic.net> <000401c22ba3$9052bc00$0a02a8c0@kameria> <3D324AB7.2080901@sonic.net> <001101c22cfe$59b2ca80$0802a8c0@ott.ca.dmr> Message-ID: <3D34F014.4040502@sonic.net> Todd Mitchell wrote: > The horn is just an item copy of a rod is it not? By making the messages > for rods and wands more generic you have solved the issue. No need to > vanilla the horn message now, just use the rod item if you want a more > generic message. Since adding in more items is backwards thinking (I didn't > think of the other code for identify or creature use, although isn't that > what happened with the horn being made a seperate item in the first place?) > it makes sense to have the messages more generic, but not to make a generic > message for horns since they are ok now and it is nice to have some > different messages for a bit of colour. I thought that by making generic > types for recharging and rechargable items you could have your generic > messages and keep the special messages for wands, rods, and horns - but the > better way is to keep te items and make the messages more generic for wider > application. I'm not positive why horns were made a different item type. Some of it may have been the messages. It may have also been to have a different equipment slot for them. The ideal/super generic method would be for the items themselves to contain the different messages depending on what happens and not have it hardcoded. But that is not likely to happen anytime soon (and since different items have different things that can be done to them, this gets a bit complicated.. But I do want to move sound information to the objects and not have it hardcoded as it is now, but I think that is a simpler case). Certainly with the new body code, the number of item types could be reduced a great deal - a lot of the different types were used to denote equipping status (could only have one item of a type on at a time). But now, that isn't true - there is really no need to differentiate between helmet, gauntlets, girdles, boots, cloaks, .. - they all do the same thing. From mwedel at sonic.net Fri Jul 19 01:58:27 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:34 2005 Subject: [CF-Devel] Java Map Editor Bug Message-ID: <3D37B893.8020703@sonic.net> Don't know if this is a peculiarity of my system. If I try selecting a single space (left click), the box is drawn around the space correctly. However, if I left click and then drag (to select and area), the selected area is shown as basically garbage. Once the selected area goes away, the display is drawn back as it should be. Just flipping around between windows I noticed an odd behaviour - as it first went to redraw it, it redraw it quickly, and then immediately followed by drawing over the selected area with garbage. Is this a problem with the actual editor, or just some oddness with my system? Also, perhaps a feature request, is there anyplace that indicated how large an area has been selected by such a drag? When cutting/pasting between maps, it is sometimes nice to be able to know that I have grabbed the 8x15 area that I've cleared space for on the other map without needing to count things up. From andi.vogl at gmx.net Fri Jul 19 05:34:12 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:34 2005 Subject: [CF-Devel] Java Map Editor Bug References: <3D37B893.8020703@sonic.net> Message-ID: <26168.1027074852@www26.gmx.net> Mark W. wrote: > Don't know if this is a peculiarity of my system. > > If I try selecting a single space (left click), the box is drawn around > the space correctly. > > However, if I left click and then drag (to select and area), the > selected area is shown as basically garbage. I never observed anything like that with the JavaEditor on my system, and this is the first time I hear from it. (I have tested the JavaEditor on WinXP, Suse Linux and Solaris 5.2) Most importantly: What OS and which Java version are you running? If this happens with JSDK 1.3 for example, you could try upgrading to 1.4 and see if the problem persist. In general I have to say the bug you described is amazing. The drawing routines used for the "dragging" of selected areas use the same basic drawing methods as everything else. Now that doesn't mean I don't believe you. However, it's going to be hard to adress this problem without being able to verify it. As far as I remember, for inserting and deleting objects, the JavaEditor redraws only the changed tiles. But for this dragging-stuff it would have been much more complicated. So I just left it with redrawing the entire map-screen every time you drag the mouse over a new tile. Maybe what messes up is the part when the JavaEditor trys to force a redraw of the mapscreen? But then, it should also mess up when you move the scrollbars of your mapwindow for example. And it should either mess up the entire screen or let it be alltogether. Another possibility would be that what gets messed up is only the icons that display the highlighting boxes. But then, why does it work for single-click selection...? Andreas -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From mwedel at sonic.net Sat Jul 20 00:09:59 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:34 2005 Subject: [CF-Devel] Java Map Editor Bug References: <3D37B893.8020703@sonic.net> <26168.1027074852@www26.gmx.net> Message-ID: <3D38F0A7.8020505@sonic.net> Andreas Vogl wrote: > Mark W. wrote: > >>Don't know if this is a peculiarity of my system. >> >>If I try selecting a single space (left click), the box is drawn around >>the space correctly. >> >>However, if I left click and then drag (to select and area), the >>selected area is shown as basically garbage. > > > I never observed anything like that with the JavaEditor on my system, > and this is the first time I hear from it. > (I have tested the JavaEditor on WinXP, Suse Linux and Solaris 5.2) Dunno what happened - it is now working OK for me. Nothing should have changed on my system (I did re-start the editor since I had quit out of it before). I wonder if I had some stale class file. > > Most importantly: What OS and which Java version are you running? > If this happens with JSDK 1.3 for example, you could try upgrading > to 1.4 and see if the problem persist. linux 2.4.18, latest sun java (1.4.0_01-b03) > > In general I have to say the bug you described is amazing. > The drawing routines used for the "dragging" of selected areas use > the same basic drawing methods as everything else. > Now that doesn't mean I don't believe you. However, it's going > to be hard to adress this problem without being able to verify it. Must must a bug in the JVM. I wonder if the newer JVM is trying to use some means of graphic acceleration which is somewhat buggy. Oh well, I'll have to see if it happens again. Spoke too soon. Seems to be somewhat reproducible. But using IBM's java implementation (1.2.something) seems to work OK. The data that is being displayed instead of the right information seems to be sort of random. One time it was garbage. Last time I tried it, it draw a bunch of trees. One time it worked OK, but then I left that workspace and returned, and it had garbage again. A few other java editor related questions: 1) Is it possible to rebind the mouse buttons (eg, left click does this, right click does that)? Not that crossedit is the best model, but that is what click pattern I'm used to. Maybe I'll just have to retrain my brain. 2) The types.txt has a pretty clear format. Is there any mechanism to transition values? For example, one of the recent changes was to add a gen_sp_armour field - the last_heal fields should get transitioned to that (the server map editor will do that automatically, so its not too big a deal to just leave it unchanged. But it would be cool if the editor could fix these up also. From root at garbled.net Sat Jul 20 01:30:45 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:02:34 2005 Subject: [CF-Devel] Equipment musings In-Reply-To: <3D31F79F.4070306@sonic.net> Message-ID: On 14-Jul-02 Mark Wedel wrote: > When I wrote the code, I envisioned just not giving body parts to creates > that > don't have them, and not using force (or other objects) to use them up. Well.. thats kind of my point.. dragons *do* have arms, if you want to be technical, they just don't have good articulate hands to hold things, thats why I suggested the claws. It's probably a bit late to be coming up with alternate ways of doing this.. but I'm just trying to keep our options open in the future. The reality is that if something relatively close is available, someone is going to use it for an unintended feature. The critical hits thing was mostly an example of why I don't like the idea of a hack like "dragons have no arms and no legs because we don't want them wearing boots". Quite honestly.. I have no intention of ever inflicting critical hits on the server.. I think they are hideously unbalancing, and take millions of manhours to balance (without making them lame). --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From andi.vogl at gmx.net Sat Jul 20 03:06:40 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:34 2005 Subject: [CF-Devel] Java Map Editor Bug References: <3D38F0A7.8020505@sonic.net> Message-ID: <4190.1027152400@www63.gmx.net> > Mark W. wrote: > > A few other java editor related questions: > 1) Is it possible to rebind the mouse buttons (eg, left click does this, > right click does that)? Not that crossedit is the best model, but > that is what click pattern I'm used to. Maybe I'll just have to retrain > my brain. No, sorry - not yet possible to bind mouse buttons. I know it's a bit uncomfortable to get used to different buttons. My motivation to change patterns was this: - left click is for selecting on most systems and apps - middle click for deleting because it seems most unlikely to accidently click the middle button (just my personal opinion) - right click for insertion as that button remains free It was a bit tricky to get the buttons working for all systems, including support for single-button-mice, and considering the protocol for middle-button is wacky on some systems. So I didn't really want to complicate things further by allowing customized buttons. > 2) The types.txt has a pretty clear format. Is there any mechanism to > transition values? For example, one of the recent changes was to > add a gen_sp_armour field - the last_heal fields should get transitioned > to that (the server map editor will do that automatically, so its not too > big a deal to just leave it unchanged. But it would be cool if the editor > could fix these up also. I didn't include tools to modify the types.txt file automatically. However, I tried to keep the format as readable as possible, so changes can be made without too much trouble of learning the format. To change the mentioned armour field for example, works like this: - Open types.txt and run a search for the armour type, "Brestplate Armour" that would be in this case I think. - In the Armour type definitions, look for the attribute "last_heal" and change that into "gen_sp_armour". - Done. Andreas -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From mwedel at sonic.net Sat Jul 20 17:31:46 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:34 2005 Subject: [CF-Devel] Equipment musings References: Message-ID: <3D39E4D2.602@sonic.net> Tim Rightnour wrote: > On 14-Jul-02 Mark Wedel wrote: > >> When I wrote the code, I envisioned just not giving body parts to creates >>that >>don't have them, and not using force (or other objects) to use them up. > > > Well.. thats kind of my point.. dragons *do* have arms, if you want to be > technical, they just don't have good articulate hands to hold things, thats why > I suggested the claws. True. > > It's probably a bit late to be coming up with alternate ways of doing this.. > but I'm just trying to keep our options open in the future. The reality is > that if something relatively close is available, someone is going to use it for > an unintended feature. Note the number of arms, legs, whatever is inherited from the archetype. So it is a trivial enough matter to add something like this to the dragon player archetype: dragon_arms 2 dragon_foot 2 dragon_torso 1 dragon_head 1 And add a few lines of code to the server to support that. It would all work as expected. But if there are no items that use those locations, there really isn't much point. I really only put in body locations that currently have equipment that will use them. I didn't see much point to adding all possible locations when they are not going to be used - especially since it is quite simple to add new ones as they are used. There are currently a very large number of monsters without any body information Even as things are now, I can think of several refinements: 1) Modify karate arch so that it uses both arms, and maybe also the torso - basically meaning you can only use karate if your not using armor or weapons. 2) some weapons can be made two handed. Items like bonecrusher come to mind as good two handed weapons. For really good artifacts, this can be used as an additional way to balance it (really good weapon, but can't use a shield with it). 3) Other skill archs can perhaps be made to use more body parts. meditation for example could be changed similar to karate - no weapons, armor, helmets. > > The critical hits thing was mostly an example of why I don't like the idea of > a hack like "dragons have no arms and no legs because we don't want them > wearing boots". Quite honestly.. I have no intention of ever inflicting > critical hits on the server.. I think they are hideously unbalancing, and take > millions of manhours to balance (without making them lame). Well, in the initial design, there were two ideas - have the body locations be descriptive of actual body locations (eg, head, arm, fingers, etc), or have it descriptive of what it allows you to wear (body_armor, body_ring, body_bracer). Either way, the functionality I envisioned was going to be the same. So what I'm perhaps saying is that the current body information should not be seen as a way to represent the form of the character in terms of arms, legs, heads, whatever. It should only really be taken for what it was designed to be - controlling what can and can not be equipped. If I had taken the second naming scheme, I have a feeling we wouldn't be having this discussion much, as from that naming scheme it would have been clearer that the descriptions were functional, and not something to use to judge the actual body a creature has. From mwedel at sonic.net Sat Jul 20 17:46:22 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:34 2005 Subject: [CF-Devel] Java Map Editor Bug References: <3D38F0A7.8020505@sonic.net> <4190.1027152400@www63.gmx.net> Message-ID: <3D39E83E.5020403@sonic.net> Andreas Vogl wrote: > No, sorry - not yet possible to bind mouse buttons. I know it's a bit > uncomfortable to get used to different buttons. My motivation to change > patterns was this: - left click is for selecting on most systems and apps - > middle click for deleting because it seems most unlikely to accidently click > the middle button (just my personal opinion) - right click for insertion as > that button remains free > > It was a bit tricky to get the buttons working for all systems, including > support for single-button-mice, and considering the protocol for > middle-button is wacky on some systems. So I didn't really want to complicate > things further by allowing customized buttons. Fair enough. I seem to remember when I first started using crossedit that I though its mappings were a bit wacky, so the reason you did the above all make sense. Shouldn't take too long to get used to the new bindings. > I didn't include tools to modify the types.txt file automatically. However, I > tried to keep the format as readable as possible, so changes can be made > without too much trouble of learning the format. Yeah - the format is reasonably clear. Would be pretty easy to modify one of my perl scripts to update these also. Its was more justa covenience issue - have it update the information automatically. Am I right in remembering that the java editor will preserve any fields it doesn't know about (eg, it just treats the object .. end as a bunch of text that it saves out again)? Or does the editor need to get updated to properly load and save new values that may get added. One other niggling bug I noticed - the placement of the window when I run the editor isn't quite right. IT seems that the editor is smart enough to preserve its geometry, but when I re-run it, it seems about 20 pixels higher than it was before - this results in the window titlebar and top bar of options disappearing off the top of the screen if the last time I ran the editor it was aligned at the top of my screen. I suppose this could be a window manager issue, but I don't see it with other apps. One request that I've made before would be for the map windows to be their own top level windows managed by the OS instead of subpanes within the editor. Alternatively, if the layout could be a bit different so that the selected object information on the map was all done in a second column to the right of the one that is used for selecting stuff to insert in the map. The odd geometry of my system (3200x1200) means that even if I maximize the window size of the editor, I effectively lose a lot of editing space, as the pane for selecte object spans the entire width of the screen, which isn't very useful. From mwedel at sonic.net Sun Jul 21 02:58:57 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:34 2005 Subject: [CF-Devel] Java Map Editor Bug References: <3D38F0A7.8020505@sonic.net> <4190.1027152400@www63.gmx.net> <3D39E83E.5020403@sonic.net> Message-ID: <3D3A69C1.20401@sonic.net> Mark Wedel wrote: > > One request that I've made before would be for the map windows to be > their own top level windows managed by the OS instead of subpanes within > the editor. Alternatively, if the layout could be a bit different so > that the selected object information on the map was all done in a second > column to the right of the one that is used for selecting stuff to > insert in the map. > > The odd geometry of my system (3200x1200) means that even if I maximize > the window size of the editor, I effectively lose a lot of editing > space, as the pane for selecte object spans the entire width of the > screen, which isn't very useful. I actually did some quick hacks, and at least have my first point working (individual top level managed for each map). I need to hack around some more - the layout of the main window is now less optimal, because the pane area that used to be used for that information is completely unused. I need to poke around some more and see about moving over the map information to that pane - then I could have a 400x1000 (or thereabouts) window for that, and devote the rest of my screen for the map stuff. The problem with this is I'm not sure how to deal with this as a configuration option. I'm a pretty java newbie, and the change I basically did was change the map stuff from inheriting from the JinternalFrame to JFrame. I have no idea how that could get done as a runtime option (maybe inheriting from both, and using the correct constructors depending on the desired behaviour)? There is also what is perhaps some other behaviour I haven't figured out - using the close (delete) feature of the window manager on these new map panes is ignored - I'm sure there must be some setting someplace to handle what to do on a requested close event. The close from the editor menu does close the window. I'm not sure how it figures out which one would get closed - I'm guessing the one last selected. The easiest solution may be to just include the diffs within the editor distribution and have people just apply the diffs if they want this different behaviour. I suppose for a 'binary' distribution, both versions could be supplied. From michael.toennies at nord-com.net Sun Jul 21 06:19:04 2002 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:02:34 2005 Subject: [CF-Devel] Java Map Editor Bug In-Reply-To: <3D3A69C1.20401@sonic.net> Message-ID: Well, i had done one project in java before i had written the editor and i call me a java newbie too - even after the editor. I think AV has the same problem. The editor need still that a real java guru looks over it and optimize some of the modules. The panel under main map window is really a problem. The main idea (and in fact from interface design the superior idea) is to put in the panel all info about a arch in the same time second you klick on it on a map. And that you also can configure it only in this panel - without clicking much around. For map making, this will increase working speed alot. From andi.vogl at gmx.net Sun Jul 21 14:27:25 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:35 2005 Subject: [CF-Devel] Java Map Editor Bug References: Message-ID: <24927.1027279645@www27.gmx.net> My point of view on the JavaEditor is a bit different than Michael Toennies'. I don't feel that lack of Java coding power is a problem. Sure I'm no Java expert, but there's nothing one cannot figure out from the API docs. For example, I made the entire font for all windows customizeable. I have no problem with changing fonts. :-) About optimization - We must face it: You can't optimize that much for graphics with Java. The JRE simply has limits in speed and those are definite. In my opinion, one of the main difficulties with the editor is design & layout. Not only coding it, but figuring out how to do it right. Creating an easy and intuitive GUI is a lot harder than one might expect. I for one don't believe it would be practical to have the entire arch-input-interface always visible. Too much data - uses too much space. Also, I don't believe having seperated windows for the map-view is good. I don't like the window-jungle Crossedit produces for example. Now if Mark likes this and codes it as optional thing - no problem with that. Talking about the JavaEditor, there's one thing I still miss a lot: Pickmaps. Implementing those poses just the same kinds of problems like discussed above. Where to put them? - Seperate frames? Or a toggle between arch panel and pickmaps? Concluding, I think best one can do is to design the graphical interface with care and never stop learning Java ;-) Andreas -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From mwedel at sonic.net Sun Jul 21 23:48:32 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:35 2005 Subject: [CF-Devel] Java Map Editor Bug References: <24927.1027279645@www27.gmx.net> Message-ID: <3D3B8EA0.6020907@sonic.net> Andreas Vogl wrote: > > I don't feel that lack of Java coding power is a problem. > Sure I'm no Java expert, but there's nothing one cannot > figure out from the API docs. > For example, I made the entire font for all windows > customizeable. I have no problem with changing fonts. :-) When I first learned java, I realized pretty quickly that the language itself wasn't very difficult. IT is all the classes and knowing what they can do. This is somewhat similar to C - if you restrict yourself to basic stdio.h type stuff, its not too hard to learn, but it is also harder to do 'useful' programs within that constraint. The problem is you just can't pick up a java reference book and read it to learn all the classes. You basically have to learn them by experience. > > About optimization - We must face it: You can't optimize > that much for graphics with Java. The JRE simply has > limits in speed and those are definite. on the bright side, as new systems come out (and perhaps even new JVM's), the performance issue is less and less. The java editor seems fast enough on my machine, but then again, I just bought it some am at more of the top edge speedwisel > > In my opinion, one of the main difficulties with the editor > is design & layout. Not only coding it, but figuring out how > to do it right. Creating an easy and intuitive GUI is > a lot harder than one might expect. > > I for one don't believe it would be practical to have the > entire arch-input-interface always visible. Too much > data - uses too much space. > Also, I don't believe having seperated windows for the map-view > is good. I don't like the window-jungle Crossedit produces > for example. Now if Mark likes this and codes it as optional > thing - no problem with that. Its also tricky in what is useful depends on a persons environment. The standard layout may be perfectly fine on a low res (1024x768 or something) system - you basically need the amount of reserved space to see the attributes. but as resolutions go higher, you can stack more of the sub fields in a vertical fashion (eg, I've hacked it so that the map view (what's in the space) is above the information that is displayed about the selected object - I can see all the relevant information within that space. Similarly, my map editing demands are probably different - as of now, I'm mostly working on the world maps - these are big (50x50) maps. And typically, I want two of them open at the same time (so I can see how the edges line up when putting in roads and what not). I'm sure most people are working on smaller maps, and only need to see one at a time. You can't please everyone. As said, ideally some of this would be configurable (popup map windows, alternate main window layout). I think the main window one may be possible to make it configurable, as it just different the splitpanes. But do make one map in a window would seem to be difficult, as your now inheriting a different class. > > Talking about the JavaEditor, there's one thing I still miss > a lot: Pickmaps. Implementing those poses just the same > kinds of problems like discussed above. Where to put them? - > Seperate frames? Or a toggle between arch panel and pickmaps? To be honest, the individual window for each pickmap was (is) fairly annoying in crossedit. One reason is as you said - to much window clutter, especially since each pickmap is a relatively small window. However, I know one of the functionalities I find useful on them is at least being able to access 2 at the same time. For example, having both the river and the background tile to be able to touch that stuff up. I can't think of an easy way to do that in the java editor. Doing the picks is also tricky because they come in different sizes (the pick maps themselves). One thing that may be sort of like the pick would be an alternate method for picking objects from the window - as it is now, its a list, icon on the left, arch name on the right. A form which is more gridlike of just the icons would let you see potentially all the available items of that type - considering you can also make that area wider, this could almost be guaranteed depending on how big you make it. The fact that there is a window below which describes the selected item in a fair amount of detail (moreso than crossedit) gives you a pretty good idea on what you are selecting. what also might be cool (and one thing crossedit does do) is that if you select a multipart object, it displays the full (recombined) image. doing something like that in the java editor (in the window which describes the selected abilities) could be useful, as the part displayed in the selecting area may not always be useful. From kbulgrien at worldnet.att.net Sat Jul 27 09:53:48 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:35 2005 Subject: [CF-Devel] Python.h not found when configure runs. In-Reply-To: <3D38F0A7.8020505@sonic.net> References: <3D37B893.8020703@sonic.net> <26168.1027074852@www26.gmx.net> <3D38F0A7.8020505@sonic.net> Message-ID: <02072709534800.05161@krayp120.worldnet.att.net> I checked out the latest updates from CVS today and rebuilt the server. I checked the config.log file - which I haven't done before and noted that Python.h wasn't detected. I don't know much about the code, but recently I was trying to find out about Rainbow Wave potions and Occidental Mages items, and noted that they seem to refer to Python, and since that interested me, this was how I decided to try to get Python.h to be found. What might I have to do to help ./configure to find my Python.h. Here are some of the details about my system: Mandrake 8.0 (all current, official updates applied) [krb@krayp120 krb]$ rpm -qa | grep python python-2.0-9mdk rpm-python-4.0-26mdk python-numeric-17.3.0-3mdk python-devel-2.0-9mdk python-imaging-1.1.1-2mdk python-docs-2.0-9mdk [krb@krayp120 krb]$ cd /usr/include [krb@krayp120 include]$ find . -name Python.h ./python2.0/Python.h [krb@krayp120 include]$ rpm -qf /usr/include/python2.0/Python.h python-devel-2.0-9mdk From kbulgrien at worldnet.att.net Sat Jul 27 10:52:02 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:35 2005 Subject: [CF-Devel] Python.h not found when configure runs. In-Reply-To: <02072709534800.05161@krayp120.worldnet.att.net> References: <3D37B893.8020703@sonic.net> <3D38F0A7.8020505@sonic.net> <02072709534800.05161@krayp120.worldnet.att.net> Message-ID: <02072710424200.08323@krayp120.worldnet.att.net> On Saturday 27 July 2002 09:53, I wrote: > I checked out the latest updates from CVS today and rebuilt the > server. I checked the config.log file - which I haven't done before > and noted that Python.h wasn't detected. So anyway, I started to dig a bit even albeit crudely... BTW, I am not sure if you'd rather I posted to the normal list instead of the devel list... My original post was to devel was accidental. I went ahead and modified configure to be able to find Python.h even though I felt sure something would break during the make. Then, I ran make depend after tweaking plugin_python.h to look for Python.h in /usr/include/python2.0: --- making depend in plugin... make[1]: Entering directory `/home/operator/cvs/crossfire/crossfire/plugin' /usr/X11R6/bin/makedepend -- -g -O2 -I../include -I./../include -I./include -I../include -- plugin_python.c "plugin_python.c":104: defined __cplusplus ? __GNUC_PREREQ (2, 6) : __GNUC_PREREQ (2, 4) ^--- expecting : make[1]: Leaving directory `/home/operator/cvs/crossfire/crossfire/plugin' making depend in crossedit... make[1]: Entering directory `/home/operator/cvs/crossfire/crossfire/crossedit' makedepend -- -g -O2 -I/usr/X11R6/include/ -I../include -I. -Iinclude -I./../include -I. -I./include -ICnv -I./Cnv -I../include -Iinclude -ICnv -I. -- crossedit.c Attr.c CrFace.c CrEdit.c CrList.c CrUtil.c Edit.c App.c Bitmaps.c Str.c xutil.c "crossedit.c":104: defined __cplusplus ? __GNUC_PREREQ (2, 6) : __GNUC_PREREQ (2, 4) ^--- expecting : (cd Cnv; make depend) make[2]: Entering directory `/home/operator/cvs/crossfire/crossfire/crossedit/Cnv' /usr/X11R6/bin/makedepend -- -I/usr/X11R6/include -I../include -I. -I../../include -- test.c CnvUtil.c CnvBrowse.c CnvNotify.c CnvMenu.c CnvFiles.c CnvPath.c CnvPrompt.c "test.c":104: defined __cplusplus ? __GNUC_PREREQ (2, 6) : __GNUC_PREREQ (2, 4) ^--- expecting : make[2]: Leaving directory `/home/operator/cvs/crossfire/crossfire/crossedit/Cnv' make[1]: Leaving directory `/home/operator/cvs/crossfire/crossfire/crossedit' --- Ok, so, now I'm not sure what the "expecting" messages mean..... and whether or not they are critical. I did a make next, and it completed without errors. From Michael.Keuchen at hamburg.de Sat Jul 27 16:58:58 2002 From: Michael.Keuchen at hamburg.de (Michael Keuchen) Date: Thu Jan 13 18:02:35 2005 Subject: [CF-Devel] CFEditor cleaning up Message-ID: <3D4317A2.8531E40F@hamburg.de> Hi, I downloaded the latest version of the CFJavaEditor and did a bit of "cleaning up". This was necessary as there was really a mess with configuration files, build files, scripts, batch files and so on. You can download my version from "http://crossfire.tabacha.de". In particular, I made the following changes: - new build file I have removed all old Makefiles, scripts, buildfiles, batch files, ... They are replaced by "build.xml" for ant for building the app and small scripts for starting. - new packages for java sources According to naming conventions, I have moved the sources in a source directory and to the package "de.tabacha.crossfire.editor". I would have preferred "com.real-time.crossfire.editor", but "-" is not allowed in a package name. - Changed project name to from CFJavaEditor to CFEditor Old name was a bit long-winded. - Resources included in jar When building the jar, the resource files (icons, help files, default configuration files) are included. From comments in the source code, someone has earlier tried to do this and had problems. Can you check my changes, please? - Separating the PNG support from the CFEditor code. Previously, the PNG source files were included in the repository. I downloaded the newest version from sixlegs.com; now it's used as a library. - Support for two different distributions Either source files or the jar is included in a distribution package. - No change in functionality and appearance of the program - Changed version number from 0.975 to 0.976 Do you think this version can replace the older versions of the CFEditor? Michael Keuchen From mwedel at sonic.net Sun Jul 28 23:28:26 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:35 2005 Subject: [CF-Devel] Python.h not found when configure runs. References: <3D37B893.8020703@sonic.net> <3D38F0A7.8020505@sonic.net> <02072709534800.05161@krayp120.worldnet.att.net> <02072710424200.08323@krayp120.worldnet.att.net> Message-ID: <3D44C46A.2020108@sonic.net> Kevin R. Bulgrien wrote: > On Saturday 27 July 2002 09:53, I wrote: > > >>I checked out the latest updates from CVS today and rebuilt the >>server. I checked the config.log file - which I haven't done before >>and noted that Python.h wasn't detected. > > > So anyway, I started to dig a bit even albeit crudely... > > BTW, I am not sure if you'd rather I posted to the normal list instead of > the devel list... My original post was to devel was accidental. Stuff about compilation or programming issues is probably better places on the developer list. The normal list is more for general topics about game play or whatever else (how do I make an > > I went ahead and modified configure to be able to find Python.h even though > I felt sure something would break during the make. Easier way is to just do 'configure --with-includes=/usr/include/python2.0 ...'. Unfortunately, this isn't documented, doing so now. > > Then, I ran make depend after tweaking plugin_python.h to look for Python.h > in /usr/include/python2.0: The make depend errors can basically be ignored. From andi.vogl at gmx.net Sun Jul 28 06:46:27 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:35 2005 Subject: [CF-Devel] CFEditor cleaning up In-Reply-To: <3D4317A2.8531E40F@hamburg.de> Message-ID: <000001c2362c$6fec6720$c86ebb81@gizmo> Micheal Keuchen wrote: > Hi, > > I downloaded the latest version of the CFJavaEditor and > did a bit of "cleaning up". This was necessary as there > was really a mess with configuration files, build files, > scripts, batch files and so on. > You can download my version from "http://crossfire.tabacha.de". The mess with configuration files is not my fault. The reason for this is that there are a lot of people who tried to configure the editor for "their personal system". So I allowed anyone to include build scripts as long as these scripts "don't hurt". > In particular, I made the following changes: > > - new build file > I have removed all old Makefiles, scripts, buildfiles, > batch files, ... They are replaced by "build.xml" for ant > for building the app and small scripts for starting. Hmm, okay this sounds good. I really never use any build scripts and I have little idea whether the old ones worked or not. The only problem is, I don't like some of the changes below, which might require modifications to these build scripts in order to work. > - new packages for java sources > According to naming conventions, I have moved the sources > in a source directory and to the package > "de.tabacha.crossfire.editor". I would have preferred > "com.real-time.crossfire.editor", but "-" is not allowed > in a package name. Sorry I don't want to have the packages renamed. These overly long names cause a big mess in the directory tree on CVS. However, I could agree to move the sources into a "src" directory. > - Changed project name to from CFJavaEditor to CFEditor > Old name was a bit long-winded. CFJavaEditor is the name - and that's where it stays. I hope you understand, but it's really not the habit to have project names changed like that. > - Resources included in jar > When building the jar, the resource files (icons, help > files, default configuration files) are included. From > comments in the source code, someone has earlier tried to do > this and had problems. Can you check my changes, please? Yes this is possible, but I want to have the resource files in non-archived form on CVS. The reason is that a lot of people don't know what a jar file is and how to unzip it. I want that everybody - including non-java-coders - can access and modify the resource files easily. Now if a release of the CFJavaEditor without source is made, there you could put the resources in the jar file and then everything is small and clean. > - Separating the PNG support from the CFEditor code. > Previously, the PNG source files were included in the > repository. I downloaded the newest version from sixlegs.com; > now it's used as a library. There are modifications in the png code, correcting some bugs and shortcomings of the sixlegs.com library. I didn't have time to look at your code yet. If the newest version of sixlegs has the old bugs corrected and directly works with the JavaEditor, then we could eventually do this. > - Support for two different distributions > Either source files or the jar is included in a distribution > package. It would make sense to have two distributions: One with full source and resource files, the other only with jar file and the must-have files (images/html help). Now this stuff mainly depends on the person(s) who pack the distributions and put them online somewhere. I don't have the webspace to make official distributions currently. > - No change in functionality and appearance of the program > - Changed version number from 0.975 to 0.976 > > Do you think this version can replace the older versions of the > CFEditor? Not directly I'm afraid. I hope this doesn't dissapoint you. But you know, you should always ask before doing a lot of work on something. I'll have a look at your code though, when I got time. Andreas From Michael.Keuchen at hamburg.de Wed Jul 31 21:47:09 2002 From: Michael.Keuchen at hamburg.de (Michael Keuchen) Date: Thu Jan 13 18:02:35 2005 Subject: FW: [CF-Devel] CFEditor cleaning up References: <000001c237ea$39528720$c86ebb81@gizmo> Message-ID: <3D48A12D.2288756E@hamburg.de> Andreas Vogl schrieb: > > In particular, I made the following changes: > > > > - new build file > Hmm, okay this sounds good. I really never use any build scripts > and I have little idea whether the old ones worked or not. > The only problem is, I don't like some of the changes below, > which might require modifications to these build scripts > in order to work. Modifications to the build scripts are no problem. There is only one unchangeable condition for this scripts to work: All source files must be in a root package or a subpackage of it. Source files out of packages (like the old CFJavaEditor class) are not recognized by the build file. > > > - new packages for java sources > Sorry I don't want to have the packages renamed. These overly > long names cause a big mess in the directory tree on CVS. What do you mean with "mess"? CVS does not have problems with several subdirectories. Arguments I see: Advantages of long names (like "de.tabacha.crossfire.editor"): - java standard - unique all over the world - more flexible (e.g. if you combine the editor with a java client, the classes for the client can be in de.tabacha.crossfire.client). Advantages of short names (like "cfeditor"): - changing from base dir to source file dir is faster - less characters to type in "import" statements I (and most Java developers) prefer the long names. But I am not bound to this point. If you think short names are a must, o.k., let 's use them. But all source files must reside in a package (nothing in default package, see above), and, PLEASE, use small characters ("cfeditor", NOT "CFEditor"). This is Java standard and will be no problem for you. > However, I could agree to move the sources into a "src" > directory. (relief) > > - Changed project name to from CFJavaEditor to CFEditor > > Old name was a bit long-winded. > > CFJavaEditor is the name - and that's where it stays. > I hope you understand, but it's really not the habit to have > project names changed like that. I understand. Seems that I was going too far at that point. However, I don 't like that name. People that are interestedd in the programming language will soon recognize that it's Java, and other people don't want to be bothered with that stuff. > > > - Resources included in jar > Yes this is possible, but I want to have the resource files > in non-archived form on CVS. The reason is that a lot of people > don't know what a jar file is and how to unzip it. ??? Complete misunderstanding! 1) The resource files will be in non-archived form on CVS. 2) The only jar that will be on CVS is the included png library. 3) No one - user or developer - will ever have to unzip a jar. 4) The CFEditor jar will not be on CVS. It will be generated and only be part of the exe-distribution, not part of the src-distribution. > I want that everybody - including non-java-coders - can access > and modify the resource files easily. Yeah, that's a point: What of the files would be changed by users? Surely not the help files, the icons and the "system" PNG pictures, but what about these four: - autojoin.txt - spells.def - typenumbers.def - types.txt Are they meant to be changed by a user? Or are they just officially updated more often than the source code, so they must be downloadable separated from the jar? > Now if a release of the CFJavaEditor without source is made, > there you could put the resources in the jar file and then > everything is small and clean. This is exactly what I did: one distribution with src and resource files, one with only the jar. > > - Separating the PNG support from the CFEditor code. > There are modifications in the png code, correcting some bugs > and shortcomings of the sixlegs.com library. > I didn't have time to look at your code yet. If the newest > version of sixlegs has the old bugs corrected and directly > works with the JavaEditor, then we could eventually do this. O.K., please check it. (BTW: That's the typical outcome of forking development.) > > - Support for two different distributions > ... > > Either source files or the jar is included in a distribution > > package. > > It would make sense to have two distributions: > One with full source and resource files, > the other only with jar file and the must-have files > (images/html help). > Now this stuff mainly depends on the person(s) who pack the > distributions and put them online somewhere. > I don't have the webspace to make official distributions > currently. At least for the next time, I can put distributions to crossfire.tabacha.de . This webspace belongs to a friend of mine who has never complained about me wasting his space. But what about the space at sourceforge? > > - No change in functionality and appearance of the program > > - Changed version number from 0.975 to 0.976 > > > > Do you think this version can replace the older versions of the > > CFEditor? > > Not directly I'm afraid. I hope this doesn't dissapoint you. No, I'm happy. We all want to and can keep on working on this. > But you know, you should always ask before doing a lot of work > on something. I'll have a look at your code though, when I got time. There's one more thing I have to tell you. My first intention for changing the editor was to have an editor for Tabacha. Tabacha is very much like crossfire, but engaged development ceased years ago, and there will never be a running version in the next decades. But the old maps and objects are still there, and after converting them to crossfire style, I changed the CFJavaEditor. No great deal: Only change faces from 32*32 PNG to 40*35 GIF. After that, I recognized that I wanted to work on the editor and that forking development is no good, so I turned back the changes and made the version you see. Two changes, that make sense, remain: The image size is now a constant (in IGUIConstants: TILE_XLEN, TILE_YLEN) and some code in ArchObjectStack is moved to a separate private method "generateFaceName". I still have to learn to discuss changes before making them, but I try. Michael From tanner at real-time.com Sat Jul 27 11:47:19 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:10 2005 Subject: [CF-Devel] Python.h not found when configure runs. In-Reply-To: <02072710424200.08323@krayp120.worldnet.att.net>; from kbulgrien@worldnet.att.net on Sat, Jul 27, 2002 at 10:52:02AM -0500 References: <3D37B893.8020703@sonic.net> <3D38F0A7.8020505@sonic.net> <02072709534800.05161@krayp120.worldnet.att.net> <02072710424200.08323@krayp120.worldnet.att.net> Message-ID: <20020727114719.E1983@real-time.com> Quoting Kevin R. Bulgrien (kbulgrien@worldnet.att.net): > I went ahead and modified configure to be able to find Python.h even though > I felt sure something would break during the make. You should tweak the configure.in, since the next time autoconf is run configure will be overwritten. > Then, I ran make depend after tweaking plugin_python.h to look for Python.h > in /usr/include/python2.0: Bottom line is configure is not finding python-2.0? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 http://www.tcwug.org, Minnesota, Wireless | Coding isn't a crime. Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 From mwedel at sonic.net Tue Jul 2 00:40:38 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:17 2005 Subject: [CF List] Crossfire 1.3.0 released Message-ID: <3D213CD6.8050706@sonic.net> Crossfire 1.3.0 has been released. There are numerous bug fixes in this, as well as improved item handling code (better item sorting with new client, as well as proper naming of plural objects). Files released for this version: sums (bsd) filename 17699 1332 crossfire-1.3.0-arch.tar.bz2 52744 1427 crossfire-1.3.0-arch.tar.gz 56236 2869 crossfire-1.3.0-maps.tar.bz2 58818 4186 crossfire-1.3.0-maps.tar.gz 37910 996 crossfire-1.3.0.doc.tar.gz 50029 2861 crossfire-1.3.0.tar.bz2 64559 3191 crossfire-1.3.0.tar.gz 61233 380 crossfire-client-1.3.0.tar.gz 27814 1276 crossfire-client-images-1.3.0.tar.gz Sums (md5) bb53582498faafc9a2ced8f6af6d861b crossfire-1.3.0-arch.tar.bz2 579072ebf6aa99536e7fdfcd435976a4 crossfire-1.3.0-arch.tar.gz 5308e236b390eb011c8f28bccb52df56 crossfire-1.3.0-maps.tar.bz2 632420953861ca96fc56d437a28da36a crossfire-1.3.0-maps.tar.gz a682581581b95989ed9f93bc15161e7d crossfire-1.3.0.doc.tar.gz 5a1702e1605bd032510ee3aabba87880 crossfire-1.3.0.tar.bz2 d1b4a00121b2a42d56c63c43a1c41de2 crossfire-1.3.0.tar.gz fc4c91bcd66c53e8da8ef13ab9554b04 crossfire-client-1.3.0.tar.gz d0115d1e429116a42080b48ea8cdfae3 crossfire-client-images-1.3.0.tar.gz crossfire-client-1.3.0 is the client (X11) distribution - standard X11 and gtk interfaces are provided. Improved object handling is now supported, and extension for future map handling has been added. crossfire-client-images.1.3.0.tar.gz is a prebuilt image file for the client - downloading this file will reduce the amount of download that needs to happen during play if the -cache option is used. This file should be untarred in the ${prefix}/share/crossfire-client directory, where ${prefix} is the --prefix option given when configure is run. The default path is /usr/local/share/crossfire-client/. crossfire-1.3.0.tar.{gz/bz2} contains the server code with prebuilt archetype and image files. crossfire-1.3.0.arch.tar.{gz/bz2} contains the unpacked archetype changes. This is not needed if you only want to compile the server and play the game. crossfire-1.3.0-maps.tar.{gz/bz2} contains the maps. This is needed with the server distribution. crossfire-1.3.0.doc.tar.gz contains preformatted documentation. In this, you get the postscript spoiler and handbook, but you also get the html versions of both of those files with all the needed graphics - this is the only archive that has all the graphics pre-made. FOR FIRST TIME USERS: You will only need the appropriate server, map and client file. You do not need the arch file. You may wish to get a copy of the doc file. If you just want to play the game at some remote server, you need the client and perhaps the image archive file. Crossfire is avaible on the following ftp sites Primary: ftp://ftp.sourceforge.net/pub/sourceforge/crossfire (64.28.67.101) Secondary: ftp://ftp.real-time.com/pub/games/crossfire ftp://ftp.cs.city.ac.uk/pub/games/crossfire/ ftp://ftp.cs.titech.ac.jp/pub/games/crossfire ftp://mirror.aarnet.edu.au/games/roguelike/crossfire/ ftp://crossfire.futt.org//pub/crossfire The initial upload of this release is only made to sourceforge - it should show up on the mirrors shortly. Mark Wedel mwedel@sonic.net Complete changelog: server: socket/request.c: If players were using the original map command with an even map size, server would try to send too much data to client - checking in server would result in an abort. Modify code to now properly send right number of spaces. lib/Makefile.in: remove extraneous / in front of motd entry in file list. include/version.h: Update for version 1.3.0 Makefile.in: Update for version 1.3.0 lib/archetypes: rebuilt. MSW 2002-07-01 doc updates: Rebuild the doc files, but most of this is fixing some of the doc build stuff to correctly working with the new image set naming scheme and fixing some bugs. Some doc is certainly out of date - the playbook doesn't mention the classes for example. doc/handbook.ps, doc/spoiler.ps: rebuilt Note: all the doc/playbook changes also apply to the same files in doc/playbook-html. doc/playbook/Makefile.in, doc/playbook/makeps, doc/playbook/makeps.pl: replace the awk makeps script with the perl one. doc/playbook/items-extract: Don't show invisible items. doc/playbook/levels-extract: Update so that it properly finds the declaration of the levels in living.c doc/playbook/treas1-extract: Clear type when we get a new Object header. was resulting in duplicate entries for the characters. doc/playbook/treas2-extract: Don't include forces of the no_class_face_change as part of characters treasures doc/playbook-html/chap1.html: Update ftp site information. doc/spoiler/Makefile.in, doc/spoiler/makeps.pl, doc/spoiler/makeps: replace the awk makeps script with the perl one. doc/spoiler/items-extract: Add a space after the name match so that it won't match on the name_pl field. doc/spoiler-html/items-extract: Add a space after the name match so that it won't match on the name_pl field. doc/spoiler-html/makeps.pl: Update to handle new naming scheme for images. doc/spoiler-html/spoiler.html: rebuilt. lib/Makefile.in: Fix error in variable not being surrounded by parens. MSW 2002-06-30 server/rune.c: Fix bug that allowed players to use marking runes to create arbitrary objects by embedding a endmsg in the string. MSW 2002-06-26 lib/ban_file: Update comments to describe how it actually works. server/commands.c: Add some time cost to shout, say, and tell commands. This prevents abusive players from issuing huge number of these commands. MSW 2002-06-20 doc/playbook-html/Makefile.in: Remove some superfluous blank lines in the file. configure, configure.in, plugin/Makefile.in: Modify configure script to subtitute PLUGIN_TARGET, have plugin/Makefile not build/install plugin if necessary support libraries are not in place. common/item.c, include/material.h: Move the declaration/initialization of materialtype from material.h to item.c server/main.c: Modify crypt_string so that on Freebsd systems, it will use des_crypt if available, if not, won't encrypt. MSW 2002-06-18 TODO: Additional updates. Add support for loading the EMERGENCY_.. locations from a .emergency file in the map directory. This makes it easy to switch map distributions without the need to recompile. The emergency information is now stored in the settings structure. common/init.c: add EMERGENCY_ defines to default values in setting. Add init_emergency_mappath which loads the information. include/config.h: Remove NEW_WORLD_MAP definition, as it is no longer needed. Update some of the EMERGENCY_.. information as we don't need to include the information for the new world map. include/global.h: Add emergency_.. fields to settings structure. server/login.c, server/main.c, server/player.c: Update references from the EMERGENCY.. values to settings.emergency values. MSW 2002-06-15 lib/Makefile.in: modified so that it doesn't overwrite commonly customized files (eg, motd, dm_file, ban_file). These files will get installed on new installations. MSW 2002-06-14 common/item.c: break out monster description into describe_monster function from describe_item - the later was a really long function. Reveal weapon speed for identified weapons, spell point regen penalty and max speed for identified armor - this was discussed about 6 weeks ago. Clean up the code to reduce the number of redundant if statements and otherwise confusing code in describe_item. MSW 2002-06-14 configure.in, configure, plugin/Makefile, plugin/Makefile.in, plugin/Makefile.old: Modify the plugin module to gets its needed information from configure. configure.in modified to look for Python.h and to find the python library. plugin/Makefile.in is a new file. plugin/Makefile.old is the old plugin/Makefile (removed) - may be useful for sites where configure does not work for some reason. The use of --with-includes=-I/usr/include/python2.2 (or the like) will likely be needed for configure to find the Python.h file. Note - if you are doing a CVS update, you will need to re-run configure with the appropriate options for this change to take effect. MSW 2002-06-13 server/main.c: If on freebsd system, don't crypt the password. Crypt on freebsd behaves diferently, and since there is little reason to encrypt passwords, easier to just leave them decrypted. Fix for sourceforge bug 469017 MSW 2002-06-13 More minor changes, including a fix for the disappearing object bug - this was caused by the flag_links not getting updated the last time new flags were added. Problem probably only showed up now because loader.c wasn't rebuilt until recent changes. -- common/loader.c, common/loader.l: add extern to arch_init, when loading and get an object from a file, complain and ignore it if arch_init is not set (only time we should get object (vs arch) for names is when we load the archetypes file). Add missing entries to flag_links array. common/treasure.c: Fix code so that proper plural names are generated for custom items (potions, flesh items, etc). include/define.h: Add note about updating flag_links when NUM_FLAGS is increased. server/skills.c: don't let players steal from players with FLAG_WIZ set. MSW 2002-06-09 Mostly bugfixes. I'm not sure if this will fix the disappearing arch problem- none of the changes made in the original multiple name would seem to cause it, so hard to say if any of these changes may fix it. -- common/arch.c: Change get_archetype_by_name to be more efficient and not leak memory. Modify code that frees all archetype data to free the name_pl information. Make sure the clone.name_pl is set to NULL. When singularites are created, set the name_pl for them. common/loader.l, common/loader.c: Modify code that fixes up name_pl to be more correct when it fixes up name_pl for old objects. common/map.c: Modify load_map_header so that tile_paths will be normalized - need for editor to be able to load maps that have a multipart object that spans the maps. crossedit/Edit.c: Modify some calls of out_of_map to OUT_OF_REAL_MAP, since tiling code really isn't fully in place for the editor. Modify EditPerformFill so that it actually works and doesn't crash the editor. include/global.h: Move FREE_AND_COPY macro from loader.l to here so that all source code files can use it. lib/adm/map_info: Modify to actually be able to examine just a sub portion of the map directories, and not all of them. Don't always show the unused objects - information isn't very interesting if only a portion is being examined. Modify the exit examining code to properly deal with random maps (if there is a finalmap component, make sure that does exist.) Loade the bmaps file and not the faces file to find valid faces. plugin/plugin_python.c: Add missing %s that described what script was actually loaded. random_maps/special.c, server/alchemy.c, server/c_misc.c, server/gods.c, server/login.c, server/player.c, server/spell_effect.c: Set up proper name_pl value for code that changes the name of objects. server/apply.c: Use FREE_AND_COPY to set up names. Set up proper name_pl values for cases that change name. In apply_lighter, call fix_player if player is lighting an object in his inventory - necessary for the players glow_radius to get updated so the change actually takes effect. socket/request.c: Modify esrv_map_scroll so that it properly clears cells that are moving out of view - failure to do this was resulting in the map1a updating these spaces with empty faces. This was causing fog of war wackiness with the client. MSW 2002-06-06 common/button.c: Fix mood floor code - before, it was changing the moods of all sorts of objects (luggage, itself, etc). Now, it only changes objects above the floor, and only monsters. MSW 2002-05-31 Main change is the addition of name_pl and client_type to object structure. The name_pl contains the proper plural name instance - fixes problem of '2 tooths'. client_type is sent to the client so that client doesn't need to figure out sorting on its own. Client_type is an object attribute, so can be modified in maps to hide the real type. -- common/arch.c: item_matched_string() modified to use the name_pl field when trying to match names, and not to try to make the name plural itself. common/item.c: query_short_name(),query_base_name() modified to use name_pl instead of trying to make the name plural. common/loader.c, common/loader.l: Add code to load and save the name_pl value and client_type. Add logic when object is finished loading to set name_pl value to same as name or arch name if no name_pl is specified - this supports old maps/characters in which the objects dont have a name_pl field yet. Disable logic for need_an and need_ie flags since they are no longer needed. Fix bug that caused elevation not to get saved. common/object.c: Add client_type check for CAN_MERGE function. Add appropriate logice in functions to handle setting, clearing, and copying of name_pl values. Remove unused anim_... fields initialization. doc/Developers/objects: Add information about the name_pl field and client_type. doc/Developers/protocol: Remove item protocol command info - it has been obsoleted. Add information about item2 protocol command. include/define.h: Remote ST1_* values - they were not being used. comment out FLAG_AN and FLAG_NEED_IE values. include/newserver.h: Add itemcmd to socket structure - this is the version of the item protocol command that will be sent to the client. include/object.h: Add name_pl and client_type field to object structure. Remove unused anim_* values. lib/archetypes: rebuilt with new archetypes that contain client_type and name_pl information. lib/bmaps, lib/bmaps.paths, lib/crossfire.1, lib/crossfire.0, lib/faces: rebuilt. server/monster.c: Remove anim_ references that were not being used. socket/init.c: Initialize itemcmd version in the socket to 1. socket/item.c: Remove special handling for clients of old versions - all clients now have to be at least sc_version 1024 (which has been around for a long time). This simplifies a lot of the object code that deals with sending or not sending plural names to the client - now always send them. Change code that sends item to client to use the item revision (currently 1 or 2) that the client wants. If version 2, send along client_type information. socket/request.c: Handle 'itemcmd' parameter in setup command. Make sure it is in proper range. If client is very old (sc_version < 1024) tell them so. MSW 2002-05-30 crossedit/png.c, crossedit/xutil.c: Increase size of temporary buffers that are used when loading images - necessary to allow the editor to run without crashing. include/newserver.h: Remove quick_pos from the MapCell structure. server/main.c: Add code to set the coordinates to the EMERGENCY_X/Y values if using the EMERGENCY_MAP. socket/request.c: Fix code that was causing darkness to get repeatedly sent for some spaces. MSW 2002-05-19 The bulk of this commit is to modify the server to only send the lower rightmost part of multipart archetypes that use the same head. This allows support of big images in the client. common/arch.c: Modify first_arch_pass to figure out the tail_x/y values for multipart archs. Rename the prev variable to head, as that it really what it is. Remove quick_pos info. common/object.c: remove quick_pos info from object. doc/Developers/images: Add notes about using merged images. doc/Developers/protocol: Add information about the map1a command, which is used to for big image support. Remove map2 documentation. include/map.h: Add MAP_LAYERS define instead of using hardcoded value of 3. include/newserver.h: Change the MapCell to use MAP_LAYERS - saves considerable memory. Add defines for MAX_CLIENT_ map sizes. Remove map1cmd, map2cmd elements from socket structure - instead use enumeration of mapmode - only one map type will be used at any time by the client, so no reason to have individual elements - it also makes it easier to add new mapmode commands. include/object.h: remove quick_pos, update_tag from object structure. Add tail_x, tail_y values to archetype structure. include/player.h: Remove some now unused values from the player structure (drawn, floor, floor2, darkmask). These have been superseded by the map cells in the socket structure for quite a while. include/sockproto.h: rebuilt server/player.c: Remove code that initialized the drawn values in the player structure since they no longer exist. socket/init.c: Replace map1cmd, map2cmd elements in socket structure with mapmode element. Modify init_ericserver so that it properly passes an int when setting the SO_REUSERADDR field. socket/request.c: Modify code in SetUp function to use the new mapmode enumeration in the socket structure. Add support for map1acmd setup option. Throughout map code, replace MAXMAPCELLFACES with MAP_LAYERS. modify map_clearcell to take options for values to clear the cell to. Add have_head, check_head, and update_space commands - used with the map1 command to store and find head information. draw_client_map1 modified to support map1a extensions, as well as added logic for checking for heads in blocked and out of viewable map spaces. Some of the code is simplified by using the update_space function, since the logic for processing each layer was otherwise the same. remove draw_client_map2 function. esrv_map_scroll has same logic - some variables and code formatting changes. MSW 2002-05-18 server/login.c, server/c_misc.c: Don't save characters with 0 experience. This apparantly fixes some abuses. MSW 2002-05-18 server/attack.c: Don't generate PLAYER_KILL_PLAYER messages if kill happened on battleground. Also, datestamp the messages. MSW 2002-05-13 server/attack.c: Generate log message when a player kills another player - include the ip address of the killer to make it easier to add them to ban files. MSW 2002-05-06 Client changes: Add support for the 'item2' command. This lets us get the item type from the server so that we don't need to figure it out for ourselves. Also, remove support for the 'item' command - that has long since been obseleted by the 'item1' command. -- common/client.c: Remove 'item' from dispatch table, add 'item2'. Add 'itemcmd 2' as part of setup command we send to server. common/commands.c: Add handling for response of 'itemcmd' setup command from server. Remove ItemCmd() function. Add type to calls to update_item(). Change Item1Cmd() function to be called common_item_command() since both item1 and item2 use almost exactly the same logic. Add Item1Cmd() and Item2Cmd() which just call common_item_command() common/item.c: Init item types to 'NO_ITEM_TYPE'. Remove get_nrof() as it was no longer being used. Add type argument to set_item_values() and update_item(). Simplify code in case of name handling, since we know that we will be using at least the 'itemcmd'. Don't worry about getting proper nrof for the player object - its nrof isn't really meaningful anyways. common/item.h: Add #define NO_ITEM_TYPE. Update type field in item to be 16 bits. common/proto.h: rebuilt. MSW 2002-05-30 The bulk of this checkin adds support in the client for the map1a protocol command and the display of big images properly in the map window. A lot of code cleanup was also done however, including removal for the support of the 'map' (original) command. The map1 has been in the server code for quite a while. TODO: Update what needs to be done for the x11 client. common/client.c: Remove map command, add map1a command to dispatch table. Modify setup we send to server to always try to use the map1a command - there is no reason not to use it. common/client.h: Change some of the CONFIG_ values - basically, change it so that there is just one entry for lighting configuration, but it can have any number of values. Modify MapCell so that instead of having multiple arrays for the different values (faces, sizes), add a MapCellLayer structure that contains the specific face information for that layer. Move the PlayerPosition struct and value to this function so that more of the map decompress logic can be handled in the common code. Remove count value from MapCell since it wasn't really being used. common/commands.c: Add code to set the use_config[CONFIG_CACHE] value based on what we get back from the server. Add code to check the setup response for the for the map1a and map1 options. Add code to deal with expanding big images into appropriate spaces. Move some functions from the gui portion to (display_map_clearcell, set_map_face). Add code for map1_common function to deal with map1a extensions. common/external.h: Remove display_map_clearcell and set_map_face from list of external functions. Add get_map_image_size function. common/init.c: change some values of the config values. Update initialization of config values for lighting. common/proto.h: rebuilt. gtk/config.c: Add new button for lighting - best per pixel. Modify code to properly deal with how lighting preference is now stored. Add legacy support for loading of per_tile_lighting and per_pixel_lighting values from config file. Add diagnostic of bad value if selected map/width is out of range. gtk/gtkproto.h: rebuilt. gtk/gx11.c: Change formatting of draw_list. Modify it so that it adjusts the column/row width based on the largest image it needs to display - In this way, if a player stands on a big building, the entire building is displayed in the look list. add row_height and column_width values so we only need to call the function to change them if they are in fact different. Add +sdl command line option to disable sdl code. Modify gtk_draw_map to include redraw parameter. gtk/gx11.h: remove PlayerPosition structure. add row_height, column_width elements to itemlist structure. gtk/image.c: Add table that is used to determine the scaling used for big images in the look list - in this way, big images still appear big, but not necessary 2 or 3 times bigger. Modify create_and_rescale_image_from_data to use this logic. Add get_map_image_size which the common code uses to determine the number of spaces an image may be. gtk/map.c: remove display_map_clearcell and set_map_face functions - now in common code. Modify the dump map/darkness routines to use the new format of the MapCell structure. Modify set_darkness to only set adjoining spaces for needing an update if lighting type is set that needs this. Remove display_map_addbelow - only used for 'map' command. Modify logic of fog of war code to have it done all at display time - not when setting/clearin g a cells contents. Modify gtk_draw_map - this basically follows the same logic of sdl_draw_map - it is now better optimized to only draw the spaces that have changed, and not the entire map - this should improve performance considerably. gtk/sdl.c: Remove #if 0 around putpixel - used for best lighting. Change indention of init_SDL - modify it so that if just_lightmap is true, that really is the only thing that is changed. Modify per_pixel_light code to use both methods of per pixel lighting depending on player prefernce. Modify sdl_gen_map to properly handle draw portion of big images. x11/png.c: Add get_map_image_size function. x11/x11.c: modify display_mapcell_pixmap to use new format of MapCell structure. Remove reference to count in MapCell structure. x11/x11.h: Remove PlayerPosition information - now in common code. x11/x11proto.h: rebuilt. x11/xutil.c: Remove display_map_clearcell and set_map_face functions. Modify du mp map code for new MapCell structure layout. Remove display_map_addbelow funtion. From huet.o at free.fr Sun Jul 7 16:16:02 2002 From: huet.o at free.fr (huet.o@free.fr) Date: Thu Jan 13 18:04:17 2005 Subject: [CF List] problem with some diseases Message-ID: <1026076562.3d28af927ebf6@imp.free.fr> Hello everybody, I hope it's the right mailing list for my "bug" report. I make a character worshiping Devourers, and I found some "high" disease ineficient to make damage : In fact, cold, flu and leprosy work fine, but typhoid, anthrax, red death and black death don't make damage. I tried to restrict the bug : in the archetypes file, all the "no damaging" disease have a negative number for the damage (ex : for red death, it's "dam -10". Then, I tried to replace the -10 by 10 and red death is very deadly (and it's the right comportment, I think.) Finding this problem, I find other "dam -" begining lines that probably have the same effect (immolation that I didn't try have perhaps the same bug). Does someone have the right solution (personaly, I think it could be a problem in the archetypes file itself or a bug in its parsing...) ? Olivier. From peterm at tonks.EECS.Berkeley.EDU Mon Jul 8 09:36:20 2002 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:04:17 2005 Subject: [CF List] problem with some diseases In-Reply-To: Your message of "Sun, 07 Jul 2002 23:16:02 +0200." <1026076562.3d28af927ebf6@imp.free.fr> Message-ID: <200207081436.g68EaK317901@tonks.EECS.Berkeley.EDU> "negative" damage had some special meaning, like it does ten percent of damage regardless of caster level, while positive damage is increased by caster level. Either that or the other way around. Are you sure the "broken" diseases aren't simply heavily damaging the monsters but not killing them? Or has someone been meddling with the disease code recently and broken the "negative" damage? PeterM > Hello everybody, > > I hope it's the right mailing list for my "bug" report. > > > I make a character worshiping Devourers, and I found some "high" disease > ineficient to make damage : > > In fact, cold, flu and leprosy work fine, but typhoid, anthrax, red death and > black death don't make damage. > > I tried to restrict the bug : in the archetypes file, all the "no damaging" > disease have a negative number for the damage (ex : for red death, it's > "dam -10". > Then, I tried to replace the -10 by 10 and red death is very deadly (and it's > the right comportment, I think.) > > Finding this problem, I find other "dam -" begining lines that probably have >the > same effect (immolation that I didn't try have perhaps the same bug). > > Does someone have the right solution (personaly, I think it could be a proble >m > in the archetypes file itself or a bug in its parsing...) ? > > Olivier. > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From huet.o at free.fr Mon Jul 8 16:32:56 2002 From: huet.o at free.fr (huet.o@free.fr) Date: Thu Jan 13 18:04:17 2005 Subject: [CF List] problem with some diseases In-Reply-To: <200207081436.g68EaK317901@tonks.EECS.Berkeley.EDU> References: <200207081436.g68EaK317901@tonks.EECS.Berkeley.EDU> Message-ID: <1026163976.3d2a0508cbccc@imp.free.fr> Hello, En r?ponse ? Peter Mardahl : > Are you sure the "broken" diseases aren't simply heavily damaging > the monsters but not killing them? > Yes : to be sure, I take another player and put him just near a monster, and then, I infect the monster with red death. My second player was infected too and take about 2 damage by "itche" of red death (it's about 1 percent of its life points). And even it's writen in the documentation that "second hand red death infected" are less powerfull than "first hand infected", I think there's a problem... > Or has someone been meddling with the disease code recently and > broken the "negative" damage? > I don't know anything in crossfire's code, but I've just take a look and put some trace in a function (I'm not sure it's the right place...) : int do_symptoms(object *disease) in disease.c : there are stuff with dam : I add some trace code (see my printf :) ... /* Something special done with dam. We want diseases to be more random in what they'll kill, so we'll make the damage they do random, note, this has a weird effect with progressive diseases.*/ if(disease->stats.dam != 0) { int dam = disease->stats.dam; // OH : printf("OHDIS dam1 : %i\n", dam); //////////////// /* reduce the damage, on average, 50%, and making things random. */ dam = random_roll(1, dam, victim, PREFER_LOW); // OH : printf("OHDIS dam2 : %i\n", dam); //////////////// if(disease->stats.dam < 0) dam = -dam; // OH : printf("OHDIS dam3 : %i\n", dam); //////////////// new_symptom->stats.dam = dam; } ... ----------------------------------------------------------- then, I launch it and cause red death to a little pirate : here is the result OHDIS dam1 : -52 Calling random_roll with min=1 max=-52 OHDIS dam2 : 1 OHDIS dam3 : -1 (repeated many times) ---------------------------------------------------- and then, I cause a leprosy OHDIS dam1 : 50 OHDIS dam2 : 20 OHDIS dam3 : 20 Trying to insert in null-map! arch leprous_skin name leprous flake of skin name_pl leprous flake of skin face skin.111 food 5 type 72 weight 7 end I must precise that the player (who cast these disease) is powerfull : level 49 of wisdom (because there is perhaps another bug -- it's another problem... : it take lot of points causing cold to low level monsters, but it's perhaps a corrected bug : it was with the 1.1.0 version) Hope my desctiption of the problem and trace will help. Olivier. > > > Hello everybody, > > > > I hope it's the right mailing list for my "bug" report. > > > > > > I make a character worshiping Devourers, and I found some "high" > disease > > ineficient to make damage : > > > > In fact, cold, flu and leprosy work fine, but typhoid, anthrax, red > death and > > black death don't make damage. > > > > I tried to restrict the bug : in the archetypes file, all the "no > damaging" > > disease have a negative number for the damage (ex : for red death, > it's > > "dam -10". > > Then, I tried to replace the -10 by 10 and red death is very deadly > (and it's > > the right comportment, I think.) > > > > Finding this problem, I find other "dam -" begining lines that > probably have > >the > > same effect (immolation that I didn't try have perhaps the same > bug). > > > > Does someone have the right solution (personaly, I think it could be a > proble > >m > > in the archetypes file itself or a bug in its parsing...) ? > > > > Olivier. > > _______________________________________________ > > crossfire-list mailing list > > crossfire-list@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-list > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list > From mwedel at sonic.net Mon Jul 8 23:28:56 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:17 2005 Subject: [CF List] problem with some diseases References: <200207081436.g68EaK317901@tonks.EECS.Berkeley.EDU> <1026163976.3d2a0508cbccc@imp.free.fr> Message-ID: <3D2A6688.4080406@sonic.net> I've fixed the problem, now committed into the CVS tree: server/disease.c: Fix propogation of diseases with negative damage (these do a percent of the creatures damage). The new disease was getting a damage rating of 1 in all cases because we were passing a negative value to random_roll for the top end of the range. MSW 2002-07-08 This was sort of an odd bug - it was introduced when garbled redid the code to use random_roll so luck had a bigger part. That particular piece of code was non obvious that damage could be negative. Apparantly, the mod (%) operator still worked (according to my very old C book, result is machine dependent if either of the options to % are negative). Simple fix. Thanks for the info provided - it made finding the bug very easy. From olle at viksten.com Tue Jul 9 01:57:10 2002 From: olle at viksten.com (Olle Viksten) Date: Thu Jan 13 18:04:17 2005 Subject: [CF List] Error compiling client Message-ID: <200207090857.10801.olle@viksten.com> When I try to compile the 1.3.0 client I get the follwing message, can someone tell me what's wrong?: making all in sound-src... make[1]: Entering directory `/data1/bygg/crossfire/crossfire-client-1.3.0/sound-src' /usr/bin/perl -p -e s#/usr/local/lib/sounds#/usr/local/share/crossfire-client/sounds# sounds.dist > sounds /usr/bin/perl ../utils/deftoheader.pl sounds soundsdef.h def_sounds 199 lines processed gcc -g -O2 -DALSA_SOUND -Wall -I. -I.. -I../common -I. -c cfsndserv.c In file included from cfsndserv.c:87: /usr/include/sys/asoundlib.h:1: warning: #warning This header is deprecated, use instead. cfsndserv.c: In function `init_audio': cfsndserv.c:283: `snd_pcm_channel_params_t' undeclared (first use in this function) cfsndserv.c:283: (Each undeclared identifier is reported only once cfsndserv.c:283: for each function it appears in.) cfsndserv.c:283: parse error before `params' cfsndserv.c:285: `SND_PCM_OPEN_PLAYBACK' undeclared (first use in this function) cfsndserv.c:285: warning: passing arg 2 of `snd_pcm_open' makes pointer from integer without a cast cfsndserv.c:290: `params' undeclared (first use in this function) cfsndserv.c:290: `SND_PCM_CHANNEL_PLAYBACK' undeclared (first use in this function) cfsndserv.c:291: `SND_PCM_MODE_BLOCK' undeclared (first use in this function) cfsndserv.c:294: `SND_PCM_SFMT_S8' undeclared (first use in this function) cfsndserv.c:294: `SND_PCM_SFMT_U8' undeclared (first use in this function) cfsndserv.c:296: `SND_PCM_SFMT_S16_LE' undeclared (first use in this function) cfsndserv.c:296: `SND_PCM_SFMT_U16_LE' undeclared (first use in this function) cfsndserv.c:304: warning: implicit declaration of function `snd_pcm_channel_params' cfsndserv.c:318: warning: unreachable code at beginning of switch statement cfsndserv.c:342: warning: implicit declaration of function `snd_pcm_file_descriptor' cfsndserv.c:343: warning: implicit declaration of function `snd_pcm_nonblock_mode' cfsndserv.c: In function `audio_play': cfsndserv.c:350: warning: implicit declaration of function `snd_pcm_write' make[1]: *** [cfsndserv.o] Error 1 make[1]: Leaving directory `/data1/bygg/crossfire/crossfire-client-1.3.0/sound-src' make: *** [all] Error 2 From tanner at real-time.com Tue Jul 9 12:08:51 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:04:17 2005 Subject: [CF List] Error compiling client In-Reply-To: <200207090857.10801.olle@viksten.com>; from olle@viksten.com on Tue, Jul 09, 2002 at 08:57:10AM +0200 References: <200207090857.10801.olle@viksten.com> Message-ID: <20020709120851.V21455@real-time.com> Quoting Olle Viksten (olle@viksten.com): > When I try to compile the 1.3.0 client I get the follwing message, can someone > tell me what's wrong?: > What OS? If linux what distribution? Version of gcc? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 http://www.tcwug.org, Minnesota, Wireless | Coding isn't a crime. Fingerprint: 02E0 2734 A1A1 DBA1 0E15 623D 0036 7327 93D9 7DA3 From reeve at linuxfreemail.com Tue Jul 9 13:11:03 2002 From: reeve at linuxfreemail.com (Scott Barnes) Date: Thu Jan 13 18:04:18 2005 Subject: [CF List] Error compiling client In-Reply-To: <20020709120851.V21455@real-time.com> References: <200207090857.10801.olle@viksten.com> <20020709120851.V21455@real-time.com> Message-ID: <20020709141103.752af33e.reeve@linuxfreemail.com> On Tue, 9 Jul 2002 12:08:51 -0500 Bob Tanner wrote: > Quoting Olle Viksten (olle@viksten.com): > > When I try to compile the 1.3.0 client I get the follwing message, can someone > > tell me what's wrong?: > > > > What OS? > > If linux what distribution? > > Version of gcc? After reading the original post I forgot to reply, so I'll reply to this one :) I've seen that same problem many times before, it's because you're using ALSA 0.9, while cfclient's ALSA code only works with ALSA 0.5. -- Reeve the cat ------------- -----BEGIN FORTUNE----- Sin boldly. -- Martin Luther ------END FORTUNE------ -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020709/60255316/attachment.pgp From taverngeek at yahoo.com Tue Jul 9 17:39:19 2002 From: taverngeek at yahoo.com (Scott Wedel) Date: Thu Jan 13 18:04:18 2005 Subject: [CF List] problem with some diseases In-Reply-To: <200207081436.g68EaK317901@tonks.EECS.Berkeley.EDU> Message-ID: <20020709223919.10548.qmail@web10402.mail.yahoo.com> --- Peter Mardahl wrote: > > "negative" damage had some special meaning, like it does > ten percent of damage regardless of caster level, > while positive damage is increased by caster level. > > Either that or the other way around. This type of stuff is straightforward really bad programming technique. It is using the sign of the damage value to determine what could be called DISEASE_DAMAGE_ADJUSTER. Currently, the disease definition is needlessly obscure when instead it should be clear so that someone could add a new disease or modify the current ones. Also, using +/- limits diseases to only two types of damage modifiers and there is no inherent reason for such a limit. Diseases could, in theory, do fixed HP damage, a percentage of current HP, a percentage of MAX HP and all of these further either independent of caster level or adjuster by caster level. A disease like gangrene might make more sense as a percentage of current HP while a disease like sepsis might make more sense as a percentage of max HP while a cold might be a fixed number of HP (a strong person might be barely affected while a weak person is comparatively hit hard). Scott Wedel __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com From kbulgrien at worldnet.att.net Wed Jul 10 01:49:35 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:04:18 2005 Subject: [CF List] Problems & question on client 1.3.1 RPMS off of SourceForge In-Reply-To: <20020709223919.10548.qmail@web10402.mail.yahoo.com> References: <20020709223919.10548.qmail@web10402.mail.yahoo.com> Message-ID: <02071001493500.14741@krayp120.worldnet.att.net> Client sounds 1) crossfire-client-sounds-1.3.1-realtime.1.rpm package confuses me. The sound files are installed to /usr/share/sounds/crossfire, but the cfsndserv task expects them elsewhere, and spews errors . The sound files really should be in /usr/share/games/crossfire/crossfire-client/sounds... I symlinked the directory, and it works, but the package really out to be built consistently. # ln -s /usr/share/sounds/crossfire /usr/share/games/crossfire/crossfire-client/sounds GTK Client 1) I noticed that pattern matching was changed with this release... Well, it has really changed... If there are "five stoneaxes" in the inventory, 'drop five stoneaxes' says "nothing to drop". 'drop 5 stoneaxes' drops five of everything you have five of... OUCH! 'drop bows +1' drops bows, not just the +1 bows... though the bow -1 is not dropped... Oops ... looks like we went to a minimal match on the regular expression or something... 'drop daggers' drops all daggers except, for example "throwing daggers"... (I would not have expected it to drop the them, so that is ok.) 2) Also there is a persisting problem from older releases of the the client... Right-clicking an item to drop it, gives messages like: There are only one clubs. Sure there are, and I wanted you to drop them silly... It seems the only fix here is to drop out of the client and restart it... When this happens, it is not possible to drop anything with a right click. 3) GTK Client How on earth do I lock inventory items? I can't see anything in help that gives me a clue... I am sure there is supposed to be some way to do it because there is a lock/unlock option on the inventory... 4) What is the "Count" field for? 5) Why does the menu selection "Client Spells just dump a bunch of "Spell:" messages on the console session... Nothing else, just that. 6) Is there a point to the menu functions under Action? I guess the pickup's make sense, but why would I click cast, then have to take my hand off the mouse to type in the spell. I must be missing something? 7) What does the 'E' key do? 8) Experienced segmentation faults whenever I tried to save configuration options... Oddly, the options did not relate to the values in the user option file. Permissions were correct. Manually edited the file with vi, and segmentation faults quit happening... Changed a few 0's to 1's... It is unclear why this started happening... the client had never been installed on this system before, so the user did not have a pre-existing saved configuration. It had created the file itself, but then was in a state where is seg faulted when the user tried to save new settings. --- Here's just a sample of the gcfclient output with some of the symptoms I've seen... [krb@krayp120 .crossfire]$ gcfclient Character Width : 11 Character Height: 11 Warning: could not convert keysym F28 into keycode, ignoring Warning: could not convert keysym F34 into keycode, ignoring Warning: could not convert keysym F30 into keycode, ignoring Warning: could not convert keysym F32 into keycode, ignoring Warning: could not convert keysym F27 into keycode, ignoring Warning: could not convert keysym F29 into keycode, ignoring Warning: could not convert keysym F31 into keycode, ignoring Warning: could not convert keysym F33 into keycode, ignoring Warning: could not convert keysym F35 into keycode, ignoring Couldn't open /dev/dsp: Device or resource busy Playing on server type Crossfire Server Fatal signal: Segmentation Fault (SDL Parachute Deployed) [krb@krayp120 .crossfire]$ gcfclient Character Width : 11 Character Height: 11Character Height: 11 Warning: could not convert keysym F28 into keycode, ignoring Warning: could not convert keysym F34 into keycode, ignoring Warning: could not convert keysym F30 into keycode, ignoring Warning: could not convert keysym F32 into keycode, ignoring Warning: could not convert keysym F27 into keycode, ignoring Warning: could not convert keysym F29 into keycode, ignoring Warning: could not convert keysym F31 into keycode, ignoring Warning: could not convert keysym F33 into keycode, ignoring Warning: could not convert keysym F35 into keycode, ignoring Unknown metaserver hostname: crossfire.real-time.com Unable to open /home/krb/.crossfire/sounds - will use built in defaults Playing on server type Crossfire Server Unknown input state: 2 /usr/share/games/crossfire/crossfire-client/sounds/click1.raw: No such file or directory /usr/share/games/crossfire/crossfire-client/sounds/click1.raw: No such file or directory /usr/share/games/crossfire/crossfire-client/sounds/Creaky-1.raw: No such file or directory ... gtk_main exited, returning from event_loop [krb@krayp120 .crossfire]$ [krb@krayp120 .crossfire]$ gcfclient Character Width : 11 Character Height: 11 Warning: could not convert keysym F28 into keycode, ignoring Warning: could not convert keysym F34 into keycode, ignoring Warning: could not convert keysym F30 into keycode, ignoring Warning: could not convert keysym F32 into keycode, ignoring Warning: could not convert keysym F27 into keycode, ignoring Warning: could not convert keysym F29 into keycode, ignoring Warning: could not convert keysym F31 into keycode, ignoring Warning: could not convert keysym F33 into keycode, ignoring Warning: could not convert keysym F35 into keycode, ignoring Couldn't open /dev/dsp: Device or resource busy [krb@krayp120 .crossfire]$ gcfclient Character Width : 11 Character Height: 11 Warning: could not convert keysym F28 into keycode, ignoring Warning: could not convert keysym F34 into keycode, ignoring Warning: could not convert keysym F30 into keycode, ignoring Warning: could not convert keysym F32 into keycode, ignoring Warning: could not convert keysym F27 into keycode, ignoring Warning: could not convert keysym F29 into keycode, ignoring Warning: could not convert keysym F31 into keycode, ignoring Warning: could not convert keysym F33 into keycode, ignoring Warning: could not convert keysym F35 into keycode, ignoring Couldn't open /dev/dsp: Device or resource busy Playing on server type Crossfire Server Fatal signal: Segmentation Fault (SDL Parachute Deployed) [krb@krayp120 .crossfire]$ gcfclient Character Width : 11 Character Height: 11 Warning: could not convert keysym F28 into keycode, ignoring Warning: could not convert keysym F34 into keycode, ignoring Warning: could not convert keysym F30 into keycode, ignoring Warning: could not convert keysym F32 into keycode, ignoring Warning: could not convert keysym F27 into keycode, ignoring Warning: could not convert keysym F29 into keycode, ignoring Warning: could not convert keysym F31 into keycode, ignoring Warning: could not convert keysym F33 into keycode, ignoring Warning: could not convert keysym F35 into keycode, ignoring Unable to open /home/krb/.crossfire/sounds - will use built in defaults Playing on server type Crossfire Server Unknown input state: 2 Spell: Spell: Spell: Spell: Spell: Spell: Spell: Spell: Spell: Spell: Spell: Spell: Spell: Spell: Spell: Spell: Spell: Spell: Spell: Spell: Spell: Spell: Spell: Spell: Spell: From kbulgrien at worldnet.att.net Wed Jul 10 01:53:45 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:04:18 2005 Subject: [CF List] Server 1.3.0 Makefile broken In-Reply-To: <20020709223919.10548.qmail@web10402.mail.yahoo.com> References: <20020709223919.10548.qmail@web10402.mail.yahoo.com> Message-ID: <02071001534501.14741@krayp120.worldnet.att.net> ..configure properly detected that makedepend did not exist, but then this happened... --- [root@krayp120 crossfire-1.3.0]# make depend making depend in common... make[1]: Entering directory `/home/operator/pkg/crossfire-1.3/crossfire-1.3.0/common' g -O2 -I../include -I./../include -- anim.c arch.c button.c exp.c friend.c glue.c holy.c info.c image.c init.c item.c links.c living.c loader.c logger.c los.c map.c object.c porting.c player.c re-cmp.c readable.c recipe.c shstr.c time.c treasure.c utils.c make[1]: g: Command not found make[1]: [depend] Error 127 (ignored) make[1]: Leaving directory `/home/operator/pkg/crossfire-1.3/crossfire-1.3.0/common' making depend in random_maps... make[1]: Entering directory `/home/operator/pkg/crossfire-1.3/crossfire-1.3.0/random_maps' g -O2 -I../include -I. -I../include -- random_map.c room_gen_onion.c room_gen_spiral.c maze_gen.c reader.c floor.c wall.c monster.c door.c decor.c exit.c treasure.c special.c style.c rogue_layout.c snake.c square_spiral.c expand2x.c make[1]: g: Command not found make[1]: [depend] Error 127 (ignored) make[1]: Leaving directory `/home/operator/pkg/crossfire-1.3/crossfire-1.3.0/random_maps' making depend in socket... make[1]: Entering directory `/home/operator/pkg/crossfire-1.3/crossfire-1.3.0/socket' g -O2 -I../include -I./../include -- image.c info.c init.c item.c loop.c lowlevel.c metaserver.c request.c sounds.c make[1]: g: Command not found make[1]: [depend] Error 127 (ignored) make[1]: Leaving directory `/home/operator/pkg/crossfire-1.3/crossfire-1.3.0/socket' making depend in server... make[1]: Entering directory `/home/operator/pkg/crossfire-1.3/crossfire-1.3.0/server' g -O2 -I../include -I./../include -I../include -- alchemy.c apply.c attack.c ban.c c_chat.c c_misc.c c_move.c c_new.c c_object.c c_party.c c_range.c c_wiz.c commands.c daemon.c disease.c egoitem.c hiscore.c gods.c init.c login.c main.c monster.c move.c pets.c player.c plugins.c resurrection.c rune.c shop.c skills.c skill_util.c spell_effect.c spell_util.c swamp.c swap.c time.c timers.c weather.c make[1]: g: Command not found make[1]: [depend] Error 127 (ignored) make[1]: Leaving directory `/home/operator/pkg/crossfire-1.3/crossfire-1.3.0/server' making depend in include... make[1]: Entering directory `/home/operator/pkg/crossfire-1.3/crossfire-1.3.0/include' make[1]: Nothing to be done for `depend'. make[1]: Leaving directory `/home/operator/pkg/crossfire-1.3/crossfire-1.3.0/include' making depend in lib... make[1]: Entering directory `/home/operator/pkg/crossfire-1.3/crossfire-1.3.0/lib' makedepend -- -I../include -- make[1]: makedepend: Command not found make[1]: *** [depend] Error 127 make[1]: Leaving directory `/home/operator/pkg/crossfire-1.3/crossfire-1.3.0/lib' making depend in utils... make[1]: Entering directory `/home/operator/pkg/crossfire-1.3/crossfire-1.3.0/utils' make[1]: `depend' is up to date. make[1]: Leaving directory `/home/operator/pkg/crossfire-1.3/crossfire-1.3.0/utils' making depend in doc... make[1]: Entering directory `/home/operator/pkg/crossfire-1.3/crossfire-1.3.0/doc' make[1]: Nothing to be done for `depend'. make[1]: Leaving directory `/home/operator/pkg/crossfire-1.3/crossfire-1.3.0/doc' making depend in plugin... make[1]: Entering directory `/home/operator/pkg/crossfire-1.3/crossfire-1.3.0/plugin' g -O2 -I../include -I./../include -I./include -I../include -- plugin_python.c make[1]: g: Command not found make[1]: [depend] Error 127 (ignored) make[1]: Leaving directory `/home/operator/pkg/crossfire-1.3/crossfire-1.3.0/plugin' [root@krayp120 crossfire-1.3.0]# From kbulgrien at worldnet.att.net Wed Jul 10 02:01:31 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:04:18 2005 Subject: [CF List] GTK 1.3.1 client trouble In-Reply-To: <20020709223919.10548.qmail@web10402.mail.yahoo.com> References: <20020709223919.10548.qmail@web10402.mail.yahoo.com> Message-ID: <02071002013102.14741@krayp120.worldnet.att.net> Whereas the ? Name and Weight tabs in the "you see" window are resizeable, the ones in the inventory window are not... From kbulgrien at worldnet.att.net Wed Jul 10 02:14:28 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:04:18 2005 Subject: [CF List] Server 1.3.0 oddity... In-Reply-To: <20020709223919.10548.qmail@web10402.mail.yahoo.com> References: <20020709223919.10548.qmail@web10402.mail.yahoo.com> Message-ID: <02071002142903.14741@krayp120.worldnet.att.net> Why does the server complain about map files or overlays not being in /var/crossfire/maps when I log in? The maps are supposed to be in usr... not var... right? Everything seems to work ok even though it complains... Then, other messages like this show up from time to time... Right now I see a complaint about a store that I just entered... --- [root@krayp120 crossfire-client]# cd /home/games/bin [root@krayp120 bin]# ls add_throw* collect.pl* crossfire* crossloop* crossloop.pl* crossloop.web* flushlocks* mktable* random_map* util.pl* [root@krayp120 bin]# ./crossfire Reading bmaps from /home/games/share/crossfire/bmaps...done (got 3828/3829/3829) Reading faces from /home/games/share/crossfire/faces...done Reading animations from /home/games/share/crossfire/animations...done. got (768) Reading archetypes from /home/games/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 /home/games/share/crossfire/attackmess...got 227 messages in 19 categories. Reading clockdata from /home/games/var/crossfire/clockdata...todtick=154 Welcome to CrossFire, v1.3.0 Copyright (C) 1994 Mark Wedel. Copyright (C) 1992 Frank Tore Johansen. Can't open /home/games/share/crossfire/shutdown Reading artifacts from /home/games/share/crossfire/artifacts...done. Initializing spells...done. Reading races from /home/games/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 /home/games/share/crossfire/messages...done. Reading bookarch from /home/games/var/crossfire/bookarch... book archives(used/avail): (2/924)(2/169)(1/77)(1/70) done. init_mon_info() got 258 monsters Done Reading alchemical formulae from /home/games/share/crossfire/formulae...done. Checking formulae lists...done. Reading skill_params from /home/games/share/crossfire/skill_params...done. Initialize new client/server data Loading image file /home/games/share/crossfire/crossfire.0 Loading image file /home/games/share/crossfire/crossfire.1 Initializing plugins : Waiting for connections... clean_friendly_list: Removed 1 bogus links CS: connection from client of type < GTK Unix Client 1.3.0> Get SetupCmd:: map1acmd 1 sound 1 sexp 1 darkness 1 newmapcmd 1 faceset 0 facecache 0 itemcmd 2 SendBack SetupCmd:: setup map1acmd 1 sound 1 sexp 1 darkness 1 newmapcmd 1 faceset 0 facecache 0 itemcmd Get SetupCmd:: faceset 0 SendBack SetupCmd:: setup faceset 0 Initializing gods...done. Trying to load map /home/games/share/crossfire/maps/HallOfSelection. load_original_map: /HallOfSelection (0) Can't open /home/games/var/crossfire/maps/HallOfSelection Can't open overlay /home/games/var/crossfire/maps/HallOfSelection enter_map: supplied coordinates are not within the map! (/HallOfSelection: -1, -1) Trying to load map /home/games/share/crossfire/maps/city/shops/generalshop. load_original_map: /city/shops/generalshop (0) Can't open /home/games/var/crossfire/maps/city/shops/generalshop Can't open overlay /home/games/var/crossfire/maps/city/shops/generalshop Checksums: 302a3ec5 302a3ec5 LOGIN: Player named Rayvin from ip 127.0.0.1 Trying to load map /home/games/share/crossfire/maps/city/city. load_original_map: /city/city (0) Can't open /home/games/var/crossfire/maps/city/city Can't open overlay /home/games/var/crossfire/maps/city/city Resetting map /HallOfSelection. From olle at viksten.com Wed Jul 10 01:53:30 2002 From: olle at viksten.com (Olle Viksten) Date: Thu Jan 13 18:04:18 2005 Subject: [CF List] Error compiling client In-Reply-To: <20020709120851.V21455@real-time.com> References: <200207090857.10801.olle@viksten.com> <20020709120851.V21455@real-time.com> Message-ID: <200207100853.30941.olle@viksten.com> tisdagen den 9 juli 2002 19.08 wrote Bob Tanner: > Quoting Olle Viksten (olle@viksten.com): > > When I try to compile the 1.3.0 client I get the follwing message, can > > someone tell me what's wrong?: > > What OS? Linux Suse 8 > Version of gcc? 2.95.3 Olle From olle at viksten.com Wed Jul 10 02:32:17 2002 From: olle at viksten.com (Olle Viksten) Date: Thu Jan 13 18:04:18 2005 Subject: [CF List] Error compiling client In-Reply-To: <20020709141103.752af33e.reeve@linuxfreemail.com> References: <200207090857.10801.olle@viksten.com> <20020709120851.V21455@real-time.com> <20020709141103.752af33e.reeve@linuxfreemail.com> Message-ID: <200207100932.17317.olle@viksten.com> tisdagen den 9 juli 2002 20.11 wrote Scott Barnes: > On Tue, 9 Jul 2002 12:08:51 -0500 > After reading the original post I forgot to reply, so I'll reply to this > one :) I've seen that same problem many times before, it's because you're > using ALSA 0.9, while cfclient's ALSA code only works with ALSA 0.5. Thanks, after running configure --disable-alsa it compiled just fine. Olle From andi.vogl at gmx.net Wed Jul 10 03:11:37 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:04:18 2005 Subject: [CF List] problem with some diseases References: <20020709223919.10548.qmail@web10402.mail.yahoo.com> Message-ID: <8753.1026288697@www47.gmx.net> Scott Wedel wrote: > > > > "negative" damage had some special meaning [...] > > This type of stuff is straightforward really bad programming technique. > It is using the sign of the damage value to determine what could > be called DISEASE_DAMAGE_ADJUSTER. No doubt it's bad style, but unfortunately the CF object structure is not as flexible as we'd like it to be. If unique variables and flags get added for different object types (like the "disease-adjuster" you proposed), that would cause a big overall increase in memory consumption. The problem is that all objects have the same structure. Best you can do is link-in substructures with pointers - But that's no perfect solution either (danger of null-pointers getting accessed). > Currently, the disease definition is needlessly obscure when > instead it should be clear so that someone could add a new > disease or modify the current ones. [...] Try the CFJavaEditor, like for most other objects there is a good interface for modifying diseases. It wouldn't be too hard to rip out the attribute-interface code from the JavaEditor and create a stand-alone "arch creation" application, if that seems useful. Andreas -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From peterm at tonks.EECS.Berkeley.EDU Wed Jul 10 09:39:37 2002 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:04:18 2005 Subject: [CF List] problem with some diseases In-Reply-To: Your message of "Tue, 09 Jul 2002 15:39:19 PDT." <20020709223919.10548.qmail@web10402.mail.yahoo.com> Message-ID: <200207101439.g6AEdbE25265@tonks.EECS.Berkeley.EDU> > This type of stuff is straightforward really bad programming technique. > It is using the sign of the damage value to determine what could be called > DISEASE_DAMAGE_ADJUSTER. Currently, the disease definition is needlessly > obscure when instead it should be clear so that someone could add a new > disease or modify the current ones. Hate to say this, but I as running out of parameters with which to modify diseases. Check out the documents I wrote on it: I've used pretty much every sensible parameter and a lot of senseless ones, for tuning diseases, and documented them very carefully so I sort of object to you describing them as "needlessly obscure". At the time there were no quick and easy ways of changing the names of stuff in archetypes to something nice like DISEASE_DAMAGE_ADJUSTER. From mwedel at sonic.net Wed Jul 10 22:23:07 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:18 2005 Subject: [CF List] problem with some diseases References: <200207101439.g6AEdbE25265@tonks.EECS.Berkeley.EDU> Message-ID: <3D2CFA1B.1080004@sonic.net> Andreas Vogl wrote: > > No doubt it's bad style, but unfortunately the CF object structure is > not as flexible as we'd like it to be. If unique variables and flags get > added for different object types (like the "disease-adjuster" you > proposed), that would cause a big overall increase in memory consumption. > The problem is that all objects have the same structure. Best you can > do is link-in substructures with pointers - But that's no perfect solution > either (danger of null-pointers getting accessed). I think the problem is more that way back in the history of crossfire, trying to conserve every byte for the object was considered very important, so all sorts of fields go overloaded with strange meanings depending on the object. Now there is certainly reason to not bloat the object up excessively, but the amount of ram in machines has grown a great deal - more so than the number of objects crossfire typically would have loaded at any time. So adding more fields to the object structure isn't that big a deal. The problem is updating all the code - in some cases, macros are used to access the member, so updating those are easy. But in many cases, the structure member is access directly. I should say that in this particular case, the use of negative damage to denote something different isn't that bad. As said, the docs say that is the case. It was really just one line that created the problem. In doing the change of apply method, I have made a lot of cleanups - really going forward, anything that needs a new field should add a new field to the object structure and not overload something. It should now be much simpler to do that in the past (which perhaps was never really hard, just cryptic). From mwedel at sonic.net Wed Jul 10 22:26:56 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:18 2005 Subject: [CF List] Error compiling client References: <200207090857.10801.olle@viksten.com> <20020709120851.V21455@real-time.com> <20020709141103.752af33e.reeve@linuxfreemail.com> Message-ID: <3D2CFB00.60902@sonic.net> Scott Barnes wrote: > On Tue, 9 Jul 2002 12:08:51 -0500 > Bob Tanner wrote: > > >>Quoting Olle Viksten (olle@viksten.com): >> >>>When I try to compile the 1.3.0 client I get the follwing message, can someone >>>tell me what's wrong?: >>> >> >>What OS? >> >>If linux what distribution? >> >>Version of gcc? > > > After reading the original post I forgot to reply, so I'll reply to this one :) > I've seen that same problem many times before, it's because you're using ALSA 0.9, while cfclient's ALSA code only works with ALSA 0.5. > I should note that I recall in the past, there was a similar problem - the ALSA code in the client worked with some older version, but not what was then current (probably 0.5 I would guess). I guess in some sense ALSA isn't at 1.0 yet so may be considered free to change their interfaces. But I'm not that interested in having to keep re-update the client code as the interfaces for ALSA changes (plus, I'm not familiar with ALSA, and don't have it installed on my system). From kbulgrien at worldnet.att.net Wed Jul 10 22:13:17 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:04:18 2005 Subject: [CF List] Problems & question on client 1.3.1 RPMS off of SourceForge In-Reply-To: <02071001493500.14741@krayp120.worldnet.att.net> References: <20020709223919.10548.qmail@web10402.mail.yahoo.com> <02071001493500.14741@krayp120.worldnet.att.net> Message-ID: <02071022131700.08948@krayp120.worldnet.att.net> On Wednesday 10 July 2002 01:49, you wrote: > 3) GTK Client > > How on earth do I lock inventory items? I can't see anything in help > that gives me a clue... I am sure there is supposed to be some way > to do it because there is a lock/unlock option on the inventory... Press the key while left clicking the item to lock/unlock... From mwedel at sonic.net Wed Jul 10 23:03:23 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:19 2005 Subject: Various troubles, Re: [CF List] Server 1.3.0 oddity... References: <20020709223919.10548.qmail@web10402.mail.yahoo.com> <02071002142903.14741@krayp120.worldnet.att.net> Message-ID: <3D2D038B.20704@sonic.net> I'm just going to reply to all the questions in one message. Kevin R. Bulgrien wrote: > Why does the server complain about map files or overlays not being > in /var/crossfire/maps when I log in? The maps are supposed to be > in usr... not var... right? > > Everything seems to work ok even though it complains... > > Then, other messages like this show up from time to time... Right now > I see a complaint about a store that I just entered... The server will produce a lot of debugging messages. There is unfortunately no clear way to know if the error is really a problem or something put in for informative purposes. Overlay maps really are not being used for anything right now. They will probably get used much more with the new world maps. I need to look at the code more, but they may also get used to replace the non per player unique map stuff - those are currently saved in a format that is unique. > Whereas the ? Name and Weight tabs in the "you see" window are resizeable, > the ones in the inventory window are not... This is intentional. There are some more complicated issues in making those resizable (whether or not all the tabs should get updated). There also seems to be some issue of gtk automatically changing the size back again at some point, but perhaps that is fixed in the more recent issues of GTK. This generally doesn't seem to be a very big issue. > ..configure properly detected that makedepend did not exist, but then this > happened... > Not having makedepend is not critical, but I'll update the makefile to more gracefully deal with cases where makedepend does not exist. > crossfire-client-sounds-1.3.1-realtime.1.rpm package confuses > me. The sound files are installed to /usr/share/sounds/crossfire, but the > cfsndserv task expects them elsewhere, and spews errors . The sound > files really should be in /usr/share/games/crossfire/crossfire-client/sounds... I believe a new RPM has been rolled that fixes this problem. > I noticed that pattern matching was changed with this release... > > Well, it has really changed... > > If there are "five stoneaxes" in the inventory, 'drop five stoneaxes' > says "nothing to drop". > > 'drop 5 stoneaxes' drops five of everything you have five of... > OUCH! > > 'drop bows +1' drops bows, not just the +1 bows... > though the bow -1 is not dropped... > > Oops ... looks like we went to a minimal match on the regular > expression or something... > > 'drop daggers' drops all daggers except, for example "throwing > daggers"... (I would not have expected it to drop the them, so > that is ok.) The pattern matching for 'drop' happens on the server. There is a bug in the 1.3.0 release that results in the bad matches when you use a drop with a number greater than 1. This is fixed in CVS. the issue with bows you describe has been around for quite a while. There is some 'oddity' in that the function that does this, item_matched_string, does return different numbers depending on how good it thinks the match is. However, nothing currently uses those, so the default is basically that very loose matching happens. The first rule to note is that all matching is against the start of the string. Which is why 'drop daggers' won't match against throwing daggers. The second thing to note is that if the first X characters in the parameter you give match the first X characters of an object in your inventory, it will be returned as a loose match. X in this case is the length of the shorter of those two names - thus, the drop bows +1 matches against 'bows' in your inventory. There is probably room for improvement. First thing would probably be to not use the shorter of the two strings being compared, instead, also compare against the length of the string passed, so the bows +1 does the right thing. > > 2) > > Also there is a persisting problem from older releases of the the > client... > > Right-clicking an item to drop it, gives messages like: > > There are only one clubs. > > Sure there are, and I wanted you to drop them silly... It seems > the only fix here is to drop out of the client and restart it... > When this happens, it is not possible to drop anything with > a right click. Just hit the right click again, and it should work. What is happening is that sometime during play, you are probably hitting the number keys. the client is holding those as the number of items to drop, so that value can be held for a very long time. When you try to drop something, whether successful or not, that count is reset to 0 In the GTK client, you can see what it things the drop/pickup count currently is - it is displayed in the upper right portion of the inventory pain. > > 3) GTK Client > > How on earth do I lock inventory items? I can't see anything in help > that gives me a clue... I am sure there is supposed to be some way > to do it because there is a lock/unlock option on the inventory... shift left click on an item in your inventory. > > 4) > > What is the "Count" field for? See note above. It is basically for dropping/picking up less than the total quantity of something. Eg, you may have 1000 platinum, but only want to drop 500 of it - setting the count to 500 will do just that. > > 5) > > Why does the menu selection "Client Spells just dump a bunch of > "Spell:" messages on the console session... Nothing else, just that. I beleive this is reserved for a future enhancement. > > 6) > > Is there a point to the menu functions under Action? I guess the > pickup's make sense, but why would I click cast, then have to take > my hand off the mouse to type in the spell. I must be missing something? No big reason - I think some of them where to make them more available to new players who may not know about cast, or who, or whatever else. They are only really 'shortcuts' - the command they send to the server is the same whether you do it through that menu or through typing in the command yourself. > > 7) > > What does the 'E' key do? examines the object below you. Generally speaking, pretty useless as you don't care what is below you. This is basically the same thing as left clicking on the object. > > 8) > > Experienced segmentation faults whenever I tried to save configuration > options... Oddly, the options did not relate to the values in the user > option file. Permissions were correct. Manually edited the file with > vi, and segmentation faults quit happening... Changed a few 0's > to 1's... > > It is unclear why this started happening... the client had never been > installed on this system before, so the user did not have a pre-existing > saved configuration. It had created the file itself, but then was in a > state where is seg faulted when the user tried to save new settings. No clue on this. The save routine appears to do the right thing when itcomes to making sure the file is opened correctly and whatnot. Would probably need to see core file to really know what is going on here. From taverngeek at yahoo.com Thu Jul 11 16:59:02 2002 From: taverngeek at yahoo.com (Scott Wedel) Date: Thu Jan 13 18:04:19 2005 Subject: [CF List] problem with some diseases In-Reply-To: <200207101439.g6AEdbE25265@tonks.EECS.Berkeley.EDU> Message-ID: <20020711215902.54492.qmail@web10403.mail.yahoo.com> > Hate to say this, but I as running out of parameters with which to modify > diseases. Check out the documents I wrote on it: I've used pretty > much every sensible parameter and a lot of senseless ones, for tuning > diseases, and > documented them very carefully so I sort of object to you describing them as > "needlessly obscure". But you (and Mark in his response) both miss the bigger point. It is the archetypes definition that is needlessly difficult. The archetype definitions should make an effort to be clear and self documenting. Diseases should be defined so that DISEASE_DAMAGE_TYPE=ADJUSTED_BY_CASTER_LEVEL or whatever is the proper way to define the effects of the disease as compared to whether the value for damage is positive or negative. Then if the archetypes parser handles that by storing a negatives value in the damage field of the object to save room in the object structure then so be it. Then the issues of clarity are isolated to the code internals. Overloading in the archetype definitions creates problems because then it becomes much harder to unwind overloading because then one has to review every archetype to determine what was the intended purpose of this value in that field. sdw __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com From peterm at tonks.EECS.Berkeley.EDU Thu Jul 11 17:58:09 2002 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:04:19 2005 Subject: [CF List] problem with some diseases In-Reply-To: Your message of "Thu, 11 Jul 2002 14:59:02 PDT." <20020711215902.54492.qmail@web10403.mail.yahoo.com> Message-ID: <200207112258.g6BMwAT28297@tonks.EECS.Berkeley.EDU> So what you're saying is, in the archetypes file, allow things like "damage_adjusted_by_caster_level 1", and then have the archetype reading code, based on what type of thing it's reading, translate that into the appropriate in-code parameter change, such as making the damage negative? Well, you do gain clarity from the archetype writer's point of view, at the expense of enormously more complicated archetype file parsing and maintenance. The way the loader works right now just wouldn't support such functionality, it'd have to be rewritten and would have to do two passes through each object, one to figure out its type, and the second to interpret all the parameters specific to that type. I think someone else's suggestion (Andrew's I think) of a front-end like crossedit providing boxes like "LOCKCODE" where you type in a number, and then setting "value" or whatever in the archetypes makes sense and doesn't force a change to the existing code, though THAT has to be maintained too. PeterM > But you (and Mark in his response) both miss the bigger point. It is > the archetypes definition that is needlessly difficult. The archetype > definitions should make an effort to be clear and self documenting. Diseases > should be defined so that DISEASE_DAMAGE_TYPE=ADJUSTED_BY_CASTER_LEVEL or > whatever is the proper way to define the effects of the disease as compared > to whether the value for damage is positive or negative. Then if the > archetypes parser handles that by storing a negatives value in the damage > field of the object to save room in the object structure then so be it. > Then the issues of clarity are isolated to the code internals. > > Overloading in the archetype definitions creates problems because then it > becomes much harder to unwind overloading because then one has to review > every archetype to determine what was the intended purpose of this value > in that field. > > sdw > > > __________________________________________________ > Do You Yahoo!? > Sign up for SBC Yahoo! Dial - First Month Free > http://sbc.yahoo.com > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From mwedel at sonic.net Thu Jul 11 23:07:36 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:19 2005 Subject: [CF List] problem with some diseases References: <200207112258.g6BMwAT28297@tonks.EECS.Berkeley.EDU> Message-ID: <3D2E5608.1080402@sonic.net> Peter Mardahl wrote: > So what you're saying is, in the archetypes file, > allow things like > "damage_adjusted_by_caster_level 1", > and then have the archetype reading code, > based on what type of thing it's reading, > translate that into the appropriate in-code > parameter change, such as making the damage negative? > > Well, you do gain clarity from the archetype writer's point > of view, at the expense of enormously more complicated > archetype file parsing and maintenance. The way the loader > works right now just wouldn't support such functionality, > it'd have to be rewritten and would have to do two passes > through each object, one to figure out its type, and the > second to interpret all the parameters specific to that > type. Or ordering of values in the archetype field itself becomes important (eg, type must be specified before anything that depends on type.) I will note that the disease bug in question would probably still have occured even with such code. However, if the names are unique for all objects, this is pretty easy to do - now just the saver is more complex (ok, this is a disease, and hp is negative, so we save it as hd_ajuster_percent) or something like that. I believe Bob Tanner actually did some experimentation to have crossfire use XML for its object format. Making such a switch would be a big change. > I think someone else's suggestion (Andrew's I think) of > a front-end like crossedit providing boxes like "LOCKCODE" > where you type in a number, and then setting "value" or whatever > in the archetypes makes > sense and doesn't force a change to the existing code, > though THAT has to be maintained too. Yep. Certainly the documentation is wanting. But at least for many of these newer things, like diseases, there is clear documentation which describes the inner workings. The problem, and cause of most obscure bugs, are things like last_heal getting used to store permanent experience. Would be much better if that was simply called perm_exp or something. No one probably knows every variable meaning and how the value works with the object, so if your going through doing a big update, some of these are going to mess you up, whether they are called slaying or path_to_map in the arch file - if they are all called slaying in the object, that creates confusion. From quinet at gamers.org Fri Jul 12 02:27:25 2002 From: quinet at gamers.org (Raphaël Quinet) Date: Thu Jan 13 18:04:19 2005 Subject: [CF List] problem with some diseases In-Reply-To: <200207101439.g6AEdbE25265@tonks.EECS.Berkeley.EDU> References: <20020709223919.10548.qmail@web10402.mail.yahoo.com> <200207101439.g6AEdbE25265@tonks.EECS.Berkeley.EDU> Message-ID: <20020712092725.1b3ba9c0.quinet@gamers.org> On Wed, 10 Jul 2002 07:39:37 -0700, "Peter Mardahl" wrote: > And to do all this I had to use the available crossfire object > items as parameters, which means for some of the parameters I > was able to use sensible names like "Cha" for reducing charisma, > for others, I had to do things like what you object to. > > Anyway, this somewhat lame situation could be fixed by > doing a re-write of Crossfire in C++, a measure no one has > stepped forward to do.... This is a bit off-topic, but here are my 2 silver coins on this issue: I don't think that re-writing any part of Crossfire in C++ will really improve the code. I think that it would be better to re-structure some parts using plain C with some object-oriented concepts, based on what is done in glib and gtk+. This could be done step-by-step instead of having to re-write everything at once. I have seen several projects moving from C to C++ and in most cases (with the exception of high-level graphical interfaces) there was little or no gain in efficiency or maintainability of the code. This is due in part to the fact that some programmers (experienced or not) tend to "over-design" some classes and add too many sub-classes. As a result, it is not easier than before to have a good overview of how the code works and some of the problems that existed in the previous incarnation of the code are still there but simply hidden. For example, several singleton objects carrying a lot of data (sometimes inherited from parent classes) are similar to static global variables and cause the same problems, but they are simply less visible. Some of these problems are also present in the projects that attempt to use object-oriented concepts in plain C, but they seem to be less frequent or less severe and in the end they have less code bloat (I cannot explain why, but it just seems to be like that for the projects that I have observed). C++ has many advantages, but it also has many disadvantages. For a collaborative project like Crossfire, I am skeptical about the total gains that could be achieved by a re-write in C++. I would rather recommend some "object-oriented C" like in glib and gtk+. -Rapha?l From erhard.sanio at gmx.net Fri Jul 12 15:41:29 2002 From: erhard.sanio at gmx.net (erhard.sanio@gmx.net) Date: Thu Jan 13 18:04:19 2005 Subject: [CF List] Testing on tavern.santa-clara.ca.us Message-ID: <1858.1026506489@www50.gmx.net> Hello, I tried to play a bit on Mark Wedel's test server in order to check out the now equipment technique. I am playing a wraith character on crossfire.real-time.com. When issueing the 'body-command, I got the following message: (I leave out the explaining part, only the table values) .. in your range slot 0 1 on your head 0 1 in your skill slot 0 1 on your feet 0 -2 That means, that i have no slots to wield weapons, wear rings and so on. What the negative value for feet means, no idea. When I unwielded my sword (flametongue), I was unable to wield it again, and not only that particular one, but any sword. Same with unwearing rings, and shield. I was able to unwear and wear a helmet, though. I get the message: You don't have the body to use a Flametongue of Mostrai +7 * You don't have the body to use a dragon shield +6 * You don't have the body to use a ring of Ancient Magic * Noteworthily, I am of level 78, with 25 in physique and 22 in magic, stats on race maximum. I think I should be able to use those weapons and armour. Hope that contributes to the test. regards, es -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From mwedel at sonic.net Fri Jul 12 19:49:56 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:19 2005 Subject: [CF List] Testing on tavern.santa-clara.ca.us Message-ID: <200207130049.g6D0nuj16873@sonic.net> Thanks - that is exactly the type of info I am looking for. It turns out I added the body_info into the wraith player force, and not the wraith player itself - I'll have to fix that up and rebuildthe archs. From temitchell at sympatico.ca Sat Jul 13 11:14:57 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:04:19 2005 Subject: [CF List] =?iso-8859-1?Q?Re:_=5BCF_List=5D_Testing_on_tavern.santa-clara.ca.us=0E?= References: <200207130049.g6D0nuj16873@sonic.net> Message-ID: <000401c22a88$6e555480$0a02a8c0@kameria> I made a dwarf character with no class (haha) and didn't have the body to use a sword or a bow. ----- Original Message ----- From: "Mark Wedel" To: Sent: Friday, July 12, 2002 8:49 PM Subject: Re: [CF List] Testing on tavern.santa-clara.ca.us > Thanks - that is exactly the type of info I am looking for. It > turns out I added the body_info into the wraith player force, > and not the wraith player itself - I'll have to fix that up > and rebuildthe archs. > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From mwedel at sonic.net Sat Jul 13 16:25:41 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:19 2005 Subject: [CF List] Re: [CF List] Testing on tavern.santa-clara.ca.us References: <200207130049.g6D0nuj16873@sonic.net> <000401c22a88$6e555480$0a02a8c0@kameria> Message-ID: <3D309AD5.4020507@sonic.net> Todd Mitchell wrote: > I made a dwarf character with no class (haha) and didn't have the body to > use a sword or a bow. I was unable to reproduce that. Now the dwarf player I created with no class lacked the necessary skill to use a weapon, but that is probably no different from the old code. From temitchell at sympatico.ca Sat Jul 13 18:59:13 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:04:19 2005 Subject: [CF List] =?iso-8859-1?Q?Re:_=5BCF_List=5D_Re:_=5BCF_List=5D_Testing_on_tavern.sant?= =?iso-8859-1?Q?a-clara.ca.us=0E?= References: <200207130049.g6D0nuj16873@sonic.net> <000401c22a88$6e555480$0a02a8c0@kameria> <3D309AD5.4020507@sonic.net> Message-ID: <000401c22ac9$4a091ee0$0a02a8c0@kameria> I went back and tried again. dwarfes worked this time (don't have the melee or missile weapon skill),wraiths elves and half orcs gave the 'you don't have the body to use this weapon' message. Also no the races with no body trying to fight or break down a door gets 'you don't have the body to use a punching'. ----- Original Message ----- From: "Mark Wedel" To: Sent: Saturday, July 13, 2002 5:25 PM Subject: Re: [CF List] Re: [CF List] Testing on tavern.santa-clara.ca.us > Todd Mitchell wrote: > > I made a dwarf character with no class (haha) and didn't have the body to > > use a sword or a bow. > > I was unable to reproduce that. Now the dwarf player I created with no class > lacked the necessary skill to use a weapon, but that is probably no different > from the old code. > > > > > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From mwedel at sonic.net Sat Jul 13 23:22:05 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:19 2005 Subject: [CF List] Re: [CF List] Re: [CF List] Testing on tavern.santa-clara.ca.us References: <200207130049.g6D0nuj16873@sonic.net> <000401c22a88$6e555480$0a02a8c0@kameria> <3D309AD5.4020507@sonic.net> <000401c22ac9$4a091ee0$0a02a8c0@kameria> Message-ID: <3D30FC6D.8010104@sonic.net> Todd Mitchell wrote: > I went back and tried again. > dwarfes worked this time (don't have the melee or missile weapon > skill),wraiths elves and half orcs gave the 'you don't have the body to use > this weapon' message. > Also no the races with no body trying to fight or break down a door gets > 'you don't have the body to use a punching'. those portions that were bugs should now be fixed (dwarves, elfs, and wraiths). A skill uses a slot on the body. There is a slot just for skills. This is sort of odd (but probably no worse than a slot for rod/wand/horn). It makes the apply/unapply code a lot cleaner - try to use something with a new skill, and your old skill object is unequipped because it used the same slot. From erhard.sanio at gmx.net Mon Jul 15 14:55:41 2002 From: erhard.sanio at gmx.net (erhard.sanio@gmx.net) Date: Thu Jan 13 18:04:19 2005 Subject: [CF List] Testing again new Equip Scheme References: <200207020608.g62687X18148@sprite.real-time.com> Message-ID: <7764.1026762941@www6.gmx.net> Hello, I tested again on tavern.santa-clara server. The errors I encountered last time have been corrected, wearing, unwearing, wielding and unwielding appeared all to work fine. Even when doing intensive testing including fighting, stealing, singing, wizard and priest spells, usage of scrolls, rods, wands, and horns I found no serious errors. Only the following things puzzled me: When I tried to change rings by simply clicking on the inventory icon I recieved the following message: "You need to unapply some item(s): ring of Ancient Magic * (worn) ring of High Magic * (worn)". Similarly when trying to wield a bow or crossbow: "You need to unapply some item(s): Flametongue of Mostrai +7 * (wielded) dragon shield +6 * (worn)". Is that intended that automatical changing of rings and twohanded weapons does not work? I would consider that unfavourable as lightning fast reaction is a must, sometimes. Changing clothes and armour still works as it ever did. The 'body command now shows sensible output: "The third column is how many slots in that location are available. in your range slot 1 0 on your arm 2 0 on your body 1 0 on your head 1 1 around your neck 1 0 in your skill slot 1 0 on your finger 2 0 around your shoulders 1 0 on your feet 2 0 on your hands 2 0 around your wrists 2 0 around your waist 1 0" Only, there seems to be a minor bug. When issueing that command I wore a crown of Sorig +1. The 'body command shows an empty slot for that type of armour. That way, I was able to wear a helmet in addition which is somewhat funny. I checked with my original character at metalforge and found that the crown is unworn correctly there when wearing a helmet. Ok, that's it for today. regards, es -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From kbulgrien at worldnet.att.net Mon Jul 15 17:44:45 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:04:19 2005 Subject: [CF List] crossfire-client-sounds-1.3.1-realtime.2.noarch.rpm problems In-Reply-To: <7764.1026762941@www6.gmx.net> References: <200207020608.g62687X18148@sprite.real-time.com> <7764.1026762941@www6.gmx.net> Message-ID: <02071517444500.01553@krayp120.worldnet.att.net> [krb@krayp120 krb]$ rpm -qa | grep crossfire crossfire-client-sounds-1.3.1-realtime.2 crossfire-client-gtk-1.3.1-realtime.2 crossfire-client-1.3.1-realtime.2 1) Sound files are not in the same place as one or more applications expect them to be (maybe its gcfclient instead of cfsndserv)... [krb@krayp120 crossfire]$ gcfclient Character Width : 11 Character Height: 11 Found bogus line in window position file: win_game: 4 20 1268 964 Unable to open /home/krb/.crossfire/sounds - will use built in defaults Playing on server type Crossfire Server Unknown input state: 2 /usr/share/games/crossfire/crossfire-client/sounds/swish.raw: No such file or directory [krb@krayp120 crossfire]$ rpm -ql crossfire-client-sounds /usr/bin/cfsndserv /usr/share/sounds/crossfire /usr/share/sounds/crossfire/Creaky-1.raw /usr/share/sounds/crossfire/Evil_Laugh.raw /usr/share/sounds/crossfire/Explosion.raw /usr/share/sounds/crossfire/FloorTom.raw /usr/share/sounds/crossfire/Gun-5.raw /usr/share/sounds/crossfire/MetalCrash.raw /usr/share/sounds/crossfire/Missed.raw /usr/share/sounds/crossfire/Missle1.raw /usr/share/sounds/crossfire/Puke.raw /usr/share/sounds/crossfire/Tear.raw /usr/share/sounds/crossfire/Teeswing.raw /usr/share/sounds/crossfire/TowerClock.raw /usr/share/sounds/crossfire/Whoosh.raw /usr/share/sounds/crossfire/blip.raw /usr/share/sounds/crossfire/boink2.raw /usr/share/sounds/crossfire/bugle_charge.raw /usr/share/sounds/crossfire/chord.raw /usr/share/sounds/crossfire/click1.raw /usr/share/sounds/crossfire/click2.raw /usr/share/sounds/crossfire/drip.raw /usr/share/sounds/crossfire/first_try.raw /usr/share/sounds/crossfire/gong.raw /usr/share/sounds/crossfire/lightning1.raw /usr/share/sounds/crossfire/magic.raw /usr/share/sounds/crossfire/ouch1.raw /usr/share/sounds/crossfire/phit2.raw /usr/share/sounds/crossfire/sci_fi_gun.raw /usr/share/sounds/crossfire/squish.raw /usr/share/sounds/crossfire/swish.raw 2) I am not sure how this is called "noarch". It has cfsndserv which reports as: ELF 32-bit LSB executable, Intel 80386, version 1 Name: crossfire-client-sounds Relocations: (not relocateable) Version: 1.3.1 Vendor: Real Time Enterprises, Inc. Release: realtime.2 Build Date: Tue 09 Jul 2002 07:56:18 PM CDT Install date: Sat 13 Jul 2002 12:47:29 AM CDT Build Host: samurai.castle.real-time.com Group: X11/Games Source RPM: crossfire-client-1.3.1-realtime.2.src.rpm Size: 441467 License: GPL Packager: Real Time Enterprises, Inc. URL: http://crossfire.real-time.com Summary: Sound effects for the crossfire game Description: Sound effects for people who want sounds with their game. [krb@krayp120 crossfire]$ file /usr/bin/cfsndserv /usr/bin/cfsndserv: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped From kbulgrien at worldnet.att.net Mon Jul 15 18:03:25 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:04:19 2005 Subject: [CF List] A way to add crossfire to your X menus In-Reply-To: <7764.1026762941@www6.gmx.net> References: <200207020608.g62687X18148@sprite.real-time.com> <7764.1026762941@www6.gmx.net> Message-ID: <02071518032501.01553@krayp120.worldnet.att.net> It appears that the tclug-menu rpm is meant to add a menu option for the clients... This doesn't work on my installation of Mandrake 8.0 - I do not have gnome installed, only KDE. (As a result, I suppose I wonder why it is a requirement on the crossfire-client rpms.) To add a crossfire client to my user's menus, I had to create the following files: [krb@krayp120 krb]$ cat /usr/lib/menu/gcfclient ?package(crossfire-client-gtk):\ needs="x11"\ section="Amusement/Adventure"\ title="Crossfire GTK Client"\ longtitle="The GTK Client for Crossfire"\ command="/usr/bin/gcfclient"\ icon="crossfire-client.png" krb@krayp120 krb]$ cat /usr/lib/menu/cfclient ?package(crossfire-client):\ needs="x11"\ section="Amusement/Adventure"\ title="Crossfire Client"\ longtitle="The Client for Crossfire"\ command="/usr/bin/cfclient"\ icon="crossfire-client.png" After this, as root, run update-menus Now all users will see the clients in their menu structure. Uhm... The main technicality I see here is that the crossfire-client.png file is supplied by the crossfire-client-gtk rpm. If you only installed the crossfire-client rpm, the graphic would not be available, but this does not prevent the menu item from being created. It would also be possible to use the file name that tclug-menu rpm... package_games_adventure.png From mwedel at sonic.net Mon Jul 15 23:07:57 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:19 2005 Subject: [CF List] Testing again new Equip Scheme References: <200207020608.g62687X18148@sprite.real-time.com> <7764.1026762941@www6.gmx.net> Message-ID: <3D339C1D.8050503@sonic.net> erhard.sanio@gmx.net wrote: > Hello, > > I tested again on tavern.santa-clara server. The errors I encountered > last time have been corrected, wearing, unwearing, wielding and > unwielding appeared all to work fine. Even when doing intensive testing > including fighting, stealing, singing, wizard and priest spells, usage > of scrolls, rods, wands, and horns I found no serious errors. > > Only the following things puzzled me: > > When I tried to change rings by simply clicking on the inventory icon > I recieved the following message: > > "You need to unapply some item(s): > ring of Ancient Magic * (worn) > ring of High Magic * (worn)". > > Similarly when trying to wield a bow or crossbow: > > "You need to unapply some item(s): > Flametongue of Mostrai +7 * (wielded) > dragon shield +6 * (worn)". > > Is that intended that automatical changing of rings and twohanded > weapons does not work? I would consider that unfavourable as lightning > fast reaction is a must, sometimes. Changing clothes and armour still > works as it ever did. Try doing 'applymode always'. Then try switching. The first case is intentional on the case of multiple choice of items. I need to look into the second case - while there are multiple items, since both need to be unequipped to equip a bow, there isn't really a choice, so it should still do it even with the default unapply mode (nochoice) > > > Only, there seems to be a minor bug. When issueing that command I > wore a crown of Sorig +1. The 'body command shows an empty slot > for that type of armour. That way, I was able to wear a helmet > in addition which is somewhat funny. I checked with my original > character at metalforge and found that the crown is unworn > correctly there when wearing a helmet. Yeah - I'll fix the arch. The crown arch wasn't with the rest of the helmets, so didn't get the right change made to it. From kbulgrien at worldnet.att.net Thu Jul 18 21:21:51 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:04:19 2005 Subject: [CF List] Sounds for cfclient and gcfclient are very quiet... In-Reply-To: <02071517444500.01553@krayp120.worldnet.att.net> References: <200207020608.g62687X18148@sprite.real-time.com> <7764.1026762941@www6.gmx.net> <02071517444500.01553@krayp120.worldnet.att.net> Message-ID: <02071821215100.01879@krayp120.worldnet.att.net> Is there a reason why the sounds for the linux clients are so muted? If I turn my sound-volumes up where they are hearable, and I forget to change mixer settings when not playing, then I get blasted out of my chair when any other sounds are made by the system... Is there embedded volume information in the .raw sound files and can I somehow adjust the files to a play louder? From kbulgrien at worldnet.att.net Thu Jul 18 21:29:45 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:04:20 2005 Subject: [CF List] CFJavaEditor availability In-Reply-To: <02071517444500.01553@krayp120.worldnet.att.net> References: <200207020608.g62687X18148@sprite.real-time.com> <7764.1026762941@www6.gmx.net> <02071517444500.01553@krayp120.worldnet.att.net> Message-ID: <02071821294501.01879@krayp120.worldnet.att.net> The links on crossfire.real-time.com for the CFJavaEditor are dead and have been dead for a few weeks at least. Does anyone know what the preferred way to get the CFJavaEditor is? I know that site issued a message about no longer hosting a crossfire server. So far, the only thing I've found is to checkout the CFJavaEditor from CVS, but, I find it odd that it is in CVS on sourceforge, but not on the downloads section. I found an archived message about a development fork some time back... What's the scoop? From temitchell at sympatico.ca Thu Jul 18 23:07:53 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:04:20 2005 Subject: [CF List] ISO crossfire dopelganger... Message-ID: <000501c22ed9$db41d1e0$0a02a8c0@kameria> I was visiting the Malfador site and I came across these screen shots of their new adventure game. I was quite surprised to see these actually and was wondering, does Michael T know about this? Malfador Machinations made a most excellent game called Space Empires 3 which ranks in my all time favorites. They have moved on to SE4 and in my opinion somewhat wrecked the feel of the game (but many would probably disagree). I always wondered if they would release the code for SE3 as an opensource project... let it take off in a different direction... http://www.malfador.com/do.html From kbulgrien at worldnet.att.net Thu Jul 18 23:00:53 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:04:20 2005 Subject: [CF List] Random house in Scorn... Odd behavior... Message-ID: <02071823005301.02560@krayp120.worldnet.att.net> Entering the building jumps me right back into town... Inside, the doorway was a teleporter... The teleporter apparantly tossed me back outside. So, one cannot enter the building until the maps regenerate. From kbulgrien at worldnet.att.net Thu Jul 18 23:13:53 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:04:20 2005 Subject: [CF List] Why are beds to reality sometimes cursed/damned? Message-ID: <02071823135302.02560@krayp120.worldnet.att.net> This happens to my permanent apartment... Is that normal? Is it undoable? From mwedel at sonic.net Thu Jul 18 23:29:27 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:20 2005 Subject: [CF List] Sounds for cfclient and gcfclient are very quiet... References: <200207020608.g62687X18148@sprite.real-time.com> <7764.1026762941@www6.gmx.net> <02071517444500.01553@krayp120.worldnet.att.net> <02071821215100.01879@krayp120.worldnet.att.net> Message-ID: <3D3795A7.6040701@sonic.net> Kevin R. Bulgrien wrote: > Is there a reason why the sounds for the linux clients are so muted? > > If I turn my sound-volumes up where they are hearable, and I forget > to change mixer settings when not playing, then I get blasted out of > my chair when any other sounds are made by the system... > > Is there embedded volume information in the .raw sound files and > can I somehow adjust the files to a play louder? The reason they are quiet is probably the history of the files - they originally date back to when they where .au files (sun audio format). The volume they had was about right to directly play to the internal speaker. Sound files obviously include some volume type information - you sort of need to so that a shout is louder than a whisper. My guess is that the raw files probably do not include sounds at maximum volume (eg, if the range for each bit of sound is 0-255, then maybe the highest in any of the raw files is like 100). I'm sure there are probably tools to read the raw files and scale the volume up. And this should probably get done, as I've noticed the same thing about the sound files being quiet. OTOH, I don't play many other sounds on my system so tend not to notice it much. From mwedel at sonic.net Thu Jul 18 23:30:46 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:20 2005 Subject: [CF List] Random house in Scorn... Odd behavior... References: <02071823005301.02560@krayp120.worldnet.att.net> Message-ID: <3D3795F6.1090005@sonic.net> Kevin R. Bulgrien wrote: > Entering the building jumps me right back into town... > > Inside, the doorway was a teleporter... The teleporter > apparantly tossed me back outside. So, one cannot > enter the building until the maps regenerate. Well, the random house is truly random - who knows what will show up. This is just part of the game. From mwedel at sonic.net Thu Jul 18 23:32:43 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:20 2005 Subject: [CF List] Why are beds to reality sometimes cursed/damned? References: <02071823135302.02560@krayp120.worldnet.att.net> Message-ID: <3D37966B.6080406@sonic.net> Kevin R. Bulgrien wrote: > This happens to my permanent apartment... Is that normal? > Is it undoable? Not undoable, but other than looking annoying, it is harmless. By default, all savebeds are cursed/damned. Just that until you cast a detect curse nearby it, you don't notice it. If I recall correctly, the cursed/damned information is used as a determination if using that particularly bed should update your home savebed location. (which you pop to when you die or get disconnected and server can't put you back on the map you were before). From mwedel at sonic.net Thu Jul 18 23:37:11 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:20 2005 Subject: [CF List] CFJavaEditor availability References: <200207020608.g62687X18148@sprite.real-time.com> <7764.1026762941@www6.gmx.net> <02071517444500.01553@krayp120.worldnet.att.net> <02071821294501.01879@krayp120.worldnet.att.net> Message-ID: <3D379777.3000007@sonic.net> Kevin R. Bulgrien wrote: > The links on crossfire.real-time.com for the CFJavaEditor are dead and have > been dead for a few weeks at least. > > Does anyone know what the preferred way to get the CFJavaEditor is? > > I know that site issued a message about no longer hosting a crossfire server. > > So far, the only thing I've found is to checkout the CFJavaEditor from CVS, > but, I find it odd that it is in CVS on sourceforge, but not on the downloads > section. I found an archived message about a development fork some > time back... > > What's the scoop? The above is probably a pretty accurate summary. An actual release for the editor that is on the normal download locations should probably be made. The java editor is definately the replacement for crossedit. From andi.vogl at gmx.net Fri Jul 19 04:40:56 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:04:20 2005 Subject: [CF List] Why are beds to reality sometimes cursed/damned? References: <3D37966B.6080406@sonic.net> Message-ID: <25654.1027071656@www26.gmx.net> > Kevin R. Bulgrien wrote: > > This happens to my permanent apartment... Is that normal? > > Is it undoable? > > [...] > If I recall correctly, the cursed/damned information is used as a > determination if using that particularly bed should update your home > savebed location. No. First of all, savebeds are damned and have no_magic flag set. This has nothing to do with the savebed functionality itself. These two flags are set to prevent casting of magic/prayers on savebeds. The reason for this is that when players die, they often remain with their fingers sticking on the (spell-)fire button for a while. What used to happen then is that people roasted their precious appartment with blast and flame after re-awakening from death. To prevent this, savebeds have the damned and no_magic flags set. Andreas -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From andi.vogl at gmx.net Fri Jul 19 05:01:55 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:04:20 2005 Subject: [CF List] CFJavaEditor availability References: <3D379777.3000007@sonic.net> Message-ID: <11610.1027072915@www26.gmx.net> > Kevin R. Bulgrien wrote: > > The links on crossfire.real-time.com for the CFJavaEditor are dead and > > have been dead for a few weeks at least. > > > > Does anyone know what the preferred way to get the CFJavaEditor is? > > > > What's the scoop? Uhm, yeah. I'm sorry - that is for the most part my fault. I used to put the JavaEditor on my account at mids server. Then mids suddenly had to close his server and I have no other place to put it now. I'm just a poor student without a personal webserver. Moreover, I'm very busy ATM and didn't have enough time to deal with this problem. I'm trying to get webspace at my university and put it there. But that's gonna take me a while to set things up. Besides, my university account won't be permanent either (Gotta finish my studies someday and leave university...). > An actual release for the editor that is on the normal download > locations should probably be made. The java editor is definately > the replacement for crossedit. That sounds good. The question is: Who rolls out the releases and when? Maybe the easiest thing would be that whenever a CF release is made, the JavaEditor gets packed and updated on the dowload sites. That means of course that the JavaEditor "releases" happen more or less at random since the Editor- and CF-Code are indipendent. Still, it provides a relyable download for the JavaEditor without too much extra-work. Andreas -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From michael.toennies at nord-com.net Fri Jul 19 09:15:14 2002 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:04:20 2005 Subject: [CF List] ISO crossfire dopelganger... In-Reply-To: <000501c22ed9$db41d1e0$0a02a8c0@kameria> Message-ID: This game use the gfx & original screen of David Gervais. Cf & iso cf use booth some of the same public gfx. The goblin and the chaos priest of the CF arches use the same gfx set. In fact, the blue wizard on there screen shots is the same as the CF chaos priest picture just in a different color. I used a modified base screen from David for the iso cf stuff - he has told me not to use the original screen design because for his own game. Iam really wonder this company is/has asked David about using his stuff for a commercial game. As i understand was his base screen not public domain. So, i think David has something to do with this company. Perhaps i ask them later. Well, because Daimonin (aka iso cf) will use a different tile size (the iso angband ones, not davids), the gfx will look different. In fact, Daimonins gfx will beat is (my opinion). Look at this. http://mids.student.utwente.nl/~michtoen/snaps/snap_new1.png http://mids.student.utwente.nl/~michtoen/snaps/snap_new2.png http://mids.student.utwente.nl/~michtoen/snaps/snap_new3.png http://mids.student.utwente.nl/~michtoen/snaps/snap_new4.png Well, when we will release it, i perhaps get a better base screen - like better buttons & menues. This is just most from me and AV - and we both have not the right talent for it. I really, really wonder there is a way to make money as shareware with this kind of game. Also wyvern is still free. Michael > > I was visiting the Malfador site and I came across these screen shots of > their new adventure game. I was quite surprised to see these actually and > was wondering, does Michael T know about this? > Malfador Machinations made a most excellent game called Space Empires 3 > which ranks in my all time favorites. They have moved on to SE4 and in my > opinion somewhat wrecked the feel of the game (but many would probably > disagree). I always wondered if they would release the code for > SE3 as an > opensource project... let it take off in a different direction... > > http://www.malfador.com/do.html > > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From nebrich at u.washington.edu Fri Jul 19 12:42:47 2002 From: nebrich at u.washington.edu (Ben Diedrich) Date: Thu Jan 13 18:04:20 2005 Subject: [CF List] Dragon unable to use bow on metalforge Message-ID: Hi, I created a dragon character recently on Metalforge. Until today, I was able to use bows. Also, I noticed that the 'body' command that was being experimented with on 'tavern'. When I try to equip a bow, the response is "You don't have the body to use a bow *". Any ideas? Thanks, Ben From mwedel at sonic.net Fri Jul 19 23:44:56 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:20 2005 Subject: [CF List] Dragon unable to use bow on metalforge References: Message-ID: <3D38EAC8.40708@sonic.net> Ben Diedrich wrote: > Hi, > > I created a dragon character recently on Metalforge. Until today, I was able > to use bows. Also, I noticed that the 'body' command that was being > experimented with on 'tavern'. When I try to equip a bow, the response is > "You don't have the body to use a bow *". Any ideas? Part of the change with new body types. It never made a lot of sense that dragons were unable to use shields or weapons, but could use bows (talk about something that requires fine fingers). On the bright side, the dragon now gets some other benefits - it can use cloaks, girdles, and bracers now. From kbulgrien at worldnet.att.net Sat Jul 20 06:48:27 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:04:20 2005 Subject: [CF List] Brace thwarts PEACEFUL mode in Server 1.3.0 Message-ID: <02072006482700.02826@krayp120.worldnet.att.net> If all players are "peaceful", and one player is braced, he attacks other players that walk in front of him. Unbraced he simply tries to push the other player. Crossfire Server version 1.3.0 From erhard.sanio at gmx.net Wed Jul 24 02:51:40 2002 From: erhard.sanio at gmx.net (Erhard Sanio) Date: Thu Jan 13 18:04:20 2005 Subject: [CF List] Problem with improved invisibility in client 1.3.0 References: <200207152305.g6FN5YX24672@sprite.real-time.com> Message-ID: <28389.1027497100@www19.gmx.net> Hello, This bug was already described on the crossfire board at www.viksten.com . Might somebody comment (or is it a known bug)? When invoking improved invisibility under client 1.3.0, the character completely vanishes. That is very inconvenient as one has to guess where the character exactly is. In all earlier client versions, improved invisibility shows a "blinking" character to the player proper so that one may see where it is. This kind of behaviour makes more sense as an invisible person is still aware of location, feeling and all that. IMHO, it would be a good idea to restore the behaviour of previous clients. regards, es -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From mwedel at sonic.net Thu Jul 25 02:02:17 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:20 2005 Subject: [CF List] Problem with improved invisibility in client 1.3.0 References: <200207152305.g6FN5YX24672@sprite.real-time.com> <28389.1027497100@www19.gmx.net> Message-ID: <3D3FA279.9080800@sonic.net> Erhard Sanio wrote: > Hello, > > This bug was already described on the crossfire board at www.viksten.com . > Might somebody comment (or is it a known bug)? > > When invoking improved invisibility under client 1.3.0, the character > completely vanishes. That is very inconvenient as one has to guess where the > character exactly is. > > In all earlier client versions, improved invisibility shows a "blinking" > character to the player proper so that one may see where it is. Fixed in CVS. This is actually a server issue. From mwedel at sonic.net Thu Jul 25 02:02:32 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:20 2005 Subject: [CF List] Brace thwarts PEACEFUL mode in Server 1.3.0 References: <02072006482700.02826@krayp120.worldnet.att.net> Message-ID: <3D3FA288.7080307@sonic.net> Kevin R. Bulgrien wrote: > If all players are "peaceful", and one player is braced, he > attacks other players that walk in front of him. Unbraced he > simply tries to push the other player. Fixed in CVS. From lembark at wrkhors.com Thu Jul 25 14:17:30 2002 From: lembark at wrkhors.com (lembark@wrkhors.com) Date: Thu Jan 13 18:04:20 2005 Subject: [CF List] Problem with improved invisibility in client 1.3.0 In-Reply-To: <3D3FA279.9080800@sonic.net> References: <200207152305.g6FN5YX24672@sprite.real-time.com> <28389.1027497100@www19.gmx.net> <3D3FA279.9080800@sonic.net> Message-ID: <2220000.1027624650@duke> >> This bug was already described on the crossfire board at www.viksten.com . >> Might somebody comment (or is it a known bug)? >> >> When invoking improved invisibility under client 1.3.0, the character >> completely vanishes. That is very inconvenient as one has to guess where the >> character exactly is. >> >> In all earlier client versions, improved invisibility shows a "blinking" >> character to the player proper so that one may see where it is. > > Fixed in CVS. This is actually a server issue. Thinking back to a long-ago discussion on Improved Invisibility, and looking at the effects of the Ring of Ruling, might the error behavior be more appropriate? I.I. is a pretty powerfull spell, which might be reasonble to have some penalty attached to. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582 From kbulgrien at worldnet.att.net Thu Jul 25 18:51:47 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:04:20 2005 Subject: [CF List] Problem with improved invisibility in client 1.3.0 In-Reply-To: <3D3FA279.9080800@sonic.net> References: <200207152305.g6FN5YX24672@sprite.real-time.com> <28389.1027497100@www19.gmx.net> Message-ID: <5.1.0.14.0.20020725182731.022fb690@postoffice.worldnet.att.net> At 02:02 AM 7/25/02, you wrote: >Erhard Sanio wrote: >>Hello, >>This bug was already described on the crossfire board at www.viksten.com . >>Might somebody comment (or is it a known bug)? >>When invoking improved invisibility under client 1.3.0, the character >>completely vanishes. That is very inconvenient as one has to guess where the >>character exactly is. >>In all earlier client versions, improved invisibility shows a "blinking" >>character to the player proper so that one may see where it is. > > Fixed in CVS. This is actually a server issue. This same problem plagues the "hiding" skill... Perhaps the same code affects both invisibility and hiding? If so, a hiding character blinks in the DX client, but does not blink in the 1.3.1 GTK client... and cannot be seen until he does something to reveal himself. Is it really a server problem? The server version is 1.3.0. From mwedel at sonic.net Thu Jul 25 22:56:52 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:20 2005 Subject: [CF List] Problem with improved invisibility in client 1.3.0 References: <200207152305.g6FN5YX24672@sprite.real-time.com> <28389.1027497100@www19.gmx.net> <5.1.0.14.0.20020725182731.022fb690@postoffice.worldnet.att.net> Message-ID: <3D40C884.1040407@sonic.net> Kevin R. Bulgrien wrote: > At 02:02 AM 7/25/02, you wrote: > > >>Erhard Sanio wrote: >> >>>Hello, >>>This bug was already described on the crossfire board at www.viksten.com . >>>Might somebody comment (or is it a known bug)? >>>When invoking improved invisibility under client 1.3.0, the character >>>completely vanishes. That is very inconvenient as one has to guess where the >>>character exactly is. >>>In all earlier client versions, improved invisibility shows a "blinking" >>>character to the player proper so that one may see where it is. >> >>Fixed in CVS. This is actually a server issue. > > > This same problem plagues the "hiding" skill... > > Perhaps the same code affects both invisibility and hiding? Yep, the change should fix that also. > > If so, a hiding character blinks in the DX client, but does not blink > in the 1.3.1 GTK client... and cannot be seen until he does something > to reveal himself. > > Is it really a server problem? Yes. The DX client uses the original protocol for map drawing. That protocol had a limited mapsize of 13x13, but didn't have the bug with respect to invisible players. Very old versions of the unix client would use that, and would also draw it correctly. Newer versions use the newer map drawing protocol, and that code on the server was never sending the player face when invisible. From mwedel at sonic.net Thu Jul 25 23:50:37 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:21 2005 Subject: [CF List] Problem with improved invisibility in client 1.3.0 References: <200207152305.g6FN5YX24672@sprite.real-time.com> <28389.1027497100@www19.gmx.net> <3D3FA279.9080800@sonic.net> <2220000.1027624650@duke> Message-ID: <3D40D51D.3070306@sonic.net> lembark@wrkhors.com wrote: > >>>This bug was already described on the crossfire board at www.viksten.com . >>>Might somebody comment (or is it a known bug)? >>> >>>When invoking improved invisibility under client 1.3.0, the character >>>completely vanishes. That is very inconvenient as one has to guess where the >>>character exactly is. >>> >>>In all earlier client versions, improved invisibility shows a "blinking" >>>character to the player proper so that one may see where it is. >> >> Fixed in CVS. This is actually a server issue. > > > Thinking back to a long-ago discussion on Improved Invisibility, > and looking at the effects of the Ring of Ruling, might the error > behavior be more appropriate? I.I. is a pretty powerfull spell, > which might be reasonble to have some penalty attached to. Well, the code is actually for anything that makes the player invisible (eg, skill, normal spell, etc). The other problem is that the player position within the map is fixed. So it would be trivial for the client to somehow mark what the middle square is. The player may not see his icon there, but know that is where you are is probably enough. From huet.o at free.fr Fri Jul 26 14:50:28 2002 From: huet.o at free.fr (huet.o@free.fr) Date: Thu Jan 13 18:04:21 2005 Subject: [CF List] strange comportments with large creature summoning Message-ID: <1027713028.3d41a80456ecb@imp.free.fr> Hello everybody, I try to play with a player worshiping Ruggili, and I when I tried "call holly servant", or sometimes "summon cult monster", a wyvern appear. With that "large" creature, I had a lot of display refresh problems (gtk client) : it's quite like the wyvern don't "visualy" move, but it apear like it really move on the server. (but changes on the pixmap seems to work well : wyvern sometimes look on the right, and sometimes on the left). And another problem (but it's perhaps a normal behavior) : with "one square summoned creature", it's possible to go "throught" : you can walk even if a pet is on your way : it automaticaly go behind you. With Wyvern, it don't work : it can sometimes block the way. My versions : gtk client : 1.3.0 server : 1.3.0 with only one cvs update : the patch of the diseases I post few week ago. Some ideas ??? Olivier. From kbulgrien at worldnet.att.net Sat Jul 27 11:25:30 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:04:21 2005 Subject: [CF List] Concerning chests... Message-ID: <02072711253000.09317@krayp120.worldnet.att.net> Crossfire 1.3.0 CVS as of today: This issue has been present for a while... You find a chest, find traps on it, disarm traps, then step on the chest. Apply the chest to open it, and various items are found. Without moving, try to "get" items and this message is given: You cannot pickup a woodfloor Step off the square, and step back. Now you can get the items... From kbulgrien at worldnet.att.net Sat Jul 27 13:58:13 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:04:21 2005 Subject: [CF List] SIGSEGV - Latest CVS crossfire server dies. Message-ID: <02072713581300.09451@krayp120.worldnet.att.net> Why does the server die when a (the only) player logs out? This is the latest CVS as of today... Checksums: 70bf482b 70bf482b LOGIN: Player named SirK from ip 127.0.0.1 Trying to load map /home/games/share/crossfire/maps/city/city. load_original_map: /city/city (0) Can't open /home/games/var/crossfire/maps/city/city Can't open overlay /home/games/var/crossfire/maps/city/city make_path_tofile /home/games/var/crossfire/players/SirK/SirK.pl... SIGSEGV received. Emergency saves disabled, no save attempted Cleaning up... Saving map /HallOfSelection make_path_tofile /home/games/var/crossfire/players/SirK/_city_apartment_apartments... Saving map /home/games/var/crossfire/players/SirK/_city_apartment_apartments Saving map /city/city From mwedel at sonic.net Sun Jul 28 23:17:29 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:21 2005 Subject: [CF List] SIGSEGV - Latest CVS crossfire server dies. References: <02072713581300.09451@krayp120.worldnet.att.net> Message-ID: <3D44C1D9.7090501@sonic.net> Kevin R. Bulgrien wrote: > Why does the server die when a (the only) player logs out? > > This is the latest CVS as of today... > > Checksums: 70bf482b 70bf482b > LOGIN: Player named SirK from ip 127.0.0.1 > Trying to load map /home/games/share/crossfire/maps/city/city. > load_original_map: /city/city (0) > Can't open /home/games/var/crossfire/maps/city/city > Can't open overlay /home/games/var/crossfire/maps/city/city > make_path_tofile /home/games/var/crossfire/players/SirK/SirK.pl... > > SIGSEGV received. > Emergency saves disabled, no save attempted > Cleaning up... > Saving map /HallOfSelection > make_path_tofile > /home/games/var/crossfire/players/SirK/_city_apartment_apartments... > Saving map /home/games/var/crossfire/players/SirK/_city_apartment_apartments > Saving map /city/city Doesn't happen on my system, and doesn't happen on metalforge. No doubt you are experiencing some problem, but the lack of reproduciblity on other systems makes it difficult to debug. A stack trace on where it is crashing might help determine the cause here. From mwedel at sonic.net Sun Jul 28 23:32:27 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:21 2005 Subject: [CF List] strange comportments with large creature summoning References: <1027713028.3d41a80456ecb@imp.free.fr> Message-ID: <3D44C55B.4070000@sonic.net> huet.o@free.fr wrote: > Hello everybody, > > > I try to play with a player worshiping Ruggili, and I when I tried "call holly > servant", or sometimes "summon cult monster", a wyvern appear. > > > With that "large" creature, I had a lot of display refresh problems (gtk client) > : it's quite like the wyvern don't "visualy" move, but it apear like it really > move on the server. (but changes on the pixmap seems to work well : wyvern > sometimes look on the right, and sometimes on the left). > > > And another problem (but it's perhaps a normal behavior) : with "one square > summoned creature", it's possible to go "throught" : you can walk even if a pet > is on your way : it automaticaly go behind you. With Wyvern, it don't work : it > can sometimes block the way. > > > My versions : > gtk client : 1.3.0 > server : 1.3.0 with only one cvs update : the patch of the diseases I post few > week ago. Haven't looked into it, but my guess is that the pet monster code isn't multi space monster capabable. So when you try to move into the tail, it sees you can't do so, but doesn't look at the head of the monster to see that it is friendly. Similarly, I bet some of the pet move code is only moving the head piece, which leaves the tail behind or in odd states. Easiest fix would just to change ruggili's summoning list to not include wyvern - I know that in the past, avatars and others have been shrunken to one space because they are just much more useful (in this case, for example, a wide space wide corrider that runs north/south results in the wyvern being useless, since it can't fit in it). From mwedel at sonic.net Sun Jul 28 23:39:54 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:21 2005 Subject: [CF List] Concerning chests... References: <02072711253000.09317@krayp120.worldnet.att.net> Message-ID: <3D44C71A.9030803@sonic.net> Kevin R. Bulgrien wrote: > Crossfire 1.3.0 CVS as of today: > > This issue has been present for a while... > > You find a chest, find traps on it, disarm traps, then step on the chest. > Apply the chest to open it, and various items are found. Without moving, > try to "get" items and this message is given: > > You cannot pickup a woodfloor > > Step off the square, and step back. Now you can get the items... This has been a thorn in my side for a while. Apply will have similar behaviour. The real cause here is that when you open the chest, the new items are placed above the player in map stacking, but the display logic knows enough to put things in the correct order as far as the client is concerned. the bigger issues is that the server has to know the stacking of objects is consistent with the client. What this unfortunately means is that if you are standing on a space with say 50 objects, and drop something (which does not merge with what is on the space), it needs to re-send all 51 objects now, since the new object is on the top of the stack. What I really want to do at some point is modify client (and server to some extent) logic so that when you try to do something like pickup or apply and object without a specifier that the client passes along the tag of the item to perform this action on (similar to if you clicked on it with the mouse). In this way, stacking is much less an issue (because the client will say 'pick up item xyz', and the server can find item xyz, which may or may not be at the top of the stack, but if the client thinks it is, it works out). I suppose what can probably done for current support for thinks like pickup and apply is always start at the topmost object on the space, which may really be above the player. In that way, things like pickup below and apply below work as expected. From jsegarraf at terra.es Mon Jul 29 05:11:20 2002 From: jsegarraf at terra.es (Juan Segarra) Date: Thu Jan 13 18:04:21 2005 Subject: [CF List] wraith issues Message-ID: <3D4514C8.6040607@terra.es> Hi, this is my first mail to the list, hello all :-) I've been playing with a wraith character, and I've noticed two issues which I don't know if they're supposed to be that way. The first one is that the invisibility and invisible to undead do not work, all enemys see you when invisible. At first I thought that it would be an undead effect, sort of like Frodo and his companions noticing the wraiths :-) But then I thought that this effect is also produced in an inverse way in other players, that is, undead notice invisible alive players. The invisible to undead spell solves that. Thus, I think that the invisibility for the wraith character should work in an inverse way, that is, invisible make it invisible to undead and invisible to undead make it invisible to alive characters. Anyway, invisibility do not work and maybe it should do. The other issue is about the devourers avatar. When I kill chinesse dragons, for example, I do not get any experience. I think the problem is that it kills with life stealing. Maybe I'm mistaken, but the performance I assume is that life stealing makes the enemy weaker until dead, so probably at the end the enemy is so weak that killing it do not give any experience. If it is so, it should be corrected, because in this way the devourer's avatar is useless for gaining exp. Thank you -- Juan Segarra From kbulgrien at att.net Mon Jul 29 09:26:23 2002 From: kbulgrien at att.net (kbulgrien@att.net) Date: Thu Jan 13 18:04:21 2005 Subject: [CF List] SIGSEGV - Latest CVS crossfire server dies. Message-ID: <20020729142623.NPEM12658.mtiwmhc21.worldnet.att.net@webmail.worldnet.att.net> It hasn't happened recently... maybe it had something to do with the save file... I wasn't running the precise config.h parameters as I was with the previous server. Anyway, it happened 5-10 times after the update. OK, well, if it continues, I'll try to figure out how to give you more data. > Kevin R. Bulgrien wrote: > > Why does the server die when a (the only) player logs out? > > > > This is the latest CVS as of today... > > > > Checksums: 70bf482b 70bf482b > > LOGIN: Player named SirK from ip 127.0.0.1 > > Trying to load map /home/games/share/crossfire/maps/city/city. > > load_original_map: /city/city (0) > > Can't open /home/games/var/crossfire/maps/city/city > > Can't open overlay /home/games/var/crossfire/maps/city/city > > make_path_tofile /home/games/var/crossfire/players/SirK/SirK.pl... > > > > SIGSEGV received. > > Emergency saves disabled, no save attempted > > Cleaning up... > > Saving map /HallOfSelection > > make_path_tofile > > /home/games/var/crossfire/players/SirK/_city_apartment_apartments... > > Saving map /home/games/var/crossfire/players/SirK/_city_apartment_apartments > > Saving map /city/city > > Doesn't happen on my system, and doesn't happen on metalforge. > > No doubt you are experiencing some problem, but the lack of reproduciblity on > other systems makes it difficult to debug. A stack trace on where it is > crashing might help determine the cause here. > > > > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From mwedel at sonic.net Mon Jul 29 23:12:35 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:21 2005 Subject: [CF List] wraith issues References: <3D4514C8.6040607@terra.es> Message-ID: <3D461233.4000300@sonic.net> Juan Segarra wrote: > Hi, this is my first mail to the list, hello all :-) > > I've been playing with a wraith character, and I've noticed two issues > which I don't know if they're supposed to be that way. > > The first one is that the invisibility and invisible to undead do not > work, all enemys see you when invisible. At first I thought that it > would be an undead effect, sort of like Frodo and his companions > noticing the wraiths :-) But then I thought that this effect is also > produced in an inverse way in other players, that is, undead notice > invisible alive players. The invisible to undead spell solves that. > Thus, I think that the invisibility for the wraith character should work > in an inverse way, that is, invisible make it invisible to undead and > invisible to undead make it invisible to alive characters. Anyway, > invisibility do not work and maybe it should do. I just looked at the code - it is badly broken. When you cast invisible to undead, it sets the FLAG_UNDEAD in the player object. When you just cast normal invisible, it clears that flag. I am sure this is very old code, but it has very bad effects - the wraith is no longer undead when he casts the invisible code. similarly, a normal player can cast invisible to undead and be considered undead for some time period, getting all the benefits that allows. This time period is basically until fix_player is called, which could be quite a while if the player doesn't equip/unequip items, or cast spells which may effect stats or resistances. I'll have to fix this up. My understanding on how this should work: Invisible makes you invisible to everything but undead. Invisible to undead makes you invisible to undead, but not anything else. improved invisible makes you invisible to everything. IT doesn't matter if you (the caster) is undead or not. In any case, after I make the changes, the above is how things should end up working. > > The other issue is about the devourers avatar. When I kill chinesse > dragons, for example, I do not get any experience. I think the problem > is that it kills with life stealing. Maybe I'm mistaken, but the > performance I assume is that life stealing makes the enemy weaker until > dead, so probably at the end the enemy is so weak that killing it do not > give any experience. If it is so, it should be corrected, because in > this way the devourer's avatar is useless for gaining exp. Actually, it hits with drain as well as several other attacktypes. But yes, the drain will suck the exp from the monster into the avatar,which doesn't do you any good. I'll see about fixing this so that drain goes to the owner (this same effect applies to things like summon pet vampires also). From mak at solace.mh.se Tue Jul 30 17:52:32 2002 From: mak at solace.mh.se (Magnus Kronhamn) Date: Thu Jan 13 18:04:21 2005 Subject: [CF List] wraith issues In-Reply-To: <3D461233.4000300@sonic.net> Message-ID: On Mon, 29 Jul 2002, Mark Wedel wrote: > > I'll have to fix this up. My understanding on how this should work: > > Invisible makes you invisible to everything but undead. > Invisible to undead makes you invisible to undead, but not anything else. > improved invisible makes you invisible to everything. > > IT doesn't matter if you (the caster) is undead or not. In any case, after I > make the changes, the above is how things should end up working. > > As I've seen it the thing with improved invisibility is that you stay invisible while attacking which you dont do with the regular version(s). I'm not sure if it effects (or should effect) undeads at all. > > > > The other issue is about the devourers avatar. When I kill chinesse > > dragons, for example, I do not get any experience. I think the problem > > is that it kills with life stealing. Maybe I'm mistaken, but the > > performance I assume is that life stealing makes the enemy weaker until > > dead, so probably at the end the enemy is so weak that killing it do not > > give any experience. If it is so, it should be corrected, because in > > this way the devourer's avatar is useless for gaining exp. > > Actually, it hits with drain as well as several other attacktypes. > > But yes, the drain will suck the exp from the monster into the avatar,which > doesn't do you any good. I'll see about fixing this so that drain goes to the > owner (this same effect applies to things like summon pet vampires also). > > > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list > From kbulgrien at worldnet.att.net Sun Jul 28 09:11:47 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:04:21 2005 Subject: [CF List] applymode weirdness Message-ID: <02072809114800.25314@krayp120.worldnet.att.net> This from the top of CVS (Server 1.3.0) Whereas usekeys yields something like: usekeys is set to keyrings applymode results in: usekeys is set to never --- > usekeys keyrings usekeys set to keyrings ("nit-pick... one space could be with "is") > usekeys usekeys is set to keyrings > applymode usekeys is set to never > usekeys usekeys is set to keyrings > applymode always Applymode now set to always > applymode usekeys is set to never From kbulgrien at worldnet.att.net Sun Jul 28 09:30:10 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:04:21 2005 Subject: [CF List] No manna from heaven and other CVS questions... Message-ID: <02072809301001.25314@krayp120.worldnet.att.net> I compiled the server from CVS by going into the crossfire directory and doing the make process ./configure cd include vi config.h cd .. make depend make make install When crossfire starts, I get a bunch of messages like: $ head -25 /var/log/games/crossfire.last Reading bmaps from /home/games/share/crossfire/bmaps...done (got 3828/3829/3829)Reading faces from /home/games/share/crossfire/faces...done Reading animations from /home/games/share/crossfire/animations...done. got (768)Reading archetypes from /home/games/share/crossfire/archetypes... arch-pass 1... Object Burning Tail of many lashings of Ruggilli seems to have too low item power? 45 > 12 Adding friendly object Evil Master, Bonehead. Object amulet of lifesaving had no item power, using 4 Object strange ring had no item power, using 4 Object tooth charm had no item power, using 7 Object Chaos Sword had no item power, using 13 Object Darkblade had no item power, using 24 Object Demonbane had no item power, using 7 Object dagger of fortune had no item power, using 7 Object Frost Hammer had no item power, using 13 Object Firestar had no item power, using 50 Object Gram had no item power, using 11 Object Holy Avenger had no item power, using 45 Object Kobold Dagger had no item power, using 4 Object Lava Slasher had no item power, using 18 calc_item_power got 25 enchantments for Katana of Masamune Object Katana of Masamune had no item power, using 50 Object Sting had no item power, using 4 calc_item_power got 24 enchantments for Belzebub's sword Object Belzebub's sword had no item power, using 50 I don't yet know the relationship between compiling a server and the other top-level dirs like arch, maps, maps-bigworld... I didn't copy the cvs maps to the datadir directory. Is that why I get messages like the above... And maybe why the "manna from heaven" spot near the castle in scorn doesn't work since I did the make install? Also, what's the thing about maps vs. maps-bigworld? I don't see an obvious description. The mapset I have in the data dir seems to look more like maps than maps-bigworld, but I think on my last cvs update, only maps-bigworld was updated. I'm not sure what the differences are, and I don't think I understand what the comments are about maps being dependant on the compile process or .emergency files. Is one map set more current or supported than another? From tanner at real-time.com Wed Jul 10 01:15:05 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:04:23 2005 Subject: [CF List] Server 1.3.0 Makefile broken In-Reply-To: <02071001534501.14741@krayp120.worldnet.att.net>; from kbulgrien@worldnet.att.net on Wed, Jul 10, 2002 at 01:53:45AM -0500 References: <20020709223919.10548.qmail@web10402.mail.yahoo.com> <02071001534501.14741@krayp120.worldnet.att.net> Message-ID: <20020710011505.I26369@real-time.com> Quoting Kevin R. Bulgrien (kbulgrien@worldnet.att.net): > > ..configure properly detected that makedepend did not exist, but then this > happened... > > --- > > [root@krayp120 crossfire-1.3.0]# make depend Try this as NON-root user :-) make CC=gcc depend -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 http://www.tcwug.org, Minnesota, Wireless | Coding isn't a crime. Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 From tanner at real-time.com Sun Jul 7 15:12:19 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:04:29 2005 Subject: [CF List] Freshmeat entry updated Message-ID: <20020707151219.H26369@real-time.com> Can't remember which list the "update freshmeat entry" was posted. But I've updated it it. It's been stored for the fresmeat crew to verify. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 http://www.tcwug.org, Minnesota, Wireless | Coding isn't a crime. Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 From tanner at real-time.com Sun Jul 21 10:45:10 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:04:33 2005 Subject: [CF List] A way to add crossfire to your X menus In-Reply-To: <02071518032501.01553@krayp120.worldnet.att.net>; from kbulgrien@worldnet.att.net on Mon, Jul 15, 2002 at 06:03:25PM -0500 References: <200207020608.g62687X18148@sprite.real-time.com> <7764.1026762941@www6.gmx.net> <02071518032501.01553@krayp120.worldnet.att.net> Message-ID: <20020721104510.E11258@real-time.com> Please tell me where Mandrake will look for the menu and icons and I'll adjust the rpm. The rpm is pretty much GNOME, Redhat friendly as that is all I got :-) But I'd like to the rpm friendly to all RPM based distros. Quoting Kevin R. Bulgrien (kbulgrien@worldnet.att.net): > > It appears that the tclug-menu rpm is meant to add a menu option for > the clients... > > This doesn't work on my installation of Mandrake 8.0 - I do not have > gnome installed, only KDE. (As a result, I suppose I wonder why it > is a requirement on the crossfire-client rpms.) > > To add a crossfire client to my user's menus, I had to create the > following files: > > [krb@krayp120 krb]$ cat /usr/lib/menu/gcfclient > ?package(crossfire-client-gtk):\ > needs="x11"\ > section="Amusement/Adventure"\ > title="Crossfire GTK Client"\ > longtitle="The GTK Client for Crossfire"\ > command="/usr/bin/gcfclient"\ > icon="crossfire-client.png" > > krb@krayp120 krb]$ cat /usr/lib/menu/cfclient > ?package(crossfire-client):\ > needs="x11"\ > section="Amusement/Adventure"\ > title="Crossfire Client"\ > longtitle="The Client for Crossfire"\ > command="/usr/bin/cfclient"\ > icon="crossfire-client.png" > > After this, as root, run update-menus > > Now all users will see the clients in their menu structure. > > Uhm... The main technicality I see here is that the crossfire-client.png > file is supplied by the crossfire-client-gtk rpm. If you only installed > the crossfire-client rpm, the graphic would not be available, but > this does not prevent the menu item from being created. > > It would also be possible to use the file name that tclug-menu rpm... > package_games_adventure.png > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list > -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 http://www.tcwug.org, Minnesota, Wireless | Coding isn't a crime. Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 From tanner at real-time.com Wed Jul 10 01:14:26 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:04:33 2005 Subject: [CF List] Server 1.3.0 Makefile broken In-Reply-To: <02071001534501.14741@krayp120.worldnet.att.net>; from kbulgrien@worldnet.att.net on Wed, Jul 10, 2002 at 01:53:45AM -0500 References: <20020709223919.10548.qmail@web10402.mail.yahoo.com> <02071001534501.14741@krayp120.worldnet.att.net> Message-ID: <20020710011426.H26369@real-time.com> Quoting Kevin R. Bulgrien (kbulgrien@worldnet.att.net): > > ..configure properly detected that makedepend did not exist, but then this > happened... > > --- > > [root@krayp120 crossfire-1.3.0]# make depend ^^^ Ouch. Don't build things as root. What would happen if someone did this: all:: @rm -rf / -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 http://www.tcwug.org, Minnesota, Wireless | Coding isn't a crime. Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 From tanner at real-time.com Sat Jul 27 14:36:21 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:04:33 2005 Subject: [CF List] SIGSEGV - Latest CVS crossfire server dies. In-Reply-To: <02072713581300.09451@krayp120.worldnet.att.net>; from kbulgrien@worldnet.att.net on Sat, Jul 27, 2002 at 01:58:13PM -0500 References: <02072713581300.09451@krayp120.worldnet.att.net> Message-ID: <20020727143621.G1983@real-time.com> Quoting Kevin R. Bulgrien (kbulgrien@worldnet.att.net): > > Why does the server die when a (the only) player logs out? > > This is the latest CVS as of today... Make sure it's compiled with at least -g (-g3 is better) and run the server in gdb. When it seg faults, post the th bt full -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 http://www.tcwug.org, Minnesota, Wireless | Coding isn't a crime. Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 From tanner at real-time.com Wed Jul 10 13:38:51 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:04:33 2005 Subject: [CF List] Problems & question on client 1.3.1 RPMS off of SourceForge In-Reply-To: <02071001493500.14741@krayp120.worldnet.att.net>; from kbulgrien@worldnet.att.net on Wed, Jul 10, 2002 at 01:49:35AM -0500 References: <20020709223919.10548.qmail@web10402.mail.yahoo.com> <02071001493500.14741@krayp120.worldnet.att.net> Message-ID: <20020710133851.D1635@real-time.com> Sound problem should be fixed and available on sourceforge. Quoting Kevin R. Bulgrien (kbulgrien@worldnet.att.net): > Client sounds > > 1) > > crossfire-client-sounds-1.3.1-realtime.1.rpm package confuses > me. The sound files are installed to /usr/share/sounds/crossfire, but the > cfsndserv task expects them elsewhere, and spews errors . The sound > files really should be in /usr/share/games/crossfire/crossfire-client/sounds... > > I symlinked the directory, and it works, but the package really out to be > built consistently. > > # ln -s /usr/share/sounds/crossfire /usr/share/games/crossfire/crossfire-client/sounds > > > GTK Client > > 1) > > I noticed that pattern matching was changed with this release... > > Well, it has really changed... > > If there are "five stoneaxes" in the inventory, 'drop five stoneaxes' > says "nothing to drop". > > 'drop 5 stoneaxes' drops five of everything you have five of... > OUCH! > > 'drop bows +1' drops bows, not just the +1 bows... > though the bow -1 is not dropped... > > Oops ... looks like we went to a minimal match on the regular > expression or something... > > 'drop daggers' drops all daggers except, for example "throwing > daggers"... (I would not have expected it to drop the them, so > that is ok.) > > 2) > > Also there is a persisting problem from older releases of the the > client... > > Right-clicking an item to drop it, gives messages like: > > There are only one clubs. > > Sure there are, and I wanted you to drop them silly... It seems > the only fix here is to drop out of the client and restart it... > When this happens, it is not possible to drop anything with > a right click. > > 3) GTK Client > > How on earth do I lock inventory items? I can't see anything in help > that gives me a clue... I am sure there is supposed to be some way > to do it because there is a lock/unlock option on the inventory... > > 4) > > What is the "Count" field for? > > 5) > > Why does the menu selection "Client Spells just dump a bunch of > "Spell:" messages on the console session... Nothing else, just that. > > 6) > > Is there a point to the menu functions under Action? I guess the > pickup's make sense, but why would I click cast, then have to take > my hand off the mouse to type in the spell. I must be missing something? > > 7) > > What does the 'E' key do? > > 8) > > Experienced segmentation faults whenever I tried to save configuration > options... Oddly, the options did not relate to the values in the user > option file. Permissions were correct. Manually edited the file with > vi, and segmentation faults quit happening... Changed a few 0's > to 1's... > > It is unclear why this started happening... the client had never been > installed on this system before, so the user did not have a pre-existing > saved configuration. It had created the file itself, but then was in a > state where is seg faulted when the user tried to save new settings. > > --- > > Here's just a sample of the gcfclient output with some of the symptoms > I've seen... > > [krb@krayp120 .crossfire]$ gcfclient > Character Width : 11 > Character Height: 11 > Warning: could not convert keysym F28 into keycode, ignoring > Warning: could not convert keysym F34 into keycode, ignoring > Warning: could not convert keysym F30 into keycode, ignoring > Warning: could not convert keysym F32 into keycode, ignoring > Warning: could not convert keysym F27 into keycode, ignoring > Warning: could not convert keysym F29 into keycode, ignoring > Warning: could not convert keysym F31 into keycode, ignoring > Warning: could not convert keysym F33 into keycode, ignoring > Warning: could not convert keysym F35 into keycode, ignoring > Couldn't open /dev/dsp: Device or resource busy > Playing on server type Crossfire Server > > Fatal signal: Segmentation Fault (SDL Parachute Deployed) > [krb@krayp120 .crossfire]$ gcfclient > Character Width : 11 > Character Height: 11Character Height: 11 > Warning: could not convert keysym F28 into keycode, ignoring > Warning: could not convert keysym F34 into keycode, ignoring > Warning: could not convert keysym F30 into keycode, ignoring > Warning: could not convert keysym F32 into keycode, ignoring > Warning: could not convert keysym F27 into keycode, ignoring > Warning: could not convert keysym F29 into keycode, ignoring > Warning: could not convert keysym F31 into keycode, ignoring > Warning: could not convert keysym F33 into keycode, ignoring > Warning: could not convert keysym F35 into keycode, ignoring > Unknown metaserver hostname: crossfire.real-time.com > Unable to open /home/krb/.crossfire/sounds - will use built in defaults > Playing on server type Crossfire Server > > Unknown input state: 2 > /usr/share/games/crossfire/crossfire-client/sounds/click1.raw: No such file or directory > /usr/share/games/crossfire/crossfire-client/sounds/click1.raw: No such file or directory > /usr/share/games/crossfire/crossfire-client/sounds/Creaky-1.raw: No such file or directory > ... > gtk_main exited, returning from event_loop > [krb@krayp120 .crossfire]$ > [krb@krayp120 .crossfire]$ gcfclient > Character Width : 11 > Character Height: 11 > Warning: could not convert keysym F28 into keycode, ignoring > Warning: could not convert keysym F34 into keycode, ignoring > Warning: could not convert keysym F30 into keycode, ignoring > Warning: could not convert keysym F32 into keycode, ignoring > Warning: could not convert keysym F27 into keycode, ignoring > Warning: could not convert keysym F29 into keycode, ignoring > Warning: could not convert keysym F31 into keycode, ignoring > Warning: could not convert keysym F33 into keycode, ignoring > Warning: could not convert keysym F35 into keycode, ignoring > Couldn't open /dev/dsp: Device or resource busy > [krb@krayp120 .crossfire]$ gcfclient > Character Width : 11 > Character Height: 11 > Warning: could not convert keysym F28 into keycode, ignoring > Warning: could not convert keysym F34 into keycode, ignoring > Warning: could not convert keysym F30 into keycode, ignoring > Warning: could not convert keysym F32 into keycode, ignoring > Warning: could not convert keysym F27 into keycode, ignoring > Warning: could not convert keysym F29 into keycode, ignoring > Warning: could not convert keysym F31 into keycode, ignoring > Warning: could not convert keysym F33 into keycode, ignoring > Warning: could not convert keysym F35 into keycode, ignoring > Couldn't open /dev/dsp: Device or resource busy > Playing on server type Crossfire Server > > Fatal signal: Segmentation Fault (SDL Parachute Deployed) > [krb@krayp120 .crossfire]$ gcfclient > Character Width : 11 > Character Height: 11 > Warning: could not convert keysym F28 into keycode, ignoring > Warning: could not convert keysym F34 into keycode, ignoring > Warning: could not convert keysym F30 into keycode, ignoring > Warning: could not convert keysym F32 into keycode, ignoring > Warning: could not convert keysym F27 into keycode, ignoring > Warning: could not convert keysym F29 into keycode, ignoring > Warning: could not convert keysym F31 into keycode, ignoring > Warning: could not convert keysym F33 into keycode, ignoring > Warning: could not convert keysym F35 into keycode, ignoring > Unable to open /home/krb/.crossfire/sounds - will use built in defaults > Playing on server type Crossfire Server > > Unknown input state: 2 > Spell: > Spell: > Spell: > Spell: > Spell: > Spell: > Spell: > Spell: > Spell: > Spell: > Spell: > Spell: > Spell: > Spell: > Spell: > Spell: > Spell: > Spell: > Spell: > Spell: > Spell: > Spell: > Spell: > Spell: > Spell: > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list > -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 http://www.tcwug.org, Minnesota, Wireless | Coding isn't a crime. Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288