From nicolas.weeger at laposte.net Tue Jul 15 15:03:23 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 15 Jul 2008 22:03:23 +0200 Subject: [crossfire] Things to fix In-Reply-To: <8700.1212594700@sonic.net> References: <8700.1212594700@sonic.net> Message-ID: <200807152203.26839.nicolas.weeger@laposte.net> > > The combat rebalance needs to be finished. Mark, how can we help you > > on that? > > Also, do people have comments about the current hand to hand combat > > rebalance? > > Can be seen on the Ailesse servers (one permadeath, the other non > > permadeath). > > What about general item/monster fixing/balance? > > I plan to start working on that once I get back from vacation in another > week and a half or so. Excuse the mistakes - Austrian kezboards have the > kezs in the wrong places... So, can we expect anything before the end of the millenium? :) Anything we can help? IMO, once combat is rebalanced, even if imperfectly, we should forget about branch except for critical bugfixes. Trunk should become stable, someday! 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/20080715/fa7bd3d6/attachment.pgp From raphael at gimp.org Wed Jul 16 11:09:05 2008 From: raphael at gimp.org (=?UTF-8?B?UmFwaGHDq2w=?= Quinet) Date: Wed, 16 Jul 2008 18:09:05 +0200 Subject: [crossfire] Importing the GTK+ editor in SVN Message-ID: <20080716180905.4fda19ec.raphael@gimp.org> Hi, I would like to contribute several improvements to the GTK+ editor "gcrossedit" (a.k.a. "gce", now "gde"). This editor was created as part of the CFplus project (now Deliantra). Unfortunately, although the editor itself works fine with both projects, it depends on some libraries that have stopped supporting crossfire a few months ago. The main author of the editor (elmex) said that he did not have time to improve it anymore and that I was free to work on it. After checking with the developers of the libraries to see if the support for the original crossfire server could be restored, I was told that the support for crossfire would not be restored in deliantra, and forking the code was the best option. I try to avoid forking as much as possible, but in this case this was the only option offered. So... I would like to add a new module in SVN, called "editor" or "gcrossedit" or whatever you think is appropriate. I would populate its trunk using the following steps: 1) Start with a pristine copy of the code from deliantra CVS before the compatibility with crossfire was removed. I have such a copy and it can be re-obtained easily by using a sticky date in the CVS checkout, then renaming a few files and directories. Commit that in SVN as the first revision. (This way of doing it assumes that we are not interested in importing the full history from CVS, but only have a stable reference point.) 2) Merge some selected bug fixes that were applied in their CVS tree in the last months (after the support for crossfire was dropped). I had a look at the CVS history of the files that are relevant for the editor, and there are only 4 or 5 changes that should be merged (and they are not very important). Commit the result in SVN to obtain something equivalent to the current state of the editor. 3) Add some of the improvements that I have started working on, such as a better guidance for the first time you start the editor (so that it can easily find the maps and archetypes) and improvements to the user interface, giving more visual feedback to the user about what is the current "mode" of the editor (pick, place, connect, select...). 4) Other improvements that I have planned but not started working on yet: better display of connected values for complex maps, improved search & replace of objects in a selected area, user guide, etc. I already mentioned on IRC some of the reasons why I think that this editor is interesting: it is fast (e.g., drawing walls or other features on a large map is much faster than with gridarta), it has a nice way to display the properties of all map objects as you move the mouse around, it has less installation dependencies than gridarta, etc. However, the current version also has some drawbacks: it is likely to fail with a confusing error message the first time you start it, the user interface has many features and shortcuts that are a bit hidden (such as the absence of visible scrollbars), there is no "main" window, etc. That's why I would like to work a bit on that, and especially improve the experience for first-time users. If there are no objections against this plan, I would like to import the code in SVN as soon as possible. -Rapha?l From subs at eracc.com Wed Jul 16 13:26:18 2008 From: subs at eracc.com (ERACC Subscriptions) Date: Wed, 16 Jul 2008 13:26:18 -0500 Subject: [crossfire] Importing the GTK+ editor in SVN In-Reply-To: <20080716180905.4fda19ec.raphael@gimp.org> References: <20080716180905.4fda19ec.raphael@gimp.org> Message-ID: <200807161326.20504.subs@eracc.com> On Wednesday 16 July 2008 Rapha?l Quinet wrote: [...] > I already mentioned on IRC some of the reasons why I think that this > editor is interesting: it is fast (e.g., drawing walls or other > features on a large map is much faster than with gridarta), it has a > nice way to display the properties of all map objects as you move the > mouse around, it has less installation dependencies than gridarta, > etc. ?However, the current version also has some drawbacks: it is > likely to fail with a confusing error message the first time you start > it, the user interface has many features and shortcuts that are a bit > hidden (such as the absence of visible scrollbars), there is no "main" > window, etc. ?That's why I would like to work a bit on that, and > especially improve the experience for first-time users. > > If there are no objections against this plan, I would like to import > the code in SVN as soon as possible. Sounds good to me. Having more editors is not bad as long as there are folks willing to support them. Gene Alexander -- ERA Computers & Consulting Preloaded computers - eComStation, Linux and Unix Voice messages: 1(731)256-0973 - FAX & Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] From lauwenmark at ailesse.com Wed Jul 16 13:12:15 2008 From: lauwenmark at ailesse.com (Yann Chachkoff) Date: Wed, 16 Jul 2008 20:12:15 +0200 Subject: [crossfire] Importing the GTK+ editor in SVN In-Reply-To: <20080716180905.4fda19ec.raphael@gimp.org> References: <20080716180905.4fda19ec.raphael@gimp.org> Message-ID: <200807162012.16228.lauwenmark@ailesse.com> Le Wednesday 16 July 2008 18:09:05 Rapha?l Quinet, vous avez ?crit?: I think I have already stated my main objection to this on IRC as well, but I'll retype it here. I'm not convinced at all that this is a good move, as it is basically *another* resource splitting and duplication of work. I'm also questioning the value of the advantages it would bring. Taking them one by one: > it is fast (e.g., drawing walls or other features on a large map is much faster than with gridarta) > Wouldn't it be more productive to work on improving Gridarta's speed where it is perceived as an issue, instead of importing a whole new project and having to learn and maintain another large chunk of code ? > it has a nice way to display the properties of all map objects as you move the mouse around > Again, any reason why this couldn't be implemented in Gridarta ? > it has less installation dependencies than gridarta, > Wrong. It depends on GTK and Perl. Gridarta depends on 1.6 JRE. I don't see how it would in any way imply "less dependencies". Besides that, it introduces yet another language (Perl) which is by far not the easiest one to maintain (Does "Write-Only Language" sound familiar ? :) ). > If there are no objections against this plan, I would like to import > the code in SVN as soon as possible. > You got my objection. Gridarta has enjoyed a long-time support, includes many useful features, and shares a great deal of code between its Dai and CF sides ensuring a larger community support. I see no point in replacing all this (or worse, duplicating it) just for a couple of features that could as well be integrated into the existing editor, coming from a codebase Just my 2?. ---- Y. Chachkoff From raphael at gimp.org Wed Jul 16 14:53:42 2008 From: raphael at gimp.org (=?UTF-8?B?UmFwaGHDq2w=?= Quinet) Date: Wed, 16 Jul 2008 21:53:42 +0200 Subject: [crossfire] Importing the GTK+ editor in SVN In-Reply-To: <200807162012.16228.lauwenmark@ailesse.com> References: <20080716180905.4fda19ec.raphael@gimp.org> <200807162012.16228.lauwenmark@ailesse.com> Message-ID: <20080716215342.06562ffc.raphael@gimp.org> On Wed, 16 Jul 2008 20:12:15 +0200, Yann Chachkoff wrote: > > it is fast (e.g., drawing walls or other features on a large map is much > faster than with gridarta) > > > Wouldn't it be more productive to work on improving Gridarta's speed where it > is perceived as an issue, instead of importing a whole new project and having > to learn and maintain another large chunk of code ? Well, there are two things that I can reply to that: - A part of the speed difference is probably due to coding issues and it may be possible to improve gridarta from that point of view. But another part is due to a different design of the user interface. So it's a difference in the process of editing the map, and I am not sure that those who are familiar with gridarta now would like to have the user interface redesigned. For instance, gcrossedit has different editing modes that control what the mouse pointer does. When you are in "Place" mode (to add some items to the map), you can "paint" the map with walls very quickly. With gridarta, you use keyboard modifiers or mouse buttons to select the action that you want to perform, instead of having a concept of "modes" or "tools". This is useful in some cases, but in the end you need many more mouse clicks to place a large number of walls or floors in a map. - Nobody is forced to "learn and maintain another large chunk of code". Those who are interested in it are welcome to contribute, but those who aren't interested can focus on other parts of crossfire. I will be the initial maintainer. If I am hit by a truck tomorrow and nobody else wants to work with that code, then that's fine: it will slowly rot and maybe become irrelevant after a while, but it will still be usable by those who want to use it, just like the old X11 crossedit has survived for many years. Hmm... and a third thing: the code for gcrossedit is probably smaller than you think. The support libraries have a total of about 10k lines of code, and we could probably remove half of them if we don't want to support the client-server protocol or the deliantra extensions. The editor itself is less than 5k lines of code. For comparison, the current crossfire server has 30k lines of C code in the "common" directory, 50k lines in the "server" directory, and so on for a total of more than 160k lines of C code, Python code, Perl code and Makefiles. So the code for gcrossedit is relatively small. > > it has a nice way to display the properties of all map objects as you move > the mouse around > > > Again, any reason why this couldn't be implemented in Gridarta ? That could be a nice addition to Gridarta. I never said that it could not be implemented also in Gridarta. I was simply pointing out that this feature is nice and it exists today in gcrossedit. > > it has less installation dependencies than gridarta, > > > Wrong. It depends on GTK and Perl. Gridarta depends on 1.6 JRE. I don't see > how it would in any way imply "less dependencies". Sorry, I should have said "it has less dependencies for Free Software users". Gridarta depends on the Sun JRE 6, which is currently non-free. I know that many users do not care about the details of the license, but I do. Fortunately, the JRE will soon be really free, but we still have to wait a bit. Also, regarding version 6, there is no package for it in the default Debian stable distribution (etch), only in testing or unstable. This is the same for most Linux distributions released last year (not all users run the latest and greatest). Or to put it simply: if you consider the most popular Linux distribution (Ubuntu) and install its default selection of packages, you will have Perl and GTK+, but you will not have a version of Java that can run Gridarta. Anyway, maybe we are both right regarding the dependencies - but we have different sets of users in mind. > Besides that, it introduces yet another language (Perl) which is by far not > the easiest one to maintain (Does "Write-Only Language" sound familiar ? :) ). I agree that Perl can be a nightmare to maintain if the code is not well structured. But it is not a new language for Crossfire. There is still more than a dozen Perl scripts in the server code, including the often used 'collect.pl' script. On the other hand, Java is not used anywhere in Crossfire, so it could be argued that Gridarta is the one using "yet another language". But I don't want to argue about languages. As I said above, those who are not interested in maintaining that editor do not even have to look at it. -Rapha?l From agschult at ucalgary.ca Wed Jul 16 15:16:02 2008 From: agschult at ucalgary.ca (Alex Schultz) Date: Wed, 16 Jul 2008 14:16:02 -0600 Subject: [crossfire] Importing the GTK+ editor in SVN In-Reply-To: <20080716215342.06562ffc.raphael@gimp.org> References: <20080716180905.4fda19ec.raphael@gimp.org> <200807162012.16228.lauwenmark@ailesse.com> <20080716215342.06562ffc.raphael@gimp.org> Message-ID: <20080716141602.34a91b64@alzerion> On Wed, 16 Jul 2008 21:53:42 +0200 Rapha?l Quinet wrote: > > > it has less installation dependencies than gridarta, > > > > > Wrong. It depends on GTK and Perl. Gridarta depends on 1.6 JRE. I > > don't see how it would in any way imply "less dependencies". > > Sorry, I should have said "it has less dependencies for Free Software > users". Gridarta depends on the Sun JRE 6, which is currently > non-free. I know that many users do not care about the details of the > license, but I do. Fortunately, the JRE will soon be really free, but > we still have to wait a bit. Well, I'd like to note that actually, a Free Software Java 6 JRE does exist today in the form of IcedTea6. It is available in Ubuntu (see http://packages.ubuntu.com/hardy/interpreters/openjdk-6-jre) and Fedora. I've been using IcedTea6 myself for little while and have had no issues including in usage with Gridarta (in fact, memory consumption seems slightly lower for some reason but I'm not completely certain). In addition at least the Fedora build does pass Sun's Java Test Compatibility Kit. So in other words, we do actually have Free Java 6 today. As far as bringing another editor in, my stance is mostly neutral however I don't think it would do much good. Alex Schultz From leaf at real-time.com Wed Jul 16 15:40:32 2008 From: leaf at real-time.com (Rick Tanner) Date: Wed, 16 Jul 2008 15:40:32 -0500 Subject: [crossfire] Importing the GTK+ editor in SVN In-Reply-To: <20080716180905.4fda19ec.raphael@gimp.org> References: <20080716180905.4fda19ec.raphael@gimp.org> Message-ID: <487E5CC0.7070505@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A couple of questions: At what state of completion(?) is a user HOWTO manual for the map editor? I think an install HOWTO is probably the most critical, then followed by ~ a "user manual" (which is very important as well.) What about official releases? Is there a volunteer to manage those? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIflzAhHyvgBp+vH4RAoVgAJ9xDMmCYwV9SNSdw+hGw6A4snU81gCgpD/7 9/vfgZ3ABvo6YBa1Vgumqus= =vs5q -----END PGP SIGNATURE----- From mwedel at sonic.net Wed Jul 16 23:01:07 2008 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 16 Jul 2008 21:01:07 -0700 Subject: [crossfire] Importing the GTK+ editor in SVN In-Reply-To: <20080716180905.4fda19ec.raphael@gimp.org> References: <20080716180905.4fda19ec.raphael@gimp.org> Message-ID: <487EC403.8040001@sonic.net> I have no issues with it being added to part of SVN. I won't go over the different points raised in the conversation, but just some quick thoughts: - Within crossfire, there has never really been any standard set of programs that must be supported. So just the fact it gets added to SVN hardly means that all developers need to support it, and in fact, there are various pieces right now where that really is not the case. - If over time/through lack of support it does no longer work, it can always get removed. - It's impossible to force anyone to work on anything when folks are contributing their time freely. While there may be 'better' things to work on (and different people may have different ideas what should be worked on), getting them to do it may not be possible. If the user doesn't have any interest in working on that, it just won't happen. - With that above note, it means that all that crossfire can really limit is if it is in SVN or not. Raphael can continue to work on it in either case. And for that matter, could create another project on sourceforge to hold the editor. It's not clear to me that is any better than having it under the crossfire tree. Documentation stating is current state could be included. If other folks use it, it would seem worthwhile. From mwedel at sonic.net Thu Jul 17 00:07:43 2008 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 16 Jul 2008 22:07:43 -0700 Subject: [crossfire] Things to fix In-Reply-To: <200807152203.26839.nicolas.weeger@laposte.net> References: <8700.1212594700@sonic.net> <200807152203.26839.nicolas.weeger@laposte.net> Message-ID: <487ED39F.1050500@sonic.net> Nicolas Weeger wrote: >>> The combat rebalance needs to be finished. Mark, how can we help you >>> on that? >>> Also, do people have comments about the current hand to hand combat >>> rebalance? >>> Can be seen on the Ailesse servers (one permadeath, the other non >>> permadeath). >>> What about general item/monster fixing/balance? >> I plan to start working on that once I get back from vacation in another >> week and a half or so. Excuse the mistakes - Austrian kezboards have the >> kezs in the wrong places... > > So, can we expect anything before the end of the millenium? :) Maybe even by the end of the decade :) > Anything we can help? If folks find areas that need balancing working, knowing about them is useful. The main things I know about are spells and higher level monsters. > > IMO, once combat is rebalanced, even if imperfectly, we should forget about > branch except for critical bugfixes. Trunk should become stable, someday! Yes - most likely. But it also depends if other incompatible changes (within the trunk) are likely to happen. From kbulgrien at worldnet.att.net Thu Jul 17 00:45:43 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu, 17 Jul 2008 00:45:43 -0500 Subject: [crossfire] Importing the GTK+ editor in SVN In-Reply-To: <20080716180905.4fda19ec.raphael@gimp.org> References: <20080716180905.4fda19ec.raphael@gimp.org> Message-ID: <200807170045.43908.kbulgrien@worldnet.att.net> > Hi, > > I would like to contribute several improvements to the GTK+ editor > "gcrossedit" (a.k.a. "gce", now "gde"). Whereas the issue of having parallel clients is to me not a problem, there seems some greater advantage to have a unified editor, but, so long as both are maintained at a high degree of compatibility with the server, I see no reason not to accept CF "friendly" projects where there is a party interested in maintaining it. There seems little point to me to murmur about diluting efforts. People will always work on what interests them, and not necessarily what someone else wants them to work on. Though my CF development time has dried up at the moment, I'd have more inclination to work on a non-Java editor due to where skills lay - not that I particularly have a problem with Java save that it would be a new learning curve when one has already climbed much of steeper parts of the C/GTK curve. And, in real life, I use C, but Java as yet has not entered my particular work environment, and I prefer to leverage hobby/work cross-pollenation. Also noted that getting the tool chain configured to build Gridarta and JXClient was an ordeal I would not wish on anyone. For the experienced Javanator, I am sure it would not be, but we aren't all in that camp. Besides a client uses GTK and uses a tool chain that is common with this editor, and whatever one feels about perl, it is still a broadly used tool. In all, pulling a hard line on having only one editor is not something I want to do. > If there are no objections against this plan, I would like to import > the code in SVN as soon as possible. None here, though a nod is given to some of the arguments against. > -Rapha?l From kbulgrien at worldnet.att.net Thu Jul 17 00:52:02 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu, 17 Jul 2008 00:52:02 -0500 Subject: [crossfire] GTK V2 Client (libglade) Release Message-ID: <200807170052.02249.kbulgrien@worldnet.att.net> Speaking of releases... It sure would be nice to see the libglade client packaged up after spending all that time working on it and debugging it. The original GTK V2 client was released far sooner and buggier. Another two cents that's not worth much in a free project, is that a client release would be a heck of a lot easier and faster than rebalancing, albeit not as much fun for the releaser. I've already toyed around a bit with glade3 and the client layouts. with thoughts of resuming development some time. No reason to artificially keep that client out of distribution. I'm not ready to start using the other client. Kevin Bulgrien From raphael at gimp.org Thu Jul 17 04:18:35 2008 From: raphael at gimp.org (=?UTF-8?B?UmFwaGHDq2w=?= Quinet) Date: Thu, 17 Jul 2008 11:18:35 +0200 Subject: [crossfire] Importing the GTK+ editor in SVN In-Reply-To: <487E5CC0.7070505@real-time.com> References: <20080716180905.4fda19ec.raphael@gimp.org> <487E5CC0.7070505@real-time.com> Message-ID: <20080717111835.c83bc232.raphael@gimp.org> On Wed, 16 Jul 2008 15:40:32 -0500, Rick Tanner wrote: > A couple of questions: > > At what state of completion(?) is a user HOWTO manual for the map editor? As I said in a previous message, the current code is not very friendly to first-time users. Although there is a tutorial available on the web (http://www.deliantra.net/editor_tut.html) explaining how to set up the editor and start editing your first maps, I think that some of these instructions should be part of the source tree. So although that web page provides some material that could be used as a starting point for creating a HOWTO, there isn't one yet in the package. > I think an install HOWTO is probably the most critical, then followed by > ~ a "user manual" (which is very important as well.) I agree. Like in other free software projects, I am planning to add two files at the top of the source tree: INSTALL (describing how to build and install the stuff) and HACKING (giving recommendations to whoever wants to contribute). Currently, there is not even a README. Note that building it is not very difficult. Basically, you do: perl Makefile.PL && make && make install You can also add PREFIX=/some/path to change the default installation path. But the INSTALL file should explain more than that: it should list the dependencies and explain how to install them if they are missing, give advice about where to install the editor, etc. Also, building the editor is one thing, but you also have to run it. The current version requires that you set the environment variable CROSSFIRE_LIBDIR at least for the first time you start it. This something that I would like to change so that the initial start would be a bit more user-friendly. > What about official releases? > Is there a volunteer to manage those? Well, I guess that I will be the first volunteer. Making a source code release is easy. I don't know what to do about the Windows binary releases, though. The Deliantra guys provide a package for Windows users, but currently I don't have the tools for doing that myself. -Rapha?l From raphael at gimp.org Thu Jul 17 04:34:13 2008 From: raphael at gimp.org (=?UTF-8?B?UmFwaGHDq2w=?= Quinet) Date: Thu, 17 Jul 2008 11:34:13 +0200 Subject: [crossfire] Importing the GTK+ editor in SVN In-Reply-To: <487EC403.8040001@sonic.net> References: <20080716180905.4fda19ec.raphael@gimp.org> <487EC403.8040001@sonic.net> Message-ID: <20080717113413.b42f1d6d.raphael@gimp.org> On Wed, 16 Jul 2008 21:01:07 -0700, Mark Wedel wrote: > I have no issues with it being added to part of SVN. Thanks! [...] > - With that above note, it means that all that crossfire can really limit is if > it is in SVN or not. Raphael can continue to work on it in either case. And > for that matter, could create another project on sourceforge to hold the editor. Exactly. I was surprised by some of the previous comments questioning if we need a new editor. But this is not a new editor: it has existed since several years (although not very visible due to the tension caused by the CFplus project). The code is only looking for a new home after its current maintainers have confirmed that the only option for restoring the support for the original crossfire (broken a few months ago) is to fork the libraries used by the editor. So question is not about whether it should exist or not, but whether it should be imported in the crossfire SVN tree or if a new project should be started in sourceforge or elsewhere. I think that the first option is much better, that's why I asked. -Rapha?l From anmaster at tele2.se Thu Jul 17 12:13:49 2008 From: anmaster at tele2.se (AnMaster) Date: Thu, 17 Jul 2008 19:13:49 +0200 Subject: [crossfire] GTK V2 Client (libglade) Release In-Reply-To: <200807170052.02249.kbulgrien@worldnet.att.net> References: <200807170052.02249.kbulgrien@worldnet.att.net> Message-ID: <487F7DCD.5040004@tele2.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 This sounds nice, would this be a 2.0 client or a branch/1.x client? As far as I can see you are suggesting separate releases of server/maps/arch and client? Is that correct? I see no need to keep them synced apart from making sure last stable client and stable server work with each other. Regards, Arvid Norlander Kevin R. Bulgrien wrote: | Speaking of releases... It sure would be nice to see the libglade client | packaged up after spending all that time working on it and debugging it. | The original GTK V2 client was released far sooner and buggier. Another | two cents that's not worth much in a free project, is that a client | release would be a heck of a lot easier and faster than rebalancing, | albeit not as much fun for the releaser. | | I've already toyed around a bit with glade3 and the client layouts. | with thoughts of resuming development some time. No reason to | artificially keep that client out of distribution. I'm not | ready to start using the other client. | | Kevin Bulgrien -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEAREKAAYFAkh/fcsACgkQWmK6ng/aMNm9FQCfWiCIFS75nF9lBIx7BUancyCx Jh0An3s2rCmH1ioJYPB9F/oYkHl67w/7 =4iql -----END PGP SIGNATURE----- From nicolas.weeger at laposte.net Thu Jul 17 12:33:32 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 17 Jul 2008 19:33:32 +0200 Subject: [crossfire] Importing the GTK+ editor in SVN In-Reply-To: <20080716180905.4fda19ec.raphael@gimp.org> References: <20080716180905.4fda19ec.raphael@gimp.org> Message-ID: <200807171933.40329.nicolas.weeger@laposte.net> *sigh* if only the list could be so lively for content-related stuff... I globally agree with Yann. Also this is code no one here knows, it'll take a while to get into it, bla bla, but you do what you want with your time :) *goes back to his hole* -- 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/20080717/77157fc6/attachment.pgp From mwedel at sonic.net Thu Jul 17 23:34:05 2008 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 17 Jul 2008 21:34:05 -0700 Subject: [crossfire] GTK V2 Client (libglade) Release In-Reply-To: <200807170052.02249.kbulgrien@worldnet.att.net> References: <200807170052.02249.kbulgrien@worldnet.att.net> Message-ID: <48801D3D.3010004@sonic.net> Kevin R. Bulgrien wrote: > Speaking of releases... It sure would be nice to see the libglade client > packaged up after spending all that time working on it and debugging it. > The original GTK V2 client was released far sooner and buggier. Another > two cents that's not worth much in a free project, is that a client > release would be a heck of a lot easier and faster than rebalancing, > albeit not as much fun for the releaser. Since (except for the window binaries), I seem to the be sole releaser, on my wishlist would be more people willing to make releases. That said, it probably is about time for another 1.x release, even though not a huge amount of stuff has changed, but just to get it out there. And putting out a 2.x client is probably reasonable. Save for having other people do releases, next on my wish list would be for people to periodically try the release process (make archive from the top level dir - same place you run configure). If everything 'works', doing a release isn't that time consuming. But often, things don't work, and it then takes a considerable amount of time to track down the problems. Most common is new files getting added to SVN, but not the actual makefiles (things like header files, but could also be config files). From akirschbaum at users.sourceforge.net Fri Jul 18 15:03:33 2008 From: akirschbaum at users.sourceforge.net (Andreas Kirschbaum) Date: Fri, 18 Jul 2008 22:03:33 +0200 Subject: [crossfire] Importing the GTK+ editor in SVN In-Reply-To: <20080716180905.4fda19ec.raphael@gimp.org> References: <20080716180905.4fda19ec.raphael@gimp.org> Message-ID: <20080718200333.GA1165@localhost.localdomain> Hi, I am one of the founders of Gridarta and I still maintain the editor. So expect my viewpoint to be slightly biased ;) > I already mentioned on IRC some of the reasons why I think that this > editor [gce] is interesting: it is fast (e.g., drawing walls or other > features on a large map is much faster than with gridarta) It is known that Gridarta is quite slow on huge maps. The main reason is a less-than-optimal implementation of the undo stack. Fixing this would need a fair amount of work without having much effect for "real" maps: Crossfire maps generally should not grow too large; instead tiled maps should be used. Therefore I (still) consider fixing this issue a waste of time since more important features are pending. Besides that, my observation with gce was just the opposite: I did create a map with gce's default size (20x20 tiles). I hardly could edit this map because gce's display updates were sluggish at best: just moving around the mouse "cleared" the map view when the tooltip moved. I had to stop doing anything (including mouse movements) and wait 3-5(!) seconds until the map view was repainted and I could continue. The test was on the exact same machine that I use for Gridarta development and testing; gce is the version available for download on the Deliantra web site. > , it has a nice way to display the properties of all map objects as > you move the mouse around Yes, this is a nice feature; I plan to add a similar one to Gridarta. > , it has less installation dependencies than gridarta I just can agree with Yann here that this is not correct. Gridarta needs only Java 1.6; no other external libraries are needed. Building from source additionally needs ant. According to the download web site gce needs at least Perl, libgtk2, and libglib2. For the implicit "free software" meaning: OpenJDK is about to go into Linux distributions. Therefore it is not (anymore) an argument for me. Also, the argument (as stated in another mail in this thread) that map makers may want to use Debian stable, is not an argument: the gce download page states that libglib2.0-0 version 2.12.6-2 is needed; Debian stable has 2.12.4-2 only. Windows users can also use OpenJDK (I guess), or just download and install Sun's JRE to run Gridarta. Not sure how easy it is to get Perl (and GTK2) installed on a Windows machine. FYI: gcj fails to compile Gridarta because gcj does not comply to the Java Language Specification (apart for other issues in the class libraries). I filed a bug report more than four months ago [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35410]. It is still in state "NEW". > , etc. See below for a list of missing features. SCNR ;) > However, the current version also has some drawbacks: [...] All these drawbacks are just technical issues that can be fixed. Therefore these issues are not really arguments against the editor (for me). (Without actually having guessed how much work is needed to get them fixed.) > If there are no objections against this plan, I would like to import > the code in SVN as soon as possible. Given that Gridarta is still in active development (more than 4000 commits since the project start about two years ago), and having invested much time (I did more than half of all commits), I do object. My main reasons are: - We (Crossfire) do not have that many (active) developers. Therefore splitting these few into the maintainance of multiple helper-applications that basically do the same seems just a waste to me. We should rather focus on the game itself. With "game" I mean: in-game content, a decent client (which runs on Windows, Linux, and hopefully on Macs), and a stable server [roughly in this order], but definitely not the maintainance of redundant helper-applications. Also, the main reason why we (Christian Hujer, Daniel Viegas (both Daimonin developers), and me) did start the Gridarta project was to fight resource splitting: at that time there have been two projects, Crossfire and Daimonin (I'm ignoring Angelion because it did use the unmodified Daimonin editor). Both projects did use and maintain similar editors. Our idea was to join the developers of both projects to get more development power. The intended outcome is a (mostly) unified editor which shares most of the basic functionality but has special features needed by either project. For Crossfire this merge process already did pay off since I could take over many features from Daimonin to Crossfire. Besides that I got quite some (constructive) feedback from Daimonin map makers. That said, I think starting a new editor would basically mean to split off Crossfire from Gridarta: having an editor part of the project (IMO) declares it as the "official" Crossfire editor. Which in turn means we (the Crossfire developers) are at the same state as two years ago: two editors to maintain (crossedit+CFJavaEditor vs. gce+Gridarta) with just a hand-full of developers. - Gridarta includes a map validator module. It checks for common mistakes when creating or editing map files. It is enabled by default to prevent map makers from adding "bad" things to maps they create or modify. This safeguard will not anymore work reliably if some maps are created (or just modified) with a different editor lacking a (or featuring a different) map validator. - A while ago I modified Gridarta to write object attributes in map files in the same order as the Crossfire server. After that all map files got normalized to this format. The reason for this effort was to minimize the changesets when editing maps. Although a quick test did indicate that gce seems to use the same attribute ordering, it inevitably will break from time to time when new attributes are added. This means, we'll both get larger changesets than necessary, and we'll have to modify both editors in the same way to not loose this benefit. That said, I strongly vote for having just one "official" editor. Of course, we cannot dictate which editor a contributor wants to improve, but IMO the Crossfire project/developers should select one (and only one) "official" editor. Of course, I vote for Gridarta. ;) Just FYI, some of Gridarta's features which I didn't find in gce (and which are not at all "hidden" but easily accessible though menus in Gridarta): - Map Validator: checks maps for common mistakes. The checks are run automatically while editing but can be disabled by the map maker. - Pickmaps: allows a map maker to compose a set of related objects for quick access. The objects can have custom modifications and inventories. Pickmaps can be organized in folders. A possible use might be pickmaps defining walls and buildings used in different areas of the world. - Treasure Lists: Treasure lists can be displayed in a tree view and interactively explored. In the Game Object Attributes Dialog this viewer is used to select the desired treasure list. Map makers are prevented from using treasure lists used internally by the server (such as the god information lists). - Plugins: Gridarta includes a plugin interface via a scripting language (Beanshell). Scripts can access all of Gridarta's functionality. Currently existing scripts are: - LegacySpellConverter: a script I did write for converting spell numbers into spell objects in all map files. It checks the actual object type (including type modifications in map files) and therefore does not produce false-positives a simple search&replace would create. - MapNormalizer: load & save all map files. I did use this script to make sure all map files have a consistent file format. It has been run on all files in branch and trunk. - MapValidator: runs the map validator on a set of (or all) maps. The result can be written to a log file. - WorldMaker: creates an overview image of the world maps. Info/worldmap.png in the maps repository was created by this script. - Non-Rectangular Selections: Many functions (cut, copy, paste, fill, selection from pickmaps, shift, etc.) operate on the selected area. The selected area can have any shape; adding, removing, and flipping is supported. - Safeguards: Gridarta tries hard to prevent the map marker from loosing unsaved work. This includes prompting for unsaved maps, pickmaps, and scripts when closing windows or exiting the application. - Map Previews: the file selector dialog optionally displays preview images of the map files. This allows easy recognition of the map(s) the map maker wants to open. - Auto-Updater: when using a pre-built editor, map makers can update Gridarta via Help->Update. Additionally, Gridarta can automatically check for updates on startup. - Non-English user interface: many of Gridarta's text messages are translatable. Currently this includes German (all messages translated), Swedish (about half translated), and French (few translated). Adding more languages is very easy through text files. - Script Editor: Gridarta includes an editor for scripts. It supports syntax-highlighting for Python (and more file types not normally used in Crossfire maps). - Map View Filtering/Highlighting: the map view can hide and/or highlight different object types. For example only walls and monsters could be shown. Hidden objects are not affected by edit operations. Available filters are not hard-coded but read from a configuration file which allows easy customization. - Syntax Highlighting of msg...endmsg fields: for objects supporting @match, the text is colored. Incorrect expressions (such as upper-case characters) are highlighted. - Information Views: displays information about the current map. This information is updated in real-time reflecting the current map state. It includes connected objects, monsters, and map validation errors. - Map Views: one map file can be concurrently displayed in multiple map views. This is useful when editing connected objects in different parts of a larger map. - Zoom Tool: displays a map file with different scalings and allows to save the result as image files. It can be used by map makers to publish previews. - Recent menu: the file menu contains previously opened map files for easy re-access. - Archetype Collection: Gridarta can collect archetypes (i.e., do the same job as the collect.pl script). The created crossfire.0 file is slightly smaller than the collect.pl one. - Opening Multiple Maps: the file selector allows to open multiple maps. - Reload Faces: reload faces without restarting the editor; this simplifies the creation of new archetypes. (This feature is not yet unified and therefore available only in DaimoninEditor.) - Control Server: Gridarta can control (i.e., start and stop) the server and a client. This simplifies testing of maps without having to manually starting server and client and issuing 'reset commands. (This feature is not yet unified and therefore available only in DaimoninEditor.) From nicolas.weeger at laposte.net Sat Jul 19 10:36:09 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 19 Jul 2008 17:36:09 +0200 Subject: [crossfire] Importing the GTK+ editor in SVN In-Reply-To: <20080718200333.GA1165@localhost.localdomain> References: <20080716180905.4fda19ec.raphael@gimp.org> <20080718200333.GA1165@localhost.localdomain> Message-ID: <200807191736.13774.nicolas.weeger@laposte.net> I concur to the arguments :) (and frankly I have no plan to work on gce's code, I'd rather learn Java, given that Gridarta is much more advanced imo) Nicolas Le vendredi 18 juillet 2008, Andreas Kirschbaum a ?crit?: > Hi, > > I am one of the founders of Gridarta and I still maintain the editor. So > expect my viewpoint to be slightly biased ;) > > > I already mentioned on IRC some of the reasons why I think that this > > editor [gce] is interesting: it is fast (e.g., drawing walls or other > > features on a large map is much faster than with gridarta) > > It is known that Gridarta is quite slow on huge maps. The main reason is > a less-than-optimal implementation of the undo stack. Fixing this would > need a fair amount of work without having much effect for "real" maps: > Crossfire maps generally should not grow too large; instead tiled maps > should be used. Therefore I (still) consider fixing this issue a waste > of time since more important features are pending. > > Besides that, my observation with gce was just the opposite: I did > create a map with gce's default size (20x20 tiles). I hardly could edit > this map because gce's display updates were sluggish at best: just > moving around the mouse "cleared" the map view when the tooltip moved. I > had to stop doing anything (including mouse movements) and wait 3-5(!) > seconds until the map view was repainted and I could continue. > > The test was on the exact same machine that I use for Gridarta > development and testing; gce is the version available for download on > the Deliantra web site. > > > , it has a nice way to display the properties of all map objects as > > you move the mouse around > > Yes, this is a nice feature; I plan to add a similar one to Gridarta. > > > , it has less installation dependencies than gridarta > > I just can agree with Yann here that this is not correct. Gridarta needs > only Java 1.6; no other external libraries are needed. Building from > source additionally needs ant. According to the download web site gce > needs at least Perl, libgtk2, and libglib2. > > For the implicit "free software" meaning: OpenJDK is about to go into > Linux distributions. Therefore it is not (anymore) an argument for me. > > Also, the argument (as stated in another mail in this thread) that map > makers may want to use Debian stable, is not an argument: the gce > download page states that libglib2.0-0 version 2.12.6-2 is needed; > Debian stable has 2.12.4-2 only. > > Windows users can also use OpenJDK (I guess), or just download and > install Sun's JRE to run Gridarta. Not sure how easy it is to get Perl > (and GTK2) installed on a Windows machine. > > FYI: gcj fails to compile Gridarta because gcj does not comply to the > Java Language Specification (apart for other issues in the class > libraries). I filed a bug report more than four months ago > [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35410]. It is still in > state "NEW". > > > , etc. > > See below for a list of missing features. SCNR ;) > > > However, the current version also has some drawbacks: [...] > > All these drawbacks are just technical issues that can be fixed. > Therefore these issues are not really arguments against the editor (for > me). (Without actually having guessed how much work is needed to get > them fixed.) > > > If there are no objections against this plan, I would like to import > > the code in SVN as soon as possible. > > Given that Gridarta is still in active development (more than 4000 > commits since the project start about two years ago), and having > invested much time (I did more than half of all commits), I do object. > My main reasons are: > > - We (Crossfire) do not have that many (active) developers. Therefore > splitting these few into the maintainance of multiple > helper-applications that basically do the same seems just a waste to > me. We should rather focus on the game itself. > > With "game" I mean: in-game content, a decent client (which runs on > Windows, Linux, and hopefully on Macs), and a stable server [roughly > in this order], but definitely not the maintainance of redundant > helper-applications. > > Also, the main reason why we (Christian Hujer, Daniel Viegas (both > Daimonin developers), and me) did start the Gridarta project was to > fight resource splitting: at that time there have been two projects, > Crossfire and Daimonin (I'm ignoring Angelion because it did use the > unmodified Daimonin editor). Both projects did use and maintain > similar editors. > > Our idea was to join the developers of both projects to get more > development power. The intended outcome is a (mostly) unified editor > which shares most of the basic functionality but has special features > needed by either project. > > For Crossfire this merge process already did pay off since I could > take over many features from Daimonin to Crossfire. Besides that I got > quite some (constructive) feedback from Daimonin map makers. > > That said, I think starting a new editor would basically mean to split > off Crossfire from Gridarta: having an editor part of the project > (IMO) declares it as the "official" Crossfire editor. Which in turn > means we (the Crossfire developers) are at the same state as two years > ago: two editors to maintain (crossedit+CFJavaEditor vs. > gce+Gridarta) with just a hand-full of developers. > > - Gridarta includes a map validator module. It checks for common > mistakes when creating or editing map files. It is enabled by default > to prevent map makers from adding "bad" things to maps they create or > modify. > > This safeguard will not anymore work reliably if some maps are created > (or just modified) with a different editor lacking a (or featuring a > different) map validator. > > - A while ago I modified Gridarta to write object attributes in map > files in the same order as the Crossfire server. After that all map > files got normalized to this format. The reason for this effort was to > minimize the changesets when editing maps. > > Although a quick test did indicate that gce seems to use the same > attribute ordering, it inevitably will break from time to time when > new attributes are added. This means, we'll both get larger changesets > than necessary, and we'll have to modify both editors in the same way > to not loose this benefit. > > > That said, I strongly vote for having just one "official" editor. Of > course, we cannot dictate which editor a contributor wants to improve, > but IMO the Crossfire project/developers should select one (and only > one) "official" editor. > > Of course, I vote for Gridarta. ;) > > > Just FYI, some of Gridarta's features which I didn't find in gce (and > which are not at all "hidden" but easily accessible though menus in > Gridarta): > > - Map Validator: checks maps for common mistakes. The checks are run > automatically while editing but can be disabled by the map maker. > > - Pickmaps: allows a map maker to compose a set of related objects for > quick access. The objects can have custom modifications and > inventories. Pickmaps can be organized in folders. > > A possible use might be pickmaps defining walls and buildings used in > different areas of the world. > > - Treasure Lists: Treasure lists can be displayed in a tree view and > interactively explored. In the Game Object Attributes Dialog this > viewer is used to select the desired treasure list. Map makers are > prevented from using treasure lists used internally by the server > (such as the god information lists). > > - Plugins: Gridarta includes a plugin interface via a scripting language > (Beanshell). Scripts can access all of Gridarta's functionality. > > Currently existing scripts are: > > - LegacySpellConverter: a script I did write for converting spell > numbers into spell objects in all map files. It checks the actual > object type (including type modifications in map files) and > therefore does not produce false-positives a simple search&replace > would create. > > - MapNormalizer: load & save all map files. I did use this script to > make sure all map files have a consistent file format. It has been > run on all files in branch and trunk. > > - MapValidator: runs the map validator on a set of (or all) maps. The > result can be written to a log file. > > - WorldMaker: creates an overview image of the world maps. > Info/worldmap.png in the maps repository was created by this script. > > - Non-Rectangular Selections: Many functions (cut, copy, paste, fill, > selection from pickmaps, shift, etc.) operate on the selected area. > The selected area can have any shape; adding, removing, and flipping > is supported. > > - Safeguards: Gridarta tries hard to prevent the map marker from loosing > unsaved work. This includes prompting for unsaved maps, pickmaps, and > scripts when closing windows or exiting the application. > > - Map Previews: the file selector dialog optionally displays preview > images of the map files. This allows easy recognition of the map(s) > the map maker wants to open. > > - Auto-Updater: when using a pre-built editor, map makers can update > Gridarta via Help->Update. Additionally, Gridarta can automatically > check for updates on startup. > > - Non-English user interface: many of Gridarta's text messages are > translatable. Currently this includes German (all messages > translated), Swedish (about half translated), and French (few > translated). Adding more languages is very easy through text files. > > - Script Editor: Gridarta includes an editor for scripts. It supports > syntax-highlighting for Python (and more file types not normally used > in Crossfire maps). > > - Map View Filtering/Highlighting: the map view can hide and/or > highlight different object types. For example only walls and monsters > could be shown. Hidden objects are not affected by edit operations. > Available filters are not hard-coded but read from a configuration > file which allows easy customization. > > - Syntax Highlighting of msg...endmsg fields: for objects supporting > @match, the text is colored. Incorrect expressions (such as upper-case > characters) are highlighted. > > - Information Views: displays information about the current map. This > information is updated in real-time reflecting the current map state. > It includes connected objects, monsters, and map validation errors. > > - Map Views: one map file can be concurrently displayed in multiple map > views. This is useful when editing connected objects in different > parts of a larger map. > > - Zoom Tool: displays a map file with different scalings and allows to > save the result as image files. It can be used by map makers to > publish previews. > > - Recent menu: the file menu contains previously opened map files for > easy re-access. > > - Archetype Collection: Gridarta can collect archetypes (i.e., do the > same job as the collect.pl script). The created crossfire.0 file is > slightly smaller than the collect.pl one. > > - Opening Multiple Maps: the file selector allows to open multiple maps. > > - Reload Faces: reload faces without restarting the editor; this > simplifies the creation of new archetypes. (This feature is not yet > unified and therefore available only in DaimoninEditor.) > > - Control Server: Gridarta can control (i.e., start and stop) the server > and a client. This simplifies testing of maps without having to > manually starting server and client and issuing 'reset commands. (This > feature is not yet unified and therefore available only in > DaimoninEditor.) > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -- 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/20080719/2ad947a5/attachment-0001.pgp From raphael at gimp.org Sat Jul 19 14:57:35 2008 From: raphael at gimp.org (=?UTF-8?B?UmFwaGHDq2w=?= Quinet) Date: Sat, 19 Jul 2008 21:57:35 +0200 Subject: [crossfire] Importing the GTK+ editor in SVN In-Reply-To: <20080718200333.GA1165@localhost.localdomain> References: <20080716180905.4fda19ec.raphael@gimp.org> <20080718200333.GA1165@localhost.localdomain> Message-ID: <20080719215735.624b3fbb.raphael@gimp.org> On Fri, 18 Jul 2008 22:03:33 +0200, Andreas Kirschbaum wrote: > Hi, > > I am one of the founders of Gridarta and I still maintain the editor. So > expect my viewpoint to be slightly biased ;) Slightly, yes. :-) I don't think that it is necessary for me to reply to each sentence in detail. I will just say this: do you realize that what you have written can be summarized as "I have worked on solution X and it works, and there is already a lot of code written for it so I do not want to let others work on solution Y"? Of course, I am deliberately exagerating what you said, but it could be interpreted like that. By the same reasoning, Gridarta should not have existed, because there was already the old X11 crossedit. And if you argue specifically about using crossfire SVN, then again the same reasoning would have prevented jxclient from being included. Why include jxclient which had less features than the existing clients, especially when a lot of code was already written for the existing clients and they were actively maintained? Well, because some developers were interested in working on something different (in that case, a Java client). Although I have no interest in working on a Java client or editor (because I already write enough Java code at work and I am looking for something different in my spare time), I never argued that the Java client or editor should be somehow banned from crossfire SVN. > Also, the argument (as stated in another mail in this thread) that map > makers may want to use Debian stable, is not an argument: the gce > download page states that libglib2.0-0 version 2.12.6-2 is needed; > Debian stable has 2.12.4-2 only. Despite what is written on the gde download page, the version of gcrossedit that I have been using since last year works fine on Debian stable. Also, at least for the stable versions of the distributions that I use or have access to (Debian, Ubuntu, OpenSUSE, Novell SUSE Linux Enterprise Desktop and Fedora), the default installation of each of these distributions included Perl, glib and gtk+ as part of the pre- installed packages (no additional download or selection of non-standard packages). Note that the latest version of gde has added some dependencies on Perl modules that are not part of a default install, but these dependencies are not needed for gcrossedit so they will probably be removed soon. Besides, the code that I will put in SVN is forked from an earlier version of gcrossedit (before the compatibility with crossfire was removed). > Just FYI, some of Gridarta's features which I didn't find in gce (and > which are not at all "hidden" but easily accessible though menus in > Gridarta): [...] Thanks for the suggestions. It looks like you overlooked at least two of the existing features of gcrossedit, because they are very similar to what you described: multiple pickers that can be customized with lists of frequently used items, map validation and map normalization done by a separate script. But most of them sound interesting so they will be added to the TODO list. The only feature that I would probably not add is the auto-updater because I prefer to have that done via the native packaging system of the target platform. -Rapha?l From kbulgrien at worldnet.att.net Sun Jul 20 04:00:01 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sun, 20 Jul 2008 04:00:01 -0500 Subject: [crossfire] GTK V2 Client (libglade) Release In-Reply-To: <48801D3D.3010004@sonic.net> References: <200807170052.02249.kbulgrien@worldnet.att.net> <48801D3D.3010004@sonic.net> Message-ID: <200807200400.01263.kbulgrien@worldnet.att.net> > Save for having other people do releases, next on my wish list would be > for people to periodically try the release process (make archive from the > top level dir - same place you run configure). If everything 'works', > doing a release isn't that time consuming. > > But often, things don't work, and it then takes a considerable amount of > time to track down the problems. Most common is new files getting added to > SVN, but not the actual makefiles (things like header files, but could also > be config files). The client release procedure on the Wiki has been used as a model for testing the releasability of the trunk clients. A lot of time was spend fixing up various aspects of the release procedure including updates to configure.ac, various Makefile.am, crossfire-client.spec, etc.. To the best of my knowledge, there are no remaining issues. I was able to run the procedure start to finish, and wind up a full set of working RPMS on my Mandriva 2008.1 x86_64 system. Basically all the work is done. All someone has to do is run the procedure and upload tarballs and RPMs. Should any issues arise due to platform differences, I'm willing to help resolve issues as needed. Kevin Bulgrien From crossfire at ailesse.com Sun Jul 20 07:14:52 2008 From: crossfire at ailesse.com (Lauwenmark) Date: Sun, 20 Jul 2008 14:14:52 +0200 Subject: [crossfire] Importing the GTK+ editor in SVN In-Reply-To: <20080719215735.624b3fbb.raphael@gimp.org> References: <20080716180905.4fda19ec.raphael@gimp.org> <20080718200333.GA1165@localhost.localdomain> <20080719215735.624b3fbb.raphael@gimp.org> Message-ID: <200807201414.53190.crossfire@ailesse.com> Le Saturday 19 July 2008 21:57:35 Rapha?l Quinet, vous avez ?crit?: > Slightly, yes. :-) I don't think that it is necessary for me to > reply to each sentence in detail. I will just say this: do you realize > that what you have written can be summarized as "I have worked on > solution X and it works, and there is already a lot of code written > for it so I do not want to let others work on solution Y"? Of course, > I am deliberately exagerating what you said, but it could be interpreted > like that. > > By the same reasoning, Gridarta should not have existed, because there > was already the old X11 crossedit. > Yes, you are exagerating a bit. The Athena-based editor was unsatisfying at the technical level - one very good point raised back then was that it was impossible to easily port to Windows. > using crossfire SVN, then again the same reasoning would have prevented > jxclient from being included. Why include jxclient which had less > features than the existing clients, especially when a lot of code was > already written for the existing clients and they were actively > maintained? Well, because some developers were interested in working > on something different (in that case, a Java client). > No, not at all (and I'm well placed to know what I'm speaking about, since *I* was the one who initially wrote JXClient). The goal was not write a "Java client" - there was already such a project somewhere else on SourceForge. The long-term goal was to provide a client that was (1) portable and (2) provided a more immersive gaming experience without sacrificing playability. In fact, early work was actually performed towards an C, SDL-based client, which would have used the common codebase of the current C clients. This changed when it became obvious that the codebase was unnecessarily complex and cluttered; it was then easier for me to rewrite a possibly cleaner base from scratch than tackling the daunting task of cleaning up the mess. Back then, I cannot say that the clients were "actively maintained" - gcfclient had quite a lot of bugs, and the intend was clearly not to solve them, but rather to develop a GTK2/Gnome client to replace it. Moreover, the switch to Java came at about the time when work towards CF 2.0 started - so, it seemed rather logical to take the opportunity to break the historical continuity with the old clients, and propose a single solution based on a cleaner code base. That's why JXClient aimed at supporting only trunk, and I made no effort to make it work with branch. So no, the purpose was not to work on a "Java client" - the purpose was to work on "a better client", regardless of the technology used behind it. Use of a specific language never was part of the initial design requirements. I also question the goals pursued by the new editor - so far, the only solid one advanced seems to be: "get rid of Java". What makes me think so is that all the possible UI advantages it comes from were obviously never discussed with the Gridarta developers before this discussion (Ragnor may need to correct me on this); if they were the real, most important reason for the change, then I admit I'm quite surprized nobody ever asked for such important features to be included in Gridarta. > I never argued that the Java client or editor should > be somehow banned from crossfire SVN. > The Java editor is not part of the Crossfire SVN, so it is a question that has no meaning. Regarding the Java client, I again can answer: there was quite a strong opposition to it at first; however, I finally did include it in the SVN anyway. Why ? There are two main reasons for this: (1) Most of the critics summarized as: "I don't like Java"; (2) Nobody had anything better to put on the table. (1) was (and still is) an interesting philosophical point to discuss. However, Crossfire is not a philosophical project - it is a game one. Real, base questions are not things like: "Where do I stand on the metaphysical level", but rather: "Is the technology up to the task ?", "Is there any advantage using it ?", "Is there anything playing against using that ?". Back in the day, apart the all too predictable "Java is slow" (which has been proven false in the case of JXClient), no other technical point was underlined. (2) Adresses the "duplication" question - would have it been duplicated effort ? Was it sane to work in parallel with the "mainstream" client line ? The answer is that back then, there were no other development attempt to provide a different user interface, and nobody was very interested on working on this. The only other new client project at that time was the Gnome2 client, which was mostly developed without much - if any - dialog with the community regarding design decisions. So there was IMHO no duplication of efforts, since nobody else was ready to improve the UI of the existing client. Add to this that it was roughly the time when branch and trunk got separate, which further strengthened the idea of "making something new for the new game version", so to speak. > I never argued that the Java client or editor should > be somehow banned from crossfire SVN. > Yes, but you asked if there was any objection to your plan, while I never did, for the reasons stated above. > Despite what is written on the gde download page, the version of > gcrossedit that I have been using since last year works fine on Debian > stable. > So does Gridarta, as Sun's JDK/JRE works fine with Debian stable. As a side note, the JRE6 is available in the official etch backports, so installing it is not really an issue; actually, maybe I should document this on the ailesse web page for the sake of completeness. For the record: the ailesse Gridarta daily builds are created on a Debian/Etch-powered system. > Also, at least for the stable versions of the distributions > that I use or have access to (Debian, Ubuntu, OpenSUSE, Novell SUSE > Linux Enterprise Desktop and Fedora), the default installation of each > of these distributions included Perl, glib and gtk+ as part of the pre- > installed packages (no additional download or selection of non-standard > packages). > Yet neither OSX nor Windows have those installed by default, so the default availability of dependencies works both for Java and GTK/Perl. *** At the risk of sounding rude (but I've a Registered Evil Lad(tm) reputation to defend), I really wonder why you asked if there was any objection, since you obviously already made up your mind. If you plan to include it in the SVN regardless of any counter-opinion given, then by all means do so, and stop wasting time in what appears to be a purely rhetorical question by now. (Yes, once more I sound overly negative and bashing - I guess somebody has to play the role of the bad guy in every discussion :)) Y. Chachkoff From raphael at gimp.org Sun Jul 20 16:24:25 2008 From: raphael at gimp.org (=?UTF-8?B?UmFwaGHDq2w=?= Quinet) Date: Sun, 20 Jul 2008 23:24:25 +0200 Subject: [crossfire] Importing the GTK+ editor in SVN In-Reply-To: <200807201414.53190.crossfire@ailesse.com> References: <20080716180905.4fda19ec.raphael@gimp.org> <20080718200333.GA1165@localhost.localdomain> <20080719215735.624b3fbb.raphael@gimp.org> <200807201414.53190.crossfire@ailesse.com> Message-ID: <20080720232425.412b499d.raphael@gimp.org> On Sun, 20 Jul 2008 14:14:52 +0200, Lauwenmark wrote: > Le Saturday 19 July 2008 21:57:35 Rapha?l Quinet, vous avez ?crit?: > > using crossfire SVN, then again the same reasoning would have prevented > > jxclient from being included. Why include jxclient which had less > > features than the existing clients, especially when a lot of code was > > already written for the existing clients and they were actively > > maintained? Well, because some developers were interested in working > > on something different (in that case, a Java client). [...] > So no, the purpose was not to work on a "Java client" - the purpose was to > work on "a better client", regardless of the technology used behind it. Use of > a specific language never was part of the initial design requirements. I agree and I respect your choices. However, to put this in perspective for this discussion, you could have opted to improve the existing gtk2 client, considering that gtk2 works well on all platforms (including Windows and MacOS X) and the "more immersive experience" is mostly a matter of how you design the user interface. You could have decided to add a full-screen mode to the existing client, allowing more freedom in the placement of the various elements of the user interface (for comparison, GIMP is also based on gtk2 and supports a full-screen mode for editing). Yet you have decided to start something different. That's fine by me and I wasn't among those who argued against its inclusion in SVN. But please don't claim that importing gcrossedit into SVN is significantly different from what happened back then. > I also question the goals pursued by the new editor - so far, the only solid > one advanced seems to be: "get rid of Java". What makes me think so is that > all the possible UI advantages it comes from were obviously never discussed > with the Gridarta developers before this discussion (Ragnor may need to > correct me on this); if they were the real, most important reason for the > change, then I admit I'm quite surprized nobody ever asked for such important > features to be included in Gridarta. The dependency on a non-free version Java has been a problem for me. This is what encouraged me to look at gcrossedit more than a year ago. And then I discovered that it had several features that were better than gridarta (faster "painting" of maps, especially for the initial layout) and that allowed me to stop using the old X11 crossedit or using gridarta from machines running non-free software, and to switch to gcrossedit instead. So although my initial motivation was to look at something that did not depend on non-free software, it has shifted now to more technical motivations because I saw that some differences in design could improve the workflow. And regarding Java, there is a subtle difference between "get rid of Java" (I don't remember ever saying that) and "I prefer to work on something else" (which is my personal opinion). I should also add that I spend many of my days at work writing proprietary code using Java and Eclipse. But when I'm not working and when I'm wearing my free software hat, I prefer to stick to the ideals of free software and avoid anything non-free. And I am passionate about it, as you can see... > So does Gridarta, as Sun's JDK/JRE works fine with Debian stable. > As a side note, the JRE6 is available in the official etch backports, so > installing it is not really an issue; [...] This is not correct. JRE6 is not available in the main Debian repositories. It is only available in the non-free repositories (for Debian testing/unstable, or as a backport for etch). So installing Sun's JRE6 is still an issue for those who only use free software. [...] > At the risk of sounding rude (but I've a Registered Evil Lad(tm) reputation to > defend), I really wonder why you asked if there was any objection, since you > obviously already made up your mind. If you plan to include it in the SVN > regardless of any counter-opinion given, then by all means do so, and stop > wasting time in what appears to be a purely rhetorical question by now. It wasn't a purely rhetorical question, although it may be now. There are several arguments that I would have accepted. For example, if Mark (as the official maintainer of crossfire) had said that he would have prefered to see gcrossedit living as a separate project, then I would have accepted that regardless of his reasons. If someone had said that creating a separate project on sourceforge would be better to encourage the usage of gcrossedit by more projects (e.g., daimonin) then I would have considered that as a useful objection. I might have argued that I prefer to focus only on crossfire, but still this would have been a useful comment. Also, if someone had said that there are already too many sub-projects in crossfire SVN and we should focus on removing some of them rather than adding new ones, then I would also have considered that as a valid reason for importing gcrossedit elsewhere. But so far, all the objections have been from developers involved with Gridarta and saying basically "don't work on a new editor". I do not consider these as valid arguments, because the editor exists and is mature (this is not something new) and because I am interested in working on it. As I said earlier, I wasn't asking if I should be allowed to work on it or not, but whether it should be part of crossfire SVN or if it would be better to create a new "crossfire editor" project on SourceForge or elsewhere. The few negative opinions received so far have been rather misdirected. But I also got some positive comments and some developers told me that they were interested in improving gcrossedit, so I think that it will be a useful addition to the crossfire SVN repository. But if that effort doesn't work and if gcrossedit becomes unmaintained a few years from now, then there is always the option of removing it from the repository. > (Yes, once more I sound overly negative and bashing - I guess somebody has to > play the role of the bad guy in every discussion :)) Well, that's fine for me. I prefer to have a honest discussion now about this, rather than facing initial silence and unspoken disagreements that blow up later and cause even more tension. That being said, please try to criticize without trolling. ;-) Several times you spoke of gcrossedit as a "new editor" as if that was something yet to be designed, while it has existed since several years. The only new thing is the import in SVN. Also, you referred twice to the GTK v2 client as a "Gnome2" client, which is obviouly incorrect because it does not depend on any GNOME code. And no, I will not be dragged into a KDE vs. GNOME troll, if that is what you were hoping for. :-) -Rapha?l From raphael at gimp.org Sun Jul 20 17:38:45 2008 From: raphael at gimp.org (=?UTF-8?B?UmFwaGHDq2w=?= Quinet) Date: Mon, 21 Jul 2008 00:38:45 +0200 Subject: [crossfire] Using UTF-8 in maps Message-ID: <20080721003845.c0e14dfd.raphael@gimp.org> Just a quick summary of what was discussed a few minutes ago on IRC, so that it's not forgotten: - the gtk v2 client is already using UTF-8 correctly; - gxclient and the old gtk v1 client are still using iso-8859-1 but it should not be hard to convert them to UTF-8; - UTF-8 is pretty much the standard today and it will be increasingly hard to justify using anything else. Those who participated in that discussion were in favor of standardizing on UTF-8 (at least for maps, we didn't really discuss archetypes or anything else). There were no objections against it. -Rapha?l From mwedel at sonic.net Sun Jul 20 22:49:06 2008 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 20 Jul 2008 20:49:06 -0700 Subject: [crossfire] GTK V2 Client (libglade) Release In-Reply-To: <200807200400.01263.kbulgrien@worldnet.att.net> References: <200807170052.02249.kbulgrien@worldnet.att.net> <48801D3D.3010004@sonic.net> <200807200400.01263.kbulgrien@worldnet.att.net> Message-ID: <48840732.9000500@sonic.net> Kevin R. Bulgrien wrote: >> Save for having other people do releases, next on my wish list would be >> for people to periodically try the release process (make archive from the >> top level dir - same place you run configure). If everything 'works', >> doing a release isn't that time consuming. >> >> But often, things don't work, and it then takes a considerable amount of >> time to track down the problems. Most common is new files getting added to >> SVN, but not the actual makefiles (things like header files, but could also >> be config files). > > The client release procedure on the Wiki has been used as a model for > testing the releasability of the trunk clients. A lot of time was spend > fixing up various aspects of the release procedure including updates to > configure.ac, various Makefile.am, crossfire-client.spec, etc.. To the > best of my knowledge, there are no remaining issues. I was able to run > the procedure start to finish, and wind up a full set of working RPMS > on my Mandriva 2008.1 x86_64 system. > > Basically all the work is done. All someone has to do is run the > procedure and upload tarballs and RPMs. Should any issues arise due > to platform differences, I'm willing to help resolve issues as needed. Thanks - that helps out a lot. A similar experiment is probably needed for the trunk server at some point - I can certainly imagine that with the refactoring and other changes, some bits may be missing. The flip side is that on the server, it tends to be files missing from Makefiles, as there are not as many files that actually get installed (or at least that have changed). I should probably just set up an automatic script that does an update and tries to make a release - at least that way, any breakage would be caught fairly quickly - the more often problem is that months happen between releases, and it is something that changed months ago. From nicolas.weeger at laposte.net Mon Jul 21 12:52:09 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 21 Jul 2008 19:52:09 +0200 Subject: [crossfire] Importing the GTK+ editor in SVN In-Reply-To: <20080720232425.412b499d.raphael@gimp.org> References: <20080716180905.4fda19ec.raphael@gimp.org> <200807201414.53190.crossfire@ailesse.com> <20080720232425.412b499d.raphael@gimp.org> Message-ID: <200807211952.13301.nicolas.weeger@laposte.net> > But so far, all the objections have been from developers involved with > Gridarta and saying basically "don't work on a new editor". Please, get your facts straight :) Yann didn't work on Gridarta unless I'm mistaken, and I definitely didn't (unless "using it" or "making feature requests" makes us developers :)). 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/20080721/b7822af1/attachment.pgp From nicolas.weeger at laposte.net Thu Jul 24 12:27:13 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 24 Jul 2008 19:27:13 +0200 Subject: [crossfire] Using UTF-8 in maps In-Reply-To: <20080721003845.c0e14dfd.raphael@gimp.org> References: <20080721003845.c0e14dfd.raphael@gimp.org> Message-ID: <200807241927.16311.nicolas.weeger@laposte.net> Le lundi 21 juillet 2008, Rapha?l Quinet a ?crit?: > Just a quick summary of what was discussed a few minutes ago on IRC, so > that it's not forgotten: > - the gtk v2 client is already using UTF-8 correctly; > - gxclient and the old gtk v1 client are still using iso-8859-1 but > it should not be hard to convert them to UTF-8; > - UTF-8 is pretty much the standard today and it will be increasingly > hard to justify using anything else. > > Those who participated in that discussion were in favor of > standardizing on UTF-8 (at least for maps, we didn't really discuss > archetypes or anything else). There were no objections against it. Agree on UTF-8, it's much simpler :) 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/20080724/3181e138/attachment.pgp From mwedel at sonic.net Thu Jul 24 22:44:02 2008 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 24 Jul 2008 20:44:02 -0700 Subject: [crossfire] Using UTF-8 in maps In-Reply-To: <20080721003845.c0e14dfd.raphael@gimp.org> References: <20080721003845.c0e14dfd.raphael@gimp.org> Message-ID: <48894C02.2080605@sonic.net> Rapha?l Quinet wrote: > Just a quick summary of what was discussed a few minutes ago on IRC, so > that it's not forgotten: > - the gtk v2 client is already using UTF-8 correctly; > - gxclient and the old gtk v1 client are still using iso-8859-1 but > it should not be hard to convert them to UTF-8; > - UTF-8 is pretty much the standard today and it will be increasingly > hard to justify using anything else. > > Those who participated in that discussion were in favor of > standardizing on UTF-8 (at least for maps, we didn't really discuss > archetypes or anything else). There were no objections against it. It all sounds good to me. What would be good to help out on this is basic directions in the editor as needed to embed the UTF8 characters. Same for some of the more popular editors so users now how to enter them. And lastly, we probably need to update the documentation that UTF8 is the proper codes to use, and the maps updated. For documentation, those hints on how to enter those characters would be useful. Saying to use UTF8 doesn't do me much good if I have no idea of the proper way to enter them. From raphael at gimp.org Fri Jul 25 01:51:29 2008 From: raphael at gimp.org (=?UTF-8?B?UmFwaGHDq2w=?= Quinet) Date: Fri, 25 Jul 2008 08:51:29 +0200 Subject: [crossfire] Using UTF-8 in maps In-Reply-To: <48894C02.2080605@sonic.net> References: <20080721003845.c0e14dfd.raphael@gimp.org> <48894C02.2080605@sonic.net> Message-ID: <20080725085129.ed5f2f16.raphael@gimp.org> On Thu, 24 Jul 2008 20:44:02 -0700, Mark Wedel wrote: > What would be good to help out on this is basic directions in the editor as > needed to embed the UTF8 characters. Same for some of the more popular editors > so users now how to enter them. Nowadays, most Linux systems are configured to use UTF-8 by default so most users will not have to change anything from their setup. This is usually done by setting the environment variable LANG to "en_US.UTF-8" (or something else than en_US depending on your language). This can also be done with the LC_* variables such as LC_CTYPE. A few systems are still configured with the old "C" locale or "en_US" without UTF-8 but most distros now default to "en_US.UTF-8". Use the command "locale" to check how your system is configured. If the locale is configured correctly, then most editors will save the right UTF-8 byte sequences to the file after the user has entered or copied some non-ASCII characters. We should probably write something similar to this section of the GIMP developers FAQ: http://developer.gimp.org/faq.html#id2467550 The examples given in that FAQ explain how to configure emacs or vi for: - setting the default code indentation style to the "GNU style" (a different style is used for crossfire and it doesn't match any of the predefined ones, so that would need some tweaking). - setting the default coding system to UTF-8 - setting the name and e-mail address used when a ChangeLog entry is added automatically (with M-X add-change-log-entry in emacs or with the function NewChangelogEntry in vim) > And lastly, we probably need to update the documentation that UTF8 is the > proper codes to use, and the maps updated. For documentation, those hints on > how to enter those characters would be useful. Right. UTF-8 will be mostly useful for those like me who want to use accented characters to write their name correcly. It is likely that those users have a keyboard with keys for entering these accented characters directly, or they know other ways to enter them anyway. Others who want to write a few accented characters can copy them from the character map (Linux or Windows) or from a character picker applet (Linux). I think that the usage of UTF-8 in the source code and in the maps should be limited to the accented characters that we really need. Even if UTF-8 supports it, I don't think that we should start entering strings in runic alphabet, hieroglyphs or linear-B because it is likely that most users will not have the right fonts to display these strange characters. So let's keep it simple. Besides, if we want to write strange text in maps, we already have the media tag [strange] for that. -Rapha?l From fuchs.andy at gmail.com Sat Jul 26 05:37:07 2008 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sat, 26 Jul 2008 06:37:07 -0400 Subject: [crossfire] Reimplementing seasonal weather. Message-ID: <1217068627.19356.52.camel@afuchs-laptop> I just had a conversation on IRC with Rapha?l Quinet, relating to seasonal changes to the world. I was thinking about making an ice dungeon in the middle of a lake, that, by using the existing scripts relating to time, would only 'exist' during winter when the lake freezes over. ?Rapha?l brought up the point, that if such a dungeon existed, it would make sense to have most of the world change to visually indicate the current season to players. Think about trees loosing their leaves, snow appearing on the ground, and lakes freezing over. A few ways for this to be implemented came up: * Allow the scripts that replace objects based on time to be attached to regions. However, this could affect indoor maps unless they are excluded by the code. ? * Create (or modify) archetypes that would change, based on the season. This could be done with C code or by attaching scripts. * Have attributes that specify how such objects change. A few things should be considered if this is done: * It would also be nice to allow various 'climates' to be specified by region. * Regardless of the implementation, special care should probably be taken to preserve special attributes of the objects being replaced or modified. If this is not done, exits and other objects can break. * If lakes and rivers are to freeze over, attention should be paid to areas where water is used to block players (such as the lake south of Brest). However, if we solve these issues, it also allows us to give pilot-able boats to players. Possible solutions include, not freezing certain parts of lakes, or the creation blocking tiles such as slush or very thin ice. -- ?Andrew Fuchs From mwedel at sonic.net Sun Jul 27 18:40:02 2008 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 27 Jul 2008 16:40:02 -0700 Subject: [crossfire] Reimplementing seasonal weather. In-Reply-To: <1217068627.19356.52.camel@afuchs-laptop> References: <1217068627.19356.52.camel@afuchs-laptop> Message-ID: <488D0752.3020601@sonic.net> Andrew Fuchs wrote: > I just had a conversation on IRC with Rapha?l Quinet, relating to > seasonal changes to the world. I was thinking about making an ice > dungeon in the middle of a lake, that, by using the existing scripts > relating to time, would only 'exist' during winter when the lake freezes > over. > ?Rapha?l brought up the point, that if such a dungeon existed, it would > make sense to have most of the world change to visually indicate the > current season to players. Think about trees loosing their leaves, snow > appearing on the ground, and lakes freezing over. > > A few ways for this to be implemented came up: > * Allow the scripts that replace objects based on time to be attached > to regions. However, this could affect indoor maps unless they are > excluded by the code. > ? * Create (or modify) archetypes that would change, based on the > season. This could be done with C code or by attaching scripts. > * Have attributes that specify how such objects change. I think the third point (attributes that dictate changes) is the best way to go. We should have learned by now that hard coding object attributes just don't work. Also, having it an archetype type attribute probably makes it easier to non coders to do updates - they just update the archetypes, they don't have to worry about modifying code, be that scripts or C code. The other advantage relates to your point below - by it being an object attribute, that attribute can be set/cleared in a map. Have an object you don't want changed on a map? Easy to do. That attribute could really just be a list of archetypes that dictate what archetype to use for different seasons. Something sort of like how animations are done. If one supposes you have 4 tree archetypes that dictate the 4 seasons, all of those different archetypes would still use that same seasonal information. and like animations, the size of that list wouldn't need to be a fixed number. A simple object maybe has 4 such seasonal archetypes. A more complex one could have 12 (one for each month). An advantage of this referring to different archetypes is each archetype still has full archetype abilities (meaning animation, as well as block and slow move). Moving over snow covered grass is perhaps slower than moving over dry grass in the fall. Likewise, frozen swamp is probably faster than non frozen swamp. > > A few things should be considered if this is done: > * It would also be nice to allow various 'climates' to be specified by > region. Yes - perhaps instead of it being based on region (which could involve a fair number of climates), just another attribute in the map header - climate - could be added. A reasonable number of standard climates would need to be decided on - if the list is too big, it then could become too hard cover all the different climates. I'd rather have just a few climates which all the relevant archetypes are updated for, vs a lot of climates, of which coverage is spotty. In fact, it could make sense to just make one climate to start out with, do all the updates for that, and when that is done, add the next climate, and repeat. But probably still a good idea to have a roadmap of what the list of climates are so you don't do three of those and then say 'oops - this one is a lot like the first one, but not quite', and you have to go and fix up the first one. > * Regardless of the implementation, special care should probably be > taken to preserve special attributes of the objects being replaced or > modified. If this is not done, exits and other objects can break. True. It might be easiest/best to decouple special attributes from the 'scenery' objects. For example, that tree that is also an exit? Make that tree just a tree and put in a separate exit object. > * If lakes and rivers are to freeze over, attention should be paid to > areas where water is used to block players (such as the lake south of > Brest). However, if we solve these issues, it also allows us to give > pilot-able boats to players. Possible solutions include, not freezing > certain parts of lakes, or the creation blocking tiles such as slush or > very thin ice. And not all lakes/rivers necessary have to freeze over - there are lots of likes and rivers in the world that don't do so. There are a few ways one could handle this - simplest would be for objects that always need to block passage, just put in some invisible blocking object (simple to do, may be time consuming to update the maps). If the seasonal changes are an object attribute, it then does become possible to have those rivers just not freeze over (clear the appropriate attributes), or have a different list which says something like 'impassable river', etc. all the graphics could be the same, just object attribute is different. It'd perhaps be fun even for the normal rivers that do freeze over to have different levels of thickness - in dead winter, anyone can walk over them, but in fall/spring, maybe the weight of the character indicates some chance to break through the ice and take damage. I'd also be nice to add objects that only show up in certain seasons - that could be done by that seasonal loop also including a bunch of invisible objects that do nothing - in seasons you don't want it, the code just puts that invisible object there - in seasons it is supposed to show up, the real object would be there. One other consideration here is when/how these seasonal changes take place, code wise. There are 2 main ways it could be handled: 1) When map is loaded, seasonal changes are applied. This may be the simplest, and has an added bonus that this logic could still get applied to those temporary maps that got swapped out. The only real downside is that map loading can be one of the slower operations right now. If this seasonal code is kept pretty simple, not a big deal - lots of processing already happens when a map loads, and updating the object at load time wouldn't add much. But this does limit long term complexibility. 2) Doing it as a separate task/process - has the advantage that things could be made very complex with little impact on the game itself. It does add some extra work to synchronize with the server itself (but even that would be pretty simple). I'd only go this way if it is believed it would become pretty complex. From mwedel at sonic.net Mon Jul 28 00:42:39 2008 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 27 Jul 2008 22:42:39 -0700 Subject: [crossfire] Using UTF-8 in maps In-Reply-To: <20080725085129.ed5f2f16.raphael@gimp.org> References: <20080721003845.c0e14dfd.raphael@gimp.org> <48894C02.2080605@sonic.net> <20080725085129.ed5f2f16.raphael@gimp.org> Message-ID: <488D5C4F.8010708@sonic.net> Rapha?l Quinet wrote: > On Thu, 24 Jul 2008 20:44:02 -0700, Mark Wedel wrote: >> What would be good to help out on this is basic directions in the editor as >> needed to embed the UTF8 characters. Same for some of the more popular editors >> so users now how to enter them. > > Nowadays, most Linux systems are configured to use UTF-8 by default so > most users will not have to change anything from their setup. This is > usually done by setting the environment variable LANG to "en_US.UTF-8" > (or something else than en_US depending on your language). This can > also be done with the LC_* variables such as LC_CTYPE. A few systems > are still configured with the old "C" locale or "en_US" without UTF-8 > but most distros now default to "en_US.UTF-8". Use the command "locale" > to check how your system is configured. If the locale is configured > correctly, then most editors will save the right UTF-8 byte sequences > to the file after the user has entered or copied some non-ASCII > characters. Hmmm - my solaris system has my locale as C. I'd need to look, but it seems that the login screen has an option of which locale I'd use. These types of steps/checks are what needs to be documented. A nice test, like 'open an editor, put ? in that file, and check contents with od -x or the like and see what it looks like to make sure it is writing it out in correct form. > > We should probably write something similar to this section of the GIMP > developers FAQ: http://developer.gimp.org/faq.html#id2467550 Yep - that would be good. >> And lastly, we probably need to update the documentation that UTF8 is the >> proper codes to use, and the maps updated. For documentation, those hints on >> how to enter those characters would be useful. > > Right. UTF-8 will be mostly useful for those like me who want to use > accented characters to write their name correcly. It is likely that > those users have a keyboard with keys for entering these accented > characters directly, or they know other ways to enter them anyway. > Others who want to write a few accented characters can copy them from > the character map (Linux or Windows) or from a character picker > applet (Linux). Yep - I think there are also a few items that have those characters in their name (mjollnir comes to mind, with the o having a / through it) > > I think that the usage of UTF-8 in the source code and in the maps > should be limited to the accented characters that we really need. > Even if UTF-8 supports it, I don't think that we should start > entering strings in runic alphabet, hieroglyphs or linear-B because > it is likely that most users will not have the right fonts to > display these strange characters. So let's keep it simple. Besides, > if we want to write strange text in maps, we already have the media > tag [strange] for that. Yep - aside from folks not having supporting it, also need to have a clear meaning if such characters were in use. In most cases, things like runic alphabets, which just use character image substitution, just gets old really quickly (ok, that symbols is A, that is B, etc, and now you can read the message, but just have to do it on your own) From nicolas.weeger at laposte.net Tue Jul 29 11:53:04 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 29 Jul 2008 18:53:04 +0200 Subject: [crossfire] Reimplementing seasonal weather. In-Reply-To: <1217068627.19356.52.camel@afuchs-laptop> References: <1217068627.19356.52.camel@afuchs-laptop> Message-ID: <200807291853.09069.nicolas.weeger@laposte.net> > I just had a conversation on IRC with Rapha?l Quinet, relating to > seasonal changes to the world. I was thinking about making an ice > dungeon in the middle of a lake, that, by using the existing scripts > relating to time, would only 'exist' during winter when the lake freezes > over. > ?Rapha?l brought up the point, that if such a dungeon existed, it would > make sense to have most of the world change to visually indicate the > current season to players. Think about trees loosing their leaves, snow > appearing on the ground, and lakes freezing over. Nice idea, however it is implemented :) 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/20080729/cd3acb90/attachment.pgp