From smurf at CSUA.Berkeley.EDU Tue Jan 1 13:28:53 2002 From: smurf at CSUA.Berkeley.EDU (Scott MacFiggen) Date: Thu Jan 13 18:01:58 2005 Subject: [CF-Devel] Client/server protocol enhancements. In-Reply-To: <3C311F6C.80ECD1F8@sonic.net>; from mwedel@sonic.net on Mon, Dec 31, 2001 at 06:31:08PM -0800 References: <3C268EE6.5A55520B@sonic.net> <20011230125142.A25962@CSUA.Berkeley.EDU> <3C2FFF77.D456B71A@sonic.net> <20011231005148.A4535@CSUA.Berkeley.EDU> <3C311F6C.80ECD1F8@sonic.net> Message-ID: <20020101112853.A36941@CSUA.Berkeley.EDU> On Mon, Dec 31, 2001 at 06:31:08PM -0800, Mark Wedel wrote: > A minor wishlist for me would be to make the map in the gtk client > scrollable - if using fog of war, it is sometimes convenient to > thing 'so what was over there again', and being able to scroll to > over their would be cool. That probably isn't too hard, but for > reasons of optimization, you really only want to render what is actually > being shown on the monitor, and not the entire canvas. I've thought about this myself, it should be easy to implement but it would be memory intensive.. > As said, currently text descriptions are not contained anyplace within the > server. That of course could change. For spells, we could send along > spellpath and spellpoint information. AS said, that last one can vary > based on many things. That could be useful for requestinfo protocol > command. As far as I'm concerned, the more info we can get to the player, the better. So if it is possible and not difficult, I'd like to see it in the next rev of the protocol. If that happenes I'll modify the gtk client to take advantage of it. > Formulas for damage/range/etc get complicated. One reason is that > the client does not have that information for the items (client > has no idea that the sword does 8 points of damage for example). > Or are you talking damage etc for spells? I was talking about spells since I know the client doens't know anything about objects, which I think is wrong but it would take more than a simple protocol extension to fix that problem. > cost, how it advances, and the spellpath would be no problem. Sending > along range and damage and how it increments could be a little iffy > depending on if people consider that secret information or not. I read a game design book a while back that was pretty blunt on this subject. The book said it was bad game design to hide things from players. The basic idea was why put something in your game and then not tell the player about it.. Also, I would think any good wizard who has spent years studying his magic would know the approximate effectivness of his spells. Anyway, if this info gets sent over to the client, I'll modify the gtk client to make use of it. > s->c: newplayerstats ... > > flag would be set/cleared depending on if a point total was being used, or if > the stats had to come back legitimately. Note that presuming swap stats is > still allowed, the str/dex/con values for each race are the adjustments (eg, +1, > -2, etc), and not the stats if they choose that race, because the swapping is > not symmetrical. EG, thing of an elf with +1 dex, -1 con. Suppose 16 was > rolled for both of those, so 17 dex and 15 con. If you swap those, you would > still have 17 dex and 15 con because the base roll is 16. Yeah, that looks right. > Spells (and most equipment) is based on class. Some skills and equipment > are on race, some on class. So you would then have to extend it the > newplayer stuff to also send the available classes. However, > I'm not positive if that is as easily done as the race is (I'd have > to look at how the hall of heroes does it). It would certainly be > possible to set up archetypes for the classes that > then send along the right stuff. Could have another selection list > above that also contains the class, shows the adjustments it has.) I would prefer it all in one step, easier for a newbie to figure out what is going on.. The hall of hereos thing works ok too though. -Scott From bugs at real-time.com Tue Jan 1 02:10:05 2002 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:58 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200201010810.g018A5N26719@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=368 http://bugzilla.real-time.com/show_bug.cgi?id=374 http://bugzilla.real-time.com/show_bug.cgi?id=379 http://bugzilla.real-time.com/show_bug.cgi?id=381 http://bugzilla.real-time.com/show_bug.cgi?id=382 http://bugzilla.real-time.com/show_bug.cgi?id=384 http://bugzilla.real-time.com/show_bug.cgi?id=385 http://bugzilla.real-time.com/show_bug.cgi?id=386 http://bugzilla.real-time.com/show_bug.cgi?id=388 http://bugzilla.real-time.com/show_bug.cgi?id=389 http://bugzilla.real-time.com/show_bug.cgi?id=390 From michael.toennies at nord-com.net Wed Jan 2 06:30:29 2002 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:59 2005 Subject: [CF-Devel] RE: [Crossfire-cvs] CVS commit: crossfire In-Reply-To: Message-ID: Hm, which kind of server crashes? Iam a bit curious about it, because the core routines aren't triggered by ani official client and the information grapping stuff inside other routines can't be problematic. The only other thing is that i forced to use the head tile. But thats something whats introduced earlier from mark. Has you a log or something what crashes and why? > Module Name: crossfire > Committed By: garbled > Date: Wed Jan 2 06:53:23 UTC 2002 > > Modified Files: > crossfire/common: anim.c > crossfire/crossedit: Attr.c > crossfire/include: libproto.h sproto.h > crossfire/server: main.c player.c time.c > > Log Message: > Backout of Anim25 patch by michtoen. It was causing server crashes, and > is generally not useful in a non-iso crossfire. Discussed w/ mwedel. > > From jbontje at suespammers.org Wed Jan 2 08:39:07 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:01:59 2005 Subject: [CF-Devel] overlay code conflicts with permanent maps -> havoc Message-ID: <20020102153907.A38189@freebsd.localdomain> Since my last update, featuring garbleds overlay code, all the permanent maps dont work anymore. The overlay code seems to be causing this. It cause 1 crash so far, but this behaviour is much worse. My players are revolting, I can hardly keep them from eating me alive. See for yourself on my server: login, create a char, get a permmap, move out of the map, save somewhere else, logoutm return, permmap is gone. I can replace a backup of the playerfiles, but this will happen right again: the server code is doing this. Regards, Joris Bontje / mids -- Gpg Key: Id=0xF19326A9 / http://mids.student.utwente.nl/~mids/jbontje.pub Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 238 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020102/a4b6ce1c/attachment.pgp From root at garbled.net Wed Jan 2 14:06:38 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:59 2005 Subject: [CF-Devel] RE: [Crossfire-cvs] CVS commit: crossfire In-Reply-To: Message-ID: On 02-Jan-02 Michael Toennies wrote: > Hm, which kind of server crashes? > Iam a bit curious about it, because the core routines aren't triggered by > ani > official client and the information grapping stuff inside other routines > can't be problematic. > > The only other thing is that i forced to use the head tile. But thats > something whats > introduced earlier from mark. > > Has you a log or something what crashes and why? Two problems I saw: 1) millions of lines in the logfiles from the following code: #ifdef DEBUG /* hm, should really not happens */ if(!op->animation_id || !NUM_ANIMATIONS(op)) { LOG(llevError,"Object lacks animation.\n"); dump_object(op); return; } #endif 2) Crashes from the following code: max_state=NUM_ANIMATIONS(op)/ NUM_FACINGS(op); base_state=0; Because in some cases, NUM_FACINGS(op) was coming up 0. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From yann.chachkoff at MailAndNews.com Wed Jan 2 14:33:48 2002 From: yann.chachkoff at MailAndNews.com (Yann Chachkoff) Date: Thu Jan 13 18:01:59 2005 Subject: [CF-Devel] Starting Suspended Animation Process Message-ID: <3C3E4A67@MailAndNews.com> Gros the Quibbler again - but maybe for the last time... Again unstable and undocumented feature popped out on the CVS code. Although I understand quite well the motivations of acting so, as well as the problems any OpenSource project like Crossfire needs to handle, I do not approve them. Thus I had two choices: either "entering the arena" and trying to convince people I'm right, or find another way to enjoy myself. The first solution was quite unsatisfying me - I'm not even sure myself to be right. I didn't like the second one, too: I like Crossfire, and contributing to it was indeed too fun to leave. But it seems that the project now reached a point where more coders was more annoying than profitable. I don't want to contribute to this, and maybe Crossfire needs a more "concentrated" team of developers, allowing it to progress faster than now. As a result, I decided to leave the status of active developer. All my current development projects will be stopped at the end of the week. I just want not to be removed from the developers list, to allow me to still assure the current CFPython plugin support (debugging and porting). All my currently unfinished works will be sent to another one so it will not be lost. I can only hope that although unstable or unbalanced, they'll be of any use. Maybe I may write code again someday for Crossfire - who knows ? Y.E.J "Gros" Chachkoff ----------------------------------------- Visit http://www.chachkoff.f2s.com for a journey into a fantastic world ! (But don't expect too much...) ----------------------------------------- From root at garbled.net Wed Jan 2 16:11:21 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:59 2005 Subject: [CF-Devel] Starting Suspended Animation Process In-Reply-To: <3C3E4A67@MailAndNews.com> Message-ID: On 02-Jan-02 Yann Chachkoff wrote: > Again unstable and undocumented feature popped out on the CVS code. > Although I understand quite well the motivations of acting so, as well as the > problems any OpenSource project like Crossfire needs to handle, I do not > approve them. Well.. I sincerely apologize for not posting first.. I really should have done so. So there are two things I'd like to try and do to rectify this: 1) Open this up for discussion. Yes, it's allready committed.. but I'm completely willing to backout and/or make changes. Since I screwed up, and didn't post first.. I will take complete responsibility for a backout if people want me to back it out. 2) Describe what it is that I did, and attempt to document it here for everyone. The overlay code does the following: An overlay is a partial map, which is loaded on top of the original map. Any items on the overlay are loaded in addition to items normally on the map from the standard map files. Overlay maps are not normally saved. There are two situations when an overlay map is saved. 1) During an emergency save. 2) When using the new world maps, the world map is slowly processed and re-saved via overlays. Overlays allow one to make modifications to a map, without modifying the original maps. In this way, information such as temperature or weather conditions can be saved in the map headers, and continually updated regardless of a new version of the map being downloaded. In addition, things such as additions by DM's can be saved on these overlays. Nothing alive is ever saved on an overlay. When a map is loaded via ready_map, it attempts to load the overlay for that map. If none exists, it continues without it. If one does exist, it loads the overlay, and replaces the map header with the one on the overlay. It also loads and places any items on the overlay map onto the map. There also exists a decay algorithim, which fires off at ready_map(). This algorithim looks over the entire map for things that were not loaded as part of the original maps (marked with a flag FLAG_OBJ_ORIGINAL) and slowly decays those objects, to prevent them from accumulating forever. In addition, the weather code, which slowly processes the entire worldmap over the course of a day, runs the decay as it goes. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From kevin at ank.com Wed Jan 2 18:51:49 2002 From: kevin at ank.com (kevin@ank.com) Date: Thu Jan 13 18:01:59 2005 Subject: [7] RE: [CF-Devel] Starting Suspended Animation Process In-Reply-To: References: <3C3E4A67@MailAndNews.com> Message-ID: <20020102165149.A23882@balrog.ank.com> I think what Yann really needs is a stable branch; or perhaps Tim needs an unstable branch. I've worked on some very large projects and you really have to be able to destabilize the tree at certain points to make any progress. Overlays sound like a very useful feature for the large map work that is going on. But that obviously shouldn't destabilize an active server like 'mids'. By branching the CVS trunk at some point it would be possible to continue patching problems in the stable branch while adding more dangerous but also more exciting changes to the main branch. Porting patches back to the main trunk can become a bit of a chore, but ultimately when the next stable version is branched it will stabilize regardless of whether the patches have all been moved or not. Cheers, -kls On Wed, Jan 02, 2002 at 03:11:21PM -0700, Tim Rightnour wrote: > > On 02-Jan-02 Yann Chachkoff wrote: > > Again unstable and undocumented feature popped out on the CVS code. > > Although I understand quite well the motivations of acting so, as well as the > > problems any OpenSource project like Crossfire needs to handle, I do not > > approve them. > > Well.. I sincerely apologize for not posting first.. I really should have done > so. So there are two things I'd like to try and do to rectify this: > > 1) Open this up for discussion. Yes, it's allready committed.. but I'm > completely willing to backout and/or make changes. Since I screwed up, and > didn't post first.. I will take complete responsibility for a backout if people > want me to back it out. > > 2) Describe what it is that I did, and attempt to document it here for everyone. > > The overlay code does the following: > > An overlay is a partial map, which is loaded on top of the original map. > Any items on the overlay are loaded in addition to items normally on the map > from the standard map files. > > Overlay maps are not normally saved. There are two situations when an overlay > map is saved. 1) During an emergency save. 2) When using the new world maps, > the world map is slowly processed and re-saved via overlays. > > Overlays allow one to make modifications to a map, without modifying the > original maps. In this way, information such as temperature or weather > conditions can be saved in the map headers, and continually updated regardless > of a new version of the map being downloaded. In addition, things such as > additions by DM's can be saved on these overlays. Nothing alive is ever saved > on an overlay. > > When a map is loaded via ready_map, it attempts to load the overlay for that > map. If none exists, it continues without it. If one does exist, it loads the > overlay, and replaces the map header with the one on the overlay. It also > loads and places any items on the overlay map onto the map. > > There also exists a decay algorithim, which fires off at ready_map(). This > algorithim looks over the entire map for things that were not loaded as part of > the original maps (marked with a flag FLAG_OBJ_ORIGINAL) and slowly decays > those objects, to prevent them from accumulating forever. In addition, the > weather code, which slowly processes the entire worldmap over the course of a > day, runs the decay as it goes. > > --- > Tim Rightnour > NetBSD: Free multi-architecture OS http://www.netbsd.org/ > NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -- // .--=, .....::://::::::::::::::::::::::::::::.. (o O & kevin@ank.com :::::::://:::://://://:/:://::||_// / V K :::::://:::://:/:|//'/' // _,|' r , 'qk :'''/____ // / // |_// // || .'~. .~`, kls \_/-=\_/ From dnh at hawthorn.csse.monash.edu.au Wed Jan 2 22:13:57 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:01:59 2005 Subject: [7] RE: [CF-Devel] Starting Suspended Animation Process In-Reply-To: <20020102165149.A23882@balrog.ank.com> References: <3C3E4A67@MailAndNews.com> <20020102165149.A23882@balrog.ank.com> Message-ID: <20020103041357.GA30714@hawthorn.csse.monash.edu.au> Hmm this is a reasonable idea. That problem stems mostly from the fact that mids server is very popular, and yet is running the cvs which is generally regarded as unstable. I think alot of problems begun here, firstly because we a relatively small group it takes a long time to release a new version sometimes, this can make server admins and players want to run the cvs just to take advantage of these great things. The problem lies in that while the cool new stuff which is bug free is there, so to are all the unbug free cool things! We could step up the speed of releasing new version, but I suspect we would start to release lesser quality code (this is my opinion, it is open to arguement). Secondly, we don't have a great deal of beta tester like people, so the only way a big change can get tested is by releasing it on a server that people play. It does mean we get feedback very fast ;), but at the same time we may upset lots of players. Perhaps it might be made clear that the cvs tree is really for those who enjoy new things, but at the same time are prepared to risk losing it all by accident. I did notice mids talking about running two servers on one machine, firstly it might be a good idea to have a stable and cvs server at mids.student...... ? but then again, i suspect players will all group to the cvs server because more people will be there? Well after the _bad_ incident with Mich =(, it is very hard hitting to see you (gros) leave too =((. I must stress I don't and didn't want to see either of you leave but it is your choice and I must let you take your own paths. Perhaps if people were alittle more open on exactly where they stood we might avoid these incidents, at the very least we could try and stop this developer loss, gros says there are to many... that point I completely, totally, and utterly disagree with. yours humbley dnh On Wed, Jan 02, 2002 at 04:51:49PM -0800, kevin@ank.com wrote: > I think what Yann really needs is a stable branch; or perhaps Tim > needs an unstable branch. I've worked on some very large projects > and you really have to be able to destabilize the tree at certain > points to make any progress. > > Overlays sound like a very useful feature for the large map work > that is going on. But that obviously shouldn't destabilize an > active server like 'mids'. By branching the CVS trunk at some > point it would be possible to continue patching problems in the > stable branch while adding more dangerous but also more exciting > changes to the main branch. Porting patches back to the main > trunk can become a bit of a chore, but ultimately when the next > stable version is branched it will stabilize regardless of whether > the patches have all been moved or not. > > Cheers, > -kls > > > On Wed, Jan 02, 2002 at 03:11:21PM -0700, Tim Rightnour wrote: > > > > On 02-Jan-02 Yann Chachkoff wrote: > > > Again unstable and undocumented feature popped out on the CVS code. > > > Although I understand quite well the motivations of acting so, as well as the > > > problems any OpenSource project like Crossfire needs to handle, I do not > > > approve them. > > > > Well.. I sincerely apologize for not posting first.. I really should have done > > so. So there are two things I'd like to try and do to rectify this: > > > > 1) Open this up for discussion. Yes, it's allready committed.. but I'm > > completely willing to backout and/or make changes. Since I screwed up, and > > didn't post first.. I will take complete responsibility for a backout if people > > want me to back it out. > > > > 2) Describe what it is that I did, and attempt to document it here for everyone. > > > > The overlay code does the following: > > > > An overlay is a partial map, which is loaded on top of the original map. > > Any items on the overlay are loaded in addition to items normally on the map > > from the standard map files. > > > > Overlay maps are not normally saved. There are two situations when an overlay > > map is saved. 1) During an emergency save. 2) When using the new world maps, > > the world map is slowly processed and re-saved via overlays. > > > > Overlays allow one to make modifications to a map, without modifying the > > original maps. In this way, information such as temperature or weather > > conditions can be saved in the map headers, and continually updated regardless > > of a new version of the map being downloaded. In addition, things such as > > additions by DM's can be saved on these overlays. Nothing alive is ever saved > > on an overlay. > > > > When a map is loaded via ready_map, it attempts to load the overlay for that > > map. If none exists, it continues without it. If one does exist, it loads the > > overlay, and replaces the map header with the one on the overlay. It also > > loads and places any items on the overlay map onto the map. > > > > There also exists a decay algorithim, which fires off at ready_map(). This > > algorithim looks over the entire map for things that were not loaded as part of > > the original maps (marked with a flag FLAG_OBJ_ORIGINAL) and slowly decays > > those objects, to prevent them from accumulating forever. In addition, the > > weather code, which slowly processes the entire worldmap over the course of a > > day, runs the decay as it goes. > > > > --- > > Tim Rightnour > > NetBSD: Free multi-architecture OS http://www.netbsd.org/ > > NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > -- > // .--=, > .....::://::::::::::::::::::::::::::::.. (o O & kevin@ank.com > :::::::://:::://://://:/:://::||_// / V K > :::::://:::://:/:|//'/' // _,|' r , 'qk > :'''/____ // / // |_// // || .'~. .~`, > kls \_/-=\_/ > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From mwedel at sonic.net Thu Jan 3 02:17:46 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:59 2005 Subject: [7] RE: [CF-Devel] Starting Suspended Animation Process References: <3C3E4A67@MailAndNews.com> <20020102165149.A23882@balrog.ank.com> <20020103041357.GA30714@hawthorn.csse.monash.edu.au> Message-ID: <3C3413AA.F035DCE2@sonic.net> My personal thoughts on this: First, for better or worse, the #crossfire irc channel has become a place where lots of discussion is going on. This is good in many cases when bouncing ideas of people or discussing certain ideas. The problem here is that if you are not online at irc when the discussion happens, the first you hear about it is when it gets checked it. So the best thing is to still use irc as a discussion place (which can be useful to get a reading on how much desire there is in what you plan to work on), but still follow up to the list, perhaps something of the lines of 'from the irc discussion, this is what I'm thinking of doing'. Unfortunately, it is hard to remember to do that at times if you have had a discussion and think the idea is widely accepted (Because the people on irc when you were there said cool idea). But it really should be done - it is also nice in that the mailing lists are archived, so even if an idea does not lead to anything, you can then say 'look back at the old mailing archive for reasons that wasn't done'. Second, while multiple cvs branches (stable vs unstable) may seem to help, it only really does if people actually do run the unstable branches. From my brief experience, dealing with multiple branches in CVS, while not really difficult, does consume a fair amount of extra time. I actually don't see anything specific about what should and should not get put into CVS in the doc directory. The spoken rule is that the functionality needs to have been tested, but saying 'tested' is fairly broad (trying to figure out all the interactions your code has with other code. There are no testsuites in crossfire, so its not like you can just go and run a regression test and see if anything breaks. I should also note a few other things about the CVS repository - first, it is up to each server if they decide to run the latest CVS. I will say that all the servers that did that for the 1.0 release were a great help in finding many bugs. How good an idea it is to do that all the time for a widely used server has just been shown that it may not be a good idea. For people running widely public servers, they may want to hold of a few days/week before updating after big changes just to insulate themselves - hopefully people running CVS on personal server will find any terrible bugs in that time period. Second, CVS does allow you to use dates (-B some date) when doing updates and checkouts, so it is generally very easy to go back to an earlier release. Now certainly, I will admit it has been an unusually long time since the last official release. It may be worthwhile to take what was in the server as of a few days ago and use that as a 1.1.0 release. But from my standpoint, it gets to be a tricky thing - ideally, for stability, you want to make the release before any big changes go in (so the code released has been tested and debugged for a while). The obviously problem with that approach is then fairly shortly thereafter, when people ask about some cool feature, you then say 'thats in CVS'. I will also admit that releases have slowed down a bit since CVS became widespread, because it became easier to say 'thats in CVS'. Perhaps some formal release schedule may be used, eg, at the end of every third quarter, an official release is mode. For months 1 and 2 of that quarter, normal rapid development/checkin can be done, but in the third month (eg, march 01 through march 31, june 01 through june 31, etc), only bug fixes get checked in? Maybe starting around the second week of that month, the public servers may want to start keeping up to date with CVS to better test and find bugs. But certainly in that 2 month period of rapid development, they really should not. This at least means that the public servers are never really more than 3 months out of date, and presumably not too much stuff will change in that 3 months (and, up to the server admin, if some cool feature they really want now is available in CVS, they could grab it and backport it to their stable copy) Note also that doesn't mean that no development happens in the third month - it really just means nothing gets checked in. The super cool XYZ could get written in the first week of the month - you just need to wait until the next month before checking it in. We would probably need some way to handle the checkins and deal with the merges - the first person to pounce in after the message saying it is OK to check things in shouldn't necessarily always be the person who never has to worry about merging possible conflicts. Perhaps something of the nature of people in the last week of that month saying what stuff they want to check in, what files it affects, and how many lines in that file. If one person has 300 lines modified in that file, and another has 10, that person with 300 should probably have precedence, because merging in 10 will almost certainly be easier than 300 (this is a rough approximation - if that 300 lines is just a few new functions at the end of the file, those 10 lines may actually be tougher to merge in than that). From tanner at real-time.com Thu Jan 3 12:59:51 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:01:59 2005 Subject: [7] RE: [CF-Devel] Starting Suspended Animation Process In-Reply-To: <3C3413AA.F035DCE2@sonic.net>; from mwedel@sonic.net on Thu, Jan 03, 2002 at 12:17:46AM -0800 References: <3C3E4A67@MailAndNews.com> <20020102165149.A23882@balrog.ank.com> <20020103041357.GA30714@hawthorn.csse.monash.edu.au> <3C3413AA.F035DCE2@sonic.net> Message-ID: <20020103125951.W3301@real-time.com> Quoting Mark Wedel (mwedel@sonic.net): > First, for better or worse, the #crossfire irc channel has become a place > where lots of discussion is going on. This is good in many cases when > bouncing ideas of people or discussing certain ideas. The problem here is > that if you are not online at irc when the discussion happens, the first you > hear about it is when it gets checked it. Most irc clients have logging capabilities. When one of these discussions takes place couldn't someone log it and then send it to Leaf to have it posted to the website or have the logger send it to the crossfire-devel list? > Second, while multiple cvs branches (stable vs unstable) may seem to help, it > only really does if people actually do run the unstable branches. > The spoken rule is that the functionality needs to have been tested, but > saying 'tested' is fairly broad (trying to figure out all the interactions > your code has with other code. There are no testsuites in crossfire, so its > not like you can just go and run a regression test and see if anything > breaks. IMHO this is the biggest issue with the crossfire project (and all the other open source project I contribute to). No test suite, so it's almost impossible to know if your code integrates correct until someone installs it on their server and people play test it. Functional testing will always require game play, but I think to partially answer the question, "Does my code break anything?", there should be a set of unit tests. There are tools to help out. http://check.sourceforge.net/ http://www.xprogramming.com/ftp/TestingFramework/wall/CUnit.zip http://www.codefactory.se/~spotty/cunit/ > Perhaps some formal release schedule may be used, eg, at the end of every > third quarter, an official release is mode. Doesn't this "break" the open source mantra of release early, release often? Part of the problem is stability of a release. We don't roll a release until it's stable. But we don't know if it's stable until we release it. Chicken-n-the-egg thing. Test suite will help. If the code passes all of the tests, it's as stable as we can make it until someone does the functional/game play testing. Recently my company switched development methofs from MSF to Extreme Programming (XP). It's be a real eye opener. XP put the "fun" back into coding. Anyways, one of the major components of XP is unit testing and I can't praise this enough. The quality of code being turned out is magnitudes better then before. I think applying a little unit testing to crossfire will help some of these issues that have been discussed here and on irc. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From jbontje at suespammers.org Thu Jan 3 17:24:27 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:02:00 2005 Subject: [CF-Devel] Imperial Post Office - a set of python scripts Message-ID: <20020104002427.A1951@freebsd.localdomain> Hello, I have made some python scripts for the python plugin in crossfire. Features: - sending mailscrolls to other players - recieving mailscrolls and storage of old ones - mailcheck on login - mailwarnings (only DM's can send those) - shop where you can buy pencils, scrolls of literacy and empty mailscrolls This collection exists out of some global event handlers (python), a few local event handlers (python) and a crossfire map. My crossfire server (mids.student.utwente.nl) is running with this scripts installed, you can find the Post Office next to the City Hall in Scorn. (There is a manual lying there on the table) The source for all this: http://mids.student.utwente.nl/~crossfire/IPO/IPO_2001-01-03.tar.gz I plan to implement more functions and also make other scripts. I am sure there are many bugs, this release is mostly intended to give a demo of the python plugin in crossfire. Many thanks to Gros for coding the python plugin and tollerating my inquisitive idiocy. Regards, Joris Bontje / mids -- Gpg Key: Id=0xF19326A9 / http://mids.student.utwente.nl/~mids/jbontje.pub Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 238 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020104/bbc0c2c2/attachment.pgp From jbontje at suespammers.org Thu Jan 3 17:27:34 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:02:00 2005 Subject: [CF-Devel] Re: Imperial Post Office - a set of python scripts In-Reply-To: <20020104002427.A1951@freebsd.localdomain>; from jbontje@suespammers.org on Fri, Jan 04, 2002 at 12:24:27AM +0100 References: <20020104002427.A1951@freebsd.localdomain> Message-ID: <20020104002734.A2007@freebsd.localdomain> On Fri, Jan 04, 2002 at 12:24:27AM +0100, Joris Bontje wrote: > The source for all this: http://mids.student.utwente.nl/~crossfire/IPO/IPO_2001-01-03.tar.gz Euh, ofcourse it is 2002 now :) Other location: http://mids.student.utwente.nl/~crossfire/IPO/IPO_2002-01-03.tar.gz Joris -- Gpg Key: Id=0xF19326A9 / http://mids.student.utwente.nl/~mids/jbontje.pub Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 238 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020104/3ed11534/attachment.pgp From jbontje at suespammers.org Thu Jan 3 03:03:56 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:02:00 2005 Subject: [7] RE: [CF-Devel] Starting Suspended Animation Process In-Reply-To: <20020103041357.GA30714@hawthorn.csse.monash.edu.au>; from dnh@hawthorn.csse.monash.edu.au on Thu, Jan 03, 2002 at 03:13:57PM +1100 References: <3C3E4A67@MailAndNews.com> <20020102165149.A23882@balrog.ank.com> <20020103041357.GA30714@hawthorn.csse.monash.edu.au> Message-ID: <20020103100356.A54307@freebsd.localdomain> First of all, some comments on the quoting style. RFC 1855 has some rules on quoting in email messages and newsgroups. See for more information http://www.rfc1855.org/ Important things: - keep it a logical story (comments under the original stuff) - delete text you dont comment on - delete headers (greetings) and footers (signatures) - summarize lenghty texts On Thu, Jan 03, 2002 at 03:13:57PM +1100, David Hurst wrote: > On Wed, Jan 02, 2002 at 04:51:49PM -0800, kevin@ank.com wrote: > > I think what Yann really needs is a stable branch; or perhaps Tim > > needs an unstable branch. I've worked on some very large projects > > and you really have to be able to destabilize the tree at certain > > points to make any progress. I remember the idea of 2 branches, a stable and an unstable one, beeing discussed somewhat like a year before. Conclusion was: we don't want it it causes too much overhead. > > Overlays sound like a very useful feature for the large map work > > that is going on. But that obviously shouldn't destabilize an > > active server like 'mids'. By branching the CVS trunk at some > > point it would be possible to continue patching problems in the > > stable branch while adding more dangerous but also more exciting > > changes to the main branch. Porting patches back to the main > > trunk can become a bit of a chore, but ultimately when the next > > stable version is branched it will stabilize regardless of whether > > the patches have all been moved or not. I think that we don't have enough coders too keep up 2 branches, maybe I don't understand the work involved completely but merging those two branches together after a new release looks like black magic to me. > Hmm this is a reasonable idea. That problem stems mostly from the fact > that mids server is very popular, and yet is running the cvs which is > generally regarded as unstable. I think alot of problems begun here, > firstly because we a relatively small group it takes a long time to > release a new version sometimes, this can make server admins and players > want to run the cvs just to take advantage of these great things. The > problem lies in that while the cool new stuff which is bug free is > there, so to are all the unbug free cool things! We could step up the > speed of releasing new version, but I suspect we would start to release > lesser quality code (this is my opinion, it is open to arguement). Ofcourse I could run two server. But there will be some problems: technical: - metaserver doesnt support 2 servers with different ports on 1 ip/hostname - my server can't handle the load, I wil have to use my workstation as a testing server (I have done that before with iso maps and scriptfire/plugins) non-technical: - we don't have enough players to fill all those servers! > Secondly, we don't have a great deal of beta tester like people, so the > only way a big change can get tested is by releasing it on a server that > people play. It does mean we get feedback very fast ;), but at the same > time we may upset lots of players. Perhaps it might be made clear that > the cvs tree is really for those who enjoy new things, but at the same > time are prepared to risk losing it all by accident. I did notice mids > talking about running two servers on one machine, firstly it might be a > good idea to have a stable and cvs server at mids.student...... ? but > then again, i suspect players will all group to the cvs server because > more people will be there? The bleeding edgyness of my server is a 2 cutting sword (cliche). Maybe it is one of the reasons that my server is quite popular. But with the latest gadgets you also have the latest bugs. Quite some bugs are captured on my server, simply because they require lots of people with too much time, lots of players, luck, etc. Therefore I will keep running the 'unstable CVS' server. If some of you new code crashes my server I might be angry, but nifty stuff keeps my box popular and playing fun for the users. Regards, Joris Bontje / mids -- Gpg Key: Id=0xF19326A9 / http://mids.student.utwente.nl/~mids/jbontje.pub Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 238 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020103/51280f8a/attachment.pgp From jshelley at ictransnet.com Thu Jan 3 18:45:54 2002 From: jshelley at ictransnet.com (johnny shelley) Date: Thu Jan 13 18:02:00 2005 Subject: [CF-Devel] expanded dm help commands Message-ID: <3C34FB42.3C56598@ictransnet.com> This covers many commands missed the first time thru as well as a bit of expansion on some of the commands. Also covers latest revisions to create tim is commiting today. -- johnny PGP Public Key available from: http://www.keyserver.net:11371/pks/lookup?op=get&search=0x17BF1DD3 -------------- next part -------------- The following commands are available to you: dmhelp abil addexp create debug dump dumpallarchtypes dumpbelow dumpallmaps dumpallobjects dumpfriendlyobjects dumpmap forget_spell free goto invisible kick learn_special_prayer learn_spell nodm nowiz overlay_save patch plugin pluglist plugout printlos reset remove set_god shutdown speed spellreset ssdumptable stats style_info summon time wizpass who General notes for DM's: Case sensitivity is important in player and map names. DM help for abil: syntax: abil notes: abil will permanently change the ability scores of players. Attribute is one of str, dex, con, int, wis, pow, cha. Value may not exceed 30. DM help for addexp: syntax: addexp notes: the player must have a skill readied. All experience added in this manner will go directly to the skill readied. DM help for create: syntax: create ... notes: creating items is rather dangerous and tends to crash the server when creating some items. The number and bonus attributes may be left off, or the bonus itself may be left off any time. If a bonus is desired, number must be specified as well. Archtype must be specified in all cases. Variable and values may be left off at any time, but specifiying a variable requires a value also be specified. Multipart values such as for an item name must be quoted. Example: create 5 +1 longsword name "Spiffy Sword" face chicken.171 This would create 5 +1 longswords named 'Spiffy Sword' that look like chickens. see also: patch, dump DM help for debug: syntax: debug notes: Without arguments, debug will simply print the current level of debugging. Valid debugging levels are 0-3 where: llevError = 0, llevInfo = 1, llevDebug = 2, llevMonster = 3 DM help for dump: syntax: dump notes: Using dump, you can see the attributes of any item in the game. To find the object number of an item you wish to view, click on it. If this item is in your inventory, or you are standing over, click on yourself and the item tags will be displayed. see also: patch DM help for dumpallarchtypes: syntax: dumpallarchtypes notes: This prints out a list of all archtypes to stderr. DM help for dumpbelow: syntax: dumpbelow notes: dumpbelow will dump the attributes of the top item you are standing over. see also: dump DM help for dumpallmaps: syntax: dumpallmaps notes: This prints out map information for all active maps to stderr. DM help for dumpallobjects: syntax: dumpallobjects notes: This prints out a list of all active objects to stderr. DM help for dumpfriendlyobjects: syntax: dumpfriendlyobjects notes: This prints out a list of all active friendly objects to stderr. DM help for forget_spell: syntax: forget_spell notes: this will cause you to permanently lose knowledge of a spell. DM help for free: syntax: free notes: free should ONLY be used after remove. Freeing an object that has not been removed will cause the game to crash. For most objects, simply removing them is sufficient and they will eventually be freed. See Also: remove DM help for goto: syntax: goto notes: using this command will instantly move you to the start point of the map specified. DM help for invisible: syntax: invisible notes: makes you invisible for a short time. DM help for kick: syntax: kick notes: this command will kick a player off the server. If used without an argument, it will kick all players off the server with the exception of you. DM help for learn_special_prayer: syntax: learn_special_prayer notes: this will allow you to permanently learn a spell as a special prayer of your god. see also: learn_spell DM help for learn_spell: syntax: learn_spell notes: this will allow you to permanently learn a spell. It is similiar to learn_special_prayer except that you will retain knowledge of this spell regardless of changing dieties. see also: learn_special_prayer DM help for overlay_save: syntax: overlay_save notes: this will save everything on the current map that was not originally part of it as an overlay. The overlay will then be loaded anytime the map itself is loaded. Be careful with this as EVERYTHING on the map will be saved in an overlay, such as spawned monsters and dropped objects. DM help for nodm and nowiz: syntax: nodm notes: both of these commands will return you to normal player status. DM help for patch: syntax: patch notes: using the patch command, you can radically modify the properties of objects in the game. Simply specify the object to modify and the new values of its variables (or completely new variables). See Also: dump DM help for plugin: syntax: plugin notes: this will load a new plugin into memory. Using this with no arguments, or invalid arguments will cause a server crash. Plugin name should be as it appears in your plugin directory. Double check the names before using plugins. DM help for pluglist: syntax: pluglist notes: this shows currently loaded plugins. DM help for plugout: syntax: plugout notes: this will remove a loaded plugin from memory. DM help for printlos: syntax: printlos notes: this is used for line of sight debugging. DM help for remove: syntax: remove notes: remove will, suprisingly enough, remove the object specified by the tag supplied. see also: free DM help for reset: syntax: reset notes: all other characters must be off of the map at the time of reset. This will NOT reset any unique items, such as players apartments, in the case of unique items being on a map, it will cause them to be saved before the map is reset. DM help for speed: syntax: speed notes: without arguments, this prints your current speed. If given an argument, it will set reset your speed to the new speed. DM help for spellreset: syntax: spellreset notes: this causes the spell table to be reinitialized. DM help for ssdumptable: syntax: ssdumptable notes: this will print out the current hash table to stderr. DM help for set_god: syntax: set_god notes: this will change a players diety to the diety specified. DM help for shutdown: syntax: shutdown notes: This will cause the server to shut down entirely. DM help for style_info: syntax: style_info notes: this will print out information regarding current styles in use. DM help for summon: syntax: summon notes: summoning a player will bring them immediately to your location. There is no 'reverse' summoning, except to go to a map yourself and summon the player again. DM help for time: syntax: time notes: this will give additional information about server performance when used as dm. DM help for wizpass: syntax: wizpass notes: this will toggle on and off your ability to walk thru walls as dm. DM help for who: syntax: who notes: when used as dm, this will also print out the object tag of players. From mwedel at sonic.net Thu Jan 3 23:45:41 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:00 2005 Subject: [7] RE: [CF-Devel] Starting Suspended Animation Process References: <3C3E4A67@MailAndNews.com> <20020102165149.A23882@balrog.ank.com> <20020103041357.GA30714@hawthorn.csse.monash.edu.au> <20020103100356.A54307@freebsd.localdomain> Message-ID: <3C354185.CED95C37@sonic.net> Bob Tanner wrote: > Most irc clients have logging capabilities. When one of these discussions takes > place couldn't someone log it and then send it to Leaf to have it posted to the > website or have the logger send it to the crossfire-devel list? That certainly works, but you need to remember to do it. For purposes of discussion on the mailing list, it still helps if it gets written by hand to really concentrate on what is relevant - often times, the discussion may be pretty long but the proposed change can be concentrated into just a few paragraphs. I don't think the difficulty of writing to the mailing list is really the problem - relative to the size and time needing to code many of the things, sending a few paragraph description of what you plan to do is really a small portion of the time. the problem is that crossfire has probably never really had a formalized procedure for committing to CVS. If your change is widely accepted as a good idea and does not hvae any serious bugs, you can get away with committing it with no real discussion, because no one will really care. It is when the idea may not be quite so widely accepted or have serious bugs that problems arise. Unfortunately, there is no way to really no what category it will fall into unless mail is sent out. > IMHO this is the biggest issue with the crossfire project (and all the other > open source project I contribute to). No test suite, so it's almost impossible > to know if your code integrates correct until someone installs it on their > server and people play test it. Yes - the obvious reason is that writing a test suite is not that intesting of a thing to do (I know personally that I would rather implement new features than spend time working on a testsuite). Also, the fact that you already have free testers probably contributes to this (eg, why should I spend a lot of time trying to test every case when it can go into CVS and those boundary cases and so on will get tested by others). I think it is relative safe to say that no one checks in code that they know has errors. I know I have checked in code which I thought was OK but errors were discovered. Why writing testsuites may be require a lot of time, I think writing testplans would be useful and not take as much time. If for example, we had a testplan for exit and map loading/saving, there is a very good chance that Tim would have caught the problems with the overlay code. Testplans only need to consist of things like 'try these things out', so it is just a matter of writing down text. IT would probably be useful for people, when they develope their testing strategies for something they are working on, to share it. The test plan does not need to be really detailed, for example, an exit and map load/save test plan may be: 1) Enter map not loaded before. Does it load correctly. Leave an item there for future reference. 2) Exit map and re-enter quickly. Is it loaded correctly? Is that item you left there? 3) Exit map, and wait for it to swap out. Then re-enter. Is that item there. 4) Repeat steps 1-3 with a per player unique map. 5) Repeat steps 1-3 with a map that has the outdoor flag set 6) repeat steps 1-3 with a map .... 7) Kill server, and re-run tests. Not very detailed, but gives an idea of what to test for. > Doesn't this "break" the open source mantra of release early, release often? > > Part of the problem is stability of a release. We don't roll a release until > it's stable. But we don't know if it's stable until we release it. > Chicken-n-the-egg thing. Once every 3 months may be more often (certainly is has been more than 3 months since the last release). One problem with doing releases is that they take some amount of time to do properly (my basic procedure is to archive it up, un-archive it someplace else, then make sure it builds and runs correctly). Doing that tends to take a non trivial amount of time. I think the release schedule would also vary a lot based on how much stuff changes. There isn't much point to release every 2 weeks if in some cases, the only thing that changed in that two week period are some very minor fixes. Alternatively, I could freeze CVS whenever I think enough stuff has changed to warrant a release. The problem is that if the freeze time is known in advanced, people try to stuff in their latest cool enhancement before the freeze time, and those last minute changes are more likely to have bugs which can only really be found during the freeze time (which then means the freeze should probably be longer). For example, if I sent out a mail saying I'm going to make a new release, and freeze any new commits in one week, there would probably be some number of commits done perhaps more hastily because they want to get in before the deadline. OTOH, if I just announce that the source is now frozen with no deadline, I'm sure some people might get upset that they can't get their latest change for the next official release. That is one reason I thought having real schedule might work - you really know when you have to get your changes in by. Now there could still be cases that it is 5 days until the deadline and you really want to get your code in. But at least if there is a known schedule for releases, you know worst case your code will be in the one three months from now. Note that releasing once a quarter was a fairly arbitrary time frame. We could do once a month, and have a 1 week freeze instead. IF in that particular month, not much got done, we skip the release cycle for the month. Joris Bontje wrote: > > I think that we don't have enough coders too keep up 2 branches, maybe > I don't understand the work involved completely but merging those two > branches together after a new release looks like black magic to me. A lot depends on how this is done. The biggest problem is when do you decide to rebase and take what is currently in CVS and make that your 'stable' branch (or at least work towards that)? In that case, you may now have 3 branches - your 'old' stable release, your bleeding edge potentially unstable, and your 'new' stable release, which your still working on making stable. What it really takes to have a stable branch is for someone to watch the commits - when they see something that is a bug fix only, the merge that into the stable branch. Likewise, any stability changes they make to the stable branch, they also make to the main branch. The problem comes that the more the main branch deviates from the stable branch, the more effort this becomes (porting the changes between the branches may no longer be just a matter of copying the code). Likewise, if the stable branch is too old, people probably won't be as interested in using it. > Ofcourse I could run two server. But there will be some problems: > technical: > - metaserver doesnt support 2 servers with different ports on 1 ip/hostname > - my server can't handle the load, I wil have to use my workstation as a testing > server (I have done that before with iso maps and scriptfire/plugins) > non-technical: > - we don't have enough players to fill all those servers! Right - if the two servers are operating on different data files (maps, players, etc), then thats basically the same as just having to totally different servers unrelated to each other. If they operate on the same data files (so that if server 1 is too unstable you go to server 2), crossfire currently doesn't support that. Also, that doesn't help if there is some bug in server 1 which just trashes the player file. From kevin at ank.com Fri Jan 4 00:18:47 2002 From: kevin at ank.com (kevin@ank.com) Date: Thu Jan 13 18:02:00 2005 Subject: [CF-Devel] Starting Suspended Animation Process In-Reply-To: <20020103100356.A54307@freebsd.localdomain> References: <3C3E4A67@MailAndNews.com> <20020102165149.A23882@balrog.ank.com> <20020103041357.GA30714@hawthorn.csse.monash.edu.au> <20020103100356.A54307@freebsd.localdomain> Message-ID: <20020103221847.A25693@balrog.ank.com> On Thu, Jan 03, 2002 at 10:03:56AM +0100, Joris Bontje wrote: > > > > Overlays sound like a very useful feature for the large map work > > > that is going on. But that obviously shouldn't destabilize an > > > active server like 'mids'. By branching the CVS trunk at some > > > point it would be possible to continue patching problems in the > > > stable branch while adding more dangerous but also more exciting > > > changes to the main branch. Porting patches back to the main > > > trunk can become a bit of a chore, but ultimately when the next > > > stable version is branched it will stabilize regardless of whether > > > the patches have all been moved or not. > > I think that we don't have enough coders too keep up 2 branches, maybe > I don't understand the work involved completely but merging those two > branches together after a new release looks like black magic to me. > CVS merges are typically through the 'cvs update' command. By using cvs update you move your view of the development tree to a different point in the tree, while keeping any changes you had in progress. Using 'cvs update -j HEAD' merges changes from the branch you currently have checked out with the head of tree and updates your pointer to the main trunk. After testing those changes you 'cvs commit' to keep the merged result. Keeping two branches doesn't require extra coders; I regularly use multiple branches on a tree even when I'm the only coder. Branching is just a way of making changes to something you gave someone a week ago, without forcing them to get all of the changes that you've made in the interim. > > Ofcourse I could run two server. But there will be some problems: > technical: > - metaserver doesnt support 2 servers with different ports on 1 ip/hostname > - my server can't handle the load, I wil have to use my workstation as a testing > server (I have done that before with iso maps and scriptfire/plugins) > non-technical: > - we don't have enough players to fill all those servers! Of course the problems you have with players on your server are entirely yours to determine, but it does help to at least set expectations appropriately. Include in the MOTD the fact that the server is an unstable testing server, and that characters and equipment may be lost. > Therefore I will keep running the 'unstable CVS' server. If some of you new > code crashes my server I might be angry, but nifty stuff keeps my box popular > and playing fun for the users. > At the same time if you take code and prematurely expose it to an overbroad audience who aren't expecting it to be immature, then you ultimately hurt the development of the system as coders become afraid of checking in code which could potentially destabilize the system. You want and need coders to be able to take chances for breakthrough innovations to occur. Cheers, -kls -- // .--=, .....::://::::::::::::::::::::::::::::.. (o O & kevin@ank.com :::::::://:::://://://:/:://::||_// / V K :::::://:::://:/:|//'/' // _,|' r , 'qk :'''/____ // / // |_// // || .'~. .~`, kls \_/-=\_/ From root at garbled.net Fri Jan 4 02:00:01 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:02:00 2005 Subject: [7] RE: [CF-Devel] Starting Suspended Animation Process In-Reply-To: <3C3413AA.F035DCE2@sonic.net> Message-ID: On 03-Jan-02 Mark Wedel wrote: > Perhaps some formal release schedule may be used, eg, at the end of every > third > quarter, an official release is mode. For months 1 and 2 of that quarter, > normal rapid development/checkin can be done, but in the third month (eg, > march > 01 through march 31, june 01 through june 31, etc), only bug fixes get > checked > in? Maybe starting around the second week of that month, the public servers > may > want to start keeping up to date with CVS to better test and find bugs. But > certainly in that 2 month period of rapid development, they really should > not. While I don't specifically object to the idea.. I personally do not like the idea of releases being time-bound. It causes a few problems: 1) The quality of each release isn't as high, because we are just arbitrarily saying "it's time", not "the features justify it being time" 2) A lot of time is spent doing release engineering type foo, like mark mentioned. 3) The freeze period before each release is only useful given two circumstances: a) servers are running the release candidate. b) people are fixing bugs. Now the issue with the second is more complex. When you do one release every now and then, when features demand it.. people tend to jump on board, and help out in the debugging. But when releases are commonplace, and occur on a set schedule.. eventually people stop worrying about the release, because we can just wait until the next one. They may be too wrapped up in writing whatever code it is they are writing to stop and go on a bug hunt. This happens less on a feature-demanded release, because generally everyone is in agreement that it's time to release. When you don't have a large number of developers.. these mandatory freezes end up just being stale-time where nothing really gets done. > This at least means that the public servers are never really more than 3 > months > out of date, and presumably not too much stuff will change in that 3 months > (and, up to the server admin, if some cool feature they really want now is > available in CVS, they could grab it and backport it to their stable copy) Unfortunately.. I think the public servers will end up running CVS regardless. Like mids said, bleeding edge is where people want to be. I think instead.. we need to come to some understanding about what the CVS really is. To some degree, people have to understand that it's not allways going to be perfectly stable. But as long as it doesn't stay that way for an inordinate amount of time, I think thats reasonable. Case in point, my recent explosion: I ran around on my server loading and unloading maps, playing the game, futzing around.. and spent about 7 days mucking with things. Now I missed a few things, for instance I missed the unique maps.. thats purely my fault. But there were a bunch of things that just completely threw me for a loop, like how often mids's server crashes.. causing way more overlays than I had anticipated to be made. The point however is, that when it was brought to my attention, I fixed it, right away, and backed out what I couldn't fix. Personally, I don't think this was unreasonable. Yes, I broke it, yes, it caused some chaos, but mids should have backed up his old binary, and I fixed the problems brought to my attention almost immediately. I do however. Like Mark's idea of having set things to test when mucking with a certain peice of code. Some of the interactions that occured on mids's server were wholly unexpected by me, and a few could have been caught. Worth noting though.. Is that the two hours I spent asking mids questions about what was going on in his server (a heavily loaded server), was more productive debugging time than I had spent the previous seven days. I personally think people need to expect CVS to be unstable at times. But they also should expect that such instability, should be fixed within a reasonable timeframe (1-2 days) or backed out. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From mwedel at sonic.net Fri Jan 4 02:01:15 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:00 2005 Subject: [CF-Devel] Client/server protocol enhancements. References: <3C268EE6.5A55520B@sonic.net> <20011230125142.A25962@CSUA.Berkeley.EDU> <3C2FFF77.D456B71A@sonic.net> <20011231005148.A4535@CSUA.Berkeley.EDU> <3C311F6C.80ECD1F8@sonic.net> <20020101112853.A36941@CSUA.Berkeley.EDU> Message-ID: <3C35614B.FDD89867@sonic.net> Scott MacFiggen wrote: > > On Mon, Dec 31, 2001 at 06:31:08PM -0800, Mark Wedel wrote: > > A minor wishlist for me would be to make the map in the gtk client > > scrollable - if using fog of war, it is sometimes convenient to > > thing 'so what was over there again', and being able to scroll to > > over their would be cool. That probably isn't too hard, but for > > reasons of optimization, you really only want to render what is actually > > being shown on the monitor, and not the entire canvas. > > I've thought about this myself, it should be easy to implement but > it would be memory intensive.. Memory is cheap. Or at least, if it is a runtime option, you can elect to use it if you have the cpu and memory to spare. Since the fog map already has that information, it doesn't really use more memory to store the other spaces. I wonder if maybe having it be a seperate pane you can toggle between (eg, show what you know either as a pop up or switching in the normal game window). If this approach is taken, you could perhaps also simplify it by not animating that window - that means the cost is only in the space to store that surface and in the time to render it when the player switches to it. Alternatively, as the player scrolls around, it could render it - in a sense, the surface size is that of the window the player is scrolling it around in, but as the player says 'scroll left', the client figures out the new offset and draws it on the surface. In that case, the memory use shouldn't be that much at all. > I read a game design book a while back that was pretty blunt on this > subject. The book said it was bad game design to hide things from players. > The basic idea was why put something in your game and then not tell > the player about it.. > Also, I would think any good wizard who has spent years studying his > magic would know the approximate effectivness of his spells. > Anyway, if this info gets sent over to the client, I'll modify the > gtk client to make use of it. That is probably true. It depends a lot of if you think that knowledge should be discovered or not. Of course, we could always do it both ways and have some server setting that controls eg - if the server admin disables the user from knowing that information, the information is sent in the same form, just the damage and increments and so forth are zero. If the server admin wants to share it, then the real values get sent. > I would prefer it all in one step, easier for a newbie to figure out > what is going on.. The hall of hereos thing works ok too though. At some level, the hall of selection would need to exist for quite a while simply to support the older clients that don't support the selection process as described in the previous mail messages (eg, the client handling most of it). From smurf at CSUA.Berkeley.EDU Fri Jan 4 16:05:04 2002 From: smurf at CSUA.Berkeley.EDU (Scott MacFiggen) Date: Thu Jan 13 18:02:00 2005 Subject: [CF-Devel] Client/server protocol enhancements. In-Reply-To: <3C35614B.FDD89867@sonic.net>; from mwedel@sonic.net on Fri, Jan 04, 2002 at 12:01:15AM -0800 References: <3C268EE6.5A55520B@sonic.net> <20011230125142.A25962@CSUA.Berkeley.EDU> <3C2FFF77.D456B71A@sonic.net> <20011231005148.A4535@CSUA.Berkeley.EDU> <3C311F6C.80ECD1F8@sonic.net> <20020101112853.A36941@CSUA.Berkeley.EDU> <3C35614B.FDD89867@sonic.net> Message-ID: <20020104140503.A78681@CSUA.Berkeley.EDU> On Fri, Jan 04, 2002 at 12:01:15AM -0800, Mark Wedel wrote: > Scott MacFiggen wrote: > > > Memory is cheap. Or at least, if it is a runtime option, you can elect to use > it if you have the cpu and memory to spare. Since the fog map already has that > information, it doesn't really use more memory to store the other spaces. I When I said it was memory intensive I meant if you had a mapview with actual scroll bars. That would imply the entire map is rendered all the time but only what was in the current viewport would be seen. Although if I were to implement it I would allow the user to move the viewport around and just re-render as the user scrolled around. That wouldn't take any more memory at all.. > > I read a game design book a while back that was pretty blunt on this > > subject. The book said it was bad game design to hide things from players. > > The basic idea was why put something in your game and then not tell > > the player about it.. > That is probably true. It depends a lot of if you think that knowledge > should be discovered or not. Of course, we could always do it both > ways and have some server setting that controls eg - if the server > admin disables the user from knowing that information, the information > is sent in the same form, just the damage and increments and so forth > are zero. If the server admin wants to share it, then the real values > get sent. The more configurable the server the better in my opinion. Customized servers would certainly make the game more interesting. -Scott From froese at gmx.de Mon Jan 7 16:24:40 2002 From: froese at gmx.de (Edgar Toernig) Date: Thu Jan 13 18:02:01 2005 Subject: [CF-Devel] [PATCH] Misc fixes for the 1.1.0 client Message-ID: <3C3A2028.B1715F82@gmx.de> Hi, I noticed that there were some problems with the X11 version of the 1.1.0 client and I fixed them. On the way I added some other features. These two were required to configure and compile: - configure script: libpng needs z-lib. A lot of version of libpng have an explicit dependency for that within the lib. Some not. I added -lz to the -lpng test. Someone has to figure out how to teach this to autoconf. - cfsndserv.c needs a #include here. Should be save on all systems. Other changes: - Added the status icons again. They were removed from the 1.0.0 version due to the png-changes. I converted these icons to bitmaps and use them instead. This also fixes a crash when opening/closing a container. - Commented the png rescale code for the x11 version. I fixed the gtk version to not use ~9MB of static arrays (now ~48kB). - Option to turn off autorepeat for directional keys. With fast autorepeat and remote server it was very difficult to move around. Commandline option: -noautorepeat. During play: 'autorepeat. Setting is saved in defaults file. - Disable nagle algorithm. That way packets are sent immediately without additional delay. Seems to make interactive feel a little bit better. I had to rework some of newpacket.c to send only complete packages. This cleaned up a lot of code and avoids a server failure (closes connection when receiving split packets). - Added -font option. Setting is saved in the defaults-file. - Fixed builtin command argument handling (remove leading spaces from arguments). Especially the 'show command did not work because of that. - Fixed the "not yet present" image (pixmaps/question.111). It looked totally wrong. It's now bigger but can still be used for 24x24 size. - When new images arrive, not the complete inventory is redrawn. Only the icons of the currently displayed. - Some minor tweaks. Browse the patch... Ciao, ET. -------------- next part -------------- diff -ruN crossfire-client-1.1.0/common/client.c crossfire-client-1.1.0-et/common/client.c --- crossfire-client-1.1.0/common/client.c Fri Dec 28 09:56:41 2001 +++ crossfire-client-1.1.0-et/common/client.c Mon Jan 7 17:05:59 2002 @@ -128,7 +128,9 @@ i=SockList_ReadPacket(csocket->fd, &csocket->inbuf, MAXSOCKBUF-1); if (i==-1) { /* Need to add some better logic here */ + /*ET: not an error. It's EOF! At least errno isn't valid. fprintf(stderr,"Got error on read (error %d)\n", errno); + */ csocket->fd=-1; return; } @@ -203,6 +205,14 @@ fprintf(stderr,"InitConnection: Error on fcntl.\n"); } + /* turn off nagle algorithm */ + if (getenv("CF_NAGLE") == NULL) { /* disabled by setting CF_NAGLE */ + int i=1; + + if (setsockopt(fd, SOL_TCP, TCP_NODELAY, &i, sizeof(i)) == -1) + perror("TCP_NODELAY"); + } + if (getsockopt(fd,SOL_SOCKET,SO_RCVBUF, (char*)&oldbufsize, &buflen)==-1) oldbufsize=0; @@ -221,9 +231,7 @@ void negotiate_connection(int sound) { - int cache; - char buf[BIG_BUF]; SendVersion(csocket); @@ -267,16 +275,14 @@ } #endif - sprintf(buf,"setup sound %d sexp %d darkness %d newmapcmd %d", - (sound<0?0:1), want_skill_exp, want_darkness, fog_of_war); - cs_write_string(csocket.fd, buf, strlen(buf)); + cs_print_string(csocket.fd, + "setup sound %d sexp %d darkness %d newmapcmd %d", + sound>=0, want_skill_exp, want_darkness, fog_of_war); mapx=11; mapy=11; - if (want_mapx!=11 || want_mapy!=11) { - sprintf(buf,"setup mapsize %dx%d",want_mapx, want_mapy); - cs_write_string(csocket.fd, buf, strlen(buf)); - } + if (want_mapx!=11 || want_mapy!=11) + cs_print_string(csocket.fd,"setup mapsize %dx%d",want_mapx, want_mapy); SendAddMe(csocket); } diff -ruN crossfire-client-1.1.0/common/commands.c crossfire-client-1.1.0-et/common/commands.c --- crossfire-client-1.1.0/common/commands.c Fri Dec 28 09:56:41 2001 +++ crossfire-client-1.1.0-et/common/commands.c Mon Jan 7 17:09:39 2002 @@ -112,12 +112,8 @@ * methods, just report on error, or try another setup command. */ if (!strcmp(cmd,"sound")) { - if (!strcmp(param,"FALSE")) { - if (nosound) - cs_write_string(csocket.fd,"setsound 0", 10); - else - cs_write_string(csocket.fd,"setsound 1", 10); - } + if (!strcmp(param,"FALSE")) + cs_print_string(csocket.fd, "setsound %d", !nosound); } else if (!strcmp(cmd,"mapsize")) { int x, y=0; char *cp,tmpbuf[MAX_BUF]; @@ -143,8 +139,8 @@ if (want_mapx > x || want_mapy > y) { if (want_mapx > x) want_mapx = x; if (want_mapy > y) want_mapy = y; - sprintf(tmpbuf," setup mapsize %dx%d", want_mapx, want_mapy); - cs_write_string(csocket.fd, tmpbuf, strlen(tmpbuf)); + cs_print_string(csocket.fd, + "setup mapsize %dx%d", want_mapx, want_mapy); sprintf(tmpbuf,"Server supports a max mapsize of %d x %d - requesting a %d x %d mapsize", x, y, want_mapx, want_mapy); draw_info(tmpbuf,NDI_RED); @@ -501,11 +497,7 @@ void send_reply(char *text) { - char buf[MAXSOCKBUF]; - - sprintf(buf,"reply %s", text); - - cs_write_string(csocket.fd, buf, strlen(buf)); + cs_print_string(csocket.fd, "reply %s", text); } diff -ruN crossfire-client-1.1.0/common/external.h crossfire-client-1.1.0-et/common/external.h --- crossfire-client-1.1.0/common/external.h Fri Dec 28 09:56:41 2001 +++ crossfire-client-1.1.0-et/common/external.h Mon Jan 7 01:46:46 2002 @@ -53,6 +53,7 @@ extern void draw_prompt(const char *str); extern void x_set_echo(void); extern void set_scroll(char *s); +extern void set_autorepeat(char *s); /* Stats related commands */ extern void draw_stats(int redraw); diff -ruN crossfire-client-1.1.0/common/init.c crossfire-client-1.1.0-et/common/init.c --- crossfire-client-1.1.0/common/init.c Fri Dec 28 09:56:41 2001 +++ crossfire-client-1.1.0-et/common/init.c Mon Jan 7 17:10:49 2002 @@ -57,26 +57,20 @@ void SendVersion(ClientSocket csock) { - char buf[MAX_BUF]; - - sprintf(buf,"version %d %d %s", VERSION_CS, VERSION_SC, VERSION_INFO); - cs_write_string(csock.fd, buf, strlen(buf)); + cs_print_string(csock.fd, + "version %d %d %s", VERSION_CS, VERSION_SC, VERSION_INFO); } void SendAddMe(ClientSocket csock) { - - cs_write_string(csock.fd, "addme",5); + cs_print_string(csock.fd, "addme"); } void SendSetFaceMode(ClientSocket csock,int mode) { - char buf[MAX_BUF]; - - sprintf(buf,"setfacemode %d", mode); - cs_write_string(csock.fd, buf, strlen(buf)); + cs_print_string(csock.fd, "setfacemode %d", mode); } diff -ruN crossfire-client-1.1.0/common/item.c crossfire-client-1.1.0-et/common/item.c --- crossfire-client-1.1.0/common/item.c Fri Dec 28 09:56:41 2001 +++ crossfire-client-1.1.0-et/common/item.c Mon Jan 7 17:23:39 2002 @@ -575,32 +575,29 @@ void toggle_locked (item *op) { SockList sl; - char buf[MAX_BUF]; + char buf[MAX_BUF]; if (op->env->tag == 0) return; /* if item is on the ground, don't lock it */ - sl.buf = (unsigned char*)buf; - strcpy((char*)sl.buf, "lock "); - sl.len=5; - if (op->locked) sl.buf[sl.len++]=0; - else sl.buf[sl.len++]=1; + SockList_Init(&sl, buf); + SockList_AddString(&sl, "lock "); + SockList_AddChar(&sl, !op->locked); SockList_AddInt(&sl, op->tag); - send_socklist(csocket.fd, sl); + SockList_Send(&sl, csocket.fd); } void send_mark_obj (item *op) { SockList sl; - char buf[MAX_BUF]; + char buf[MAX_BUF]; if (op->env->tag == 0) return; /* if item is on the ground, don't mark it */ - sl.buf = (unsigned char*)buf; - strcpy((char*)sl.buf, "mark "); - sl.len=5; + SockList_Init(&sl, buf); + SockList_AddString(&sl, "mark "); SockList_AddInt(&sl, op->tag); - send_socklist(csocket.fd, sl); + SockList_Send(&sl, csocket.fd); } diff -ruN crossfire-client-1.1.0/common/newsocket.c crossfire-client-1.1.0-et/common/newsocket.c --- crossfire-client-1.1.0/common/newsocket.c Fri Dec 28 09:56:41 2001 +++ crossfire-client-1.1.0-et/common/newsocket.c Mon Jan 7 17:03:25 2002 @@ -30,15 +30,16 @@ */ -#ifdef DEBUG #include #include -#endif +#include + +#include +#include /* The LOG function is normally part of the libcross. If client compile, * we need to supply something since some of the common code calls this. */ -#include void LOG (int logLevel, char *format, ...) { #ifdef DEBUG @@ -48,42 +49,89 @@ va_end(ap); #endif } + + /* We don't care what these values are in the client, since * we toss them */ #define llevDebug 0 #define llevError 0 -#include -#include -void SockList_Init(SockList *sl) +/* + * This writes data to the socket. + */ +static int write_socket(int fd, unsigned char *buf, int len) +{ + int amt=0; + unsigned char *pos=buf; + + /* If we manage to write more than we wanted, take it as a bonus */ + while (len>0) { + do { + amt=write(fd, pos, len); + } while ((amt<0) && (errno==EINTR)); + + if (amt < 0) { /* We got an error */ + LOG(llevError,"New socket (fd=%d) write failed.\n", fd); + return -1; + } + if (amt==0) { + LOG(llevError,"Write_To_Socket: No data written out.\n"); + } + len -= amt; + pos += amt; + } + return 0; +} + + + +void SockList_Init(SockList *sl, char *buf) { sl->len=0; - sl->buf=NULL; + sl->buf=buf + 2; /* reserve two bytes for total length */ } void SockList_AddChar(SockList *sl, char c) { - sl->buf[sl->len]=c; - sl->len++; + sl->buf[sl->len++]=c; } void SockList_AddShort(SockList *sl, uint16 data) { - sl->buf[sl->len++]= (data>>8)&0xff; + sl->buf[sl->len++] = (data>>8)&0xff; sl->buf[sl->len++] = data & 0xff; } void SockList_AddInt(SockList *sl, uint32 data) { - sl->buf[sl->len++]= (data>>24)&0xff; - sl->buf[sl->len++]= (data>>16)&0xff; - sl->buf[sl->len++]= (data>>8)&0xff; + sl->buf[sl->len++] = (data>>24)&0xff; + sl->buf[sl->len++] = (data>>16)&0xff; + sl->buf[sl->len++] = (data>>8)&0xff; sl->buf[sl->len++] = data & 0xff; } +void SockList_AddString(SockList *sl, const char *str) +{ + int len = strlen(str); + + if (sl->len + len > MAX_BUF-2) + len = MAX_BUF-2 - sl->len; + memcpy(sl->buf + sl->len, str, len); + sl->len += len; +} + +int SockList_Send(SockList *sl, int fd) +{ + sl->buf[-2] = sl->len / 256; + sl->buf[-1] = sl->len % 256; + + return write_socket(fd, sl->buf-2, sl->len+2); +} + + /* Basically does the reverse of SockList_AddInt, but on * strings instead. Same for the GetShort, but for 16 bits. */ @@ -168,56 +216,19 @@ return 0; } -/* This writes data to the socket. we precede the len information on the - * packet. Len needs to be passed here because buf could be binary - * data +/* + * Send a printf-formatted packet to the socket. */ -static int write_socket(int fd, unsigned char *buf, int len) -{ - int amt=0; - unsigned char *pos=buf; - - /* If we manage to write more than we wanted, take it as a bonus */ - while (len>0) { - do { - amt=write(fd, pos, len); - } while ((amt<0) && (errno==EINTR)); - - if (amt < 0) { /* We got an error */ - LOG(llevError,"New socket (fd=%d) write failed.\n", fd); - return -1; - } - if (amt==0) { - LOG(llevError,"Write_To_Socket: No data written out.\n"); - } - len -= amt; - pos += amt; - } - return 0; -} - -/* Send With Handling - cnum is the client number, msg is what we want - * to send. - */ -int send_socklist(int fd,SockList msg) -{ - unsigned char sbuf[2]; - - sbuf[0] = ((uint32)(msg.len) >> 8) & 0xFF; - sbuf[1] = ((uint32)(msg.len)) & 0xFF; - - write_socket(fd, sbuf, 2); - return write_socket(fd, msg.buf, msg.len); -} - -/* Takes a string of data, and writes it out to the socket. A very handy - * shortcut function. - */ -int cs_write_string(int fd, char *buf, int len) +int cs_print_string(int fd, char *str, ...) { + va_list args; SockList sl; + char buf[MAX_BUF]; + + SockList_Init(&sl, buf); + va_start(args, str); + sl.len += vsprintf(sl.buf + sl.len, str, args); + va_end(args); - sl.len = len; - sl.buf = (unsigned char*)buf; - return send_socklist(fd, sl); + return SockList_Send(&sl, fd); } diff -ruN crossfire-client-1.1.0/common/player.c crossfire-client-1.1.0-et/common/player.c --- crossfire-client-1.1.0/common/player.c Fri Dec 28 09:56:41 2001 +++ crossfire-client-1.1.0-et/common/player.c Mon Jan 7 17:26:09 2002 @@ -64,36 +64,24 @@ void look_at(int x, int y) { - char buf[MAX_BUF]; - - sprintf(buf,"lookat %d %d", x, y); - cs_write_string(csocket.fd, buf, strlen(buf)); + cs_print_string(csocket.fd, "lookat %d %d", x, y); } void client_send_apply (int tag) { - char buf[MAX_BUF]; - - sprintf(buf,"apply %d", tag); - cs_write_string(csocket.fd, buf, strlen(buf)); + cs_print_string(csocket.fd, "apply %d", tag); } void client_send_examine (int tag) { - char buf[MAX_BUF]; - - sprintf(buf,"examine %d", tag); - cs_write_string(csocket.fd, buf, strlen(buf)); + cs_print_string(csocket.fd, "examine %d", tag); } /* Requests nrof objects of tag get moved to loc. */ void client_send_move (int loc, int tag, int nrof) { - char buf[MAX_BUF]; - - sprintf(buf,"move %d %d %d", loc, tag, nrof); - cs_write_string(csocket.fd, buf, strlen(buf)); + cs_print_string(csocket.fd, "move %d %d %d", loc, tag, nrof); } @@ -195,7 +183,6 @@ */ int send_command(const char *command, int repeat, int must_send) { - char buf[MAX_BUF]; static char last_command[MAX_BUF]=""; if (cpl.input_state==Reply_One) { @@ -231,19 +218,15 @@ csocket.command_sent++; csocket.command_sent &= 0xff; /* max out at 255 */ - sl.buf = (unsigned char*)buf; - strcpy((char*)sl.buf,"ncom "); - sl.len=5; + SockList_Init(&sl, buf); + SockList_AddString(&sl, "ncom "); SockList_AddShort(&sl, csocket.command_sent); SockList_AddInt(&sl, repeat); - strncpy((char*)sl.buf + sl.len, command, MAX_BUF - sl.len); - sl.buf[MAX_BUF-1]=0; - sl.len += strlen(command); - send_socklist(csocket.fd, sl); + SockList_AddString(&sl, command); + SockList_Send(&sl, csocket.fd); } } else { - sprintf(buf,"command %d %s", repeat,command); - cs_write_string(csocket.fd, buf, strlen(buf)); + cs_print_string(csocket.fd, "command %d %s", repeat,command); } if (repeat!=-1) cpl.count=0; return 1; @@ -289,7 +272,7 @@ draw_info(" ~/.crossfire/defaults", NDI_BLACK); draw_info(" show - determine what type of items", NDI_BLACK); draw_info(" to show in inventory", NDI_BLACK); - + draw_info(" autorepeat - toggle autorepeat", NDI_BLACK); } /* This is an extended command (ie, 'who, 'whatever, etc). In general, @@ -312,6 +295,10 @@ strncpy(command, ocommand, len); command[len] = '\0'; cp = command; + while (*cpnext == ' ') + cpnext++; + if (*cpnext == 0) + cpnext = NULL; } /* cp now contains the command (everything before first space), * and cpnext contains everything after that first space. cpnext @@ -327,6 +314,8 @@ set_show_weight (cpnext); else if (!strcmp(cp,"scroll")) set_scroll(cpnext); + else if (!strcmp(cp,"autorepeat")) + set_autorepeat(cpnext); else if (!strcmp(cp,"magicmap")) { cpl.showmagic=1; draw_magic_map(); @@ -352,7 +341,7 @@ save_winpos(); } else if (!strcmp(cp,"mapredraw")) { - cs_write_string(csocket.fd, "mapredraw",9); + cs_print_string(csocket.fd, "mapredraw"); } else if (!strcmp(cp,"savedefaults")) { save_defaults(); diff -ruN crossfire-client-1.1.0/common/proto.h crossfire-client-1.1.0-et/common/proto.h --- crossfire-client-1.1.0/common/proto.h Fri Dec 28 09:56:41 2001 +++ crossfire-client-1.1.0-et/common/proto.h Mon Jan 7 17:19:30 2002 @@ -63,15 +63,16 @@ extern char *strdup_local(char *str); /* newsocket.c */ extern void LOG(int logLevel, char *format, ...); -extern void SockList_Init(SockList *sl); +extern void SockList_Init(SockList *sl, char *buf); extern void SockList_AddChar(SockList *sl, char c); extern void SockList_AddShort(SockList *sl, uint16 data); extern void SockList_AddInt(SockList *sl, uint32 data); +extern void SockList_AddString(SockList *sl, const char *str); +extern int SockList_Send(SockList *sl, int fd); extern int GetInt_String(unsigned char *data); extern short GetShort_String(unsigned char *data); extern int SockList_ReadPacket(int fd, SockList *sl, int len); -extern int send_socklist(int fd, SockList msg); -extern int cs_write_string(int fd, char *buf, int len); +extern int cs_print_string(int fd, char *str, ...); /* player.c */ extern void new_player(long tag, char *name, long weight, long face); extern void look_at(int x, int y); diff -ruN crossfire-client-1.1.0/configure crossfire-client-1.1.0-et/configure --- crossfire-client-1.1.0/configure Fri Dec 28 09:56:41 2001 +++ crossfire-client-1.1.0-et/configure Mon Jan 7 00:45:29 2002 @@ -7220,7 +7220,7 @@ echo $ECHO_N "(cached) $ECHO_C" >&6 else ac_check_lib_save_LIBS=$LIBS -LIBS="-lpng $LIBS" +LIBS="-lpng -lz $LIBS" cat >conftest.$ac_ext <<_ACEOF #line 7225 "configure" #include "confdefs.h" @@ -7267,7 +7267,7 @@ #define HAVE_LIBPNG 1 _ACEOF - LIBS="-lpng $LIBS" + LIBS="-lpng -lz $LIBS" else { { echo "$as_me:7273: error: You must have the png library installed to compile the client" >&5 diff -ruN crossfire-client-1.1.0/gnome/gnome.c crossfire-client-1.1.0-et/gnome/gnome.c --- crossfire-client-1.1.0/gnome/gnome.c Fri Dec 28 09:56:41 2001 +++ crossfire-client-1.1.0-et/gnome/gnome.c Mon Jan 7 17:14:33 2002 @@ -385,9 +385,9 @@ requestface(int pnum, char *facename, char *facepath) { char buf[MAX_BUF]; + facetoname[pnum] = strdup_local(facepath); - sprintf(buf, "askface %d", pnum); - cs_write_string(csocket.fd, buf, strlen(buf)); + cs_print_string(csocket.fd, "askface %d", pnum); sprintf(buf, "%s/%c%c", facecachedir, facename[0], facename[1]); if (access(buf, R_OK)) make_path_to_dir(buf); @@ -3138,10 +3138,7 @@ if (nosound) { nosound = FALSE; sound = init_sounds(); - if (sound < 0) - cs_write_string(csocket.fd, "setsound 0", 10); - else - cs_write_string(csocket.fd, "setsound 1", 10); + cs_print_string(csocket.fd, "setsound %d", sound >= 0); } } else { if (!nosound) { @@ -3912,6 +3909,11 @@ void set_scroll(char *s) +{ +} + +void +set_autorepeat(char *s) { } diff -ruN crossfire-client-1.1.0/gnome/map.c crossfire-client-1.1.0-et/gnome/map.c --- crossfire-client-1.1.0/gnome/map.c Fri Dec 28 09:56:41 2001 +++ crossfire-client-1.1.0-et/gnome/map.c Mon Jan 7 17:14:46 2002 @@ -127,7 +127,7 @@ } } - cs_write_string( csocket.fd, "mapredraw", 9); + cs_print_string(csocket.fd, "mapredraw"); return; } diff -ruN crossfire-client-1.1.0/gtk/gtkproto.h crossfire-client-1.1.0-et/gtk/gtkproto.h --- crossfire-client-1.1.0/gtk/gtkproto.h Fri Dec 28 09:56:41 2001 +++ crossfire-client-1.1.0-et/gtk/gtkproto.h Mon Jan 7 17:19:43 2002 @@ -50,6 +50,7 @@ extern void create_windows(void); extern void set_weight_limit(uint32 wlim); extern void set_scroll(char *s); +extern void set_autorepeat(char *s); extern int get_info_width(void); extern void do_clearlock(void); extern void x_set_echo(void); @@ -109,10 +110,6 @@ extern int rgba_to_gdkpixmap(GdkWindow *window, uint8 *data, int width, int height, GdkPixmap **pix, GdkBitmap **mask, GdkColormap *colormap); extern int png_to_gdkpixmap(GdkWindow *window, uint8 *data, int len, GdkPixmap **pix, GdkBitmap **mask, GdkColormap *colormap); /* sdl.c */ -extern void init_SDL(GtkWidget *sdl_window, int just_lightmap); -extern void do_sdl_per_pixel_lighting(int x, int y, int mx, int my); -extern void sdl_gen_map(void); -extern void sdl_mapscroll(int dx, int dy); /* sound.c */ extern void signal_pipe(int i); extern int init_sounds(void); diff -ruN crossfire-client-1.1.0/gtk/gx11.c crossfire-client-1.1.0-et/gtk/gx11.c --- crossfire-client-1.1.0/gtk/gx11.c Fri Dec 28 09:56:41 2001 +++ crossfire-client-1.1.0-et/gtk/gx11.c Mon Jan 7 17:18:10 2002 @@ -3138,10 +3138,7 @@ if (nosound) { nosound=FALSE; sound = init_sounds(); - if (sound<0) - cs_write_string(csocket.fd,"setsound 0", 10); - else - cs_write_string(csocket.fd,"setsound 1", 10); + cs_print_string(csocket.fd, "setsound %d", sound >= 0); } } else { if (!nosound) { @@ -3211,7 +3208,7 @@ per_tile_lighting= 0; init_SDL( NULL, 1); if( csocket.fd) - cs_write_string( csocket.fd, "mapredraw", 9); + cs_print_string(csocket.fd, "mapredraw"); } } else { if( per_pixel_lighting == 1) { @@ -3219,7 +3216,7 @@ per_tile_lighting= 1; init_SDL( NULL, 1); if( csocket.fd) - cs_write_string( csocket.fd, "mapredraw", 9); + cs_print_string(csocket.fd, "mapredraw"); } } if( GTK_TOGGLE_BUTTON( ccheckbutton9)->active) { @@ -3277,10 +3274,7 @@ if (nosound) { nosound=FALSE; sound = init_sounds(); - if (sound<0) - cs_write_string(csocket.fd,"setsound 0", 10); - else - cs_write_string(csocket.fd,"setsound 1", 10); + cs_print_string(csocket.fd, "setsound %d", sound >= 0); } } else { if (!nosound) { @@ -3350,16 +3344,16 @@ per_pixel_lighting= 1; per_tile_lighting= 0; init_SDL( NULL, 1); - if( csocket.fd) - cs_write_string( csocket.fd, "mapredraw", 9); + if (csocket.fd) + cs_print_string(csocket.fd, "mapredraw"); } } else { if( per_pixel_lighting == 1) { per_pixel_lighting= 0; per_tile_lighting= 1; init_SDL( NULL, 1); - if( csocket.fd) - cs_write_string( csocket.fd, "mapredraw", 9); + if (csocket.fd) + cs_print_string(csocket.fd, "mapredraw"); } } if( GTK_TOGGLE_BUTTON( ccheckbutton9)->active) { @@ -5033,6 +5027,10 @@ { } + +void set_autorepeat(char *s) +{ +} int get_info_width() diff -ruN crossfire-client-1.1.0/gtk/image.c crossfire-client-1.1.0-et/gtk/image.c --- crossfire-client-1.1.0/gtk/image.c Fri Dec 28 09:56:41 2001 +++ crossfire-client-1.1.0-et/gtk/image.c Mon Jan 7 17:18:35 2002 @@ -94,8 +94,7 @@ char buf[MAX_BUF]; facetoname[pnum] = strdup_local(facepath); - sprintf(buf,"askface %d", pnum); - cs_write_string(csocket.fd, buf, strlen(buf)); + cs_print_string(csocket.fd, "askface %d", pnum); /* Need to make sure we have the directory */ sprintf(buf,"%s/%c%c", facecachedir, facename[0], facename[1]); if (access(buf,R_OK)) make_path_to_dir(buf); diff -ruN crossfire-client-1.1.0/gtk/map.c crossfire-client-1.1.0-et/gtk/map.c --- crossfire-client-1.1.0/gtk/map.c Fri Dec 28 09:56:41 2001 +++ crossfire-client-1.1.0-et/gtk/map.c Mon Jan 7 17:18:48 2002 @@ -152,8 +152,7 @@ } } - cs_write_string( csocket.fd, "mapredraw", 9); - + cs_print_string(csocket.fd, "mapredraw"); return; } diff -ruN crossfire-client-1.1.0/gtk/png.c crossfire-client-1.1.0-et/gtk/png.c --- crossfire-client-1.1.0/gtk/png.c Fri Dec 28 09:56:41 2001 +++ crossfire-client-1.1.0-et/gtk/png.c Mon Jan 7 20:15:48 2002 @@ -211,13 +211,14 @@ */ #define RATIO 100 -#define MAX_IMAGE_BYTES 512*512 +#define MAX_IMAGE_WIDTH 1024 +#define MAX_IMAGE_HEIGHT 1024 #define BPP 4 uint8 *rescale_rgba_data(uint8 *data, int *width, int *height, int scale) { - static int xrow[BPP * MAX_IMAGE_BYTES], yrow[BPP*MAX_IMAGE_BYTES]; - static uint8 *nrows[MAX_IMAGE_BYTES]; + static int xrow[BPP * MAX_IMAGE_WIDTH], yrow[BPP*MAX_IMAGE_HEIGHT]; + static uint8 *nrows[MAX_IMAGE_HEIGHT]; /* Figure out new height/width */ int new_width = *width * scale / RATIO, new_height = *height * scale / RATIO; @@ -227,6 +228,13 @@ int x,y; uint8 *ndata; uint8 r,g,b,a; + + if (*width > MAX_IMAGE_WIDTH || new_width > MAX_IMAGE_WIDTH + || *height > MAX_IMAGE_HEIGHT || new_height > MAX_IMAGE_HEIGHT) + { + fprintf(stderr, "Image too big\n"); + exit(0); + } /* clear old values these may have */ memset(yrow, 0, sizeof(int) * *height * BPP); diff -ruN crossfire-client-1.1.0/pixmaps/applied.xbm crossfire-client-1.1.0-et/pixmaps/applied.xbm --- crossfire-client-1.1.0/pixmaps/applied.xbm Thu Jan 1 01:00:00 1970 +++ crossfire-client-1.1.0-et/pixmaps/applied.xbm Mon Jan 7 19:20:19 2002 @@ -0,0 +1,5 @@ +#define applied_width 24 +#define applied_height 6 +static char applied_bits[] = { + 0xe7,0xa4,0x3b,0x11,0x25,0x49,0x13,0x25,0x39,0x11,0x25,0x09,0xe7,0x98,0x0b, + 0x00,0x01,0x00}; diff -ruN crossfire-client-1.1.0/pixmaps/clear.xbm crossfire-client-1.1.0-et/pixmaps/clear.xbm --- crossfire-client-1.1.0/pixmaps/clear.xbm Thu Jan 1 01:00:00 1970 +++ crossfire-client-1.1.0-et/pixmaps/clear.xbm Mon Jan 7 19:22:47 2002 @@ -0,0 +1,6 @@ +#define clear_width 24 +#define clear_height 13 +static char clear_bits[] = { + 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, + 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, + 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}; diff -ruN crossfire-client-1.1.0/pixmaps/close.xbm crossfire-client-1.1.0-et/pixmaps/close.xbm --- crossfire-client-1.1.0/pixmaps/close.xbm Thu Jan 1 01:00:00 1970 +++ crossfire-client-1.1.0-et/pixmaps/close.xbm Mon Jan 7 19:20:19 2002 @@ -0,0 +1,6 @@ +#define close_width 24 +#define close_height 13 +static char close_bits[] = { + 0x00,0x00,0x00,0x26,0x18,0x73,0x29,0xa4,0x10,0x21,0x24,0x33,0x29,0x24,0x14, + 0xe6,0x19,0x73,0x00,0x00,0x00,0x40,0xc4,0x03,0xc0,0x46,0x00,0x40,0xc5,0x01, + 0x40,0x44,0x00,0x40,0xc4,0x03,0x00,0x00,0x00}; diff -ruN crossfire-client-1.1.0/pixmaps/cursed.xbm crossfire-client-1.1.0-et/pixmaps/cursed.xbm --- crossfire-client-1.1.0/pixmaps/cursed.xbm Thu Jan 1 01:00:00 1970 +++ crossfire-client-1.1.0-et/pixmaps/cursed.xbm Mon Jan 7 19:20:19 2002 @@ -0,0 +1,5 @@ +#define cursed_width 24 +#define cursed_height 6 +static char cursed_bits[] = { + 0x4e,0x1a,0x77,0x51,0xaa,0x10,0x41,0x1a,0x73,0x51,0x2a,0x14,0x8e,0xa9,0x73, + 0x00,0x00,0x00}; diff -ruN crossfire-client-1.1.0/pixmaps/damned.xbm crossfire-client-1.1.0-et/pixmaps/damned.xbm --- crossfire-client-1.1.0/pixmaps/damned.xbm Thu Jan 1 01:00:00 1970 +++ crossfire-client-1.1.0-et/pixmaps/damned.xbm Mon Jan 7 19:20:19 2002 @@ -0,0 +1,5 @@ +#define damned_width 24 +#define damned_height 6 +static char damned_bits[] = { + 0x8f,0x6c,0x09,0x52,0x6d,0x0b,0xd2,0x55,0x0b,0x52,0x55,0x0d,0x4f,0x45,0x09, + 0x00,0x00,0x00}; diff -ruN crossfire-client-1.1.0/pixmaps/locked.xbm crossfire-client-1.1.0-et/pixmaps/locked.xbm --- crossfire-client-1.1.0/pixmaps/locked.xbm Thu Jan 1 01:00:00 1970 +++ crossfire-client-1.1.0-et/pixmaps/locked.xbm Mon Jan 7 19:20:19 2002 @@ -0,0 +1,5 @@ +#define locked_width 24 +#define locked_height 6 +static char locked_bits[] = { + 0xc7,0x71,0x26,0x22,0x8a,0x14,0x22,0x0a,0x0c,0x2a,0x8a,0x14,0xcf,0x71,0x36, + 0x00,0x00,0x00}; diff -ruN crossfire-client-1.1.0/pixmaps/magic.xbm crossfire-client-1.1.0-et/pixmaps/magic.xbm --- crossfire-client-1.1.0/pixmaps/magic.xbm Thu Jan 1 01:00:00 1970 +++ crossfire-client-1.1.0-et/pixmaps/magic.xbm Mon Jan 7 19:20:19 2002 @@ -0,0 +1,5 @@ +#define magic_width 24 +#define magic_height 6 +static char magic_bits[] = { + 0x9b,0x38,0x39,0x5b,0x05,0x45,0xd5,0x75,0x05,0x55,0x45,0x45,0x51,0x39,0x39, + 0x00,0x00,0x00}; diff -ruN crossfire-client-1.1.0/pixmaps/question.111 crossfire-client-1.1.0-et/pixmaps/question.111 --- crossfire-client-1.1.0/pixmaps/question.111 Fri Dec 28 09:56:41 2001 +++ crossfire-client-1.1.0-et/pixmaps/question.111 Mon Jan 7 21:40:29 2002 @@ -1,9 +1,14 @@ -#define question_width 24 -#define question_height 24 +#define question_width 32 +#define question_height 32 static unsigned char question_bits[] = { - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x1f, 0x00, 0xc0, 0x7f, 0x00, - 0xe0, 0xff, 0x00, 0x70, 0xc0, 0x01, 0x38, 0x80, 0x03, 0x38, 0x80, 0x03, - 0x38, 0x80, 0x03, 0x38, 0x80, 0x03, 0x38, 0x80, 0x03, 0x70, 0xc0, 0x01, - 0x00, 0xc0, 0x01, 0x00, 0x70, 0x00, 0x00, 0x78, 0x00, 0x00, 0x3e, 0x00, - 0x00, 0x0e, 0x00, 0x00, 0x0e, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, - 0x00, 0x00, 0x00, 0x00, 0x0e, 0x00, 0x00, 0x0e, 0x00, 0x00, 0x0e, 0x00}; + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x1f, 0x00, 0x00, + 0xc0, 0x7f, 0x00, 0x00, 0xe0, 0xff, 0x00, 0x00, 0x70, 0xc0, 0x01, 0x00, + 0x38, 0x80, 0x03, 0x00, 0x38, 0x80, 0x03, 0x00, 0x38, 0x80, 0x03, 0x00, + 0x38, 0x80, 0x03, 0x00, 0x38, 0x80, 0x03, 0x00, 0x70, 0xc0, 0x01, 0x00, + 0x00, 0xc0, 0x01, 0x00, 0x00, 0x70, 0x00, 0x00, 0x00, 0x78, 0x00, 0x00, + 0x00, 0x3e, 0x00, 0x00, 0x00, 0x0e, 0x00, 0x00, 0x00, 0x0e, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x0e, 0x00, 0x00, 0x00, 0x0e, 0x00, 0x00, 0x00, 0x0e, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; diff -ruN crossfire-client-1.1.0/pixmaps/question24.111 crossfire-client-1.1.0-et/pixmaps/question24.111 --- crossfire-client-1.1.0/pixmaps/question24.111 Thu Jan 1 01:00:00 1970 +++ crossfire-client-1.1.0-et/pixmaps/question24.111 Mon Jan 7 21:32:59 2002 @@ -0,0 +1,9 @@ +#define question_width 24 +#define question_height 24 +static unsigned char question_bits[] = { + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x1f, 0x00, 0xc0, 0x7f, 0x00, + 0xe0, 0xff, 0x00, 0x70, 0xc0, 0x01, 0x38, 0x80, 0x03, 0x38, 0x80, 0x03, + 0x38, 0x80, 0x03, 0x38, 0x80, 0x03, 0x38, 0x80, 0x03, 0x70, 0xc0, 0x01, + 0x00, 0xc0, 0x01, 0x00, 0x70, 0x00, 0x00, 0x78, 0x00, 0x00, 0x3e, 0x00, + 0x00, 0x0e, 0x00, 0x00, 0x0e, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x0e, 0x00, 0x00, 0x0e, 0x00, 0x00, 0x0e, 0x00}; diff -ruN crossfire-client-1.1.0/pixmaps/unpaid.xbm crossfire-client-1.1.0-et/pixmaps/unpaid.xbm --- crossfire-client-1.1.0/pixmaps/unpaid.xbm Thu Jan 1 01:00:00 1970 +++ crossfire-client-1.1.0-et/pixmaps/unpaid.xbm Mon Jan 7 19:20:19 2002 @@ -0,0 +1,5 @@ +#define unpaid_width 24 +#define unpaid_height 6 +static char unpaid_bits[] = { + 0x29,0x1d,0x69,0x69,0xa5,0xaa,0x69,0x9d,0xab,0xa9,0x85,0xaa,0x26,0x85,0x6a, + 0x00,0x00,0x00}; diff -ruN crossfire-client-1.1.0/sound-src/cfsndserv.c crossfire-client-1.1.0-et/sound-src/cfsndserv.c --- crossfire-client-1.1.0/sound-src/cfsndserv.c Fri Dec 28 09:56:41 2001 +++ crossfire-client-1.1.0-et/sound-src/cfsndserv.c Mon Jan 7 01:15:35 2002 @@ -51,6 +51,7 @@ #include #include #include +#include #ifdef HAVE_FCNTL_H #include @@ -974,7 +975,7 @@ if (FD_ISSET(infd,&inset)){ int err=read(infd,inbuf+inbuf_pos,1); if (err<1 && errno!=EINTR){ - perror("read"); + if (err<0) perror("read"); break; } if (inbuf[inbuf_pos]=='\n'){ diff -ruN crossfire-client-1.1.0/x11/cfclient.man crossfire-client-1.1.0-et/x11/cfclient.man --- crossfire-client-1.1.0/x11/cfclient.man Fri Dec 28 09:56:41 2001 +++ crossfire-client-1.1.0-et/x11/cfclient.man Mon Jan 7 17:38:17 2002 @@ -42,14 +42,21 @@ be moved around and resized as desired. -nosplit starts the game up with a single window - this is the default. The option is useful if your saved defaults are set for -split (see Saved Defaults further down). - +.TP +.B -font +Use the given font instead of the default 8x13. Only fixed width +fonts will work properly. +.TP +.B -noautorepeat +Disable autorepeat on directional keys. This may be useful when +playing on a distant remote server. This flag may be toggled +while playing with the 'autorepeat' command. .TP .B -echo Echo commands as they are entered. Normally, commands bound to keys are just sent to the server without any echoing on the client of what that command actually was. This option causes the commands to also be printed in the information window as they are sent to the server. - .TP .B -mapsize XxY Sets the desired viewable map window. X and Y are number of tiles. @@ -65,8 +72,6 @@ (simple test - go to the start town, run in some direction, stop running and see how long it takes before the client stops moving you). - - .TP .B -pix|-xpm|-png This determines the graphic image types to use. -pix uses pixmap images - @@ -81,7 +86,6 @@ efficiency of the png format, actually take less bandwidth to transmit than the xpm images. Using the png images require that the client has been compiled with png support. - .TP .B -pngximage gcfclient only. This option is only meaningful if png graphics are @@ -91,7 +95,6 @@ the mapsize option above, it is suggested the experimentation is done to make performance is still acceptable. This option does not affect bandwidth - it only affects cpu performancs. - .TP .B -sdl gcfclient only. Will only be available if the SDL library was @@ -100,14 +103,12 @@ library to actualy draw them to the screen. This is slightly faster than -pngximage - if you have SDL, you should use this instead of -pngximage. - .TP .B -showicon This shows a little icon next to items in your inventory that contains a brief description of some of the item properties (magic, cursed, equipped, etc.) This can make spotting some items easier, but some players may not like the extra space these icons take up or the - .TP .B -scollines This is the number of lines to use in the information window. By default, @@ -116,17 +117,14 @@ through old messages. It is strongly recommended you set this to some value, since some areas output more data than will fit in the output window at one time. - .TP .B -sync Runs the server in synchronous display mode. This option tends only to be useful in debugging purposes - using this will slow down the display and not gain anything for the typical player. - .TP .B -help Prints out a brief description of the options to standard output. - .TP .B -cache|-nocache Determines if the client will cache images for future runs. With -nocache, @@ -144,7 +142,6 @@ is slower than home directory access - this is likely to be the case except in case of nfs mounted home directories on the server on the local lan. - .TP .B -darkness|-nodarkness Controls whether the server sends darkness information to the client @@ -152,7 +149,6 @@ for maps that use darkness code (currently, very few maps use darkness code). Turning off darkness may also be desirable as in some graphics mode the quality of darkness may not add much to the map. - .TP .B -updatekeycodes The standard behaviour when a player uses the bind command to bind @@ -221,13 +217,11 @@ .TP .B savewinpos savedefaults These commands were described in the SAVED DEFAULTS options above. - .TP .B scroll This toggles whether or the information windows scrolls when it gets to the bottom of the window or wraps to the top. Wrapping is slighly less cpu intensive, but is generally harder to read. - .TP .B bind unbind bind is used to add new keybindings. Do you want to be able to press @@ -257,7 +251,11 @@ Having this value too low on slow links can result in the character sitting idle even though they have an action comming to them. - +.TP +.B autorepeat +Toggle the autorepeat handling for directional keys. When +disabled artifical keystrokes generated by the autorepeat +of the X-server are not sent to the Crossfire server. .SH FILES .TP diff -ruN crossfire-client-1.1.0/x11/png.c crossfire-client-1.1.0-et/x11/png.c --- crossfire-client-1.1.0/x11/png.c Fri Dec 28 09:56:41 2001 +++ crossfire-client-1.1.0-et/x11/png.c Mon Jan 7 22:45:25 2002 @@ -62,6 +62,8 @@ data_start += length; } +#ifdef PNG_GDK + uint8 *png_to_data(unsigned char *data, int len, int *width, int *height) { uint8 *pixels=NULL; @@ -217,13 +219,14 @@ */ #define RATIO 100 -#define MAX_IMAGE_BYTES 512*512 +#define MAX_IMAGE_WIDTH 1024 +#define MAX_IMAGE_HEIGHT 1024 #define BPP 4 uint8 *rescale_rgba_data(uint8 *data, int *width, int *height, int scale) { - static int xrow[BPP * MAX_IMAGE_BYTES], yrow[BPP*MAX_IMAGE_BYTES]; - static uint8 *nrows[MAX_IMAGE_BYTES]; + static int xrow[BPP * MAX_IMAGE_WIDTH], yrow[BPP*MAX_IMAGE_HEIGHT]; + static uint8 *nrows[MAX_IMAGE_HEIGHT]; /* Figure out new height/width */ int new_width = *width * scale / RATIO, new_height = *height * scale / RATIO; @@ -234,6 +237,13 @@ uint8 *ndata; uint8 r,g,b,a; + if (*width > MAX_IMAGE_WIDTH || new_width > MAX_IMAGE_WIDTH + || *height > MAX_IMAGE_HEIGHT || new_height > MAX_IMAGE_HEIGHT) + { + fprintf(stderr, "Image too big\n"); + exit(0); + } + /* clear old values these may have */ memset(yrow, 0, sizeof(int) * *height * BPP); @@ -365,7 +375,6 @@ return ndata; } -#ifdef PNG_GDK guchar rgb[512*512*3]; /* Make this especially big to support larger images in the future */ @@ -611,6 +620,8 @@ } #else + + static XImage *ximage; static int rmask=0, bmask=0,gmask=0,need_color_alloc=0, rshift=16, bshift=0, gshift=8, rev_rshift=0, rev_gshift=0, rev_bshift=0; diff -ruN crossfire-client-1.1.0/x11/x11.c crossfire-client-1.1.0-et/x11/x11.c --- crossfire-client-1.1.0/x11/x11.c Fri Dec 28 09:56:41 2001 +++ crossfire-client-1.1.0-et/x11/x11.c Mon Jan 7 21:59:11 2002 @@ -149,6 +149,8 @@ uint32 weight_limit; /* Weight limit for this list - used for title */ } itemlist; +int noautorepeat = FALSE; /* turn off autorepeat detection */ + static char *font_name="8x13", **gargv; struct Map the_map; @@ -182,7 +184,8 @@ Display_Mode display_mode = DISPLAY_MODE; uint8 cache_images=FALSE; Display *display; -long screen_num; +static Window def_root; /* default root window */ +static long def_screen; /* default screen number */ static unsigned long foreground,background; Window win_stats,win_message; Window win_root,win_game; @@ -246,11 +249,11 @@ #define XPMGCS 100 enum { - locked_icon = 1, applied_icon, unpaid_icon, + no_icon = 0, locked_icon, applied_icon, unpaid_icon, damned_icon, cursed_icon, magic_icon, close_icon, stipple1_icon, stipple2_icon, max_icons }; -static struct PixmapInfo icons[max_icons]; +static Pixmap icons[max_icons]; static Pixmap icon,xpm_pixmap,xpm_masks[XPMGCS]; static GC gc_root,gc_stats,gc_message, @@ -442,7 +445,7 @@ (_Xconst char *) crossfire_bits, (unsigned int) crossfire_width, (unsigned int)crossfire_height); if (split_windows) { - iscolor=allocate_colors(display, win_root, screen_num, + iscolor=allocate_colors(display, win_root, def_screen, &colormap, discolor); if (iscolor){ foreground=discolor[0].pixel; @@ -479,8 +482,7 @@ gc_xpm_object = XCreateGC(display,win_game,0,0); XSetGraphicsExposures(display, gc_xpm_object, False); XSetClipOrigin(display, gc_xpm_object,0, 0); - xpm_pixmap = XCreatePixmap(display, RootWindow(display, - DefaultScreen(display)), image_size, image_size, + xpm_pixmap = XCreatePixmap(display, def_root, image_size, image_size, DefaultDepth(display, DefaultScreen(display))); gc_clear_xpm = XCreateGC(display,xpm_pixmap,0,0); XSetGraphicsExposures(display,gc_clear_xpm,False); @@ -1471,22 +1473,12 @@ ****************************************************************************/ -#if 1 -/* Do nothing - status icons are not being created - FIX THIS */ -#define draw_status_icon(l,x,y,face) +static void draw_status_icon(itemlist *l, int x, int y, int face) +{ + XCopyPlane(display, icons[face], l->win, l->gc_status, 0,0, 24,6, x,y, 1); +} + -#else -#define draw_status_icon(l,x,y,face) \ -do { \ - XClearArea(display, l->win, x, y, 24, 6, False); \ - if (face) { \ - XSetClipMask(display, l->gc_status, icons[face].mask), \ - XSetClipOrigin(display, l->gc_status, x, y), \ - XCopyArea(display, icons[face].pixmap, l->win, l->gc_status, \ - 0, 0, 24, 6, x, y); \ - } \ -} while (0) -#endif /* compares the 'flags' against the item. return 1 if we should draw * that object, 0 if it should not be drawn. */ @@ -1513,55 +1505,42 @@ static void create_status_icons () { +#include "pixmaps/clear.xbm" +#include "pixmaps/locked.xbm" +#include "pixmaps/applied.xbm" +#include "pixmaps/unpaid.xbm" +#include "pixmaps/damned.xbm" +#include "pixmaps/cursed.xbm" +#include "pixmaps/magic.xbm" +#include "pixmaps/close.xbm" #include "pixmaps/stipple.111" #include "pixmaps/stipple.112" -#if 0 -#include "pixmaps/locked.xpm" -#include "pixmaps/unpaid.xpm" -#include "pixmaps/applied.xpm" -#include "pixmaps/magic.xpm" -#include "pixmaps/damned.xpm" -#include "pixmaps/cursed.xpm" -#include "pixmaps/close.xpm" static int hasinit=0; if (hasinit) return; hasinit=1; - - if (XpmCreatePixmapFromData(display, RootWindow(display, screen_num), - locked_xpm, &(icons[locked_icon].pixmap), - &(icons[locked_icon].mask), NULL) - || XpmCreatePixmapFromData(display, RootWindow(display, screen_num), - applied_xpm, &(icons[applied_icon].pixmap), - &(icons[applied_icon].mask), NULL) - || XpmCreatePixmapFromData(display, RootWindow(display, screen_num), - unpaid_xpm, &(icons[unpaid_icon].pixmap), - &(icons[unpaid_icon].mask), NULL) - || XpmCreatePixmapFromData(display, RootWindow(display, screen_num), - magic_xpm, &(icons[magic_icon].pixmap), - &(icons[magic_icon].mask), NULL) - || XpmCreatePixmapFromData(display, RootWindow(display, screen_num), - damned_xpm, &(icons[damned_icon].pixmap), - &(icons[damned_icon].mask), NULL) - || XpmCreatePixmapFromData(display, RootWindow(display, screen_num), - cursed_xpm, &(icons[cursed_icon].pixmap), - &(icons[cursed_icon].mask), NULL) - || XpmCreatePixmapFromData(display, RootWindow(display, screen_num), - close_xpm, &(icons[close_icon].pixmap), - &(icons[close_icon].mask), NULL)) { - fprintf(stderr, "Unable to create icon pixmaps.\n"); +#define CREATEPM(name,data) \ + (icons[name] = XCreateBitmapFromData(display, def_root,\ + data##_bits, data##_width, data##_height)) + + if (0 + || CREATEPM(no_icon, clear) == None + || CREATEPM(locked_icon, locked) == None + || CREATEPM(applied_icon, applied) == None + || CREATEPM(unpaid_icon, unpaid) == None + || CREATEPM(damned_icon, damned) == None + || CREATEPM(cursed_icon, cursed) == None + || CREATEPM(magic_icon, magic) == None + || CREATEPM(close_icon, close) == None + || CREATEPM(stipple1_icon, stipple) == None + || CREATEPM(stipple2_icon, stipple1) == None + ) + { + fprintf(stderr, "Unable to create pixmaps.\n"); exit (0); } -#endif - icons[stipple1_icon].bitmap = XCreateBitmapFromData(display, - RootWindow(display, screen_num), (char*)stipple_bits, 24, 24); - icons[stipple2_icon].bitmap = XCreateBitmapFromData(display, - RootWindow(display, screen_num), (char*)stipple1_bits, 24, 24); - if (icons[stipple1_icon].bitmap==None || icons[stipple2_icon].bitmap==None) { - fprintf(stderr, "Unable to create stipple pixmaps.\n"); - exit(0); - } +#undef CREATEPM } /* @@ -1598,13 +1577,8 @@ l->weight_limit/1000); if (strcmp (buf, l->old_title)) { - XClearArea(display, l->win, 2, 2, image_size, 13, False); - if (l->env->open) { - XSetClipMask(display, l->gc_status, icons[close_icon].mask); - XSetClipOrigin(display, l->gc_status, 2, 2); - XCopyArea(display, icons[close_icon].pixmap, l->win, l->gc_status, - 0, 0, image_size, 13, 2, 2); \ - } + XCopyPlane(display, icons[l->env->open ? close_icon : no_icon], + l->win, l->gc_status, 0,0, image_size,13, 2,2, 1); strcpy (l->old_title, buf); XDrawImageString(display, l->win, l->gc_text, (l->show_icon ? image_size+24+4 : image_size+4), @@ -1638,24 +1612,24 @@ /* draw status icon */ if (l->show_icon) { sint8 tmp_icon; - tmp_icon = tmp->locked ? locked_icon : 0; + tmp_icon = tmp->locked ? locked_icon : no_icon; if (l->icon1[i] != tmp_icon) { l->icon1[i] = tmp_icon; draw_status_icon (l, image_size+4, 16 + image_size * i, tmp_icon); } tmp_icon = tmp->applied ? applied_icon : - tmp->unpaid ? unpaid_icon : 0; + tmp->unpaid ? unpaid_icon : no_icon; if (l->icon2[i] != tmp_icon) { l->icon2[i] = tmp_icon; draw_status_icon (l, image_size+4, 22 + image_size * i, tmp_icon); } - tmp_icon = tmp->magical ? magic_icon : 0; + tmp_icon = tmp->magical ? magic_icon : no_icon; if (l->icon3[i] != tmp_icon) { l->icon3[i] = tmp_icon; draw_status_icon (l, image_size+4, 28 + image_size * i, tmp_icon); } tmp_icon = tmp->damned ? damned_icon : - tmp->cursed ? cursed_icon : 0; + tmp->cursed ? cursed_icon : no_icon; if (l->icon4[i] != tmp_icon) { l->icon4[i] = tmp_icon; draw_status_icon (l, image_size+4, 34 + image_size * i, tmp_icon); @@ -1746,6 +1720,17 @@ draw_list (l); } + +/* we have received new images. update these only */ +static void update_icons_list(itemlist *l) +{ + int i; + for (i = 0; i < l->size; ++i) + l->faces[i] = 0; + draw_list(l); +} + + void open_container (item *op) { look_list.env = op; @@ -1866,7 +1851,7 @@ static int get_inv_display() { inv_list.env = cpl.ob; - strcpy (inv_list.title, "Inventory:"); + strcpy (inv_list.title, ""/*ET: too long: "Inventory:"*/); inv_list.show_weight = 1; inv_list.show_what = show_all; inv_list.weight_limit=0; @@ -1952,6 +1937,13 @@ } } +void set_autorepeat(char *s) +{ + noautorepeat = noautorepeat ? FALSE : TRUE; + draw_info(noautorepeat ? "Autorepeat is disabled":"Autorepeat is enabled", + NDI_BLACK); +} + int get_info_width() { return infodata.info_chars; @@ -1992,6 +1984,9 @@ if ((getenv("ERIC_SYNC")!= NULL) || sync_display) XSynchronize(display,True); + def_root = DefaultRootWindow(display); + def_screen = DefaultScreen(display); + /* For both split_windows and display mode, check to make sure that * the command line has not set the value. Command line settings * should always have precedence over settings in the Xdefaults file. @@ -2027,10 +2022,20 @@ if ((cp=XGetDefault(display,X_PROG_NAME, "scrollLines"))!=NULL) { infodata.maxlines=atoi(cp); } + if ((cp=XGetDefault(display,X_PROG_NAME,"font")) != NULL) { + font_name = strdup_local(cp); + } + /* Failure will result in an uncaught X11 error */ + font=XLoadQueryFont(display,font_name); + if (!font) { + fprintf(stderr,"Could not load font %s\n", font_name); + exit(1); + } + FONTWIDTH=font->max_bounds.width; + FONTHEIGHT=font->max_bounds.ascent + font->max_bounds.descent; - screen_num=DefaultScreen(display); - background=WhitePixel(display,screen_num); - foreground=BlackPixel(display,screen_num); + background=WhitePixel(display,def_screen); + foreground=BlackPixel(display,def_screen); roothint.x=0; roothint.y=0; roothint.width=582+6+INFOCHARS*FONTWIDTH; @@ -2045,14 +2050,14 @@ } roothint.max_width=roothint.min_width=roothint.width; roothint.max_height=roothint.min_height=roothint.height; - roothint.flags=PPosition | PSize; + roothint.flags=PSize; /*ET: no PPosition. let window manager handle that. */ if(!split_windows) { - win_root=XCreateSimpleWindow(display,DefaultRootWindow(display), + win_root=XCreateSimpleWindow(display,def_root, roothint.x,roothint.y,roothint.width,roothint.height,2, background,foreground); - iscolor=allocate_colors(display, win_root, screen_num, + iscolor=allocate_colors(display, win_root, def_screen, &colormap, discolor); if (iscolor){ foreground=discolor[0].pixel; @@ -2066,27 +2071,15 @@ gc_root=XCreateGC(display,win_root,0,0); XSetForeground(display,gc_root,foreground); XSetBackground(display,gc_root,background); - } - else win_root = DefaultRootWindow(display); - - if(!split_windows) { XSelectInput(display,win_root,KeyPressMask| KeyReleaseMask|ExposureMask|StructureNotifyMask); XMapRaised(display,win_root); - XNextEvent(display,&event); - } - if ((cp=XGetDefault(display,X_PROG_NAME,"font")) != NULL) { - font_name = strdup_local(cp); - } - /* Failure will result in an uncaught X11 error */ - font=XLoadQueryFont(display,font_name); - if (!font) { - fprintf(stderr,"Could not load font %s\n", font_name); - exit(1); + XNextEvent(display,&event); /*ET: this is bogus */ } - FONTWIDTH=font->max_bounds.width; - FONTHEIGHT=font->max_bounds.ascent + font->max_bounds.descent; + else + win_root = def_root; + return 0; } @@ -2226,7 +2219,7 @@ * do this anyways, so it is not a problem. */ -static void do_key_press() +static void do_key_press(int repeated) { KeySym gkey; char text[10]; @@ -2249,7 +2242,7 @@ } switch(cpl.input_state) { case Playing: - parse_key(text[0],event.xkey.keycode,gkey); + parse_key(text[0],event.xkey.keycode,gkey,repeated); break; case Reply_One: @@ -2432,7 +2425,7 @@ draw_prompt(":"); while (cpl.input_state == Metaserver_Select) { check_x_events(); - usleep(100); + usleep(50000); /* 1/20 sec */ } /* while input state is metaserver select. */ /* We need to clear out cpl.input_text - otherwise the next @@ -2461,6 +2454,7 @@ void check_x_events() { KeySym gkey=0; static int lastupdate=0; + static XEvent prev_event; /* to detect autorepeated keys */ /* If not connected, the below area does not apply, so don't deal with it */ if (cpl.input_state != Metaserver_Select) { @@ -2473,8 +2467,8 @@ * especially since we might get a bunch of images at the same time. */ if (cache_images && lastupdate>5 && newimages) { - draw_all_list(&inv_list); - draw_all_list(&look_list); + update_icons_list(&inv_list); + update_icons_list(&look_list); if (!cpl.showmagic) display_map_doneupdate(TRUE); newimages=0; lastupdate=0; @@ -2488,6 +2482,7 @@ while (XPending(display)!=0) { + prev_event = event; XNextEvent(display,&event); switch(event.type) { @@ -2561,7 +2556,14 @@ break; case KeyPress: - do_key_press(); + if (noautorepeat + && prev_event.type == KeyRelease + && prev_event.xkey.keycode == event.xkey.keycode + && prev_event.xkey.state == event.xkey.state + && prev_event.xkey.time == event.xkey.time) + do_key_press(1); /* auto-repeated key */ + else + do_key_press(0); /* regular key */ break; } } @@ -2625,6 +2627,7 @@ puts("-font - Use as font to display data."); puts("-pngfile - Use for source of images"); puts("-mapsize xXy - Set the mapsize to be X by Y spaces."); + puts("-noautorepeat - Auto repeat on directional keys is ignored."); exit(0); } @@ -2788,6 +2791,10 @@ keepcache=TRUE; continue; } + else if (!strcmp(argv[on_arg],"-autorepeat")) { + noautorepeat=TRUE; + continue; + } else { fprintf(stderr,"Do not understand option %s\n", argv[on_arg]); usage(argv[0]); @@ -3073,9 +3080,7 @@ } } - bitmap = XCreateBitmapFromData(display, - RootWindow(display,DefaultScreen(display)), - buf,image_size,image_size); + bitmap = XCreateBitmapFromData(display,def_root,buf,image_size,image_size); newimages++; pixmaps[face].bitmap = bitmap; pixmaps[face].fg = fg; @@ -3171,12 +3176,12 @@ } else { /* interesting object */ if ((val & FACE_COLOR_MASK)==0) - XCopyPlane(display, icons[stipple2_icon].bitmap, + XCopyPlane(display, icons[stipple2_icon], win_game, gc_game, 0, 0, cpl.mapxres,cpl.mapyres, 2+cpl.mapxres*x, 2+cpl.mapyres*y, 1); else - XCopyPlane(display, icons[stipple1_icon].bitmap, + XCopyPlane(display, icons[stipple1_icon], win_game, gc_game, 0, 0, cpl.mapxres,cpl.mapyres, 2+cpl.mapxres*x, 2+cpl.mapyres*y, 1); @@ -3399,6 +3404,15 @@ else cpl.food_beep=FALSE; continue; } + if (!strcmp(inbuf,"noautorepeat")) { + if (!strcmp(cp,"True")) noautorepeat=TRUE; + else noautorepeat=FALSE; + continue; + } + if (!strcmp(inbuf,"font")) { + font_name = strdup_local(cp); + continue; + } fprintf(stderr,"Got line we did not understand: %s: %s\n", inbuf, cp); } fclose(fp); @@ -3421,7 +3435,7 @@ fprintf(fp,"# This file is generated automatically by cfclient.\n"); fprintf(fp,"# Manually editing is allowed, however cfclient may be a bit finicky about\n"); fprintf(fp,"# some of the matching it does. all comparissons are case sensitive.\n"); - fprintf(fp,"# 'True' and 'False' are the proper cases for those two values"); + fprintf(fp,"# 'True' and 'False' are the proper cases for those two values\n"); fprintf(fp,"port: %d\n", port_num); fprintf(fp,"server: %s\n", server); @@ -3430,6 +3444,7 @@ } else if (display_mode==Png_Display) { fprintf(fp,"display: png\n"); } + fprintf(fp,"font: %s\n", font_name); fprintf(fp,"cacheimages: %s\n", cache_images?"True":"False"); fprintf(fp,"split: %s\n", split_windows?"True":"False"); fprintf(fp,"showicon: %s\n", inv_list.show_icon?"True":"False"); @@ -3438,6 +3453,7 @@ fprintf(fp,"sound: %s\n", nosound?"False":"True"); fprintf(fp,"command_window: %d\n", cpl.command_window); fprintf(fp,"foodbeep: %s\n", cpl.food_beep?"True":"False"); + fprintf(fp,"noautorepeat: %s\n", noautorepeat?"True":"False"); fclose(fp); sprintf(buf,"Defaults saved to %s",path); Binary files crossfire-client-1.1.0/x11/x11.c.swp and crossfire-client-1.1.0-et/x11/x11.c.swp differ diff -ruN crossfire-client-1.1.0/x11/x11.h crossfire-client-1.1.0-et/x11/x11.h --- crossfire-client-1.1.0/x11/x11.h Fri Dec 28 09:56:41 2001 +++ crossfire-client-1.1.0-et/x11/x11.h Mon Jan 7 18:56:56 2002 @@ -58,7 +58,6 @@ extern struct PixmapInfo pixmaps[MAXPIXMAPNUM]; extern Display *display; -extern long screen_num; extern uint8 image_size; extern Window win_root,win_game; extern GC gc_game; diff -ruN crossfire-client-1.1.0/x11/x11proto.h crossfire-client-1.1.0-et/x11/x11proto.h --- crossfire-client-1.1.0/x11/x11proto.h Fri Dec 28 09:56:41 2001 +++ crossfire-client-1.1.0-et/x11/x11proto.h Mon Jan 7 17:19:32 2002 @@ -24,6 +24,7 @@ extern void set_show_weight(char *s); extern void set_weight_limit(uint32 wlim); extern void set_scroll(char *s); +extern void set_autorepeat(char *s); extern int get_info_width(void); extern char *get_metaserver(void); extern void check_x_events(void); @@ -58,7 +59,7 @@ extern void parse_keybind_line(char *buf, int line, int standard); extern void init_keys(void); extern void parse_key_release(KeyCode kc, KeySym ks); -extern void parse_key(char key, KeyCode keycode, KeySym keysym); +extern void parse_key(char key, KeyCode keycode, KeySym keysym, int repeated); extern void bind_key(char *params); extern void configure_keys(KeyCode k, KeySym keysym); extern void unbind_key(char *params); diff -ruN crossfire-client-1.1.0/x11/xutil.c crossfire-client-1.1.0-et/x11/xutil.c --- crossfire-client-1.1.0/x11/xutil.c Fri Dec 28 09:56:41 2001 +++ crossfire-client-1.1.0-et/x11/xutil.c Mon Jan 7 22:21:17 2002 @@ -51,7 +51,7 @@ "White", /* 1 */ "Navy", /* 2 */ "Red", /* 3 */ -"Orange", /* 4 */ +"Chocolate", /* 4 was Orange, but impossible to read on DarkSeaGreen */ "DodgerBlue", /* 5 */ "DarkOrange2", /* 6 */ "SeaGreen", /* 7 */ @@ -145,19 +145,16 @@ */ pixmaps[0].mask=None; - pixmaps[0].bitmap=XCreateBitmapFromData(display, - RootWindow(display, screen_num), (const char*)question_bits, image_size,image_size); + pixmaps[0].bitmap=XCreateBitmapFromData(display,DefaultRootWindow(display), + question_bits,question_width,question_height); /* In xpm mode, XCopyArea is used from this data, so we need to copy * the image into an pixmap of appropriate depth. - * Note that while are image created is the image size, since we know - * that are filler image is currently only 24x24, we only copy that much - * data. */ pixmaps[0].pixmap=XCreatePixmap(display, win_root, image_size, image_size, DefaultDepth(display,DefaultScreen(display))); XCopyPlane(display, pixmaps[0].bitmap, pixmaps[0].pixmap, gc_game, - 0,0,24,24,0,0,1); + 0,0,image_size,image_size,0,0,1); pixmaps[0].bg = 0; pixmaps[0].fg = 1; @@ -187,9 +184,9 @@ { char buf[MAX_BUF]; + //printf("requestface: %s (%d)\n", facename, pnum);//@@@ facetoname[pnum] = strdup_local(facepath); - sprintf(buf,"askface %d", pnum); - cs_write_string(csocket.fd, buf, strlen(buf)); + cs_print_string(csocket.fd, "askface %d", pnum); /* Need to make sure we have the directory */ sprintf(buf,"%s/%c%c", facecachedir, facename[0], facename[1]); if (access(buf,R_OK)) make_path_to_dir(buf); @@ -294,8 +291,7 @@ } else if (display_mode==Pix_Display) { pixmaps[pnum].bitmap = XCreateBitmapFromData(display, - RootWindow(display,DefaultScreen(display)), - (char*)data,24,24); + DefaultRootWindow(display), (char*)data,24,24); pixmaps[pnum].fg = (data[24] << 24) + (data[25] << 16) + (data[26] << 8) + data[27]; pixmaps[pnum].bg = (data[28] << 24) + (data[29] << 16 )+ (data[30] << 8 )+ @@ -720,7 +716,7 @@ /* This parses a keypress. It should only be called when in Playing * mode. */ -void parse_key(char key, KeyCode keycode, KeySym keysym) +void parse_key(char key, KeyCode keycode, KeySym keysym, int repeated) { Key_Entry *keyentry, *first_match=NULL; int present_flags=0; @@ -809,10 +805,12 @@ run_dir(first_match->direction); sprintf(buf,"run %s", first_match->command); } - else { + else if (!repeated) { strcpy(buf,first_match->command); extended_command(first_match->command); } + else + sprintf(buf,"move %s (ignored)", first_match->command); if (cpl.echo_bindings) draw_info(buf,NDI_BLACK); } else { @@ -1503,8 +1501,7 @@ } } - cs_write_string( csocket.fd, "mapredraw", 9); - + cs_print_string(csocket.fd, "mapredraw"); return; } From froese at gmx.de Tue Jan 8 19:30:41 2002 From: froese at gmx.de (Edgar Toernig) Date: Thu Jan 13 18:02:01 2005 Subject: [CF-Devel] [PATCH] fix compile problem; wheelmouse support. Message-ID: <3C3B9D41.610AD2DF@gmx.de> Hi, another patch. It has to be applied on top of the previous one I sent. It fixes a compile problem on FreeBSD and adds wheel mouse support to cfclient. Ciao, ET. -------------- next part -------------- diff -ru crossfire-client-1.1.0-et/common/client.c crossfire-client-1.1.0-et2/common/client.c --- crossfire-client-1.1.0-et/common/client.c Mon Jan 7 17:05:59 2002 +++ crossfire-client-1.1.0-et2/common/client.c Wed Jan 9 02:20:09 2002 @@ -161,6 +161,7 @@ #include #include #include +#include #include #include @@ -205,6 +206,10 @@ fprintf(stderr,"InitConnection: Error on fcntl.\n"); } +#ifdef TCP_NODELAY +#ifndef SOL_TCP +#define SOL_TCP IPPROTO_TCP +#endif /* turn off nagle algorithm */ if (getenv("CF_NAGLE") == NULL) { /* disabled by setting CF_NAGLE */ int i=1; @@ -212,6 +217,7 @@ if (setsockopt(fd, SOL_TCP, TCP_NODELAY, &i, sizeof(i)) == -1) perror("TCP_NODELAY"); } +#endif if (getsockopt(fd,SOL_SOCKET,SO_RCVBUF, (char*)&oldbufsize, &buflen)==-1) oldbufsize=0; diff -ru crossfire-client-1.1.0-et/x11/x11.c crossfire-client-1.1.0-et2/x11/x11.c --- crossfire-client-1.1.0-et/x11/x11.c Mon Jan 7 21:59:11 2002 +++ crossfire-client-1.1.0-et2/x11/x11.c Wed Jan 9 01:26:29 2002 @@ -2299,7 +2299,10 @@ { int y = xbutton->y-16, x=xbutton->x, button = xbutton->button,dy,pos=0; - if (!infodata.has_scrollbar || x<=(infodata.width-SCROLLBAR_WIDTH-4)) + if (!infodata.has_scrollbar) + return; + + if (button < 4 && x <= infodata.width-SCROLLBAR_WIDTH-4) return; dy = y / FONTHEIGHT > 0 ? y / FONTHEIGHT : 1; @@ -2317,6 +2320,14 @@ pos = infodata.bar_pos + dy; break; + case 4: + pos = infodata.bar_pos - 1; + break; + + case 5: + pos = infodata.bar_pos + 1; + break; + } if (pos image_size * l->size) return 1; + + if (button == 4 || button == 5) + { + if (button == 4) + l->item_pos--; + else + l->item_pos++; + draw_list(l); + return 1; + } if (x > l->width-23) { /* scrollbar */ From dnh at hawthorn.csse.monash.edu.au Tue Jan 8 20:34:28 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:01 2005 Subject: [CF-Devel] [PATCH] fix compile problem; wheelmouse support. In-Reply-To: <3C3B9D41.610AD2DF@gmx.de> References: <3C3B9D41.610AD2DF@gmx.de> Message-ID: <20020109023428.GA31949@hawthorn.csse.monash.edu.au> Wheel mouse support to CFclient? Why the hell would you do that? I barely even uses scroll bars. Could I request you add this to the gcfclient, or at least tell someone how to do it. Actually now that I think about it, wheel support is done by X/GTK not by the app? ahh well. dnh From froese at gmx.de Tue Jan 8 21:18:03 2002 From: froese at gmx.de (Edgar Toernig) Date: Thu Jan 13 18:02:01 2005 Subject: [CF-Devel] [PATCH] fix compile problem; wheelmouse support. References: <3C3B9D41.610AD2DF@gmx.de> <20020109023428.GA31949@hawthorn.csse.monash.edu.au> Message-ID: <3C3BB66B.B093E818@gmx.de> David Hurst wrote: > > Wheel mouse support to CFclient? > Why the hell would you do that? I barely even uses scroll bars. Because it's more convenient and pretty simple to implement. If you do not use the scroll bars, how do you browse longer shop inventories or your own inventory? > Could I request you add this to the gcfclient, or at least tell someone > how to do it. Actually now that I think about it, wheel support is done > by X/GTK not by the app? I'm not using GTK or gcfclient. But afaik, newer versions of GTK handle the wheel. I do not know whether the app has to do something special to make use of it though. Ciao, ET. From jbontje at suespammers.org Wed Jan 9 03:35:34 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:02:01 2005 Subject: [CF-Devel] [PATCH] fix compile problem; wheelmouse support. In-Reply-To: <20020109023428.GA31949@hawthorn.csse.monash.edu.au>; from dnh@hawthorn.csse.monash.edu.au on Wed, Jan 09, 2002 at 01:34:28PM +1100 References: <3C3B9D41.610AD2DF@gmx.de> <20020109023428.GA31949@hawthorn.csse.monash.edu.au> Message-ID: <20020109103534.A17178@freebsd.localdomain> On Wed, Jan 09, 2002 at 01:34:28PM +1100, David Hurst wrote: > Wheel mouse support to CFclient? > Why the hell would you do that? I barely even uses scroll bars. > Could I request you add this to the gcfclient, or at least tell someone > how to do it. Actually now that I think about it, wheel support is done > by X/GTK not by the app? With my GTK (1.2.10) it works already without any GTK / app modifications. The only thing you have to do is enable wheelmouse support in X. I looked at the code and it is a clean way how he did it, it just uses mouse buttons 4 & 5 which are the default bindings for the wheelmouse's wheel. (If you work with XFree 4.x.y, you have to add these lines to XF86Config-4 in the mouse section: Option "Buttons" "5" Option "ZAxisMapping" "4 5" ) Regards, Joris Bontje / mids -- Gpg Key: Id=0xF19326A9 / http://mids.student.utwente.nl/~mids/jbontje.pub Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 238 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020109/cae68e71/attachment.pgp From jbontje at suespammers.org Wed Jan 9 07:12:34 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:02:02 2005 Subject: [CF-Devel] 1.1.0 client patches by Edgar Message-ID: <20020109141234.A20240@freebsd.localdomain> Today I tried the patches from Edgar Toernig for the 1.1.0 client, so far I could test it works fine. After the second patch it compiles fine under both FreeBSD and Linux. I did a quick code review, as far as I could see there were no style violations or other strange things. Edgar made a lot of security fixes that prevent bufferoverflow problems (I think) and fixed some bad layout. The only thing I am not sure of is the SOL_TCP fix that he did in the second part. It works, but is doing this with ifdef's the best way? I vote for putting this in CVS after a more formal review from one of out C experts. Regards, Joris Bontje / mids -- Gpg Key: Id=0xF19326A9 / http://mids.student.utwente.nl/~mids/jbontje.pub Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 238 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020109/f0274c5a/attachment.pgp From jbontje at suespammers.org Wed Jan 9 15:00:16 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:02:02 2005 Subject: [CF-Devel] new server command: reply Message-ID: <20020109220016.A35293@freebsd.localdomain> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 238 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020109/9dfc31fa/attachment.pgp From mwedel at sonic.net Fri Jan 11 00:58:20 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:02 2005 Subject: [CF-Devel] 1.1.0 client patches by Edgar References: <20020109141234.A20240@freebsd.localdomain> Message-ID: <3C3E8D0C.D206B598@sonic.net> Joris Bontje wrote: > > Today I tried the patches from Edgar Toernig for the 1.1.0 client, > so far I could test it works fine. After the second patch it compiles fine > under both FreeBSD and Linux. I looked over it pretty closely, and it generally looked OK - a few minor points: 1) His fix/check for libz is put in the configure file, and not in the configure.in where it should be. As it is now, the next time configure is rebuilt via autoconf, that change will be lost. 2) The check for TCP_NODELAY should be possible in configure. Also, if it really is a useful option, using something other than an environmental variable is desired (eg, command line option, setting in options file, etc). From mwedel at sonic.net Sun Jan 13 22:54:40 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:02 2005 Subject: [CF-Devel] Light and Darkness References: <20011228105235.A16617@balrog.ank.com> <3C2D41E1.8867C1FA@sonic.net> <20011229170459.A18129@balrog.ank.com> <20011230184521.A19876@balrog.ank.com> Message-ID: <3C426490.2900FDD5@sonic.net> kevin@ank.com wrote: > > For what it is worth, I rechecked my light testing map. Walls don't > affect the light one way of the other. If light propagates 4 squares > from a source then it does so regardless of any intervening walls, > including double walls. Yeah - I just made a simple test map, and the behaviour is pretty plain. I'll put this on the list of things TODO, but to be honest, this isn't really high on my priority list - its definately a bug, but to fix it properly is a bit of a work for (at least at current time) not a lot of gain. Bigger fish to fry, so to speak. From mwedel at sonic.net Mon Jan 14 00:01:51 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:02 2005 Subject: [CF-Devel] various bugs References: <3C30FE72.AA4D325C@ictransnet.com> Message-ID: <3C42744F.3209369C@sonic.net> johnny shelley wrote: > > Picking up a bomb into a container causes a server crash. > > Lately directors are a bit broken. They seem to only reflect spells when > they are used slowly - casting many fireballs as fast as you can, for > example, will results in quite a few of them flying past the director. > Has anyone made changes that would cause this in the last several weeks? should be fixed now: common/object.c: Fix bug in check_walk_on which would result in spell objects not being properly processed - the intention is not to process spell objects - we should stop going up (in previous loop) when we get such an object, not on the way down. This fixes directors not working really well. Looks like the offending code was originally checked in in late November. From tanner at real-time.com Mon Jan 14 16:28:35 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:02:02 2005 Subject: [CF-Devel] Fwd: open source quality assurance Message-ID: <20020114162835.D21131@real-time.com> Thought I'd share this with the rest of you. ----- Forwarded message from Luyin Zhao ----- Dear Bob Tanner, My professor S. Elbaum (Univ. of Nebraska-Lincoln) and I are investigating how quality assurance activities are carried in open source development, and what differences can be found when compared against more traditional industry practices. A pilot study was performed and published ("A Survey on Software Quality Related Activities in Open Source", Software Engineering Notes, ACM, 54-57, June 2000). We are extending the study through the attached survey (22 multiple choise questions), which will provide additional empirical evidence exposing the unique characteristics of the open source development movement. We hope you can take a few minutes to complete it basd on your open source project 'Crossfire RPG game' released on SourceForge.net. Your effort is greatly appreciated! Luyin Zhao Survey Questionnaire: Part A: Project characterization 1. What is the estimated number of lines of code of the project? A. < 1,000 B. 1,000 - 10,000 C. 10,000 - 100,000 D. > 100,000 Lines of code Response: 2. How many software developers are actively involved in this project? A. 1 B. 1-5 C. 5-20 D. +20 Response: 3. What is the estimated current number of users of this product? A. 1-5 B. 5-10 C. 10-50 D. +50 Response: 4. How often are the product releases (on average)? A. Every week B. Every month C. Every quarter D. Every 6 months E. Other Response: 5. How long has the product been available in the market? A. Less than 6 months B. Between 6 months and a year C. Between 1 and 3 years D. More than 3 years Response: Part B: Respondent characterization 6. Software development experience A. <1 year B. 1-5 years C. +5 years Response: 7. What level of participation do you have in the project? A. Dedicated full-time B. Part-time, supported by employer C. Part-time, personal time D. Other Response: Part C: Process 8. Did the project start to satisfy: A. Personal needs B. Company needs C. Community needs D. Other Response: 9. What percentage of your product changes from release to release (major releases)? A. < 20 % B. 20% - 40% C. 40% - 60% D. 60% - 80% E. > 80% Response: 10. Do you use software configuration management tools (version control tools) ? A. A. Yes (Name ) B. No C. Not sure Response: 11. Do you use any "bug" tracking tool? A. Yes (Name ) B. No C. Not sure Response: 12. Which of the following documents is used to support the project? A. Document to plan releases (dates and content) B. Design document C. Installation and building guidelines D. "TODO" List (including list of pending features and open bugs) Response: Part D: Testing 13. How do you validate your product before release? A. Provide inputs trying to imitate user behavior (ad-hoc) B. Use script to provide random values as inputs C. Provide extreme values as inputs D. Use assertions (assert, Junit, others) E. Other Response: 14. What percentage of your time and effort is spent on testing? A. < 20 % B. 20% - 40% C. 40% - 60% D. 60% - 80% E. > 80% Response: 15. Do you have a "baseline" test suite that you re-run on your software before every release? A. Yes B. No Response: 16. What percentage of source code is covered by the testing activity? A. < 20 % B. 20% - 40% C. 40% - 60% D. 60% - 80% E. > 80% Response: 17. The previous coverage information was based on: A. Reports by coverage tool (Name it: __________) B. Personal estimation Response: Part E: Users Participation and Feedback 18. How soon after release do you hear back from users? A. Hours B. Days C. Weeks Response: 19. What percentage of "bugs" did users find? A. < 20% B. 20% - 40% C. 40% - 60% D. 60 - 80% E. >80% Response: 20. What percentage of code has changed in response to users suggestions? A. < 20% B. 20% - 40% C. 40% - 60% D. 60% - 80% E. > 80% Response: 21. How do you evaluate the "bug" locating effectiveness of external users? A. They found "hard" bugs that could have taken us a long time to find B. Given some more time, I would have found most of them C. They don't help too much D. Other Response: 22. The modifications suggested by users, are: A. Very creative B. Reasonable C. Useful but not so necessary D. Not fitting into my application design E. Other Response: ----- End forwarded message ----- -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From froese at gmx.de Mon Jan 14 11:44:56 2002 From: froese at gmx.de (Edgar Toernig) Date: Thu Jan 13 18:02:02 2005 Subject: [CF-Devel] 1.1.0 client patches by Edgar References: <20020109141234.A20240@freebsd.localdomain> <3C3E8D0C.D206B598@sonic.net> Message-ID: <3C431918.E498701@gmx.de> Mark Wedel wrote: > > 1) His fix/check for libz is put in the configure file, and not in the > configure.in where it should be. As it is now, the next time configure is > rebuilt via autoconf, that change will be lost. I'm aware of that. But as I said, I'm not used to autoconf and someone has to figure out how to modify configure.in. > 2) The check for TCP_NODELAY should be possible in configure. Hmm... And then? Changing the #ifdef TCP_NODELAY to #ifdef HAVE_TCP_NODELAY? > Also, if it really is a useful option, using something other than an > environmental variable is desired (eg, command line option, setting in > options file, etc). Wrapping the NODELAY into an if(getenv) is mainly done for debugging. It's much easier to "CF_NAGLE=1 cfclient" then to change a define and recompile. About the "usefulness" of this addition: Normally the TCP stack tries to avoid sending small packets. So, if you do a write(acoupleofbytes) the system waits a little bit before sending out a small packet in the hope that there will be some more writes that make the packet larger. The TCP_NODELAY disables this behavior. Each write tries to send the data immediately. (The actual algorithm is more complex but it comes down to this.) Of course, if you quickly send a lot of small packets this may hurt because there is an overhead of ~40 bytes per packet. You trade latency with band- width. What you want is normal (delaying) behavior with an additional "flush" like call to force that data to be sent. Unfortunately, such a system call does not exist (at least in Linux *g*). So, to get this, one can turn off the delay (TCP_NODELAY) and collect the data within the application and write it out when when you know that there will be nothing more to send. What I did in the patch is to turn on TCP_NODELAY and at least make sure that a single crossfire command is send with one write. That results in one net- work packet per command. A future optimization would be to collect more commands and send them together. I'll add that later. (In fact, the reason I did not do it right away was that crossfire uses very little bandwidth so there was no immediate urge to add it.) Ciao, ET. From mwedel at sonic.net Mon Jan 14 23:33:08 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:02 2005 Subject: [CF-Devel] 1.1.0 client patches by Edgar References: <20020109141234.A20240@freebsd.localdomain> <3C3E8D0C.D206B598@sonic.net> <3C431918.E498701@gmx.de> Message-ID: <3C43BF14.D36A2114@sonic.net> Edgar Toernig wrote: > > Mark Wedel wrote: > > > > 1) His fix/check for libz is put in the configure file, and not in the > > configure.in where it should be. As it is now, the next time configure is > > rebuilt via autoconf, that change will be lost. > > I'm aware of that. But as I said, I'm not used to autoconf and someone > has to figure out how to modify configure.in. I've applied the patch to a copy I have. I'll take care of the configure.in setup - it is actually quite easy if you have the tools installed - you modify configure.in, run 'autoconf', and it generates a new configure file for you. > > > 2) The check for TCP_NODELAY should be possible in configure. > > Hmm... And then? Changing the #ifdef TCP_NODELAY to #ifdef HAVE_TCP_NODELAY? Yeah, I actually don't see anything in configure, so keeping the TCP_NODELAY as it is makes sense. > Wrapping the NODELAY into an if(getenv) is mainly done for debugging. It's > much easier to "CF_NAGLE=1 cfclient" then to change a define and recompile. Right, but even better is to be able to do something like gcfclient -fastransmit or the like. If something is meant for the end user to use, it should be accessible in some easier manner. > What I did in the patch is to turn on TCP_NODELAY and at least make sure that > a single crossfire command is send with one write. That results in one net- > work packet per command. A future optimization would be to collect more > commands and send them together. I'll add that later. (In fact, the reason > I did not do it right away was that crossfire uses very little bandwidth > so there was no immediate urge to add it.) The patch you did makes sense - the amount of data the client sends to the server is relatively small, and you were able to form complete packets pretty easily. I don't have a problem with it - my only point was really that it should be less cryptic for users than having to set an undocumented env variable. In all practicality, if available, it should always be used. I'd probably say don't bother with trying further consolidation for the client->server commands - my initial thought is that it would get much more complicated - the client would now need to have its own write buffer, and when it then knows that nothing can get generated for a while (eg, about to sleep), it sends out the buffer. I mainly say this because the number of times the client is likely to generate more than 1 command before such a sleep is probably quite rare, and certainly infrequent enough that the extra tcp header probably won't be that significant. Of course, if there were functions in the client which were going to send multiple pieces and know it, then that function should optimize itself to only do one write - I can't think of any such case right now, but an example I could see would be if the client was smart enough to know about what the rings the player had on (eg, had the paper doll type thing), if the player dragged a new ring to a particular hand, it should unapply the old ring and apply the new one, which amounts to two commands to the server, which should be in one packet. From jbontje at suespammers.org Mon Jan 14 12:04:26 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:02:02 2005 Subject: [CF-Devel] Reply command server patch version 2 Message-ID: <20020114190426.A49212@freebsd.localdomain> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 238 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020114/2c9aa3e4/attachment.pgp From jbontje at suespammers.org Tue Jan 15 17:56:58 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:02:02 2005 Subject: [CF-Devel] Teleport patch Message-ID: <20020116005657.A71852@freebsd.localdomain> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 238 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020116/9a82d850/attachment.pgp From andi.vogl at gmx.net Thu Jan 17 09:27:44 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:03 2005 Subject: [CF-Devel] RE: [Crossfire-cvs] CVS commit: CFJavaEditor In-Reply-To: Message-ID: <000601c19f6b$832128b0$c86ebb81@gizmo> Referring to the following cvs commit by Bob Tanner: > Module Name: CFJavaEditor > Committed By: tanner > Date: Wed Jan 2 08:54:57 UTC 2002 > [...] > Log Message: > General changes to most of the files list below: > Some simple changes to make building the editor under Linux a > little easier. Start of stylistic changes to be compliant > with doc/programming_guide. Pretty-printted most of the code. > > Conceptual changes: > Change the concept of where resources are located. Instead of > having resource files in specific directories I put them all in > the .jar file and extract them as needed. This change is complete > except for the images in the system directory. [...] First of all, I'm grateful for the work you have done to improve the linux build configuration for CFJavaEditor. However, as I took a look at the newest cvs version of the editor today, I noticed unfortunately that there are some changes which I don't like: o The biggest Problem is the new formatting. The linux tabs turn out completely corrupt in Visual J++ (Windows). Please convert all tabs into spaces, if that is possible. That is the only way to keep the formatting platform-independant. Besides, I actually liked my old formatting with 4 space indent. And I believe MichToen did so too. But nevermind on that one... o Why is the source code suddenly in "/src/org/crossfire/editor/CFEditor"? Did you try to hide it or something? This new directory strucure might be handy in *your* editor, it definitly is not in mine. Besides, to my knowing it is convention that Package name and directory path are identical. Visual J++ enforces this. The new Package name "org.crossfire.editor.CFEditor" therefore doesn't work. It has to be "src.org.crossfire.editor.CFEditor". However, I would greatly prefer the *.java files back in the "/CFEditor" dir, where they belong. o The new policy of extracting all resources out of the .jar file doesn't seem like a good idea to me. Unless I totally misunderstood your purpose. Resource files (like icons and config files like "autojoin.txt") should be easy to access and easy to modify. If they are burried in the jar file, the average user won't find them. And you have no visual control over the stuff in the jar file either. If someone commits a corrupt jar file, will that be noticeable from the cvs diff? I guess not - though effectively all resource files are lost. Well, I hope that doesn't sound too criticizing. I'm sorry that I didn't come up with these issues earlier, but I was busy and didn't have time to test the new stuff before. Besides, I wasn't really aware of these changes and nobody asked me. Andreas V. From tanner at real-time.com Thu Jan 17 19:10:02 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:02:03 2005 Subject: [CF-Devel] Converting tabs to spaces via emacs. Please confirm. Message-ID: <20020117191002.K27148@real-time.com> AV, Can check to see if the ArchObject.java looks right inside of Visual J++? I believe I have converted all tabs to 4 spaces, but I'd like verification. ----- Forwarded message from crossfire-cvs-admin@lists.sourceforge.net ----- Module Name: CFJavaEditor Committed By: tanner Date: Fri Jan 18 01:07:21 UTC 2002 Modified Files: CFJavaEditor/src/org/crossfire/editor/CFEditor: ArchObject.java Log Message: Test to see if the changes to my .emacs are appropriate programming_guide #12, ie, 4 space instead of tabs. The following files had too many changes to show the context diffs here: cvs rdiff -r1.2 -r1.3 CFJavaEditor/src/org/crossfire/editor/CFEditor/ArchObject.java _______________________________________________ Crossfire-cvs mailing list Crossfire-cvs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/crossfire-cvs ----- End forwarded message ----- -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From tanner at real-time.com Thu Jan 17 18:23:28 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:02:03 2005 Subject: [CF-Devel] RE: [Crossfire-cvs] CVS commit: CFJavaEditor In-Reply-To: <000601c19f6b$832128b0$c86ebb81@gizmo>; from andi.vogl@gmx.net on Thu, Jan 17, 2002 at 04:27:44PM +0100 References: <000601c19f6b$832128b0$c86ebb81@gizmo> Message-ID: <20020117182328.A27148@real-time.com> Quoting Andreas Vogl (andi.vogl@gmx.net): > o The biggest Problem is the new formatting. The linux tabs turn out > completely corrupt in Visual J++ (Windows). > Please convert all tabs into spaces, if that is possible. That is > the only way to keep the formatting platform-independant. > > Besides, I actually liked my old formatting with 4 space indent. > And I believe MichToen did so too. But nevermind on that one... Hmm, I thought I changed emacs to do this. :-( Point 12 of the programming_guide specifically says to use 4 spaces. I'll have to double check it. I've added the appropriate info to the programming_guide to configure emacs and vim according to the 4 space rule. > o Why is the source code suddenly in > "/src/org/crossfire/editor/CFEditor"? > Did you try to hide it or something? This is the default setup that the Enhydra build evironment wants. Plus it allows all source code to be located in 1 directory. It's more a requirement of the Enhydra build env then anything else. > This new directory strucure might be handy in *your* editor, it > definitly is not in mine. Besides, to my knowing it is convention > that Package name and directory path are identical. Visual J++ > enforces > this. The new Package name "org.crossfire.editor.CFEditor" therefore > doesn't work. It has to be "src.org.crossfire.editor.CFEditor". > However, I would greatly prefer the *.java files back in the > "/CFEditor" dir, where they belong. This is why I specifically asked for a linux branch. Since no one under Linux will use or can using Visual J++, and all the editors under Linux allow src to be located in any directory, even in non-package-name compliant areas, I wanted a linux branch so I could work on it without upseting or breaking any windows stuff. As an aside, Visual J++ requirement seems a little restrictive. I've used JBuilder and it does not have this requirement. I renamed the package, to org.crossfire.editor.CFEditor, because some day there could be other editors, or other java code for this project. So the package name becomes important to prevent name collisions as well as an organization issue. > o The new policy of extracting all resources out of the .jar file > doesn't seem like a good idea to me. Unless I totally misunderstood > your purpose. > Resource files (like icons and config files like "autojoin.txt") > should be easy to access and easy to modify. If they are burried > in the jar file, the average user won't find them. > And you have no visual control over the stuff in the jar file > either. What is the standard location, cross-platform, for resource files? Shoving them into the jar gives a default cross-platform location. Does the average end user really need access to the icons? I can't think of any reason why, unless the want to change the image of the save button, etc. I do have code for putting resource files into the users home directory, using System's user.home property, for things like autojoin.txt, but I've found that not all Window JVM's set this property, so it can be an issue. The jar also makes for easy packaging in linux. 1 file contains everything. Drop it into the classpath and your done. I'm not sure what you mean about visual control, but I have written lots of code that extracts and puts stuff into a .jar file. My code is based on this url: http://www.javaworld.com/javaworld/javatips/jw-javatip49.html What I've found that works well, is to put a resonable set of default Properties and Resources into the .jar file, but make the visual side of things read from the defaults (.jar), and save customization into user.home. > If someone commits a corrupt jar file, will that be > noticeable from the cvs diff? I guess not - though effectively all > resource files are lost. What happens if someone commits a corrupt .png file in the server code page? All resource files are still in cvs, just bundle them into the jar for easy distribution. > Well, I hope that doesn't sound too criticizing. > I'm sorry that I didn't come up with these issues earlier, but I > was busy and didn't have time to test the new stuff before. > Besides, I wasn't really aware of these changes and nobody asked me. I asked: http://mailman.real-time.com/pipermail/crossfire-devel/2001-December/002840.html You responded: http://mailman.real-time.com/pipermail/crossfire-devel/2001-December/002841.html I again asked a question: http://mailman.real-time.com/pipermail/crossfire-devel/2001-December/002854.html You responded: http://mailman.real-time.com/pipermail/crossfire-devel/2001-December/002857.html What do I need to do to keep you more aware? What things should I ask you? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From andi.vogl at gmx.net Fri Jan 18 08:47:03 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:03 2005 Subject: [CF-Devel] Converting tabs to spaces via emacs. Please confirm. In-Reply-To: <20020117191002.K27148@real-time.com> Message-ID: <000001c1a02f$033cd530$c86ebb81@gizmo> > AV, > > Can check to see if the ArchObject.java looks right > inside of Visual J++? > > I believe I have converted all tabs to 4 spaces, but > I'd like verification. > > --- Forwarded message from crossfire-cvs-admin@lists.sourceforge.net ----- > > Module Name: CFJavaEditor > Committed By: tanner > Date: Fri Jan 18 01:07:21 UTC 2002 > > Modified Files: > CFJavaEditor/src/org/crossfire/editor/CFEditor: ArchObject.java > Yes, this file now is perfectly formatted with 4 space indent And no tabs. - Thanks. :-) Andreas From tanner at real-time.com Fri Jan 18 13:21:38 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:02:03 2005 Subject: [CF-Devel] Converting tabs to spaces via emacs. Please confirm. In-Reply-To: <000001c1a02f$033cd530$c86ebb81@gizmo>; from andi.vogl@gmx.net on Fri, Jan 18, 2002 at 03:47:03PM +0100 References: <20020117191002.K27148@real-time.com> <000001c1a02f$033cd530$c86ebb81@gizmo> Message-ID: <20020118132138.E7255@real-time.com> Quoting Andreas Vogl (andi.vogl@gmx.net): > > I believe I have converted all tabs to 4 spaces, but > > I'd like verification. > > Yes, this file now is perfectly formatted with 4 space indent > And no tabs. - Thanks. :-) I'll try to convert the rest of the files over the next couple of days. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From andi.vogl at gmx.net Fri Jan 18 10:16:00 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:03 2005 Subject: [CF-Devel] CVS commit: CFJavaEditor In-Reply-To: <20020117182328.A27148@real-time.com> Message-ID: <000101c1a03b$6ec82690$c86ebb81@gizmo> In reply to Bob Tanner: > > o The biggest Problem is the new formatting. [...] > > Hmm, I thought I changed emacs to do this. :-( Point 12 of > the programming_guide specifically says to use 4 spaces. I'll have > to double check it. > > I've added the appropriate info to the programming_guide to > configure emacs and vim according to the 4 space rule. Oh, I'm glad to hear this is only a minor flaw from your emacs settings. There's no problem then. The new ArchObject.java file you committed testwise is now perfectly formatted. > > o Why is the source code suddenly in > > "/src/org/crossfire/editor/CFEditor"? > > This is the default setup that the Enhydra build evironment wants. [...] Well, for my part I didn't even include the Visual J++ Project file into CVS. It might have increased my personal convenience but this file would be garbage for anyone using a different editor. Anyways - To solve this debate: I suggest we try and leave it as is, at least for now. It's not a big problem, paths can always be changed. > > [...] The new Package name [...] doesn't work. > > [...] I would greatly prefer the *.java files back in > > the "/CFEditor" dir, where they belong. > > This is why I specifically asked for a linux branch. [...] The Java Editor is all about Platform-Independency. Doesn't it seem paradoxical to have both a Linux- and a Windows- branch for an explicit cross-platform software? Moving some directorys after checkout is less work than synchronizing two branches I believe. > I renamed the package, to org.crossfire.editor.CFEditor, because > some day there could be other editors, or other java code for > this project. So the package name becomes important to prevent > name collisions as well as an organization issue. Naming collision is hardly an issue for the CF Java Editor. I doubt there will ever be a second Java Editor, let alone one with identical name, trying to import classes from the first one. > > The new policy of extracting all resources out of the .jar file > > doesn't seem like a good idea to me. [...] > > Resource files (like icons and config files like "autojoin.txt") > > should be easy to access and easy to modify. [...] > > What is the standard location, cross-platform, for resource files? > Shoving them into the jar gives a default cross-platform location. > Does the average end user really need access to the icons? I can't > think of any reason why, unless they want to change the image of the > save button, etc. Why would directory locations be platform-independent? And yes, why not change icons? Some of the icons, like the highlighting frame (for the map-view) might depend a lot on personal taste. > I do have code for putting resource files into the users home > directory, using System's user.home property, for things like > autojoin.txt, but I've found that not all Window JVM's set this > property, so it can be an issue. Why not simply leave it unpacked? Seems quite practical to me... > The jar also makes for easy packaging in linux. 1 file > contains everything. Drop it into the classpath and your done. A jar file does not make for easy packing in Windows. And even for Linux, don't forget that there are people much less accustomed to java than you are. After all, the editor is designed for users, not developers. > > If someone commits a corrupt jar file, will that be > > noticeable from the cvs diff? I guess not - though effectively > > all resource files are lost. > > What happens if someone commits a corrupt .png file in the server > code page? Yes, that has happened numerous times on CF cvs. But it means only loss of *one* resource file, which is usually easy to fix. And it's not like I'm making this up: There have already been corrupt jar files on cvs. It is much more likely to build a jar file in the wrong way, than to come up with a corrupt .png file. > > Well, I hope that doesn't sound too criticizing. > > I'm sorry that I didn't come up with these issues earlier, but I > > was busy and didn't have time to test the new stuff before. > > Besides, I wasn't really aware of these changes and nobody asked me. > > I asked: [...] You responded: [...] > What do I need to do to keep you more aware? Specifically, you said you were "trying to put Makefiles and build.xml (ant) files around CFJavaEditor". You may call me simple-minded, but this did not imply to me that you were about to change directory structure, package names and resource- location-policy. :-) My reply: "I'm very happy if someone works on good makefiles for the Editor" might have also shown my lack of deeper understanding. Anyways, there's nothing we can't settle. If you only fix the formatting, I'm already quite happy. ;-) Andreas From yann.chachkoff at MailAndNews.com Sat Jan 19 02:18:22 2002 From: yann.chachkoff at MailAndNews.com (Yann Chachkoff) Date: Thu Jan 13 18:02:03 2005 Subject: [CF-Devel] RE: [Crossfire-cvs] CVS commit: CFJavaEditor Message-ID: <3C4F2B46@MailAndNews.com> >o Why is the source code suddenly in >"/src/org/crossfire/editor/CFEditor"? > Did you try to hide it or something? > This new directory strucure might be handy in *your* editor, it > definitly is not in mine. Besides, to my knowing it is convention > that Package name and directory path are identical. Visual J++ >enforces > this. The new Package name "org.crossfire.editor.CFEditor" therefore > doesn't work. It has to be "src.org.crossfire.editor.CFEditor". > However, I would greatly prefer the *.java files back in the > "/CFEditor" dir, where they belong. Just as a short information notice: The package name and directory path are not identical. The package name and the directory path -relative to the base classpath- are. So in this case, the editor code can be put in any subdirectory following the scheme: CLASSPATH/org/crossfire/editor/CFEditor I don't know Visual J++ very well, but there's certainly a way to extend your base classpath for each project. If you use an external JVM (like the one from Sun), you can also redefine the global CLASSPATH variable and add /src (or X:\src) to it. Now quite a lot of other programs follow the package name convention org.. (like org.crossfire.editor.CFEditor); this may make the integration of the project into a complex package tree easier (For example, the Giant Java Tree at http://www.gjt.org). Hope this may be of any use to youY. Chachkoff ------------------------------------------------ Visit http://www.chachkoff.pronym.org for a journey into a fantastic world ! (But don't expect too much...) GPG: http://www.chachkoff.pronym.org/gros.pub ------------------------------------------------ From tanner at real-time.com Sat Jan 19 03:16:41 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:02:03 2005 Subject: [CF-Devel] CVS commit: CFJavaEditor In-Reply-To: <000101c1a03b$6ec82690$c86ebb81@gizmo>; from andi.vogl@gmx.net on Fri, Jan 18, 2002 at 05:16:00PM +0100 References: <20020117182328.A27148@real-time.com> <000101c1a03b$6ec82690$c86ebb81@gizmo> Message-ID: <20020119031641.M18368@real-time.com> Quoting Andreas Vogl (andi.vogl@gmx.net): > > This is why I specifically asked for a linux branch. [...] > > The Java Editor is all about Platform-Independency. > Doesn't it seem paradoxical to have both a Linux- and a Windows- > branch for an explicit cross-platform software? > > Moving some directorys after checkout is less work than > synchronizing two branches I believe. A linux branch, so I would not mess up the main branch. Personally, I find merging branches a simple task, cvs does most of the work for you. Most of the projects I work on have several branches. Like PROJECT_2_0 Final version of 2.0 release PROJECT_2_0_BRANCH Branch for 2.0 release development When a port to a new OS is done PROJECT_2_0_LINUX Branch for 2.0 port to Linux Maybe it's because the other projects I work on are larger (in terms of number of developers). But the above system works well IMHO. > Naming collision is hardly an issue for the CF Java Editor. > I doubt there will ever be a second Java Editor, let alone > one with identical name, trying to import classes from the > first one. Ok, how about to follow Sun's recommended naming convention. http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367 > Why would directory locations be platform-independent? Quoting you: "The Java Editor is all about Platform-Independency." > And yes, why not change icons? Some of the icons, like the highlighting > frame (for the map-view) might depend a lot on personal taste. Again quoting you: "After all, the editor is designed for users, not developers." How many users would want to chage the icons? That's more of a developer thing. Unless you invision some sort of PLAF (pluggable look-n-feel, aka skins). I talked a little bit about this in irc, I should have logged it. The stuff (icons, autojoin, etc) in the .jar as a set of reasonable defaults. 1. This make package management easier. 1 file, drop it in the classpath and your done with it. 2. Make setup easier for non-package management. Ie just download this .jar file and java -jar CFEditor.jar to make it work. 3. Makes documentation lots easier. Don't have to tell users where the files need to be located, etc. By no means, be for it to be unflexible. They are in the .jar as defaults, the users can easily change their preferences. Using the Properties class, you can instantiate a new Properties with a set of defaults. http://java.sun.com/j2se/1.3/docs/api/java/util/Properties.html#Properties(java.util.Properties) Pseudo code: // Create some new properties using .jar as defaults. Properties prop = new Properties(defaults from jar); // Look for the user preferences, if they don't exist write // the defaults from the .jar to their preference file. String path = System.pathSeperator; if (user.home+path+CFEditor does not exist) { prop.store(user.home+path+CFEditor); } else { prop.load(user.home+path+CFEditor); } > > The jar also makes for easy packaging in linux. 1 file > > contains everything. Drop it into the classpath and your done. > > A jar file does not make for easy packing in Windows. > And even for Linux, don't forget that there are people > much less accustomed to java than you are. > After all, the editor is designed for users, not developers. .jar is just a zip file. Winzip can manipulate them just as easy as the jar tool. What is easier then saying put this .jar into your classpath and run java org.crossfire.editor.CFEditor? Verse, put .jar into a directory, make sure you download the autojoin.txt and put it into the same directory, and download the HelpFiles, system files, etc.. Make makes it much easier for the end user IMHO. > Yes, that has happened numerous times on CF cvs. > But it means only loss of *one* resource file, which is > usually easy to fix. As I stated before, ALL the files in the jar are still in cvs, the .jar is all that is distributed to end users to make it easier for them all around. Again quoting you: "After all, the editor is designed for users, not developers." If this is true, most user are not going to be looking at cvs, they are going to be looking at the pre-build packages. > And it's not like I'm making this up: There have already been > corrupt jar files on cvs. > It is much more likely to build a jar file in the wrong way, > than to come up with a corrupt .png file. If you notice, I did not check in .jar file, it's not in cvs. I don't believe the .jar should be in cvs in the first place. We don't store the .a or .o files for the server, why store the .jar? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From andi.vogl at gmx.net Sat Jan 19 08:28:07 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:03 2005 Subject: [CF-Devel] CVS commit: CFJavaEditor In-Reply-To: <20020119031641.M18368@real-time.com> Message-ID: <000701c1a0f5$87233df0$c86ebb81@gizmo> In reply to Bob Tanner: I have the impression that the discussion leads not much further at this point. I'm willing to accept the changes to package name and jar-file policy for now. Please fix the formating in return (not today, just when you have time). I'll try to be around on IRC in my spare time the next days. Maybe we can have a chat there. I'm sorry if my tone was a bit harsh or unfriendly, I did not mean to be. The only thing that bothered me about the whole issue is the fact that you committed major structural changes whithout notice. I think I am the third person in this month to complain about such an incident. In the CFJavaEditor code, the online help and the "about"-menu, you'll find Michael Toennies and me stated as Developers, Maintainers and even Copyright holders of the CFJavaEditor. We are not claiming to "own" the code, but I think at least being informed about important changes before the cvs commit is not asking too much. And for that purpose, the cf-devel mailing list exists. I don't know why people keep ignoring the mailing list. Maybe it's the fear of changes getting rejected when asking. Personally I guarantee that I'm much more willing to accept changes when asked peacefully and reasonably *before* the commit. Andreas V. From jukkaho at mail.student.oulu.fi Sun Jan 20 15:26:03 2002 From: jukkaho at mail.student.oulu.fi (Jukka Holappa) Date: Thu Jan 13 18:02:03 2005 Subject: [CF-Devel] Cheating possibility with current rules/map Message-ID: Hi, I noticed that it is possible to very easily make more money. In first room when creating characters one can first 'create' more food by walking up and down just above the place where two pieces of food appear. One can create first a very strong character and then create huge amounts of food, go to the shop and drop the food/sell them there and another player can then collect and sell the food or just pick up the money. By creating new players, moving food to a suitable place and quitting, one can easily create as much money as one wish. This abuse could be easily fixed by fixing the first map where food appears by not allowing more food to be created. - Jukka From tchize at MailAndNews.com Mon Jan 21 03:05:22 2002 From: tchize at MailAndNews.com (david delbecq) Date: Thu Jan 13 18:02:03 2005 Subject: [CF-Devel] Cheating possibility with current rules/map Message-ID: <3C4C0073@MailAndNews.com> >===== Original Message From Jukka Holappa ===== >Hi, > >I noticed that it is possible to very easily make more money. > >In first room when creating characters one can first 'create' more food by >walking up and down just above the place where two pieces of food >appear. > >One can create first a very strong character and then create huge amounts >of food, go to the shop and drop the food/sell them there and another >player can then collect and sell the food or just pick up the money. > >By creating new players, moving food to a suitable place and quitting, one >can easily create as much money as one wish. > >This abuse could be easily fixed by fixing the first map where food >appears by not allowing more food to be created. > >- Jukka > I understand this may seem a problem.This should be fixed. But creating a huge amount of money is more easy. Ask a high level player for a bit of money and some potions. They will give you since they have no need of it. --Tchize From jbontje at suespammers.org Mon Jan 21 16:45:05 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:02:03 2005 Subject: [CF-Devel] server patch: damned exits Message-ID: <20020121234505.A7322@freebsd.localdomain> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 238 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020121/584deb8a/attachment.pgp From tanner at real-time.com Fri Jan 25 19:32:33 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:02:03 2005 Subject: [CF-Devel] Fork in CFJavaEditor? Message-ID: <20020125193233.W16264@real-time.com> I know this is going to sound accusational, but has the CFJavaEditor forked? I saw AV's talk about a new CFJavaEditor web page on irc, so I look here: http://mids.student.utwente.nl/~avogl/CFJavaEditor/index.htm There are changes that are not in the cvs logs. Just curious. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From andi.vogl at gmx.net Sun Jan 27 06:31:50 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:03 2005 Subject: [CF-Devel] Fork in CFJavaEditor? References: <20020125193233.W16264@real-time.com> Message-ID: <28955.1012134710@www42.gmx.net> > I know this is going to sound accusational, but has the CFJavaEditor > forked? > > I saw AV's talk about a new CFJavaEditor web page on irc, so I look here: > > http://mids.student.utwente.nl/~avogl/CFJavaEditor/index.htm > > There are changes that are not in the cvs logs. > > Just curious. Yes, you're right. I did not put my latest changes of CFJavaEditor on cvs. I have decided to continue developing on that version that I have coded from ground up. It's available at and I will put my future updates there. Andreas V. -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From tanner at real-time.com Sun Jan 27 18:58:42 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:02:04 2005 Subject: [CF-Devel] Fork in CFJavaEditor? In-Reply-To: <28955.1012134710@www42.gmx.net>; from andi.vogl@gmx.net on Sun, Jan 27, 2002 at 01:31:50PM +0100 References: <20020125193233.W16264@real-time.com> <28955.1012134710@www42.gmx.net> Message-ID: <20020127185842.C21613@real-time.com> Quoting Andreas Vogl (andi.vogl@gmx.net): > > There are changes that are not in the cvs logs. > > > > Just curious. > > Yes, you're right. I did not put my latest changes of CFJavaEditor > on cvs. I have decided to continue developing on that version that I > have coded from ground up. That's dissappointing. Why'd you open source it in the first place, if you don't want other to contribute to the code base? The currect release was difficult to package up for linux, so I made some structural changes that fall in line with Java's programming style guide lines. What really is irritating is that you do not seem to "get" open source development. In all the other project I code for there is always a clash of ego. Then lots of discussion, compromises, and finally a solution that acceptable to the developers and (usually) very good for the community. Forking of the code can be good and bad. If we had more developers, it would be good thing. The strongest/best features of each fork would, inventually be incorporated into each other and the -community- would win; 2 good pieces of software to choose from. But we have a small development community, so in effect the fork takes away developers from the community and creates hard feelings. In crossfire's case 1 project will stagnate. Bottom line AV, your fork hurts the -community-, IMHO. I've seen you do this 2 times now. If it's not your way, then you storm off and fork the code and start a new project, instead of trying to work with the community. My intention with the editor was to make it easier to build, package and deploy under linux. I never intended to take over the development or design of the project. Since I have written lots of Java code for Linux and deployed under Windows, I felt I had some skills to contribute to the community in making a more cross-platform build and deploy environment. I did not mean to piss you off. I'd like to work with you to integrate your changes into the main cvs repository and change whatever you want to keep the project together. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From andi.vogl at gmx.net Sun Jan 27 21:52:38 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:04 2005 Subject: [CF-Devel] Fork in CFJavaEditor? In-Reply-To: <20020127185842.C21613@real-time.com> Message-ID: <000001c1a7af$3dd4dbc0$c86ebb81@gizmo> In reply to Bob Tanner: > That's dissappointing. Why'd you open source it in the first > place, if you don't want other to contribute to the code base? > [...] > What really is irritating is that you do not seem to "get" open > source development. In all the other project I code for there is > always a clash of ego. Then lots of discussion, compromises, and > finally a solution that acceptable to the developers and (usually) > very good for the community. And I have heard opensource also means that people inform the community before changing other people's work. Maybe I didn't get it indeed... > Forking of the code can be good and bad. [...] > In crossfire's case 1 project will stagnate. > Bottom line AV, your fork hurts the -community-, IMHO. I enjoy working in a community as long as I feel treated in a fair way. > I've seen you do this 2 times now. If it's not your way, then > you storm off and fork the code and start a new project, instead > of trying to work with the community. Your wrong, I didn't do that before. I didn't meet anyone I couldn't get along with, before. > My intention with the editor was to make it easier to build, > package and deploy under linux. I never intended to take over > the development or design of the project. > [...] > I'd like to work with you to integrate your changes into the > main cvs repository and change whatever you want to keep the > project together. That's a very kind offer. If I had the old package name, source in "/CFEditor" and the former indenting style - I could easily merge my stuff in cvs and abandon the forked version. Andreas V. PS.: By "former indenting style" I mean this: if (expression) { statement; statement; } on cvs currently, most files contain this: if (expression) { statement; statement; } From kevin at ank.com Tue Jan 29 00:57:23 2002 From: kevin at ank.com (kevin@ank.com) Date: Thu Jan 13 18:02:04 2005 Subject: [8] RE: [CF-Devel] Fork in CFJavaEditor? In-Reply-To: <000001c1a7af$3dd4dbc0$c86ebb81@gizmo> References: <20020127185842.C21613@real-time.com> <000001c1a7af$3dd4dbc0$c86ebb81@gizmo> Message-ID: <20020128225723.A9439@balrog.ank.com> To Bob, FWIW, it is pretty easy to work around the need for directory structure to match package structure in Linux. Just set the class output directory (using -d IIRC) and Java will be happy with the sources where ever they come from. Java only gets upset when the output files don't correspond to the package structure. Hope this helps resolve some of the problems with the CVS tree. Cheers, -kls On Mon, Jan 28, 2002 at 04:52:38AM +0100, Andreas Vogl wrote: > In reply to Bob Tanner: > > > That's dissappointing. Why'd you open source it in the first > > place, if you don't want other to contribute to the code base? > > [...] > > What really is irritating is that you do not seem to "get" open > > source development. In all the other project I code for there is > > always a clash of ego. Then lots of discussion, compromises, and > > finally a solution that acceptable to the developers and (usually) > > very good for the community. > > And I have heard opensource also means that people inform > the community before changing other people's work. > Maybe I didn't get it indeed... > > > Forking of the code can be good and bad. [...] > > In crossfire's case 1 project will stagnate. > > Bottom line AV, your fork hurts the -community-, IMHO. > > I enjoy working in a community as long as I > feel treated in a fair way. > > > I've seen you do this 2 times now. If it's not your way, then > > you storm off and fork the code and start a new project, instead > > of trying to work with the community. > > Your wrong, I didn't do that before. > I didn't meet anyone I couldn't get along with, before. > > > My intention with the editor was to make it easier to build, > > package and deploy under linux. I never intended to take over > > the development or design of the project. > > [...] > > I'd like to work with you to integrate your changes into the > > main cvs repository and change whatever you want to keep the > > project together. > > That's a very kind offer. > If I had the old package name, source in "/CFEditor" and the > former indenting style - I could easily merge my stuff in cvs > and abandon the forked version. > > > Andreas V. > > PS.: By "former indenting style" I mean this: > > if (expression) { > statement; > statement; > } > > on cvs currently, most files contain this: > > if (expression) > { > statement; > statement; > } > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -- // .--=, .....::://::::::::::::::::::::::::::::.. (o O & kevin@ank.com :::::::://:::://://://:/:://::||_// / V K :::::://:::://:/:|//'/' // _,|' r , 'qk :'''/____ // / // |_// // || .'~. .~`, kls \_/-=\_/ From tanner at real-time.com Tue Jan 29 01:38:47 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:02:04 2005 Subject: [8] RE: [CF-Devel] Fork in CFJavaEditor? In-Reply-To: <20020128225723.A9439@balrog.ank.com>; from kevin@ank.com on Mon, Jan 28, 2002 at 10:57:23PM -0800 References: <20020127185842.C21613@real-time.com> <000001c1a7af$3dd4dbc0$c86ebb81@gizmo> <20020128225723.A9439@balrog.ank.com> Message-ID: <20020129013847.G12662@real-time.com> Quoting kevin@ank.com (kevin@ank.com): > To Bob, > > FWIW, it is pretty easy to work around the need for directory > structure to match package structure in Linux. Just set the > class output directory (using -d IIRC) and Java will be happy > with the sources where ever they come from. Java only gets > upset when the output files don't correspond to the package > structure. > > Hope this helps resolve some of the problems with the CVS tree. Actually, it's AV that wish to have the directory structure different. The issue was resolved in irc. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From henric at lysator.liu.se Thu Jan 31 11:18:35 2002 From: henric at lysator.liu.se (Henric Karlsson) Date: Thu Jan 13 18:02:04 2005 Subject: [CF-Devel] death attack, AT_DEATH Message-ID: Hi I noticed something strange a few days ago, while I was chopping through some trolls with my headcutter (it has death attack and makes the process quick), now I had devourer enchant my katana of Masamune (slay undead and now death attack from devourer), now my assumption was that I would chopp trolls even faster since I had a higher weapon speed. But now I started to slowely grind those poor trolls instead of instant death attacks like before. Puzzeld I looked at the code for the answer, and found first in the function deathstrike_player() in attack.c if (hitter->slaying) (a few conditions that my trolls didn't meet) return; Now why can't I use the attack type death on a weapon with slay set? This sounds like a bug to me, but maybe I missed something in the code. /Henric (aka Gambold) From andi.vogl at gmx.net Thu Jan 31 12:10:29 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:04 2005 Subject: [CF-Devel] death attack, AT_DEATH In-Reply-To: Message-ID: <000001c1aa82$94715410$c86ebb81@gizmo> In reply to Henric Karlsson: > Now why can't I use the attack type death on a weapon with slay set? > This sounds like a bug to me, but maybe I missed something in > the code. It's not really a bug. As far as I know, death attack was originally designed to increase the effect of slaying-weapons (weapons with a slaying set). So, if you have a weapon with death attack and a slaying, all monsters of the slayed race are killed with death-attacks. Now for some reason, it slipped into the code that if there is no slaying on your weapon, death-attack works on everything. Ever since, people's opinions differ about what to do: 1. Make death attack always work, despite of slayings? 2. Or make it work only with slayings? Andreas V. From mwedel at sonic.net Wed Jan 23 02:04:33 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:04 2005 Subject: [CF-Devel] server patch: damned exits References: <20020121234505.A7322@freebsd.localdomain> Message-ID: <3C4E6E91.24460BDB@sonic.net> Joris Bontje wrote: > > Oh no, another patch from me, when will it end :) > > Server patch: > Damned exits change savebed location > This patch allows you to change the savebed location of a player in > your map without the need for the player to apply a savebed. > I have written this to restrict espaces from the jail map > (local map on my server) by dying. I also hope that this will help > linking the nethack mapset, because now players cant cheat anymore and > escape with WoR, TownPortal or dying. > Current problems (that I know of): > -The remove Town Portal code just removes a force in your inventory, > it doesnt remove existing townportals. > -The name for the force is a define, the same define appears in the > town portal code in spell_effect.c I think that they both need to > be in a headerfile. (which one?) Its sort of odd the way it does it. Looking more closely at the portal code, it probably would have made more sense to have 2 portal archs - one source, one dest, and then more of the builtin functions could get used. It also would have been better if the portal code didn't use op->slaying to hold that tag - it would have made life easier when debugging exit logic, as then it would have followed the scheme. In any case, to answer your question, those defines would probably be best placed in spells.h. Your code otherwise looks fine. From peterm at tonks.EECS.Berkeley.EDU Thu Jan 31 14:41:09 2002 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:02:04 2005 Subject: [CF-Devel] death attack, AT_DEATH In-Reply-To: Your message of "Thu, 31 Jan 2002 19:10:29 +0100." <000001c1aa82$94715410$c86ebb81@gizmo> Message-ID: <200201312041.g0VKf9E00539@tonks.EECS.Berkeley.EDU> > In reply to Henric Karlsson: > > > Now why can't I use the attack type death on a weapon with slay set? > > This sounds like a bug to me, but maybe I missed something in > > the code. Well, I originally coded a lot of this stuff, and what I had in mind was this: 1) If a weapon had a "slaying" and AT_DEATH, it used AT_DEATH on the monsters listed in "slaying" and the other attacktypes on anything else. 2) If it didn't have a slaying field, it used AT_DEATH on everything. PM > It's not really a bug. > > As far as I know, death attack was originally designed to > increase the effect of slaying-weapons (weapons with a slaying set). > So, if you have a weapon with death attack and a slaying, > all monsters of the slayed race are killed with death-attacks. > > Now for some reason, it slipped into the code that if there > is no slaying on your weapon, death-attack works on everything. > > Ever since, people's opinions differ about what to do: > 1. Make death attack always work, despite of slayings? > 2. Or make it work only with slayings? > > > Andreas V. > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From andi.vogl at gmx.net Thu Jan 31 21:36:27 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:04 2005 Subject: [CF-Devel] CFJavaEditor update Message-ID: <000001c1aad1$a4ced630$c86ebb81@gizmo> I happily announce that there is a new feature for the CFJavaEditor available, which is going to make mapmaking significantly easier. The biggest problem with Crossfire maps is the terrible mess of the arch syntax. Arch attributes like "sp", "wc", "last_heal" etc. are confusing on their own - and they get used in so many different ways. Even the most passionate Crossfire-developer needs a long time to understand half of it. I tried to improve the situation by writing my map-guide. Docu is a fine thing - but not good enough. It's way too annoying to read all that, and look things up repeatedly. So now I have integrated a Graphical User Interface in the editor, providing a convenient input-mask for all kinds of crossfire-objects. The GUI is very flexible, the data is parsed from a definitions- file called "types.txt". As you can imagine, this file has a non-trivial syntax, but it's quite easy to understand. It already contains a lot more information than my map-guide. The whole thing is available for now at (I can easily put it on cvs later, the new code is pretty much stand-alone) Look for the red "Attributes"-button... Of course the whole thing isn't complete yet. And the "types.txt" still lacks a bunch of information, but it's already extremely helpful. I started to work on this feature long time ago and decided it's time for a first release. Andreas V. From dl at leo.org Wed Jan 9 14:31:12 2002 From: dl at leo.org (Daniel Lang) Date: Thu Jan 13 18:04:09 2005 Subject: [CF List] Problems reusing characters from 0.94.3 Message-ID: <20020109213112.A37579@atrbg11.informatik.tu-muenchen.de> Hi, I used to play 0.94.3 for a while, but decided to upgrade now to 1.0.0 (server) and 1.1.0 client. At first I was unsure if I could reuse the character at all, since there are now distinct races. But when I tried it, it seemed to work at first. Then a serious problem occurred, it seems like this happened together with a crash in the chess club, but I'm not sure if this related: I went into the chess club (that was new to me) and 'applied' the bookshelf. Then the client crashed because of a Bad X11 request (unknown pixmap or something). Since then, I could no longer play, since the position was saved obviously and I the client continued to crash as soon as my character was logged in. My only solution seemed to remove the location info from the player file, thus I've edited the map-line into 'beginners' instead of chess_club, which allowed me to log in again. But since then I was unable to move, as it seemed all default key-bindings have been lost, all the keys to move, to apply, etc did no longer work. I could redefine these keys again with 'bind' but what did no longer work is to use a skill, cast a spell or shoot a missile weapon into a direction. - did no longer work, and I could not find a way to readd these kind of keys again. If this is a FAQ please point me to the right documentation. Thanks a lot, Daniel -- IRCnet: Mr-Spock - Burn them to ashes, then burn the ashes. - *Daniel Lang * dl@leo.org * +49 89 289 25735 * http://www.leo.org/~dl/* From mathwizard at gmx.de Thu Jan 10 05:24:13 2002 From: mathwizard at gmx.de (mathwizard@gmx.de) Date: Thu Jan 13 18:04:09 2005 Subject: [CF List] Problems reusing characters from 0.94.3 In-Reply-To: <20020109213112.A37579@atrbg11.informatik.tu-muenchen.de> References: <20020109213112.A37579@atrbg11.informatik.tu-muenchen.de> Message-ID: <20020110122413.11973f10.mathwizard@gmx.de> Hi, what about reinstalling server/client? Wouldn't this solve the problem? Since I don't have any problems in the Chess Club these might also be solved in that way. Christoph Bergemann -- "Do not meddle in the affairs of Wizards, for they are subtle and quick to anger." -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020110/49c58f55/attachment.pgp From mwedel at sonic.net Fri Jan 11 00:21:30 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:09 2005 Subject: [CF List] Problems reusing characters from 0.94.3 References: <20020109213112.A37579@atrbg11.informatik.tu-muenchen.de> Message-ID: <3C3E846A.DF93E2CF@sonic.net> Daniel Lang wrote: > > At first I was unsure if I could reuse the character > at all, since there are now distinct races. > But when I tried it, it seemed to work at first. > > Then a serious problem occurred, it seems like > this happened together with a crash in the chess club, > but I'm not sure if this related: I'd have to see the character file to see what really happened. It seems that the client crash would be unrelated to the old character file, as nothing in the character file should cause anything to get sent that would cause a crash. > > I went into the chess club (that was new to me) > and 'applied' the bookshelf. Then the client crashed > because of a Bad X11 request (unknown pixmap or something). > Since then, I could no longer play, since the position > was saved obviously and I the client continued to crash > as soon as my character was logged in. There seems to be a bug in the x11 client - my guess is the removal of the pixmaps caused this, as it is probably trying to display a null pixmap. > But since then I was unable to move, as it seemed all > default key-bindings have been lost, all the keys > to move, to apply, etc did no longer work. > I could redefine these keys again with 'bind' but what > did no longer work is to use a skill, cast a spell or > shoot a missile weapon into a direction. > - did no longer work, and I > could not find a way to readd these kind of keys again. Not sure why they got clobbered. You could probably copy the keys file from the client distribution into ~/.crossfire.