From nicolas.weeger at laposte.net Sun Aug 3 13:31:33 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 3 Aug 2008 20:31:33 +0200 Subject: [crossfire] Face information for animations Message-ID: <200808032031.37454.nicolas.weeger@laposte.net> Hello. When collecting the .face files, the collect.pl script will only write fg/visibility information for faces outside animation, and not all faces. On the other hand, when an animation is defined into an archetype file, the visiblity/magicmap is set for all faces of the animation. I'd like to fix that so the various animations can be factorized into .face files, with the face information (color_fg and such), that doesn't really belong to archetypes imo. Example: the 'sea' animation is duplicated between 'sea' and 'sea1' (file ground/sea.arch) - it would be much easier to have it defined in sea.face, including color_fg and magicmap and visibility, and just tell 'animation sea' in both archetypes. Opinions? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080803/7c1568fe/attachment.pgp From raphael at gimp.org Sun Aug 3 18:00:21 2008 From: raphael at gimp.org (=?UTF-8?B?UmFwaGHDq2w=?= Quinet) Date: Mon, 4 Aug 2008 01:00:21 +0200 Subject: [crossfire] Broken trigger_markers (type 52) breaking several maps in SVN trunk Message-ID: <20080804010021.ba0c354a.raphael@gimp.org> Hi, This is about bug 1985944: https://sourceforge.net/tracker/index.php?func=detail&aid=1985944&group_id=13833&atid=113833 Since about four months, the trigger_marker archetype (using the object type 52 TRIGGER_MARKER) is broken. During the refactorization of the code for type 55 MARKER, the code that was also handling the TRIGGER_MARKER objects was removed. It is hard to know if that was an accident or if there were some plans to restore or improve that code later. In any case, this bug is rather annoying because it prevents players from entering the apartments in Brest or Lone Town, it prevents access to the smithery, kitchen, tannery and similar shops in Scorn and Navar, and it breaks some parts of the python guilds. This affects all servers based on SVN trunk. If I am not mistaken, the main difference between objects of type 55 (MARKER) and type 52 (TRIGGER_MARKER) is that markers detect when a player steps on them, and apply the mark. Trigger_markers are only activated via a connection, not when someone moves over them. Both of them add a mark (force) in the player's inventory. I would like to fix that bug but I'm not sure about the best way to do it. I can think about the following options: 1) Restore the old code that was removed - easy, but bad solution. 2) (Re-)write the /types/... code for object type 52 TRIGGER_MARKER, trying to share some code with type 55 MARKER in /types/marker/. 3) Get rid of TRIGGER_MARKER and instead try to use the same object type (MARKER) for both archetypes "marker" and "trigger_marker". It should be possible to customize some fields of these archetypes so that "trigger_marker" is only activated by its connection and not when a player walks on it. Maybe it would be enough to set "move_on walk fly_low" for "marker" and "move_on 0" for "trigger_marker", but I don't know if that would work. 4) Get rid of the TRIGGER_MARKER type and "trigger_marker" archetype. Update all maps to use the "marker" archetype, assuming that some object fields can be set in a way that prevents its activation when a player steps on it. 5) Do the opposite: get rid of the type MARKER and the archetype "marker", keeping only "trigger_marker". Update all maps using "marker" objects and replace them by a pair of connected objects: a pedestal + a trigger_marker. Currently, I am hesitating between (2) and (3). But I would like some advice about the best way to proceed, and maybe some comments about why the support for TRIGGER_MARKER was removed (if it was not an accident and if someone remembers the reason). -Rapha?l From mwedel at sonic.net Mon Aug 4 22:39:59 2008 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 04 Aug 2008 20:39:59 -0700 Subject: [crossfire] Face information for animations In-Reply-To: <200808032031.37454.nicolas.weeger@laposte.net> References: <200808032031.37454.nicolas.weeger@laposte.net> Message-ID: <4897CB8F.60703@sonic.net> Nicolas Weeger wrote: > Hello. > > > When collecting the .face files, the collect.pl script will only write > fg/visibility information for faces outside animation, and not all faces. On > the other hand, when an animation is defined into an archetype file, the > visiblity/magicmap is set for all faces of the animation. > > I'd like to fix that so the various animations can be factorized into .face > files, with the face information (color_fg and such), that doesn't really > belong to archetypes imo. > Example: the 'sea' animation is duplicated between 'sea' and 'sea1' (file > ground/sea.arch) - it would be much easier to have it defined in sea.face, > including color_fg and magicmap and visibility, and just tell 'animation sea' > in both archetypes. Sounds good. As a note, color_fg is deprecated, and instead every color_fg should get replaced with the 'magicmap' name instead. The color_fg (and at the time, color_bg) dates back to when crossfire used bitmaps, and those colors determined the foreground and background color. For some images, the foreground color was not a good indicator for magicmap purposes, so magicmap (as a supplemental field) was added. Bitmap support has been gone for years now. Within the server, if it finds a color_fg, it just sets that face->magicmap to that value. I'd actually like to get rid of magicmap at some point also, and change what magicmap spell does - maybe instead of sending the color information, which is of limited usefulness, it insteads non visible map squares to the client (in a sense, fills in the 25x25 map - the client could treat that as fog of war information or something). To be more useful, probably want a zoom out feature of the map window, so lots of folks don't play with a 25x25 visible map size. But that is a bit beside the question asked here. From kedjane at hotmail.com Sat Aug 9 05:38:01 2008 From: kedjane at hotmail.com (Kedjane -) Date: Sat, 9 Aug 2008 12:38:01 +0200 Subject: [crossfire] Crossfire won't work (several errors)! Message-ID: Hey, I used to play Crossfire seriously a few years ago - had a great time but eventually something else came up so I had to stop playing, but still I've been making an annual (or twice a year) return to my character: checking the appartment out, seeing so my character hasn't gotten auto-deleted and visiting a certain place. Anyhow now I've got problems and it might be because I'm using Windows XP, a 1680x1050 screen (although I tried briefly on a smaller screen I have plugged in aswell) and I noticed Gaim have switched name to Pidgin! The problem I'm having is when I start it up no servers appear in the list - I can't type anything in the little field and it runs in a strange window. The window is always exactly so tall it won't fit on my screen and I can only pull it out wider horisontally but not vertically - quite a problem. So, when I try to maximize it the whole thing freezes or something and everything I hold over appears to stay there if you know what I mean. For example: if I open a .txt window and move it above my Crossfire window, then close the .txt window it still appears to be there even though it's not - proof that Crossfire have frozen. The files I'm using are just the Windows Client linked on the Crossfire page (1.11.0) and Pidgin 2.4.3. Anyhow, I tried to solve it myself by removing everything and saw the "Windows users use this:" thing on the Crossfire site, some GTK thing, and downloaded it but when I tried to install it it said a newer version of GTK already was installed. I've tried searching through the entire computer and I have deleted everything named both "GTK" and "Crossfire" but still it sais it's already installed. So, right now I've installed Crossfire (1.11.0) again along with Pidgin but now when I try to play it sais libglib-2.0.0.dll is missing and reinstalling might help. My guess is because I deleted all "GTK" files earlier - but since there is some fraction of them left somewhere I can't reinstall them to solve the problem! Any hints on how I can completely delete GTK? Add/remove software and searching for "GTK" doesn't work. For now I'll try to remove everything to get as clean in my folders as possible and wait for a reply on how to properly install the game. By the way, why can't you register to your forums with a hotmail adress, that's just really annoying. I did register using a different email, but it turns out I can't access it (I think it was deleted for not being used for a few years). _________________________________________________________________ Skapa dina egna uttryckssymboler till Messenger! www.windowslive.se/dinegensmiley -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.metalforge.org/pipermail/crossfire/attachments/20080809/a39da39b/attachment.htm From leaf at real-time.com Sat Aug 9 19:34:36 2008 From: leaf at real-time.com (Rick Tanner) Date: Sat, 09 Aug 2008 19:34:36 -0500 Subject: [crossfire] Crossfire won't work (several errors)! In-Reply-To: References: Message-ID: <489E379C.5070602@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kedjane - wrote: > > By the way, why can't you register to your forums with a hotmail > adress, that's just really annoying. It's due to the hundreds of spam(mer) accounts that have attempted to register on the forum using @hotmail.com > I did register using a different > email, but it turns out I can't access it (I think it was deleted for > not being used for a few years). Please reply to me via private email as to what address you used and I can investigate. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFInjechHyvgBp+vH4RAvwOAKC8pGPey8iSnC0l/Z5A0iAChwFSKwCgl8M5 3RUdSDozYeboR300vq0lNDQ= =1zxt -----END PGP SIGNATURE----- From leaf at real-time.com Sat Aug 9 20:00:22 2008 From: leaf at real-time.com (Rick Tanner) Date: Sat, 09 Aug 2008 20:00:22 -0500 Subject: [crossfire] Crossfire won't work (several errors)! In-Reply-To: References: Message-ID: <489E3DA6.8050405@real-time.com> > For example: if I open a .txt window and move it above my Crossfire > window, then close the .txt window it still appears to be there even > though it's not - proof that Crossfire have frozen. > > The files I'm using are just the Windows Client linked on the > Crossfire page (1.11.0) and Pidgin 2.4.3. What version of GTK ? The issues you described with the screen not refreshing or appearing to lock up - I have encountered them as well when GTK had some sort of conflict with the running app. What server did you try and connect to? There is at least 1 server that does not work with recent clients. > Anyhow, I tried to solve it myself by removing everything and saw the > "Windows users use this:" thing on the Crossfire site, some GTK thing, > and downloaded it but when I tried to install it it said a newer version > of GTK already was installed. I've tried searching through the entire > computer and I have deleted everything named both "GTK" and "Crossfire" > but still it sais it's already installed. The 1.11.0 client did work best with GTK+ Runtime Environment 2.10.11 Earlier this week (2008-Aug-04), a new snapshot release was made and that looks to use GTK+ 2.12.9 An install HOWTO is available at, http://wiki.metalforge.net/doku.php/windows#gtk_2_runtime_environment > So, right now I've installed Crossfire (1.11.0) again along with > Pidgin but now when I try to play it sais libglib-2.0.0.dll is missing > and reinstalling might help. My guess is because I deleted all "GTK" > files earlier - but since there is some fraction of them left somewhere > I can't reinstall them to solve the problem! Try re-installing Pidgin? Try installing GTK+ 2.12.9? > Any hints on how I can completely delete GTK? Add/remove software and > searching for "GTK" doesn't work. As far as removing your old install of GTK, in all my test installs for creating the screen shots, etc. I have found using the Uninstall menu option that is created in Program Files -> GTK+ to work. From leaf at real-time.com Mon Aug 11 17:32:49 2008 From: leaf at real-time.com (Rick Tanner) Date: Mon, 11 Aug 2008 17:32:49 -0500 Subject: [crossfire] Testing svnmerge.py Message-ID: <48A0BE11.2040206@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A couple of people have suggested using svnmerge.py to manage and track merges (or backports) from Trunk to Branch. So, I have volunteered and taken the initiative to start on this right away for maps only. This is the online guide that I am using to get started: http://www.orcaware.com/svn/wiki/Svnmerge.py If this crashes and burns on me, then I will spend alot of time putting out the fire. ;-) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIoL4RhHyvgBp+vH4RAnITAJ9LC91Kj+KXLr1gHqRp+T12NeIRsQCeNfjl QwozF5AxT4a1S49eBh9BTnw= =7v5z -----END PGP SIGNATURE----- From nicolas.weeger at laposte.net Fri Aug 15 05:24:30 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 15 Aug 2008 12:24:30 +0200 Subject: [crossfire] Testing svnmerge.py In-Reply-To: <48A0BE11.2040206@real-time.com> References: <48A0BE11.2040206@real-time.com> Message-ID: <200808151224.34550.nicolas.weeger@laposte.net> Le mardi 12 ao?t 2008, Rick Tanner a ?crit?: > A couple of people have suggested using svnmerge.py to manage and track > merges (or backports) from Trunk to Branch. > > So, I have volunteered and taken the initiative to start on this right > away for maps only. Many thanks to you :) (though I admit I'd rather have trunk become the official release, and branch forgotten except for major bugfixes maybe) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080815/208e201d/attachment.pgp From leaf at real-time.com Mon Aug 18 20:26:55 2008 From: leaf at real-time.com (Rick Tanner) Date: Mon, 18 Aug 2008 20:26:55 -0500 Subject: [crossfire] Incorrect Type and Material on multiple objects in Fun Zone Message-ID: <48AA215F.6030003@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mapper complained about "Couldn't find archetype 0" so I went to check on the map with the map editor (snapshot build from Aug-18-2008.) The Map Editor also gave warnings about many objects (chairs, beds, tables, pipeweed) having the wrong material and type. I tried to manually fix them, but found it much easier to just remove and re-insert the objects in question. I only worked on fz_lobby, see r9752. Given the development history of these maps.. I suspect that the snapshot .jar file is out of date or the gtk editor may have some outdated information or my archetypes/editor has the wrong or outdated info. I'm posting this, because I don't know what could be the cause and to also alert others to this problem(?). - - Rick Tanner leaf at real-time.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIqiFfhHyvgBp+vH4RAkBqAJ0Std9g1bqlxbwsDutQVS+unjrqWgCeMygQ 1C8JgCaPJxAi09wvLgFNSns= =Ue4b -----END PGP SIGNATURE----- From leaf at real-time.com Wed Aug 20 14:49:12 2008 From: leaf at real-time.com (Rick Tanner) Date: Wed, 20 Aug 2008 14:49:12 -0500 Subject: [crossfire] Magic map colors and related changes necessary for client and server Message-ID: <48AC7538.1050300@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 After testing on my part and discussion on IRC, it was discovered that one can add addition colors to server/common/images.c (around line 100) and then recompile to allow more colors for the magic map spell (assuming archetypes are also updated with this new color in their magicmap field -- formerly, color_fg). (Note: make sure to add a comma after the color "kahki" like this "kahki", ) However, the current X11 and GTKv1 and GTKv2 can/will crash if any new colors are added. So, some undetermined change(s?) needs to be made with the clients to support 13 (or more) colors. The JXclient does not crash; it displays, in this case, purple as dark_gray. With this in mind, I went through the archetypes and replaced purple with black. This was r9762. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIrHU4hHyvgBp+vH4RAmPNAKCUSC7guzfAKOl6Vx1HxE18/o+a+gCg2HjL 11UcxP0Bp44GD2s9M7Ncqqs= =zTbK -----END PGP SIGNATURE----- From leaf at real-time.com Wed Aug 20 14:53:48 2008 From: leaf at real-time.com (Rick Tanner) Date: Wed, 20 Aug 2008 14:53:48 -0500 Subject: [crossfire] Testing svnmerge.py In-Reply-To: <48A0BE11.2040206@real-time.com> References: <48A0BE11.2040206@real-time.com> Message-ID: <48AC764C.6080801@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rick Tanner wrote: > > A couple of people have suggested using svnmerge.py to manage and track > merges (or backports) from Trunk to Branch. > > So, I have volunteered and taken the initiative to start on this right > away for maps only. I've found some problems with using this. Svnmerge requires an "all or nothing" approach for merging. For instance, r9738 was some map changes to update or add the difficulty level to 14 maps. At least 4 of those maps were not in branches/1.x; so svnmerge would not merge the changes. For the time being, I will continue to manually backport changes. If anyone else is interested in trying this out and showing how it can work - by all means, please do. Thanks. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIrHZLhHyvgBp+vH4RAvyBAJ4rZJARRtvMDpZM3B3R9lD5jGig6gCfeJEc CjuwZZXtpByA/Ce330wxl94= =FPhx -----END PGP SIGNATURE----- From mwedel at sonic.net Wed Aug 20 23:53:56 2008 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 20 Aug 2008 21:53:56 -0700 Subject: [crossfire] Magic map colors and related changes necessary for client and server In-Reply-To: <48AC7538.1050300@real-time.com> References: <48AC7538.1050300@real-time.com> Message-ID: <48ACF4E4.406@sonic.net> Rick Tanner wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > After testing on my part and discussion on IRC, it was discovered that > one can add addition colors to server/common/images.c (around line 100) > and then recompile to allow more colors for the magic map spell > (assuming archetypes are also updated with this new color in their > magicmap field -- formerly, color_fg). > > (Note: make sure to add a comma after the color "kahki" like this "kahki", ) > > However, the current X11 and GTKv1 and GTKv2 can/will crash if any new > colors are added. So, some undetermined change(s?) needs to be made > with the clients to support 13 (or more) colors. The JXclient does not > crash; it displays, in this case, purple as dark_gray. > > With this in mind, I went through the archetypes and replaced purple > with black. This was r9762. Yes - this is because color information for magicmap is sent to the client as that value on the server. The current colors for magicmap correspond to the colors for the messages (NDI_....) Almost certainly what is happening is the client is getting a color value that it assumes is valid, and is looking up values beyond what are in fact valid. The Java client is more intelligent and does bound checking or the like. The right solution for the client in these cases is that if it does get a value out of bounds, it should just use a default. If more colors are desired, that is more work to do, as the NDI type values would need to get extended. IMO, those NDI values will eventually go away (the messages have been changed to send the type of message, and the client can then look up how that type of message should be displayed). I'm still tempted for magic map to just send more data so fill in fog of war or other details on the map - in that case, the magicmap values would completely go away. From akirschbaum at users.sourceforge.net Thu Aug 21 01:26:35 2008 From: akirschbaum at users.sourceforge.net (Andreas Kirschbaum) Date: Thu, 21 Aug 2008 08:26:35 +0200 Subject: [crossfire] Magic map colors and related changes necessary for client and server In-Reply-To: <48ACF4E4.406@sonic.net> References: <48AC7538.1050300@real-time.com> <48ACF4E4.406@sonic.net> Message-ID: <20080821062635.GA14363@localhost.localdomain> Mark Wedel wrote: > Almost certainly what is happening is the client is getting a color > value that it assumes is valid, and is looking up values beyond what > are in fact valid. The Java client is more intelligent and does bound > checking or the like. > > The right solution for the client in these cases is that if it does > get a value out of bounds, it should just use a default. This is exactly what is happening: all of x11/gtk/gtk-v2 either allocate an array having 13 elements or allocate 16 elements but do not initialize more than 13 elements. The access is a color index 0..15 (without bounds checking). Jxclient allocates a 16 element array, fills the undefined entries with dark gray as a default, then uses an index 0..15 for access. > If more colors are desired, that is more work to do, as the NDI type > values would need to get extended. IMO, those NDI values will > eventually go away (the messages have been changed to send the type of > message, and the client can then look up how that type of message > should be displayed). I'm still tempted for magic map to just send > more data so fill in fog of war or other details on the map - in that > case, the magicmap values would completely go away. I vote for this solution -- do not "improve" the existing magicmap color table but send actual face information in magicmap responses. From raphael at gimp.org Mon Aug 25 13:16:53 2008 From: raphael at gimp.org (=?UTF-8?B?UmFwaGHDq2w=?= Quinet) Date: Mon, 25 Aug 2008 20:16:53 +0200 Subject: [crossfire] Incorrect Type and Material on multiple objects in Fun Zone In-Reply-To: <48AA215F.6030003@real-time.com> References: <48AA215F.6030003@real-time.com> Message-ID: <20080825201653.c6c119b6.raphael@gimp.org> On Mon, 18 Aug 2008 20:26:55 -0500, Rick Tanner wrote: > Mapper complained about "Couldn't find archetype 0" so I went to check > on the map with the map editor (snapshot build from Aug-18-2008.) > > The Map Editor also gave warnings about many objects (chairs, beds, > tables, pipeweed) having the wrong material and type. Well, in this case I think that both mapper and gridarta gave wrong warning. All objects in the lobby had been given "type 0" and "material 0" in order to make sure that they could not be destroyed by spells or other means. This is useful because the lobby is where players respawn after being killed on the battleground tiles in the various Fun Zone maps. Blocking spells in the lobby wouldn't be sufficient because players who are killed in one of these maps could have been in the process of throwing a dangerous potion (fiery destruction, black fire, etc.) or attempting a prayer triggering godly retribution. > I tried to manually fix them, but found it much easier to just remove > and re-insert the objects in question. I only worked on fz_lobby, see > r9752. > > Given the development history of these maps.. I suspect that the > snapshot .jar file is out of date or the gtk editor may have some > outdated information or my archetypes/editor has the wrong or outdated info. This was intentional, so I think that the bug is in the inappropriate warnings that you got, not in the maps. Both Chad (using gridarta) and myself (using gcrossedit) had spent some time editing the attributes of each object and setting their type and material to 0 in order to make sure that they could not be destroyed. This was done by Chad in the original version of most Fun Zone maps, and further done by myself for the lobby in SVN revision 9710: "Protect the furniture against accidental destruction by spells" (after Chad complained that some objects could still be destroyed). I think that the changes in revision 9752 should be reverted, because the lobby can now be destroyed easily. Also, I think that the changes in revision 9751 are also due to a wrong warning in the editor: the exits were not set to /city/city. They were not set at all in the map, which is IMHO appropriate for unused teleporters. You probably saw them as pointing to /city/city because the editor used the default value for attributes that were not set in the map (although gcrossedit doesn't do that and leaves the field blank). Doing svn diff on revision 9751 also shows that it includes some other changes compared to 9710: some barrels lost their "type 0" attributes. > I'm posting this, because I don't know what could be the cause and to > also alert others to this problem(?). As this was intentional, I would like both r9751 and r9752 to be reverted and I think that the mapper tool should be modified so that it doesn't complain about objects of type/material 0. However, if someone can suggest a better way to handle this, I would be happy to discuss other solutions. -Rapha?l From raphael at gimp.org Mon Aug 25 13:39:46 2008 From: raphael at gimp.org (=?UTF-8?B?UmFwaGHDq2w=?= Quinet) Date: Mon, 25 Aug 2008 20:39:46 +0200 Subject: [crossfire] Handling of "Created" and "Modified" info in map headers Message-ID: <20080825203946.62e417a0.raphael@gimp.org> Hi, I noticed a difference between how gridarta updates the map headers and how my patched version of gcrossedit handles it: - gcrossedit handles the "Created" and "Modified" fields like a ChangeLog, appending a new "Modified" line whenever a change is made and the date or author doesn't match the previous entry. - gridarta seems to always replace the first "Modified" line, regardless of what was there before. The fact that gridarta only considers the first "Modified" entry and ignores the other ones leads to strange situations, like in this example with /darcap/darcap/circus/fz_olobby: Revision 9710 looked like this: Created: 2008-07-24 Chad Opperman | cromagic at sbcglobal.net Modified: 2008-07-26 Chad Opperman | cromagic at sbcglobal.net Modified: 2008-08-01 Rapha?l Quinet After editing (presumably with gridarta), r9751 looks like this: Created: 2008-07-24 Chad Opperman | cromagic at sbcglobal.net Modified: 2008-08-18 Rick Tanner Modified: 2008-08-01 Rapha?l Quinet The second "Modified" entry is still there, but the first one has been replaced, resulting in dates that are in the wrong order. What should be the appropriate behavior in this case? Should there be only one "Modified" line in each map header (in which case both gridarta and gcrossedit should be modified to delete other lines) or should "Modified" lines be collected like a mini ChangeLog (in which case gridarta should be modified to append instead of replacing the first "Modified" line)? Personally, I like the mini ChangeLog approach because it can give useful clues about the history of the map to those who get the mapinfo without having SVN access. This is also useful if a map goes through several iterations before being imported in SVN, or when external contributors submit patches without having SVN access. But I could also understand the desire to keep the map header small and only keep a single "Modified" line. -Rapha?l From raphael at gimp.org Mon Aug 25 14:01:47 2008 From: raphael at gimp.org (=?UTF-8?B?UmFwaGHDq2w=?= Quinet) Date: Mon, 25 Aug 2008 21:01:47 +0200 Subject: [crossfire] Magic map colors and related changes necessary for client and server In-Reply-To: <20080821062635.GA14363@localhost.localdomain> References: <48AC7538.1050300@real-time.com> <48ACF4E4.406@sonic.net> <20080821062635.GA14363@localhost.localdomain> Message-ID: <20080825210147.09a9d7f8.raphael@gimp.org> On Thu, 21 Aug 2008 08:26:35 +0200, Andreas Kirschbaum wrote: > Mark Wedel wrote: > > [...] I'm still tempted for magic map to just send > > more data so fill in fog of war or other details on the map - in that > > case, the magicmap values would completely go away. > > I vote for this solution -- do not "improve" the existing magicmap color > table but send actual face information in magicmap responses. Yes! If there was a way to vote for this (other than by coding it, which requires time), then I would vote with both hands. Sending actual map data would feel more natural and would make magic maps much more useful. This would also get rid of ugly widgets in the clients. FYI, that's exactly what Nethack does. When you invoke that spell in Nethack, you get a full view of all static objects in the map. Magic mapping doesn't display monsters or other living objects (unless this has changed since I last played it) but it shows all walls and tunnels, as if you had already been there. -Rapha?l From mwedel at sonic.net Mon Aug 25 23:49:20 2008 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 25 Aug 2008 21:49:20 -0700 Subject: [crossfire] Handling of "Created" and "Modified" info in map headers In-Reply-To: <20080825203946.62e417a0.raphael@gimp.org> References: <20080825203946.62e417a0.raphael@gimp.org> Message-ID: <48B38B50.5020109@sonic.net> Rapha?l Quinet wrote: > Hi, > > I noticed a difference between how gridarta updates the map headers > and how my patched version of gcrossedit handles it: > > - gcrossedit handles the "Created" and "Modified" fields like a > ChangeLog, appending a new "Modified" line whenever a change is > made and the date or author doesn't match the previous entry. > > - gridarta seems to always replace the first "Modified" line, > regardless of what was there before. As a probably irrelevant data point, the old crossedit also only did one Modified line IIRC, which may be where gridarta got it from. As I'm thinking about this more, I'm more tempted that all editors should really just do 'Modified: $Id$', and let svn/cvs/whatever deal with that last modified date. This actually works better because any checkin has to have a real name/e-mail addressed to it. Or maybe put in another field like ID: which has that info. This allows for exact version information with the mapinfo command. While unlikely, one could get situations where the same person makes multiple changes to the same map file on the same day, and the Modified entry only has a resolution of 1 day (so you couldn't tell from it whether it was the most recent or not). I think it also works better with patches, as it makes it crystal clear what version of the map the patch is made against. I'm also not sure if the map header should really duplicate material that is found in SVN (which the modified field info is). The created file is different, because who created the map vs who checked it in originally can certainly be different. So I'd still be tempted to have only the most recent Modified field, or perhaps none at all - none of the other source files do. I sort of suspect the reason that the maps do have that modified fields is because at some point, they predated version control and at that time, there was some desire to track that info. From mwedel at sonic.net Tue Aug 26 00:06:14 2008 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 25 Aug 2008 22:06:14 -0700 Subject: [crossfire] Magic map colors and related changes necessary for client and server In-Reply-To: <20080825210147.09a9d7f8.raphael@gimp.org> References: <48AC7538.1050300@real-time.com> <48ACF4E4.406@sonic.net> <20080821062635.GA14363@localhost.localdomain> <20080825210147.09a9d7f8.raphael@gimp.org> Message-ID: <48B38F46.6030209@sonic.net> Rapha?l Quinet wrote: > On Thu, 21 Aug 2008 08:26:35 +0200, Andreas Kirschbaum wrote: >> Mark Wedel wrote: >>> [...] I'm still tempted for magic map to just send >>> more data so fill in fog of war or other details on the map - in that >>> case, the magicmap values would completely go away. >> I vote for this solution -- do not "improve" the existing magicmap color >> table but send actual face information in magicmap responses. > > Yes! If there was a way to vote for this (other than by coding it, > which requires time), then I would vote with both hands. Sending actual > map data would feel more natural and would make magic maps much more > useful. This would also get rid of ugly widgets in the clients. > > FYI, that's exactly what Nethack does. When you invoke that spell in > Nethack, you get a full view of all static objects in the map. Magic > mapping doesn't display monsters or other living objects (unless this has > changed since I last played it) but it shows all walls and tunnels, as if > you had already been there. Note that in crossfire, at some level this could be simple, at some level it could be hard, depending on desired results. The simple case is we use the existing map2 command to send the data, but we just extend the amount of data. The limitation is that the coordinates in map2 are limited from 0 to 63, with the player located anywhere from about 21 to 27 IIRC. It would probably be odd to provide non centered map data, so what this really means it that the size of the magic map is limited to about 40x40. That is probably fine - unless zoom out or scrolling of the map window is added (maybe that exists in the jxclient - not sure), that is still going to be much larger than any viewable area, which right now is 25x25. I often thought it wouldn't be that hard to add a zoom out feature to the map which reduces its scale by 50% or something (the opengl one makes that easier, as it does scaling in real time - the SDL and pixmap code would be more complicated, as it would likely need to draw onto a temporary buffer with the images it is using, then scale that down by 50% or something) I'm pretty sure that the C client will properly handle coordinates outside its viewable area, but not 100%. For the server, probably some hybrid of what it does now is needed - basically: 1) Still use the find viewable spaces function of existing magic map (in this way, things like hidden mechanisms are not revealed) 2) Use that information instead of the normal LOS code to determine which spaces are visible to send to client. 3) Send that data to the client. It is probably worth adding a bit or something in the data sent to note this is magic map data. Another reason for that is this could be used to note this space has transitory data, and thus we don't update the servers idea of what data it sent to the client. In this way, on the next tick, there server doesn't have to send a bunch of data say 'clear this space as it isn't visible', since the only reason it was visible was because of magic map. On the client, really few changes: For all data received, just update the spaces as we do now. The use of that magic map bit set above is for any spaces we do update, we do not want to clear the fog status - we still want them to be shown as fog spaces (or maybe a different type - magic map space or something, but unless drawn differently, probably no gain there). The main point is you probably don't want them to flash as normally visible spaces for a tick and then flash into fog spaces. From raphael at gimp.org Tue Aug 26 09:10:35 2008 From: raphael at gimp.org (=?UTF-8?B?UmFwaGHDq2w=?= Quinet) Date: Tue, 26 Aug 2008 16:10:35 +0200 Subject: [crossfire] Handling of "Created" and "Modified" info in map headers In-Reply-To: <48B38B50.5020109@sonic.net> References: <20080825203946.62e417a0.raphael@gimp.org> <48B38B50.5020109@sonic.net> Message-ID: <20080826161035.4b99acc6.raphael@gimp.org> On Mon, 25 Aug 2008 21:49:20 -0700, Mark Wedel wrote: > As I'm thinking about this more, I'm more tempted that all editors should > really just do 'Modified: $Id$', and let svn/cvs/whatever deal with that last > modified date. This actually works better because any checkin has to have a > real name/e-mail addressed to it. Or maybe put in another field like ID: which > has that info. I think that it is still useful to have both the "Created" line and at least one "Modified" line. And as I said in my previous message, I would even prefer a full history of "Modified" fields. [...] > I'm also not sure if the map header should really duplicate material that is > found in SVN (which the modified field info is). The created file is different, > because who created the map vs who checked it in originally can certainly be > different. So I'd still be tempted to have only the most recent Modified field, > or perhaps none at all - none of the other source files do. > > I sort of suspect the reason that the maps do have that modified fields is > because at some point, they predated version control and at that time, there was > some desire to track that info. Probably. But even with SVN, there is some information that may be lost when a map is submitted as a patch by someone who doesn't have SVN access. I do not have this problem because I can commit my changes directly in SVN but those who contribute new maps or map updates as patches may have strong feelings about that. If an external contributor submits a map (with her name in a "Modified" field), this is currently discarded by gridarta if the one who commits the map in SVN edits the map before the commit. The information about the original author of the patch may or may not be included in the commit message depending on whether the committer does his job correctly or not, but in any case it will be gone from the map itself. Also, I don't think that relying only on the version control system that we use is the best solution. For instance, remember that some historical information was lost during the migration from CVS to SVN. Besides, those who get the maps or other parts of crossfire from a tarball or via a pre-built package in their distribution may not have easy access to the SVN logs to see who modified what and when. Now that I think about it, the maps are distributed with the GPL version 2, and section 2.a of the GPLv2 requires all files to carry a notice stating who changed the files and when. The GPLv3 and AGPLv3 have the same requirement in section 5.a and state clearly in section 4 that all previous notices must be kept intact (this was also mentioned in section 1 of the GPLv2 that we are using, although not as clearly). Most files in the server or client source code start with our standard header assigning the copyright to you and the "Crossfire Development Team". This is fine for the source code, but this copyright notice is currently absent from the maps. And even if it was added to all maps, I don't think that it would be appropriate to simply credit the "Crossfire Development Team" for the maps (and to some extent, for the archetypes) because we accepted many significant contributions coming from people who are not developers. So I think that it would be more appropriate to credit them individually. Or to be more precise, if they did add their own name in the map header, then I don't think that it is appropriate to remove it, according to the license that we use. Yesterday I asked about opinions regarding how to handle the "Modified" headers as a matter of personal preferences, but after having considered the GPL and the potential copyright issues with external contributors, I think that it is not just a matter of personal preferences anymore... -Rapha?l From mwedel at sonic.net Wed Aug 27 00:18:33 2008 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 26 Aug 2008 22:18:33 -0700 Subject: [crossfire] Handling of "Created" and "Modified" info in map headers In-Reply-To: <20080826161035.4b99acc6.raphael@gimp.org> References: <20080825203946.62e417a0.raphael@gimp.org> <48B38B50.5020109@sonic.net> <20080826161035.4b99acc6.raphael@gimp.org> Message-ID: <48B4E3A9.3060401@sonic.net> I think there are several different issues we're talking about. If we're talking about giving developers credit, and using the modified field, it may be reasonable to do so. Note that I don't believe 2a of the license applies in the maps in the context you indicate. From my reading, 2a covers the case if someone else branches crossfire and makes changes they need to properly record the differences they have modified them and in what way. I don't read it that the files in the original file have to have that complete change history. And should we even discuss the arch files, we don't have any copyright notice or change notice? I would almost say those are more problematic as those are more likely to be new work. A concern I do have with listing all the modified history in map files is that at some point, for some maps, that could get pretty unwieldy if it is trying to be used as a change log history. That is because for changelog purposes, you wouldn't just keep that last entry, but all of them. So something like: Modified: Mark Wedel, 2008-08-25 Modified: Mark Wedel, 2008-08-21 Modified: Rick Tanner, 2008-08-16 Modified: Mark Wedel, 2008-08-01 .... And could create a very long list (I just look at one map and it had 40+ commits on it over its lifetime). So while this may not be a problem that shows up very quickly, it is certainly something that should be thought about - how long a list is too long? My point about adding in $Id$ strings is that provides a totally clear view of the map having troubles, or what map a patch was made against. It is marginally simpler than having to look at the modified dates and then figure out if the map has been fixed. As for access to source system - that doesn't really make a difference - folks making patches will start from some base, and that would hopefully get included in the diff (maybe the editor should empty the $Id$ string?). For folks running server from tar balls, the maps would still contain revision information, which would likely make tracking down bugs easier (map R9821 has this problem - pretty simple to check if that is the latest). A list of Modified fields doesn't really convey to that user much more information, other than last time the map was modified, unless I have some other reference (like I did a svn update last night, and that modified date is fairly recent, so probably a fairly recent change broke it). But that is really by the date, not by who modified it ($Id$ strings contain date as a note) All that said, if some number of Modified: fields were listed, wouldn't bother me that much. But then if done, I think we might also want to clarify what would be appropriate data there - having a name that one can't associate with anyone in a real basis doesn't add much either. From raphael at gimp.org Wed Aug 27 08:33:41 2008 From: raphael at gimp.org (=?UTF-8?B?UmFwaGHDq2w=?= Quinet) Date: Wed, 27 Aug 2008 15:33:41 +0200 Subject: [crossfire] Handling of "Created" and "Modified" info in map headers In-Reply-To: <48B4E3A9.3060401@sonic.net> References: <20080825203946.62e417a0.raphael@gimp.org> <48B38B50.5020109@sonic.net> <20080826161035.4b99acc6.raphael@gimp.org> <48B4E3A9.3060401@sonic.net> Message-ID: <20080827153341.8c9bde50.raphael@gimp.org> On Tue, 26 Aug 2008 22:18:33 -0700, Mark Wedel wrote: > > I think there are several different issues we're talking about. > > If we're talking about giving developers credit, and using the modified field, > it may be reasonable to do so. Yes, that's what I am now talking about: having proper copyright attributions in the map files. Knowing the map version and modification date is also useful, but is less important than respecting copyright IMHO. > Note that I don't believe 2a of the license applies in the maps in the context > you indicate. From my reading, 2a covers the case if someone else branches > crossfire and makes changes they need to properly record the differences they > have modified them and in what way. I don't read it that the files in the > original file have to have that complete change history. Anyone who modifies any file (such as a map) is producing a modified version of crossire. The GPL allows anyone to modify the files and use them privately without any restrictions. However, if that code is given to others (which includes sending the modified version to us), then the requirements of the GPL apply. This is explained in the FAQ: http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLRequireSourcePostedPublic According to section 2a of the GPLv2, the one who modified the file (and holds the copyright on the modifications) must then state that the file was changed and when. If we accept this modified version and redistribute it, then section 1 of the GPLv2 requires us to keep intact all copyright notices. Again, the GPLv3 explains this more clearly in sections 4 and 5 than the GPLv2 in sections 1 and 2, but the intent is the same. Note that if someone submits only a small patch, then including it in our distribution can be considered as "fair use". In that case, we are not bound by the license and the requirement to keep the copyright notices. But for any non-trivial patch, I think that it is clear that we should keep the copyright notices in the modified files (e.g., in map headers). The following items in the GPL FAQ are also relevant for the copyright requirements and "fair use": http://www.fsf.org/licensing/licenses/gpl-faq.html#RequiredToClaimCopyright http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLFairUse With that in mind, I think that it would be more appropriate for map editors to append "Modified" fields in the map header instead of keeping only the first one. Or at least, if the editor doesn't append such a thing automatically, then it should never remove nor replace existing "Modified" fields. Another way to solve this problem would be to use different fields for different purposes. We could have an "Id:" field or "Last-Modified:" field that is automatically updated and may contain $Id$ or $Revision$ for SVN. And we could have an optional "Modified:" field or maybe "Copyright:" that is _not_ updated automatically and requires some user action to decide if their changes are worth a copyright notice. Requiring some user action (such as selecting "Add modification notice" or "Add log entry" in some menu of the editor) would avoid the problem of having too many entries if only minor changes are made. Again, I am now more worried about respecting copyright than tracking map versions. But for the latter, most problems can be solved by having a separate, automatically updated field for tracking the last revision number (for those who have SVN access) and/or modification date (for those who don't have SVN access). > And should we even discuss the arch files, we don't have any copyright notice > or change notice? I would almost say those are more problematic as those are > more likely to be new work. Well, there is the top-level CHANGES file, but there is nothing in the individual files and I agree that archetypes are more problematic. I think that most people who contributed archetypes expected them to be covered by the same license as other parts of crossfire (GPL). By the way, that CHANGES file should be replaced by a proper ChangeLog using the standard ChangeLog format. But that's another topic... [...] > All that said, if some number of Modified: fields were listed, wouldn't bother > me that much. But then if done, I think we might also want to clarify what > would be appropriate data there - having a name that one can't associate with > anyone in a real basis doesn't add much either. Well, it doesn't really matter. It could be some user id, a real name, an e-mail address, a company name or anything that the copyright holder considers appropriate for identifying themselves. So it would be fine for me to have things like that: Created: 1999-12-31 J. Random Hacker Modified: 2000-01-01 somebody at example.org Modified: 2008-08-27 The Crossfire Development Team Modified: 2038-01-19 mwedel We could also rename all these lines "Copyright:" if we want to make it clear that they are more useful for copyright tracking than for knowing the version or modification date of the map. Although there may be some value in having separate entries for the original creator and for subsequent modifications. -Rapha?l From mwedel at sonic.net Thu Aug 28 02:03:56 2008 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 28 Aug 2008 00:03:56 -0700 Subject: [crossfire] spell rebalancing Message-ID: <48B64DDC.9060506@sonic.net> I'm doing some more work on spell rebalancing. While giving first level character cone and bullet spells isn't a bad start, trying to do much with it is pretty frustrating. To help things out, I give characters a first level aura spell. It doesn't do much damage (1 hp/tick), but aura spells hit all spaces around the player, so does a pretty good job with a group of monsters _if_ you're willing to wander into the middle of them. For a first level mage, wandering into the middle of low level creatures is still a pretty fast way to die, so this does amount more to sitting in doorways and hitting them with the bold spells until numbers are reasonable. One problem is that it also hits friendly creatures, so when I got to the top level of the mad mages tower, his bodyguard promptly killed me. I think just to make the spell more useful in both parties and not to aggravate friendly creatures, it probably shouldn't damage them. I also need to tweak the destruction logic a bit - a huge amount of gear is burned up - this actually created a food shortage at some point. In the end, the character got to second level in about the same amount of time as a fighter took, and there really wasn't much sitting around for sp to regain - I made the aura pretty long lasting, so that doesn't need to be recast much. I'd probably say there wasn't any more sitting around waiting for mana regen than a fighter spends for hp regen. I do need to test further. One thing I would like to do, especially given that more layers of information is supported, is somehow include that information (this could be useful for lots of things, like protection spells could have some type of overlay to make it cleaer that character is affected, etc) I've also thought a bit about spells. One goal is to try to reduce the number some - fewer spells means fewer things that need adjusting. for things like the bolt & cone, different sized versions likely are not needed - if the size scales up with level, that should be fine. I'm also pondering a different change - rather than to try and scale up damage to keep up at higher levels, instead decrease casting time and keep mana cost the same. So rather than hitting creatures with more potent spells, you're just hitting them with more spells faster (character mana goes up, so a character that might only be able to cast 5 at first level could cast 10 and 5th level before mana is expended). I'll have to play with that more.