From nicolas.weeger at laposte.net Fri Mar 2 16:04:25 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 2 Mar 2007 23:04:25 +0100 Subject: [crossfire] FLAG_PICK_UP flag Message-ID: <200703022304.25075.nicolas.weeger@laposte.net> Hello. There is a FLAG_PICK_UP which is used only for determining monster's experience and nowhere else. This seems like a leftover of some code, should we remove it? Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Sun Mar 4 04:17:28 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 4 Mar 2007 11:17:28 +0100 Subject: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire: [5665] maps/tags/1.10/ In-Reply-To: References: Message-ID: <200703041117.28334.nicolas.weeger@laposte.net> Le dimanche 04 mars 2007 08:55, Crossfire CVS repository messages. a ?crit?: > Revision: 5665 > http://svn.sourceforge.net/crossfire/?rev=5665&view=rev > Author: mwedel > Date: 2007-03-03 23:55:08 -0800 (Sat, 03 Mar 2007) > > Log Message: > ----------- > 1.10 branch Hello. I (and I'm sure others) would have appreciated some notification of incoming 1.10 release, as I'm trying to fix some things related to Windows version of server. Could I ask for ~2 weeks notice before releases, so we can freeze stuff and fix critical/blocking bugs? Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Sun Mar 4 05:14:08 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 4 Mar 2007 12:14:08 +0100 Subject: [crossfire] Patch for (void) Message-ID: <200703041214.08684.nicolas.weeger@laposte.net> Hello. The patch https://sourceforge.net/tracker/index.php?func=detail&aid=1660388&group_id=13833&atid=313833 adds (void) to functions instead of () when no argument. What do you think of that? I have mixed feelings, I don't like adding unecessary things. On the other hand maybe that's the convention we want to follow? Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From kbulgrien at worldnet.att.net Sun Mar 4 10:32:35 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sun, 4 Mar 2007 10:32:35 -0600 Subject: [crossfire] Patch for (void) In-Reply-To: <200703041214.08684.nicolas.weeger@laposte.net> References: <200703041214.08684.nicolas.weeger@laposte.net> Message-ID: <200703041032.35336.kbulgrien@worldnet.att.net> On Sunday 04 March 2007 05:14, Nicolas Weeger wrote: > Hello. > > The patch > https://sourceforge.net/tracker/index.php?func=detail&aid=1660388&group_id=13833&atid=313833 > adds (void) to functions instead of () when no argument. > > What do you think of that? > > I have mixed feelings, I don't like adding unecessary things. On the other > hand maybe that's the convention we want to follow? > > Nicolas Using "Learning C++, Third Edition, by Erik Nagler" as a reference, the distinction between void and the absence of void is based on whether the source is C++ or C. In C, empty parentheses mean "I'll take anything you want to give me." whereas in C++ empty parentheses mean "no arguments can be passed in". Unless the source is moving to C++, it seems best to allow the compiler to help find errors that involve passing of parameters when none should be passed, but that is from a developer that has worked mostly with other languages and from one who has limited C experience. Kevin From mwedel at sonic.net Sun Mar 4 13:57:28 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 04 Mar 2007 11:57:28 -0800 Subject: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire: [5665] maps/tags/1.10/ In-Reply-To: <200703041117.28334.nicolas.weeger@laposte.net> References: <200703041117.28334.nicolas.weeger@laposte.net> Message-ID: <45EB24A8.8020708@sonic.net> Nicolas Weeger wrote: > Le dimanche 04 mars 2007 08:55, Crossfire CVS repository messages. a ?crit : >> Revision: 5665 >> http://svn.sourceforge.net/crossfire/?rev=5665&view=rev >> Author: mwedel >> Date: 2007-03-03 23:55:08 -0800 (Sat, 03 Mar 2007) >> >> Log Message: >> ----------- >> 1.10 branch > > Hello. > > I (and I'm sure others) would have appreciated some notification of incoming > 1.10 release, as I'm trying to fix some things related to Windows version of > server. > > Could I ask for ~2 weeks notice before releases, so we can freeze stuff and > fix critical/blocking bugs? The problem here is my available time to make releases. As many may recall, at the start of this year, I made the announcement that I'd make a release (1.10) shortly. At the time I made the announcement, I had time (right then) to make the release, but giving a couple weeks for bugs to get fixed, etc, seemed like a good thing to do. However, work, home, and other things cropped up, and 2 weeks later, I didn't have the time. So now we are 2 months later, and 1.10 has yet to be released. So I basically came to the conclusion that I have the time right now to make a release, so should do it. Looking at my schedule, there is a good chance that 2 weeks from now, I wouldn't have time. And then the release gets put off longer, etc. This release is also a little more time consuming, as it is our first release under SVN. I'm also writing a pretty detailed doc on the wiki on the steps needed, so perhaps others could make the releases (it isn't particularly hard, but does take a fair amount of time). IMO, release of crossfire should be done more often (quarterly perhaps)? Gets the code out there a little faster, but it also means that if something misses a release, it doesn't have to wait as long for the next release. In any case, sorry for not giving notice, but just needed to get a release out while I had the time to do it. > > Nicolas From nicolas.weeger at laposte.net Sun Mar 4 14:44:20 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 4 Mar 2007 21:44:20 +0100 Subject: [crossfire] =?iso-8859-1?q?=5BCrossfire-cvs=5D_SF=2Enet_SVN=3A_cr?= =?iso-8859-1?q?ossfire=3A_=5B5665=5D=09maps/tags/1=2E10/?= In-Reply-To: <45EB24A8.8020708@sonic.net> References: <200703041117.28334.nicolas.weeger@laposte.net> <45EB24A8.8020708@sonic.net> Message-ID: <200703042144.20385.nicolas.weeger@laposte.net> > This release is also a little more time consuming, as it is our first > release under SVN. I'm also writing a pretty detailed doc on the wiki on > the steps needed, so perhaps others could make the releases (it isn't > particularly hard, but does take a fair amount of time). Yes, everything should be documented (this includes how to make Windows releases ^_-) > IMO, release of crossfire should be done more often (quarterly perhaps)? > Gets the code out there a little faster, but it also means that if > something misses a release, it doesn't have to wait as long for the next > release. Maybe even more often? That reminds me of a discussion about release numbers and such ^_- I try to do releases of Windows version often (not done any yet this year, will need to correct that), so people can test stuff. Of course Linux is different since it has compilation tools almost builtin. > In any case, sorry for not giving notice, but just needed to get a > release out while I had the time to do it. Then could I suggest we, people developing for Crossfire, and not only you alone, try to coordinate to make releases? I'm sure we'd be 3 or 4 people willing to take a share of the release process - be it tagging, making archives, whatever. Given like one week notice (maybe 2 to account for holidays), it'd be pretty fast to do what is needed. We could even make releases while you're not available, possibly ^_- As for free time, I'm sure most people on this list are in the same case, so we (I at least) do understand your time issue :) But please remember that there are other people who'll need to eg make Windows 1.10 release to follow the Linux one, and they also have the same time issues - thus my call for increased coordination ^_- Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From mwedel at sonic.net Sun Mar 4 18:38:05 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 04 Mar 2007 16:38:05 -0800 Subject: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire: [5665] maps/tags/1.10/ In-Reply-To: <200703042144.20385.nicolas.weeger@laposte.net> References: <200703041117.28334.nicolas.weeger@laposte.net> <45EB24A8.8020708@sonic.net> <200703042144.20385.nicolas.weeger@laposte.net> Message-ID: <45EB666D.3000302@sonic.net> Nicolas Weeger wrote: >> IMO, release of crossfire should be done more often (quarterly perhaps)? >> Gets the code out there a little faster, but it also means that if >> something misses a release, it doesn't have to wait as long for the next >> release. > > Maybe even more often? > That reminds me of a discussion about release numbers and such ^_- Yes - I just looked at that doc - it doesn't mention anything about how often releases should be made. For the stable releases, it is a tricky question. In theory, not a lot should be changing - doing monthly releases may not be bad, but may also mean that the only thing that has changed is a couple bugfixes, and so the question then becomes if it is worth the effort to make a release for that. Or maybe the release logic gets changed some - make quarterly minor releases (1.10, 1.11, 1.12, etc). But if there is a critical bug that people are likely to hit, make a micro release right after that change (1.10.1, 1.10.2, etc). The micro release only needs to contain the affected area (server, client, etc), so is easier than doing a full minor release. this gets critical bug changes out there in a timely fashion. Because even if advanced notice is given, there is the possibility that the day after a release is made, some critical bug is found. This actually may be more likely, as people are likely to download the new release and try it out, so if the bug was introduced since the last release, this may be the first time it gets widespread use. My thoughts for doing releases on a more regular schedule is that there is then implied deadlines for fixes. Eg, a release will be made at start of march, june, september, december, so make sure any fixes get in by then. At some level, the better answer is that developers should consider that a new release could be made any time, so bugfixes, etc, should always go in promptly. But I know that is not realistic, and don't really follow it myself. >> In any case, sorry for not giving notice, but just needed to get a >> release out while I had the time to do it. > > Then could I suggest we, people developing for Crossfire, and not only you > alone, try to coordinate to make releases? > I'm sure we'd be 3 or 4 people willing to take a share of the release > process - be it tagging, making archives, whatever. > Given like one week notice (maybe 2 to account for holidays), it'd be pretty > fast to do what is needed. > We could even make releases while you're not available, possibly ^_- That is one reason I'm documenting the process - so others could do releases. This is also one reason that regularly scheduled releases may make sense - people will know to try to set aside time/clean up any open bugs. It also means that if something misses a release, and isn't critical, it is known when the next release is, and thus when that feature/bug fix would be put in. I think one problem/issue right now is that there is no determined release cycle, so there is real desire to have the advanced notice - if you don't get something in for this release, who knows when the next release might be out. Case in point is that is has been 8 months or so since the 1.9.1 release. > > As for free time, I'm sure most people on this list are in the same case, so > we (I at least) do understand your time issue :) > But please remember that there are other people who'll need to eg make Windows > 1.10 release to follow the Linux one, and they also have the same time > issues - thus my call for increased coordination ^_- Consider the release of 1.10 a one-off, and that in future, better coordination, both in scheduling, and hopefully in people, would be done. I could be wrong, but I think right now, no one else other than me is comfortable making the official releases. Hopefully, the documentation will help that, and the best way to write that is to write it as I do it. I also cam to the conclusion that I could to a release right now, which would probably miss some bug fixes, etc (which is always the case), or probably not have time to do another one for 2 months (between work schedule and vacation). 2 months from now would almost be time for the next release (presuming quarterly scheduled), so I figured that putting a release out now would be better than waiting. I forgot about the windows releases, and the time you'd need to make those. OTOH, I don't know if there is really a requirement that those show up the next day after the official release. From kbulgrien at att.net Mon Mar 5 04:32:23 2007 From: kbulgrien at att.net (Kevin R. Bulgrien) Date: Mon, 05 Mar 2007 04:32:23 -0600 Subject: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire: [5665] maps/tags/1.10/ References: <200703041117.28334.nicolas.weeger@laposte.net> Message-ID: >> Log Message: >> ----------- >> 1.10 branch > > Hello. > > I (and I'm sure others) would have appreciated some notification of > incoming 1.10 release, as I'm trying to fix some things related to Windows > version of server. > > Could I ask for ~2 weeks notice before releases, so we can freeze stuff > and fix critical/blocking bugs? > > Nicolas The old adage about CVS not being a replacement for developer communication likely applies well in this situation, IMO. 2 weeks not needed here as _any_ notice would be appreciated. I had two regressions to fix in maps. I could have had them fixed in a few hours, but had just discovered them through playtesting and was needing to experiment a bit to learn how to fix them. (I have fixed them now, but it is too late.) With 24 or 48 hours notice, these regressions might have been fixed for the release as I could have upped priority for hammering out a correction. I acknowledge it is my problem for not having tested well enough before committing. At the time I did test on my server, but did not have in mind the nuances of testing for hidden attribute changes that come in from the arch when switching out floor pieces. I know now, so hopefully it won't happen again. Kevin From nicolas.weeger at laposte.net Mon Mar 5 13:31:30 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 5 Mar 2007 20:31:30 +0100 Subject: [crossfire] New type "sstring"? Message-ID: <200703052031.30798.nicolas.weeger@laposte.net> Hello. I'd like to add a "typedef const char* sstring" and use that for relevant members / variables. sstring is of course "shared_string". It wouldn't change much things, but clarify when the string is shared (add_string / add_refcount) and when it's safe to alter it. Unless I'm mistaking the const char* <-> sstring conversion would be implicit, so wouldn't need to change all functions immediately :) What do you think of that? Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Mon Mar 5 13:43:04 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 5 Mar 2007 20:43:04 +0100 Subject: [crossfire] Plugin API Message-ID: <200703052043.04738.nicolas.weeger@laposte.net> Hello. I'd like to propose changes to the plugin API. Currently, plugins call eg char* directory = cfapi_system_directory(&val, 3) to get a directory information. I'd like to change that to the general format: int result = cfapi_system_directory(&val, 3, &directory, sizeof(directory)) with result a plugin-specific code (0 => no error, 1 => invalid parameter, ...) Basically, to wrap a server function object* get_split_ob(object* ob, int nrof) one should call cfapi_object_get_split(&val, ob, nrof, &split) with object* split. This way, the plugin layer could return some information (object was lost, invalid parameter). It would also avoid having static variables used to return int/float values. If no one objects, I'd feel like doing that starting around next week :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From alex_sch at telus.net Mon Mar 5 18:18:24 2007 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 05 Mar 2007 17:18:24 -0700 Subject: [crossfire] New type "sstring"? In-Reply-To: <200703052031.30798.nicolas.weeger@laposte.net> References: <200703052031.30798.nicolas.weeger@laposte.net> Message-ID: <45ECB350.40102@telus.net> Nicolas Weeger wrote: > I'd like to add a "typedef const char* sstring" and use that for relevant > members / variables. sstring is of course "shared_string". > > It wouldn't change much things, but clarify when the string is shared > (add_string / add_refcount) and when it's safe to alter it. > > Unless I'm mistaking the const char* <-> sstring conversion would be implicit, > so wouldn't need to change all functions immediately :) > > What do you think of that? I'd say this would be a great idea as it would make it easier to tell in the code when things are a shared string :) I'm not 100% sure of the choice of that particular name 'sstring', however I don't have any better alternatives in mind at the moment. Alex Schultz From mwedel at sonic.net Tue Mar 6 01:02:58 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 05 Mar 2007 23:02:58 -0800 Subject: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire: [5665] maps/tags/1.10/ In-Reply-To: References: <200703041117.28334.nicolas.weeger@laposte.net> Message-ID: <45ED1222.3040007@sonic.net> Kevin R. Bulgrien wrote: >>> Log Message: >>> ----------- >>> 1.10 branch >> Hello. >> >> I (and I'm sure others) would have appreciated some notification of >> incoming 1.10 release, as I'm trying to fix some things related to Windows >> version of server. >> >> Could I ask for ~2 weeks notice before releases, so we can freeze stuff >> and fix critical/blocking bugs? >> >> Nicolas > > The old adage about CVS not being a replacement for developer communication > likely applies well in this situation, IMO. > > 2 weeks not needed here as _any_ notice would be appreciated. I had two > regressions to fix in maps. I could have had them fixed in a few hours, > but had just discovered them through playtesting and was needing to > experiment a bit to learn how to fix them. (I have fixed them now, but it > is too late.) With 24 or 48 hours notice, these regressions might have > been fixed for the release as I could have upped priority for hammering > out a correction. > > I acknowledge it is my problem for not having tested well enough before > committing. At the time I did test on my server, but did not have in mind > the nuances of testing for hidden attribute changes that come in from the > arch when switching out floor pieces. I know now, so hopefully it won't > happen again. As said before in other thread, sorry about no advanced notice. If I knew I was going to make the release last weekend, I would have given advanced noticed. It just turned out that I found myself with the time to do the release when I sat down at the computer at the weekend. So I basically had these options: 1) Start the release process since I know I had time then. 2) Give notice about an upcoming release, and hope that I'd actually have the time to do it before when I said so. My estimated probability of this was low (and if the deadline is missed, it almost seems like the process is restarted, since at some point, the immediancy of a release coming out goes away. 3) Do neither - wait 2-3 months when I estimate I may have time, and schedule a release then (which would be when the release is done if I missed schedule on #2) IMO, none of those is ideal - the ideal is ability to announce I'll do a release in 2 weeks, and then actually do the release then. But as of right now, that seemed low. And since there were no docs, its not like I could point someone else to do the release in that timely fashion. Hopefully, since I'm writing docs, that may be more doable. Looking back, the only thing I might really change is perhaps saying something on irc like "I'm going to do a release starting right now - if you have anything ready to commit, let me know now and commit it", to catch any of those ready to commit fixes (but that in itself can sometimes be dangerous). If I had a time machine, I'd send a note to myself 2 weeks ago to send mail to the list saying I'm going to do a release in 2 weeks. But I have to go on what I knew at the time, not what I knew later. Otherwise, I still think my decision to do a release now is better than waiting another 2 months for a release. Even though the code has some bugs, I'd say it is better than what is out there right now as 1.9.1, and at some level, getting code out there for others to use has some advantages. This is one of the arguments for frequent releases - sure, each build will have some bugs, and could be made better if delayed, but by getting the builds out there, you get people to discover some of those new bugs so that they can get fixed in the next release. If infrequent releases are done, quality may in fact not be better because people are stuck using an old buggy build for a longer time period. Now to turn this more constructive, I think the real question is: How often should we be doing releases? Every month? Every 3 months? Somewhere in between? I think anything more frequent then every month (save for critical builds/to fix something DOA) doesn't make much sense, as I don't think the 1.x branch is changing fast enough. I also think that less than every 3 months is too long a gap - just looking at the client, there were lots of things changed since the last release, such that if there were 3 releases in that time period, each would still have enough changes to be compelling. From kbulgrien at worldnet.att.net Tue Mar 6 07:48:41 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Tue, 6 Mar 2007 07:48:41 -0600 Subject: [crossfire] Release schedule: was maps/tags/1.10/ In-Reply-To: <45ED1222.3040007@sonic.net> References: <45ED1222.3040007@sonic.net> Message-ID: <200703060748.42183.kbulgrien@worldnet.att.net> > Looking back, the only thing I might really change is perhaps saying something > on irc like "I'm going to do a release starting right now - if you have anything > ready to commit, let me know now and commit it", to catch any of those ready to > commit fixes (but that in itself can sometimes be dangerous). If I had a time > machine, I'd send a note to myself 2 weeks ago to send mail to the list saying > I'm going to do a release in 2 weeks. But I have to go on what I knew at the > time, not what I knew later. Ok... and not to beat a dead horse, but my fixes were in easy maps, the ones most likely for new players to see, which is why it gave me heartburn, and this kind of heartburn is what you begin to address below, so we are on the same page. I know some distributions will ship 1.10 with those glaring bugs, and a slow release means I just let them out the gate for who knows how long even if I didn't have a hand in when the release occurred > Otherwise, I still think my decision to do a release now is better than > waiting another 2 months for a release. Even though the code has some bugs, I'd > say it is better than what is out there right now as 1.9.1, and at some level, > getting code out there for others to use has some advantages. I'm not totally on the same page here. I think I would be if there were stable and unstable releases, and if we were talking about an unstable one, but... on the flip side, I get the point that it should not have waited another 2 months... and agree on that point even though there rarely seems to be a truly acceptable reason for releasing without mentioning it to co-developers. > This is one of the arguments for frequent releases - sure, each build will > have some bugs, and could be made better if delayed, but by getting the builds > out there, you get people to discover some of those new bugs so that they can > get fixed in the next release. If infrequent releases are done, quality may in > fact not be better because people are stuck using an old buggy build for a > longer time period. > > Now to turn this more constructive, I think the real question is: How often > should we be doing releases? Every month? Every 3 months? Somewhere in between? > > I think anything more frequent then every month (save for critical builds/to > fix something DOA) doesn't make much sense, as I don't think the 1.x branch is > changing fast enough. > > I also think that less than every 3 months is too long a gap - just looking at > the client, there were lots of things changed since the last release, such that > if there were 3 releases in that time period, each would still have enough > changes to be compelling. More frequent releases than quarterly for stable releases seems questionable, and would propose a tri-annual or bi-annual stable release to better line up with major distribution release schedules. As far as getting more testers running the code that doing monthly or bi-monthly build releases is a good idea (all the way to packaging so that the release process itself can be tested). I only see this possible if the release process is documented and scripted as much as possible. At work, I do releases where I use a document and a special make file that does all the tasks between events that need operator intervention... using the Makefile as a simple library of things that need to be done... a la `make zip`. On that note, I'd like to see a top-level "tools" directory added to SVN to encourage us to put our utility scripts in SVN for others to use. I worked a bit on a map spell checker, for instance, but because it is not good enough to "release", it rots in my working directory. Such a directory would be a great place for scripts that could be used to manage SVN's bizarre concept of making you either waste disk space or have bazillions of individual checkouts. It would also be wonderful for the release process to be supported by scripts in that directory. 2 cents... maybe not worth much in some economies... Kevin From nicolas.weeger at laposte.net Tue Mar 6 12:10:03 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 6 Mar 2007 19:10:03 +0100 Subject: [crossfire] =?iso-8859-1?q?=5BCrossfire-cvs=5D_SF=2Enet_SVN=3A_cr?= =?iso-8859-1?q?ossfire=3A_=5B5665=5D=09maps/tags/1=2E10/?= In-Reply-To: <45ED1222.3040007@sonic.net> References: <45ED1222.3040007@sonic.net> Message-ID: <200703061910.03801.nicolas.weeger@laposte.net> > Now to turn this more constructive, I think the real question is: How > often should we be doing releases? Every month? Every 3 months? > Somewhere in between? > > I think anything more frequent then every month (save for critical > builds/to fix something DOA) doesn't make much sense, as I don't think the > 1.x branch is changing fast enough. > > I also think that less than every 3 months is too long a gap - just > looking at the client, there were lots of things changed since the last > release, such that if there were 3 releases in that time period, each would > still have enough changes to be compelling. I think one major issue is how long it takes to make a release. For instance, I know there are some things to do for Windows server/client (and I will write that down somewhere!), but I don't know how long it takes. IMO, what we should do is: * automatize to the maximum the release process. This can include writing sh scripts for Linux, scripts for Windows, and so on. [as a side note, I'm thinking of doing a small C program for Windows to replace the Perl script for maps, and make the build process more easy, ie change version numbers and such. C because Perl isn't needed, apart for arch collecting which i can do on my linux box) * time how much time a release takes * decide after we automate to the maximum :) I would aim for something like a release every 2 months. It may appear short, but if release process is automated well we don't take much time to release. It would enable us to have many tests and such. Note that we should probably do trunk releases too, so people get to test it. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Tue Mar 6 15:58:50 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 6 Mar 2007 22:58:50 +0100 Subject: [crossfire] Fun issue :) Message-ID: <200703062258.50395.nicolas.weeger@laposte.net> Hello. I just fixed a fun issue: add_string() will abort() if sent string is NULL and MANY_CORES is defined. Except this define was never used, since the relevant file (config.h) wasn't included :) Now the file is included, so the define has effect - and I had to fix the race for "dwarf_player" archetype, races file was still referring to old player dwarf_p (would cause an abort() in add_string!). There was no warning as dwarf_p still exists, in arch/races/old. Maybe that directory should be cleaned? At least files renames to eg .arc.old so they don't get collected? Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From mwedel at sonic.net Wed Mar 7 00:39:21 2007 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 06 Mar 2007 22:39:21 -0800 Subject: [crossfire] Release schedule: was maps/tags/1.10/ In-Reply-To: <200703060748.42183.kbulgrien@worldnet.att.net> References: <45ED1222.3040007@sonic.net> <200703060748.42183.kbulgrien@worldnet.att.net> Message-ID: <45EE5E19.40004@sonic.net> Kevin R. Bulgrien wrote: >> >> I also think that less than every 3 months is too long a gap - just looking at >> the client, there were lots of things changed since the last release, such that >> if there were 3 releases in that time period, each would still have enough >> changes to be compelling. > > More frequent releases than quarterly for stable releases seems questionable, > and would propose a tri-annual or bi-annual stable release to better line up with > major distribution release schedules. Ok. I think bi-annual may be too infrequent, by every 3-4 months is probably reasonable. > > As far as getting more testers running the code that doing monthly or bi-monthly > build releases is a good idea (all the way to packaging so that the release process > itself can be tested). I only see this possible if the release process is documented > and scripted as much as possible. At work, I do releases where I use a document > and a special make file that does all the tasks between events that need operator > intervention... using the Makefile as a simple library of things that need to be done... > a la `make zip`. I'm documenting the process as I go along. What I have so far is at: http://wiki.metalforge.net/doku.php/crossfire_release_guide (I have yet to the server release) Some things could perhaps be scripted more than they are done now. For example, I could certainly see a top level script along the lines of 'make 1.11 release', which goes, does the svn copy (to the right name), and perhaps even collects that archetype, maps, and sounds. Some of it gets trickier - for example, to make the ChangeLog file appear a little nicer, I remove the 'for top of SVN' in the branch - and just have 'Fixed in release 1.10'. That could perhaps get scripted, but becomes a question of whether it is worth the time to try and script it (it may be that the automatic script fires up an editor). OTOH, automating it too far may be bad. IT may very well be a case that we say we'll do a release on some date, and someone says they'll take care of the archs, another says they'll do the maps, etc. Aside from splitting the load, there could be other reasons - the person doing the most work with the arches may be the person that is also doing the release - this makes sense - he'll know when his changes are in, etc. there are also some things just not easily scriptable. Like for me to build the 32 bit rpms, I have to boot my other computer, log in, run the commands, etc. Running the commands to build the RPM is the easy part - it is the other steps that take more time. In terms of more frequent 'build' releases, I'm not sure how that really differs from a normal release. If it is a semi private release (not uploaded to sourceforge), it probably won't get as widespread testing, and in fact may not get any testing. If it does get uploaded to sourceforge, then it basically becomes like a normal release - people are going to download that (so better make sure all the bugs are fixed in it), etc. I also think there is some limit on how often you can release those and get real feedback. > > On that note, I'd like to see a top-level "tools" directory added to SVN to encourage > us to put our utility scripts in SVN for others to use. I worked a bit on a map spell > checker, for instance, but because it is not good enough to "release", it rots in my > working directory. Such a directory would be a great place for scripts that could be > used to manage SVN's bizarre concept of making you either waste disk space or > have bazillions of individual checkouts. It would also be wonderful for the release > process to be supported by scripts in that directory. That makes some sense. But from the description, it seems a little odd. If the scripts are not of release quality, there is nothing preventing us right now from putting those in something like maps/scripts-nrq (non release quality), and then just not include that directory when the data is tarred up. That may make more sense than putting them in a top level script directory - I just have visions of hundreds of scripts there, with no real clue what half of them do, and then you start wondering if this or that script should be deleted, etc. I think it also makes sense to have script dirs in the arch and map distribution - there are already a bunch of map checking scripts in the server area, but that doesn't make a lot of sense - people don't necessarily know that they are there, etc. From mwedel at sonic.net Wed Mar 7 00:58:04 2007 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 06 Mar 2007 22:58:04 -0800 Subject: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire: [5665] maps/tags/1.10/ In-Reply-To: <200703061910.03801.nicolas.weeger@laposte.net> References: <45ED1222.3040007@sonic.net> <200703061910.03801.nicolas.weeger@laposte.net> Message-ID: <45EE627C.7010704@sonic.net> Nicolas Weeger wrote: > I think one major issue is how long it takes to make a release. > For instance, I know there are some things to do for Windows server/client > (and I will write that down somewhere!), but I don't know how long it takes. I know this release is taking a bit more time, but that is also because I'm documenting it. the arch and map stuff is pretty easy - it is basically make a copy to the branch, tar it up, and upload it. Even the server and client is pretty easy _if_ everything works correctly. The directions are basically update the configure.in, run autoconf, do make dist. The issue is when things don't work right - someone adds a file but forgets to update the makefile. Then you go through, fix that, repeat the steps, etc, and hopes it works. Also, for the client & server, I do some extra checking, like can I run the client, log into the server, and have it work? Just a basic 'this isn't completely brain dead' type of thing. that takes some extra time, but after being hit one time with something being delivered that was braindead, it seems like a good idea. The time may also depend on your upload speed. Uploading 40 MB of map files takes a little bit of time on an ADSL connection. But in short summary, I'd say that normally it takes the good part of an evening to do a release (2-4 hours). If releases are done more often, I'd expect this to go down some - likelihood of release process getting broken is less when there have only been 20 changes and not 200, etc. > > IMO, what we should do is: > * automatize to the maximum the release process. This can include writing sh > scripts for Linux, scripts for Windows, and so on. [as a side note, I'm > thinking of doing a small C program for Windows to replace the Perl script > for maps, and make the build process more easy, ie change version numbers and > such. C because Perl isn't needed, apart for arch collecting which i can do > on my linux box) > * time how much time a release takes > * decide after we automate to the maximum :) See other post about automation. Certainly more automation can be done, and that shaves some time off. I suppose the main advantage of automation is it could be something that you do a 'make release 1.11', go to bed, and next morning, log on to find everything worked and the files are uploaded to sourceforge. At least for me, it may be a little while before I trust everything that much. And I'm sure it could be automated more - I think it basically came down to: A) Do a write a script to automate it more, which will take X amount of time to write and make sure it works B) Just do it by hand, where it takes Y more time than fully automated Where Y*NUM_RELEASES > X, but unclear what value NUM_RELEASES are. it's also a matter of time concentration. If Y is 10 minutes, not a big deal - just means I go to bed a few minutes later, and shaving 10 minutes off probably means I go to bed 10 minutes earlier. if X is 90 minutes, that is enough time to actually do something relevant - look into fixing some bugs, writing new features, whatever else. > > I would aim for something like a release every 2 months. It may appear short, > but if release process is automated well we don't take much time to release. > It would enable us to have many tests and such. More frequent releases do also have the advantage that there is likely less breakage. > > Note that we should probably do trunk releases too, so people get to test it. The trunk releases get messy, because from what I recall, what we have right now in trunk may not be compatible with final release of 2.0 (in terms of maps, locations, etc). So it gets sort of tricky to put this out there, but don't rely on it too heavily, because things could change in incompatible ways. But that sort of discourages people from using it. Its sort of a different discussion, but the compatible breaking changes should probably be done as soon as possible, so that the rest of more tweaking, fixing bugs, etc. But time doesn't always work that way. From kbulgrien at worldnet.att.net Wed Mar 7 22:30:27 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Wed, 7 Mar 2007 22:30:27 -0600 Subject: [crossfire] Release schedule: was maps/tags/1.10/ In-Reply-To: <45EE5E19.40004@sonic.net> References: <200703060748.42183.kbulgrien@worldnet.att.net> <45EE5E19.40004@sonic.net> Message-ID: <200703072230.28005.kbulgrien@worldnet.att.net> > Some things could perhaps be scripted more than they are done now. For > example, I could certainly see a top level script along the lines of 'make 1.11 > release', which goes, does the svn copy (to the right name), and perhaps even > collects that archetype, maps, and sounds. > > Some of it gets trickier - for example, to make the ChangeLog file appear a > little nicer, I remove the 'for top of SVN' in the branch - and just have 'Fixed > in release 1.10'. That could perhaps get scripted, but becomes a question of > whether it is worth the time to try and script it (it may be that the automatic > script fires up an editor). > > OTOH, automating it too far may be bad. IT may very well be a case that we > say we'll do a release on some date, and someone says they'll take care of the > archs, another says they'll do the maps, etc. FWIW, I agree that it usually is going to take a balance between manual and assisted. I tend toward scripting the basic rote work that doesn't take imagination. Going to far with the hard stuff doesn't pay back, and is often to easy to break quickly. > Aside from splitting the load, there could be other reasons - the person doing > the most work with the arches may be the person that is also doing the release - > this makes sense - he'll know when his changes are in, etc. > > there are also some things just not easily scriptable. Like for me to build > the 32 bit rpms, I have to boot my other computer, log in, run the commands, > etc. Running the commands to build the RPM is the easy part - it is the other > steps that take more time. > > In terms of more frequent 'build' releases, I'm not sure how that really > differs from a normal release. Perhaps a technicality, but having a distinction would make it "easier" to release something even if there was a big bug unfixed, or it might be top of tree so that new development gets tested quicker... and also encourages new development to not go too long in an unusable state. > If it is a semi private release (not uploaded to sourceforge), it probably > won't get as widespread testing, and in fact may not get any testing. Not my intent. Say Joe wants to run a server... he picks stable because he mostly wants to play with a bunch of friends and doesn't want a lot of risk that stuff will be busted. Jack though, likes to hack around, and play the bleeding edge, but he's not up to doing SVN checkout and build, so he goes for the "unstable". It's all up to the downloader. It's not a new concept as a number of big projects run that way... TortoiseCVS... CVS... etc. I'd not say it is without some downsides if not managed well. Say you go for a release every four months, then maybe there are three "unstable" releases between where people don't try as hard to get all the bugs out... they are in essence, release candidates on steroids in that there is not requirement for new features to not be added. The point is to get the stuff tested, not to presume it is error-free. Maybe the schedule helps people stop putting in features after the last unstable before a new release... or maybe not depending on how formal you want things to run... but that might help people plan what to work on so that bug fixing gets attention as well as adding new stuff. > If it does get uploaded to sourceforge, then it basically becomes like a > normal release - people are going to download that (so better make sure all the > bugs are fixed in it), etc. I also think there is some limit on how often you > can release those and get real feedback. > > > > > On that note, I'd like to see a top-level "tools" directory added to SVN to encourage > > us to put our utility scripts in SVN for others to use. I worked a bit on a map spell > > checker, for instance, but because it is not good enough to "release", it rots in my > > working directory. Such a directory would be a great place for scripts that could be > > used to manage SVN's bizarre concept of making you either waste disk space or > > have bazillions of individual checkouts. It would also be wonderful for the release > > process to be supported by scripts in that directory. > > That makes some sense. But from the description, it seems a little odd. > > If the scripts are not of release quality, there is nothing preventing us > right now from putting those in something like maps/scripts-nrq (non release > quality), and then just not include that directory when the data is tarred up. When I said release quality, I was meaning that I wouldn't necessarily want someone to think I thought they were polished, but since they were in SVN, someone could hack on them when I didn't. It seems too bad to hoard a script just because I don't know where junk like that goes. It seems harder to add a file in a maps directory, etc if your just hacking around a proof of concept that might just fizzle. Having a tools area might make it easier to chuck something in in case someone else might look at it and go... hey... that's a cool idea, but how about doing it this way... or whatever. I tend to feel less confident about uploading a script into say maps, or server if I'm not sure someone else would even use it, because it would be easy to be seen as clutter especially if abused. If a script matured and got heavily used, it could be moved to a more permanent location that was in the directory it was most applicable to. The other thing is, that it is hard to know where scripts are and what they are for right now. If there was an obvious top-level directory for that sort of thing, it would make it much easier to find out what was available to try on for size. > That may make more sense than putting them in a top level script directory - I > just have visions of hundreds of scripts there, with no real clue what half of > them do, and then you start wondering if this or that script should be deleted, etc. > > I think it also makes sense to have script dirs in the arch and map > distribution - there are already a bunch of map checking scripts in the server > area, but that doesn't make a lot of sense - people don't necessarily know that > they are there, etc. Agree mostly... but still think there might be an advantage to having them collected in a common scripts directory that had subdirectories named after the arch, maps, etc. they serve. Don't know SVN well enough, but it could be you could have some kind of "view" that also put them in the directory where they were most likely to be used, but as far as version control went, they were controlled in the common tools area. Mostly this is just thinking out loud. Don't know if it fits the project, but since I write scripts that aren't in SVN I was thinking about how I might be more likely to put them up for people to look at and adapt for their own use. From mwedel at sonic.net Thu Mar 8 02:23:45 2007 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 08 Mar 2007 00:23:45 -0800 Subject: [crossfire] Release schedule: was maps/tags/1.10/ In-Reply-To: <200703072230.28005.kbulgrien@worldnet.att.net> References: <200703060748.42183.kbulgrien@worldnet.att.net> <45EE5E19.40004@sonic.net> <200703072230.28005.kbulgrien@worldnet.att.net> Message-ID: <45EFC811.7020700@sonic.net> Kevin R. Bulgrien wrote: >> In terms of more frequent 'build' releases, I'm not sure how that really >> differs from a normal release. > > Perhaps a technicality, but having a distinction would make it "easier" to > release something even if there was a big bug unfixed, or it might be top of > tree so that new development gets tested quicker... and also encourages > new development to not go too long in an unusable state. Ok. I wasn't thinking about the head releases here, just the stable releases/branch. So we have the case where 1.10.0 was just released. The next official release (in 2-3 months time) would be called 1.11.0. So if we do these interim (every 2 week) releases, what do we call them? Now my thought, and also stated in the in the release guidelines, that micro releases could be done. So in the case of maps, if you have some bugs that need to be fixed and you want to make a new release, you could make a 1.10.1 and release it in a few weeks. I think that is perfectly reasonably, but should perhaps be more driven by bugs it fixes or other changes. It certainly doesn't make sense to make a map release every 2 weeks if the last thing that changed from the previous release were a few minor spelling mistakes. But the flip side is that if serious bugs are discovered, a release right away probably makes sense. And if a serious bug (say security) is discovered the day after that micro release, then another micro release a day later probably makes sense. There is also some advantage to this - for the micro releases, there is no need for a full release of all the components. If there are map fixes and they will work fine with the 1.10.0 server, make a micro release of the new map set, etc. For the stable release, this works pretty good, because big changes shouldn't be happening in the stable branches, so the interfaces should remain stable. IT does get a little trickier with the maps, because you could get the case where the new maps require new archetypes, yet the archetypes are part of the server, so you'd need to make a new server release. One could probably make a strong case that the data files from the server should be in a separate archive than the binaries (just like the maps are separate). Server admins are probably more willing to dump a new set of archetypes/maps down than to have to recompile everything and make sure nothing got messed up in the process. > >> If it is a semi private release (not uploaded to sourceforge), it probably >> won't get as widespread testing, and in fact may not get any testing. > > Not my intent. Say Joe wants to run a server... he picks stable because he > mostly wants to play with a bunch of friends and doesn't want a lot of risk > that stuff will be busted. Jack though, likes to hack around, and play the > bleeding edge, but he's not up to doing SVN checkout and build, so he goes > for the "unstable". It's all up to the downloader. It's not a new concept as > a number of big projects run that way... TortoiseCVS... CVS... etc. I'd not > say it is without some downsides if not managed well. As of now, we are not making any releases of the head branch. As said, that should perhaps change, but there are lots of downsides to it. There are actually lots to think about here - doing both head and stable releases double the release work. have things drifted far enough apart for this to make lots of sense? do we want to wait until we are close (6 months) from a 2.0 release and start doing releases then, on the basis that we know some things in the code right now are work in progress? One reason for the branches was to open up the head branch for more rapid development without the more strict model done in a stable release. But the other issue I mention is incompability between future releases. We pretty much know what is in the main trunk right now is pretty far away from 2.0, and will be incompatible in various ways. You can imagine some of the reaction where joe user downloads the snapshot of the trunk right now that we provides, and sets up a server on it because he wants bleeding edge. The next snapshot 2 months from now is various in incompatible ways, meaning that the player files have to be wiped, etc. I think the reaction there would be negative, not positive. This is a bit different than most other programs, where things may change in various incompatible ways, but you don't effectively lose 2 months of work because of it So in a sense, if we make those snapshots, we almost need to put a warning like "What, are you crazy? You almost certainly should be using the stable release because you may be forced to start with new characters at any time with this branch" That said, if people think we should put these releases out there, I won't stop it. but I personally would rather wait to the stage where we pretty sure things are somewhat stable in terms of not needing to wipe character, but may still have a fairly long train of other enhancements and bug fixes. d. >> >> If the scripts are not of release quality, there is nothing preventing us >> right now from putting those in something like maps/scripts-nrq (non release >> quality), and then just not include that directory when the data is tarred up. > > When I said release quality, I was meaning that I wouldn't necessarily want > someone to think I thought they were polished, but since they were in SVN, > someone could hack on them when I didn't. It seems too bad to hoard a > script just because I don't know where junk like that goes. It seems harder > to add a file in a maps directory, etc if your just hacking around a proof of > concept that might just fizzle. Having a tools area might make it easier to > chuck something in in case someone else might look at it and go... hey... > that's a cool idea, but how about doing it this way... or whatever. I tend to > feel less confident about uploading a script into say maps, or server if I'm > not sure someone else would even use it, because it would be easy to be > seen as clutter especially if abused. If a script matured and got heavily > used, it could be moved to a more permanent location that was in the > directory it was most applicable to. The other thing is, that it is hard to > know where scripts are and what they are for right now. If there was an > obvious top-level directory for that sort of thing, it would make it much > easier to find out what was available to try on for size. I see what your saying. I'm just concerned that such directories will end up filled with scripts in progress or otherwise stuff of questionable status, and then we're stuck trying to figure out what to do with it (should it get removed? Is someone going to work on it, etc). If too many misc. scripts are put in there, then it also becomes harder to find the useful/good ones. I suppose this could be helped somewhat by having a README file, with a requirement that if you add a script, you add a line to the README providing a quick summary, so someone can quickly look at the README and see what is there and what may be useful. Some level of coordination is still needed. I could see a script that hasn't been modified for 6 months which I don't think is particularly useful, but decide with some modifications, it would be. However, if someone else is finding it useful in its current form, and I change it in incompatible ways, that isn't a great thing either. I'm not positive if SVN is the best thing for work in progress type of stuff or not. But we could try it out. >> I think it also makes sense to have script dirs in the arch and map >> distribution - there are already a bunch of map checking scripts in the server >> area, but that doesn't make a lot of sense - people don't necessarily know that >> they are there, etc. > > Agree mostly... but still think there might be an advantage to having them > collected in a common scripts directory that had subdirectories named > after the arch, maps, etc. they serve. Don't know SVN well enough, but > it could be you could have some kind of "view" that also put them in > the directory where they were most likely to be used, but as far as > version control went, they were controlled in the common tools area. > Mostly this is just thinking out loud. Don't know if it fits the project, but > since I write scripts that aren't in SVN I was thinking about how I might > be more likely to put them up for people to look at and adapt for their > own use. You can do external references in SVN. So if someone does a 'svn checkout maps', it pulls scripts/maps into maps/scripts. However, that is done at the directory level. So this then doesn't work great if pre production quality scripts are there (as they are now part of the map area). Also, there isn't a major concept of controlled area. Right now, if you have SVN write access, you have it in all areas. So in that above example, if we have a scripts directory with maps/scripts being an external references to it, I can go into maps/scripts, make the changes, and to a svn commit and it would commit them just fine. It would commit them to scripts/maps, but I don't have to manually go to scripts/maps to do the checkin. The external reference support basically just provides a mechanism to link in other projects. The link doesn't even need to be the same project. I'm not sure what we really get by doing that, vs just having maps/scripts, arch/scripts, etc. I suppose the one thing is that it does provide an area for scripts outside of those areas, or which hits multiple areas (something that can process map files looking for spelling errors could probably also parse the archetypes files). The other case would be scripts to do the release process, etc. From pate at mail.ru Thu Mar 8 16:47:37 2007 From: pate at mail.ru (=?koi8-r?B?59LJx8/Syco=?=) Date: Fri, 9 Mar 2007 08:47:37 +1000 Subject: [crossfire] Compiling server (trunk, MS VC++ 6.0) Message-ID: <001901c761d3$c5c7fc40$e28ba252@pate> Good day everyone. I try to compile the server to debug the bug with server crash when user exits the game via the bed. So I get numerous "unresolved external symbol" Some of missing functions are in the reader.l and loader.l (neither reader.c nor loader.c nor swamp.c are in TRUNK or in BRANCH/1.x, which is strange, cause they are included in PROJECT) I don'd know what compiler should understand their syntax, but ok, I edited them for VC++ to understand. I get this: error C2065: 'yytext' : undeclared identifier error C2065: 'YY_CURRENT_BUFFER' : undeclared identifier error C2065: 'YY_BUF_SIZE' : undeclared identifier error C2065: 'yybufstate' : undeclared identifier etc. Strange, I do can't find any declarations of them in these sources. Other missing functions are in files which are not included in project at all. Like "legacy_ob_apply()", which is in the /types/legacy/apply.c Could anyone enlight me what I did wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.metalforge.org/pipermail/crossfire/attachments/20070309/e7e78a43/attachment.htm From lalo.martins at gmail.com Sat Mar 10 16:38:57 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Sat, 10 Mar 2007 22:38:57 +0000 (UTC) Subject: [crossfire] Pupland branch Message-ID: I re-created the pupland branch, and started by moving everything to where I think it should be according to the guidelines. As a special open issue, ancient Pupland went to /quests/pupland/ancient, but there are arguments for /ancient_pupland and /quests/ancient_pupland. So if anyone feels strongly about it, now would be the best time to speak up. Also, I'd like people to check out this branch and test if I fixed all the exits. If I have, I'm planning to merge this back into the trunk before starting the actual worldmap work. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From nicolas.weeger at laposte.net Mon Mar 12 13:57:08 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 12 Mar 2007 19:57:08 +0100 Subject: [crossfire] Pupland branch In-Reply-To: References: Message-ID: <200703121957.08875.nicolas.weeger@laposte.net> Le samedi 10 mars 2007 23:38, Lalo Martins a ?crit?: > I re-created the pupland branch, and started by moving everything to where > I think it should be according to the guidelines. > > As a special open issue, ancient Pupland went to /quests/pupland/ancient, > but there are arguments for /ancient_pupland and /quests/ancient_pupland. > So if anyone feels strongly about it, now would be the best time to speak > up. > > Also, I'd like people to check out this branch and test if I fixed all the > exits. If I have, I'm planning to merge this back into the trunk before > starting the actual worldmap work. Yeah! Thanks for the work :) Cheers Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From subs at eracc.com Mon Mar 12 14:02:57 2007 From: subs at eracc.com (ERACC Subscriptions) Date: Mon, 12 Mar 2007 13:02:57 -0600 Subject: [crossfire] Pupland branch In-Reply-To: References: Message-ID: <200703121302.58702.subs@eracc.com> On Saturday 10 March 2007 04:38 pm Lalo Martins wrote: > As a special open issue, ancient Pupland went to /quests/pupland/ancient Works for me. Using the underscores has caused some problems for me as a mapper in the past (specifically with the Lone Town Apartment). I prefer to avoid them. Gene Alexander -- ERA Computers & Consulting We can provide you with VoIP phone service for your home and/or business. Our VoIP phone service has FREE long distance in the USA and Canada! Contact us! Voice messages: 1(731)256-0973 - FAX & Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] From mwedel at sonic.net Tue Mar 13 01:20:35 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 12 Mar 2007 23:20:35 -0700 Subject: [crossfire] Maps passwords/phrases text Message-ID: <45F642B3.5020006@sonic.net> I think this may have been discussed informally on irc or other places, but for some reason I was thinking about this on the drive home from work tonight. I also didn't see this on the wiki immediately, which makes me think that any discussions haven't really been recorded. The basic premise of the problem is that passwords on the public maps are difficult to change, and in fact haven't been changed in a long time for that very reason. One would think that the city of scorn might want to change their gate password once in a while. The reason for this is pretty straightforward - going through all the maps and changing the passwords is not an easy task. Plus, if anyone else makes changes to those maps, you'll get conflicts on checkout. One just can't replace all uses of the word 'chain', as there could very well be other uses of that word unrelated to the password ("watch out for the chain lightning", etc). The real solution here is to use keywords instead of the actual word, like $SCORN_PASSWORD. So you'd have something like: @match $SCORN_PASSWORD you look ok, ... Now there are really 3 ways I thought this could be done. In all methods, you'd have a central file, that has things like: $SCORN_PASSWORD=chain $WHATEVER=... And to make the transition easier, all those defines would match the current values in the map. I'd have to think about it more - if it makes sense for other messages to be broader substitutions, like: SCORN_PASSWORD_WALL=The password used to be chain, I think it is now bar With the wall just using $SCORN_PASSWORD_WALL for its entire thing. This could also be used for more than just passwords - could be good portion of NPC conversations, eg: $SKELETON1_RIDDLE=What is at the start of end and the end of time $SKELETON1_ANSWER=e Method 1: Have a perl script (or the like) go through the maps, doing simple substitution. Advantages is pretty simple. Disadvantage - basically need two copies of the maps - one that this runs on and copies to final location (like a make install). Thus, you would do your svn updates on that first one, then run the substitute and copy script. You couldn't use the svn copy directly. Also danger of users trying to use the data from SVN directly, and getting those odd values. One plus is that this doesn't require any changes to the server. One minus is that the server still doesn't know anything about these passwords, so thus can not manipulate them. Method 2: Have a file that the server reads at startup which lists the password. When the server loads a map from disk, it runs the substitution on the msg portions of archetypes. This is pretty good as there is minimal code changes (do substitution on msg structure after loading object from map). This would increase map load times some. Since the server knows about the passwords, these can be manipulated in game via dm commands (set_password SCORN_PASSWORD bar) or the like. These wouldn't take effect immediately, but instead on next map reset/reload (which could be sped along by other DM commands, like reset map, etc). If the password file is installed into the var area, this would be a modifiable file, like the ban file, so changes of passwords could be temporary (last until next server reset or someone else sets them) or permanent (well, until someone resets them, but last across reboots). Another advantage is that since the password file would be in lib, and installed as part of make install, it would be impossible to run a server without at least the basic password file. Could even be some interesting things beyond just dm commands - it'd somehow be interesting to tie changing certain passwords to other things (high ranking nobles (via the scorn nobility quest) being able to change the scorn password, etc). That gets more complicated, and would probably be a followon project (or maybe tied in by scripts would be easier way - scorn noble goes to certain office, and python script checks his rank, etc). Method 3: A bit like method 2, in that the server does the substitution, but not at load time, but rather when the msg structure is referenced. This probably has more an impact on performance during actualy play, but probably not too much (if the $ or other unique character is used to denote these, then at load time the loader could quickly examine the msg structure for those fields and mark if it needs to be updated). The only real benefit of this method over #2 is that changes to the password take effect immediately (dm changes the passwords, map in memory have the new password right away). I personally like #2. The potential lag in updates, at least for some things like the scorn password, makes sense - takes some time for that information to get to everyone. Just my ramblings for the night. From nicolas.weeger at laposte.net Tue Mar 13 14:00:58 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 13 Mar 2007 20:00:58 +0100 Subject: [crossfire] Maps passwords/phrases text In-Reply-To: <45F642B3.5020006@sonic.net> References: <45F642B3.5020006@sonic.net> Message-ID: <200703132000.58981.nicolas.weeger@laposte.net> Hello. > The real solution here is to use keywords instead of the actual word, > like $SCORN_PASSWORD. So you'd have something like: > > @match $SCORN_PASSWORD > you look ok, ... Agreed there, shouldn't be too hard. Also makes everything way more souple, not linked to maps. Of course, there should be appropriate warnings when a variable isn't found in the substitution file. > Method 1: Not really that great IMO, for the reasons you give. > Method 2: I like that method. IMO, that could even be done through a small plugin - intercept the EVENT_MAPLOAD and do the substitution. > Method 3: This method has one drawback, in that it adds some overhead to every NPC talk / magic ear/mouth. Note that this is similar to what I did for the quest management stuff, btw (change the message dynamically). If I were to choose, I'd choose #2 :) I like both methods #2 and #3, because they give DM some more power over the world. IMO we should move to that kind of system for game-related options - let DMs customize. Arguably, it's the role of the server administrator, but he doesn't always have the time for everything, and currently many options require a server restart. For instance, if we ever implement shop opening hours, that'd be something I'd let DMs tweak ingame directly :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From mwedel at sonic.net Tue Mar 13 23:12:08 2007 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 13 Mar 2007 21:12:08 -0700 Subject: [crossfire] Maps passwords/phrases text In-Reply-To: <200703132000.58981.nicolas.weeger@laposte.net> References: <45F642B3.5020006@sonic.net> <200703132000.58981.nicolas.weeger@laposte.net> Message-ID: <45F77618.8090003@sonic.net> Nicolas Weeger wrote: > Hello. > >> The real solution here is to use keywords instead of the actual word, >> like $SCORN_PASSWORD. So you'd have something like: >> >> @match $SCORN_PASSWORD >> you look ok, ... > > Agreed there, shouldn't be too hard. Also makes everything way more souple, > not linked to maps. > Of course, there should be appropriate warnings when a variable isn't found in > the substitution file. True - as long as some special character is used, that is easy enough to do. $ may be just as valid as anything. >> Method 2: > > > I like that method. > > IMO, that could even be done through a small plugin - intercept the > EVENT_MAPLOAD and do the substitution. I should look at the plugins further. But right now, there is a 'check object' type function in loader.l that is called each time after the object is loaded. Its original purpose was to catch things that changed in various versions. Adding the substitution there would be easier, and perhaps faster than a plugin, simply because that substitution would be done right after the object is loaded, so more likely to have stuff in local cpu cache, vs having to iterate through all the objects in the map later. Plus, you'd have a lot of cases where op->msg is null, and checking for that in that function would be very fast - while also fast in a plugin, you'd still get the overhead of having to iterate through the map objects, so you're spending some extra just going through the object points, going through inventories, etc. But as I think further, if some defined character, like $ is used to denote these, then I think the actual msg parsing code in the lex loader could be used to find these, perhaps make it even faster (could get the variable name from the lex parser, do a simple btree type search to find what it subsitutes to, and copy that in the temp buffer right now - better than doing it later and having to make a new buffer because the size is going to be different, and copy/substitute at that point). > >> Method 3: > > > This method has one drawback, in that it adds some overhead to every NPC > talk / magic ear/mouth. > Note that this is similar to what I did for the quest management stuff, btw > (change the message dynamically). The related problem with that is that it also means a lot more code needs updating - anything that references the op->msg probably needs to be updated, where as with method #2, none of the other code has to be touched - everything is handled at load time. > I like both methods #2 and #3, because they give DM some more power over the > world. IMO we should move to that kind of system for game-related options - > let DMs customize. > Arguably, it's the role of the server administrator, but he doesn't always > have the time for everything, and currently many options require a server > restart. > For instance, if we ever implement shop opening hours, that'd be something I'd > let DMs tweak ingame directly :) I'd almost say there should be different access levels: 0) Normal player, can't do anything special. 1) Extended access granted through in game mechanisms (finishing quests, etc) which provide access to a limited set of changes (lords of scorn changing scorn password, or maybe changing business hours, or perhaps even shutting down shops temporarily). This adds some interest in that by doing some in-game stuff, you can have more noticable effects on the game world. 2) Wiz access granted by server admin. These people would have access to everything/every region of #1 access (change passwords anywhere) plus some extended access (summon players, item creation, etc). There may be some wiz commands not available, like shutdown, which these people generally shouldn't have. 3) Admin access, which can do anything provided through the crossfire interface (all dm commands) . From nicolas.weeger at laposte.net Sat Mar 17 07:11:31 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 17 Mar 2007 13:11:31 +0100 Subject: [crossfire] Reincarnation Message-ID: <200703171311.31796.nicolas.weeger@laposte.net> Hello. Cleaning the treasures files (exploding in individual .trs files), I found old cruff about reincarnation: it can possibly change player's race. But the treasure list was using old (now removed) archetypes. So that should be fixed, if someone knows how to? Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Sat Mar 17 13:06:47 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 17 Mar 2007 19:06:47 +0100 Subject: [crossfire] Random map layout Message-ID: <200703171906.47576.nicolas.weeger@laposte.net> Hello. Current random map layouts are kind of limited, and repetitive, and such :) To improve that, I'd like to either alter existing layouts or add new ones. I just committed some changes that enable a plugin to access random map code generation, including giving a layout for map filling (add walls, exits, monsters, ...). Would it be better to add those new layouts through a plugin, or directly into the random_maps code? Note that to correctly work, the plugin needs an event_apply into the exit that should point to a random map, to hook. I already made a proof-of-concept layout generator, that correctly works. Would be a matter to implement the layouts there, simply. Opinions welcome :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Sat Mar 17 14:25:26 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 17 Mar 2007 20:25:26 +0100 Subject: [crossfire] Plugin generation script Message-ID: <200703172025.26507.nicolas.weeger@laposte.net> Hello. If anyone wants to create plugin, I just did a small sh script to help, located in plugins/template/create_plugin.sh Syntax is: create_plugin.sh id [name] where id is the plugin's identifier (Python, CFAnim, ...). Script will update required Makefile.[in|am] and configure.ac files, and run automake & autoconf. Just need to run configure after that, plugin should be good to go. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From alex_sch at telus.net Sun Mar 18 00:15:09 2007 From: alex_sch at telus.net (alex_sch at telus.net) Date: Sat, 17 Mar 2007 22:15:09 -0700 Subject: [crossfire] Random map layout In-Reply-To: <200703171906.47576.nicolas.weeger@laposte.net> References: <200703171906.47576.nicolas.weeger@laposte.net> Message-ID: <1174194909.45fccadd96b90@webmail.telus.net> Quoting Nicolas Weeger : > Current random map layouts are kind of limited, and repetitive, and such :) > To improve that, I'd like to either alter existing layouts or add new ones. Agreed :) > I just committed some changes that enable a plugin to access random map code > generation, including giving a layout for map filling (add walls, exits, > monsters, ...). > > Would it be better to add those new layouts through a plugin, or directly > into > the random_maps code? My view is that it'd be best to include directly in the random_maps code, except for two cases: 1) prototyping, or 2) a layout that's completely unique to one location in crossfire and isn't that useful elsewhere. Alex Schultz From subs at eracc.com Sun Mar 18 17:01:56 2007 From: subs at eracc.com (ERACC Subscriptions) Date: Sun, 18 Mar 2007 17:01:56 -0500 Subject: [crossfire] Random map layout In-Reply-To: <200703171906.47576.nicolas.weeger@laposte.net> References: <200703171906.47576.nicolas.weeger@laposte.net> Message-ID: <200703181701.57743.subs@eracc.com> On Saturday 17 March 2007 01:06 pm Nicolas Weeger wrote: > To improve that, I'd like to either alter existing layouts or add new ones. I vote for adding new ones, please. Gene Alexander -- ERA Computers & Consulting We can provide you with VoIP phone service for your home and/or business. Our VoIP phone service has FREE long distance in the USA and Canada! Contact us! Voice messages: 1(731)256-0973 - FAX & Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] From mwedel at sonic.net Sun Mar 18 22:43:00 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 18 Mar 2007 20:43:00 -0700 Subject: [crossfire] Random map layout In-Reply-To: <200703171906.47576.nicolas.weeger@laposte.net> References: <200703171906.47576.nicolas.weeger@laposte.net> Message-ID: <45FE06C4.4050302@sonic.net> Nicolas Weeger wrote: > Hello. > > Current random map layouts are kind of limited, and repetitive, and such :) I don't think it was ever designed to cover all possible map possibilities, but was really put in to add some more maps for the game. > > To improve that, I'd like to either alter existing layouts or add new ones. > > I just committed some changes that enable a plugin to access random map code > generation, including giving a layout for map filling (add walls, exits, > monsters, ...). > > Would it be better to add those new layouts through a plugin, or directly into > the random_maps code? > Note that to correctly work, the plugin needs an event_apply into the exit > that should point to a random map, to hook. > > I already made a proof-of-concept layout generator, that correctly works. > Would be a matter to implement the layouts there, simply. My thought is this In general, the code should be in the random maps (C) code for most of the layout. However, it would certainly be a good thing to be able to hook plugins into aspects of the map generation. IIRC, there are about half a dozen steps in doing a random map - putting down the walls, putting in doors, putting in exits, putting in monsters, etc. It'd be really nice to be able to have something like (psuedo python code here): event_apply for random exit: do_standard_layout(); do_standard_walls() do_my_custom_monster_generation() (function is in this plugin, etc) do_standard_treasure(); etc. As for why C code vs python: I'll first admit I'm submit biased, as I'm not much a python user, but for me, it mostly comes down to it seems much easier to debug C code when things go wrong than the python code - much easier to see what line of code it was, all the values it was using, etc, than the python logic - I'm sure it can be done in some ways, but isn't as automatic to see what actual line of python script was executing, the values in the python script, etc. From nicolas.weeger at laposte.net Wed Mar 21 13:46:01 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 21 Mar 2007 19:46:01 +0100 Subject: [crossfire] Pickup mode Message-ID: <200703211946.02045.nicolas.weeger@laposte.net> Hello. I'd like to remove old pickup mode code, and either remove totally support for it, or merge it with new pickup. Objections? Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From mwedel at sonic.net Fri Mar 23 01:46:57 2007 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 22 Mar 2007 23:46:57 -0700 Subject: [crossfire] Pickup mode In-Reply-To: <200703211946.02045.nicolas.weeger@laposte.net> References: <200703211946.02045.nicolas.weeger@laposte.net> Message-ID: <460377E1.1020403@sonic.net> Nicolas Weeger wrote: > Hello. > > I'd like to remove old pickup mode code, and either remove totally support for > it, or merge it with new pickup. My thought is that perhaps it should go away, but there be some sort of compatibility mode, such that if you select some value with old pickup mode, it means it is effectively this with new pickup. I know that I'm still in the habit of going to 'pickup 4' to pick up everything in a dungeon, and then 'pickup 0' when I'm done (4=everything, 0=nothing). I don't really care how that works internally, but I'd be nice to keep those old (simple) pickup modes for those of us that do use the command to switch pickup modes. I would think that those could be converted to new pickup modes in most cases, or even pretty close cases (I wouldn't care if pickup 4 actually did skip cursed or unpaid objects for example). Likewise, the value density modes could perhaps get rounded/adjusted to the nearest value in new pickup mode, etc. From nicolas.weeger at laposte.net Sun Mar 25 12:46:11 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 25 Mar 2007 19:46:11 +0200 Subject: [crossfire] New plugin: cfnewspaper Message-ID: <200703251946.11517.nicolas.weeger@laposte.net> Hello. I just committed a new plugin, 'cfnewspaper', which as its name implies is a newspaper generating plugin :) It is really an alpha version. For now, it'll only list monster and player deaths for the last ingame day. I hope to improve it to add many more things, but of course other people can help too :) In particuler I plan on having regional papers. For now plugin only replies to the 'apply' event, inserting the newspaper into applied object - mail box, anything. Note that it uses cflogger's database, so you'll need to use that other plugin too. (yes, i could have done that with Python, but well...) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From mwedel at sonic.net Mon Mar 26 01:52:05 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 25 Mar 2007 23:52:05 -0700 Subject: [crossfire] New plugin: cfnewspaper In-Reply-To: <200703251946.11517.nicolas.weeger@laposte.net> References: <200703251946.11517.nicolas.weeger@laposte.net> Message-ID: <46076D95.70205@sonic.net> Nicolas Weeger wrote: > Hello. > > I just committed a new plugin, 'cfnewspaper', which as its name implies is a > newspaper generating plugin :) > > It is really an alpha version. For now, it'll only list monster and player > deaths for the last ingame day. > > I hope to improve it to add many more things, but of course other people can > help too :) > In particuler I plan on having regional papers. Regional papers is a good idea. Other thoughts of things to add in the paper: Quest information - people doing the nobility quest of scorn as an example Maybe most valuable items recently sold. Player deaths in the area. A thing on the RFE list would be regional based messages. I'd perhaps extend that to type based messages, eg: REGION scorn TYPE newspaper (other possiblities are things like scroll, book, and npc) If the messages file got big/complete enough, it could actually be worthwhile to talk to NPC's for information (npcs with default messages perhaps get one of the random ones added). From mwedel at sonic.net Tue Mar 27 01:47:39 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 26 Mar 2007 23:47:39 -0700 Subject: [crossfire] Release schedule/notes Message-ID: <4608BE0B.4010305@sonic.net> After finally finishing up the 1.10.0 release, and the discussion around that, quick thoughts on future releases. In this discussion, I'm talking about minor releases from the 1.x branch, so this next release would be 1.11.0 Doing somewhere between 3 and 6 releases/year seems roughly the right rate - not so much time is being used making releases, yet is it often enough to get changes out there, but not so often than a release might only have 2 changes. So I'd say that puts the next release in the June timeframe. That probably works for my schedule, presuming I'm the person still doing the release. I'd send out mail as the date gets closer. Other thoughts: I'd say there is nothing prevent some micro releases of some components between now and then, if a change warrants it. For example, map and archetype changes are quite quick to do and contain perhaps some of the more noticable changes to the player, so doing a micro release of those between now and then may make sense. Likewise critical bug fixes in either the server of client would warrant a micro release (1.10.1). I'm not sure if doing releases of those, especially the server, makes sense, as that is a bit more of a pain. --- Main trunk releases: The server is going under some major changes - I'm not sure it makes sense to do releases until that is sorted out. Just from my experience with the 1.10.0 release, it would seem that someone could otherwise be spending a lot of time getting it so the release aspect of it works, only to have a lot of that work go away as files and other paths may change. The client, as of right now, should be compatible with older server (eg, a trunk client can player on a 1.10.0 server without problems), so we could do releases of those. I almost wonder if it makes sense to completely decouple the numbering schemes between those, and instead have a compatibility chart. My expectation is that trunk client will likely be able to play on 1.x servers until some protocol changes are made and the legacy support for older protocol is removed from the client. What this effectively means is that one day the trunk client could work with 1.x, and the next day it doesn't. maps & archetypes: These are almost one piece, as they depend on each other pretty heavily. I don't believe there have been any server changes required for the maps & archetypes as we have them now, so releases on those could be made. OTOH I also don't recall seeing any major changes, so making releases of pre 2.0 releases of just the maps & archetypes would be confusing. I really thing, relative to the trunk, this is a brief outline of steps: 1) Finish with the major overhaul of whatever we plan to overhaul in the trunk server for 2.0 2) Set up some test server(s), see how they work. 3) start worrying about making pre 2.0 releases once we have a pretty good idea that what we have will have some semblance to what final 2.0 will look like. From alex_sch at telus.net Tue Mar 27 19:08:48 2007 From: alex_sch at telus.net (alex_sch at telus.net) Date: Tue, 27 Mar 2007 17:08:48 -0700 Subject: [crossfire] Release schedule/notes In-Reply-To: <4608BE0B.4010305@sonic.net> References: <4608BE0B.4010305@sonic.net> Message-ID: <1175040528.4609b21014e75@webmail.telus.net> Quoting Mark Wedel : > Doing somewhere between 3 and 6 releases/year seems roughly the right rate - > not so much time is being used making releases, yet is it often enough to get > changes out there, but not so often than a release might only have 2 changes. This rate seems to make sense to me. > Other thoughts: I'd say there is nothing prevent some micro releases of some > components between now and then, if a change warrants it. For example, map > and archetype changes are quite quick to do and contain perhaps some of the > more noticable changes to the player, so doing a micro release of those > between now and then may make sense. Likewise critical bug fixes in either > the server of client would warrant a micro release (1.10.1). To me, it seems more sane to reserve micro releases solely to bug fixes of particular note (affects gameplay significantly or affects security). Generic quick changes seem like they wouldn't be worth doing micro releases for really. > Main trunk releases: > The server is going under some major changes - I'm not sure it makes sense to > do releases until that is sorted out. Just from my experience with the 1.10.0 > release, it would seem that someone could otherwise be spending a lot of time > getting it so the release aspect of it works, only to have a lot of that work > go away as files and other paths may change. Agreed. Also note, in terms of finishing major changes first, though the current going code changes are among them, we should also think about gameplay changes, think about what frusturates players, and think about how to change the game mechanics to improve that. Those things are even more important IMHO to warrenting a 2.0 release and we should remember that code restructuring while important, is largely so the gameplay changes and features are easier to deal with. I suggest in terms of gameplay changes/improvements, before we look at things like adding a character creation menu, we should look at things like movement/attack speed which are easier to change the algorithm for but require greater testing and thought IMHO. (Ok, done drifting off from Mark's topic :)) > maps & archetypes: These are almost one piece, as they depend on each other > pretty heavily. I don't believe there have been any server changes required > for the maps & archetypes as we have them now, so releases on those could be > made. OTOH I also don't recall seeing any major changes, so making releases of > pre 2.0 releases of just the maps & archetypes would be confusing. Well, recently Ragnor did remove some depreciated parsing code from the server for things like "flying", and changed the arches accordingly, thus we'd need pre 2.0 arches and probably maps along with a pre 2.0 server release. > I really thing, relative to the trunk, this is a brief outline of steps: > 1) Finish with the major overhaul of whatever we plan to overhaul in the trunk > server for 2.0 > 2) Set up some test server(s), see how they work. > 3) start worrying about making pre 2.0 releases once we have a pretty good > idea that what we have will have some semblance to what final 2.0 will look > like. A quick comment on this, is once #1 of that gets to a certain stage, #2 and #1 should probably go in parallel :) From nicolas.weeger at laposte.net Sat Mar 31 01:32:50 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 31 Mar 2007 08:32:50 +0200 Subject: [crossfire] New plugin: cfnewspaper In-Reply-To: <46076D95.70205@sonic.net> References: <200703251946.11517.nicolas.weeger@laposte.net> <46076D95.70205@sonic.net> Message-ID: <200703310832.50274.nicolas.weeger@laposte.net> > Regional papers is a good idea. > > Other thoughts of things to add in the paper: > Quest information - people doing the nobility quest of scorn as an > example Maybe most valuable items recently sold. > Player deaths in the area. > > A thing on the RFE list would be regional based messages. I'd perhaps > extend that to type based messages, eg: > REGION scorn > TYPE newspaper (other possiblities are things like scroll, book, and npc) > > If the messages file got big/complete enough, it could actually be > worthwhile to talk to NPC's for information (npcs with default messages > perhaps get one of the random ones added). There alread is a mechanism to handle different newspaper, based on region. Hasn't been much tested, but well, it'll be soon enough :) As for other reports, sure, needs to have cflogger log'em, then cfnewspaper can use'em :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From mwedel at sonic.net Sat Mar 31 01:41:49 2007 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 30 Mar 2007 23:41:49 -0700 Subject: [crossfire] Release schedule/notes In-Reply-To: <1175040528.4609b21014e75@webmail.telus.net> References: <4608BE0B.4010305@sonic.net> <1175040528.4609b21014e75@webmail.telus.net> Message-ID: <460E02AD.4010506@sonic.net> alex_sch at telus.net wrote: >> Other thoughts: I'd say there is nothing prevent some micro releases of some >> components between now and then, if a change warrants it. For example, map >> and archetype changes are quite quick to do and contain perhaps some of the >> more noticable changes to the player, so doing a micro release of those >> between now and then may make sense. Likewise critical bug fixes in either >> the server of client would warrant a micro release (1.10.1). > > To me, it seems more sane to reserve micro releases solely to bug fixes of > particular note (affects gameplay significantly or affects security). Generic > quick changes seem like they wouldn't be worth doing micro releases for really. I generally agree. OTOH, if someone wants to do a release of some component to fix some aspects, I don't think there is a big reason to stop them OTOH, scheduling has to be done properly - it doesn't make sense to do a micro release 2 days before the next minor release. > >> Main trunk releases: >> The server is going under some major changes - I'm not sure it makes sense to >> do releases until that is sorted out. Just from my experience with the 1.10.0 >> release, it would seem that someone could otherwise be spending a lot of time >> getting it so the release aspect of it works, only to have a lot of that work >> go away as files and other paths may change. > > Agreed. Also note, in terms of finishing major changes first, though the current > going code changes are among them, we should also think about gameplay changes, > think about what frusturates players, and think about how to change the game > mechanics to improve that. Those things are even more important IMHO to > warrenting a 2.0 release and we should remember that code restructuring while > important, is largely so the gameplay changes and features are easier to deal > with. I suggest in terms of gameplay changes/improvements, before we look at > things like adding a character creation menu, we should look at things like > movement/attack speed which are easier to change the algorithm for but require > greater testing and thought IMHO. (Ok, done drifting off from Mark's topic :)) Ordering of what to work on is always tricky. Especially given the volunteer nature. What I'd put near the top: - things which hold dependencies (I can't do Y until X is finished, so X should be done sooner, not later - Changes that result in incompatibilities (say different save file format), or game play changes that would be hard to fix with script, making it so that the only fair thing to do is start with all new characters (changing how exp is gained, enchanting objects, etc, could fall into this case, with the older characters have a perceived benefit that the new characters can't get) - Game changes related to balance, as the process of changing those could take quite a while (this character too weak at low levels, but too powerful at high, etc) while changes to gameplay themselves should be done sooner, not later, it depends on the change. In the example of speed/attack speed - in some sense, that could be done at any time (even to the 1.x release), the main issue being that it could be confusing/misleading to players because they attacked at speed X, and now attack at speed X/2 for example, making things more difficult. This sort of falls into the incompatibilies realm, but to a lesser extent. IT probably also falls into the game game changes related to balance - if player speed is changed, that changes the balance all around - you couldn't do it late in the process. And while some cosmetic changes may not make sense, in other cases, it may make sense rather than doing two versions of the code. For example, if we change the way characters are created (like you get so many stat points), and even extend it to things like choosing some skills, it doesn't make a lot of sense to do it once with draw infos, replies, message states in the server, and then later, write up the nice GUI for it - in a sense, it is less effort to just do that gui while those other changes are going on so that code isn't written that is then thrown away.