From mwedel at sonic.net Wed Feb 1 00:44:17 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 31 Jan 2006 22:44:17 -0800 Subject: [crossfire] Transports In-Reply-To: <43DF1D3B.2000302@sonic.net> References: <43DF1D3B.2000302@sonic.net> Message-ID: <43E058C1.6040202@sonic.net> Quick notes on issues/questions raised: 1) I had thought about transports having maps associated with them (map of a ship, etc). But that adds a lot of complication - first, you need to somehow make those maps unique, update exits, etc. But also, you get issues of actual appearance. IMO, when driving around/whatever, you just want a relative small thing moving about. So you would have the case that you enter/board the ship, it takes you to a new map, but then to sail it, you then have to transition back to it just being the ship icon, not the entire map. To me, this just adds a lot of complication without adding a whole bunch. 2) the move_block can be given to certain objects to prevent them from being taken into dungeons, etc. This means more move types would be needed - move_horse, move_cart, etc. Easy enough to do, just need to think about what movement types are needed (you don't really want one for each transportation object - you want some level of abstraction). But this could be useful - carts could perhaps not go through jungles, forests, mountains and other rough terrain. 3) Shops are not much an issue - the block in point 2 can be used. But there is code right now that aggressively looks for unpaid inventory in containers - that code should work just fine for transports. And arguably, in some cases, being able to bring in transports to shops makes things easier - don't have to leave the shop, get more items, enter again, etc. 4) Scale is always an issue. Arguably, players are too big for most stuff in the bigworld map (or all buildings must use magic to be bigger on the inside than they appear). For that matter, right now, things like the longships and the like would appear out of scale - a longship could apparantly only hold 2 people based on size, which obviously isn't correct. But I'd say it is something that is hard to really get right given we still have varying scales in the game. 5) The idea of 'picking up' and transport to use it is odd to me. Picking up a wagon doesn't make sense. What may make sense is that you apply the transport to board it and leave it (that makes sense - that is the same logic like entering exits, etc). If you are aboard the transport, you can see everything loaded onto it. If you drop something, it goes in the tranport, and not the space. This would probably be most intuitive interface wise. Also, thinking about this, probably necessary to have some flag to denote if items can in fact be loaded into the transport. You can't necessarily pile stuff onto a horse, but could on a wagon. 6) Damage - damaging transport requires a whole new set of code and complication. Do transports now have resistances and the like? Do they heal, etc? I'd say this could perhaps be done later, but not sure how compelling it is to do it - may just really create more bother and complications. From mwedel at sonic.net Wed Feb 1 00:48:37 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 31 Jan 2006 22:48:37 -0800 Subject: [crossfire] cfclient colouring In-Reply-To: <7903f03c0601310631n31fcaf8bl5f61678ae181283f@mail.gmail.com> References: <7903f03c0601301849n395753er7cbc61623ff0df36@mail.gmail.com> <43DF0803.4060203@sonic.net> <7903f03c0601310631n31fcaf8bl5f61678ae181283f@mail.gmail.com> Message-ID: <43E059C5.6070900@sonic.net> Brendan Lally wrote: > On 1/31/06, Mark Wedel wrote: >> I'd personally say that requiring a 256 color display isn't asking too much >> now days. > > I'm inclined to agree, I just don't know xlibs well enough to break > support for 16 colour displays in a non-hacky way. (there is still > some 'private colourmap' stuff, which I think is somehow related to > that) actually, I don't think there is anything specific about using 16 colors. I think it was just that 16 colors were used - it could very well be 12 or 25 - as far as X is concerned, it doesn't care (unless someone only had 4 bit color, but I don't know if such hardware ever existed). And right now, while only those 16 colors are used for standard drawing elements, hundreds of more are used for the actual images themselves. Private colormap is a leftover from 8 bit display - most 8 bit hardware could only display 256 different colors at a time, but out of the palette of 16 million (24 bit color). So one would use colormaps to determine what colors of the palette your are drawing. Now there may still be some people out there still on 8 bit color. But it is probably fair to have 16+ bit color be a minimum requirement now days (actually, the other clients, that don't do color map stuff, will probably work on 8 bit color, just look pretty crappy) From mwedel at sonic.net Wed Feb 1 00:52:27 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 31 Jan 2006 22:52:27 -0800 Subject: [crossfire] crossfire traffic In-Reply-To: <7903f03c0601310751w66491ebtd011ac1f45a3112a@mail.gmail.com> References: <7903f03c0601310751w66491ebtd011ac1f45a3112a@mail.gmail.com> Message-ID: <43E05AAB.4090805@sonic.net> That looks like a great idea to me. Nice to also get a monthly recap of what has been talked about From mwedel at sonic.net Wed Feb 1 01:03:09 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 31 Jan 2006 23:03:09 -0800 Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <7903f03c0601311533v1d9c54ebn5448d0ea0aba7025@mail.gmail.com> References: <43DC4B0A.8030808@sonic.net> <7903f03c0601290420x2a1eae8fpe3a7c919d2b2f5bb@mail.gmail.com> <7903f03c0601311533v1d9c54ebn5448d0ea0aba7025@mail.gmail.com> Message-ID: <43E05D2D.4090306@sonic.net> Brendan Lally wrote: > On 1/31/06, Anton Oussik wrote: >> In order to achieve that I propose starting with 3 changes: >> * DRASTICALLY reduce the hp regeneration (something like 10-fold) >> * Significantly increase hp of players and monsters (3-10 fold) >> * Significantly lower resistances given by items (so a player can >> get up to 25% resistance or so with several items) > > One thing that might work well there, would be to also have a > reduction in weapon speed (reduce it by a factor of 2 or so). > Currently when you attack monsters the attack messages are numerous > and spam-y, if they were slowed down a lot (to at least the point > where you could read all of them out loud as they come in). There > would be fewer attacks to calculate, the rate of damage would be less, > and there would also be fewer draw_info messages to transmit, which > seems like a win all round. > > It would also make it possible to bring back the point from long ago > of attack sounds, since attacks and parries would be slow enough that > you could actually have sounds mapped to them. But this is also tied to player speed. Unless you make attack speeds really slow, but that doesn't work will with current movement code - really, attack speed I don't think has much effect if it is slower than the players normal speed. So I think without some significant changes, hard to slow it down to the point you can read it out without some major restructuring. If we say the player speed is 0.5, that is still 4 attacks/second. I think to be at a 'readable' pace, it would need to be closer to about 1 attack/second. But you still want to move at a reasonable pace. So to do that 'slow' attack, you'd need some code restructuring - basically, you'd have to have a separate 'weapon_speed_left' variable or the like - if you try to move onto a monster, if your weapon_speed_left is less than zero, you just can't move there (right now, you'd attack the monster). I had suggested a long time ago adding something like 'damage factor' as a setting, which divides/multiplies damage done/received. This provides a convenient way to make adjustments without having to change all the archetypes and the like If we're going to start adjusting HP of creatures/players, I'd state a primary goal to be that monsters and players have more similar HP. One of the problems right now is monsters have so many more hp than players that targeting spells at other players become almost instant death. From brenlally at gmail.com Wed Feb 1 05:17:39 2006 From: brenlally at gmail.com (Brendan Lally) Date: Wed, 1 Feb 2006 11:17:39 +0000 Subject: [crossfire] cfclient colouring In-Reply-To: <43E059C5.6070900@sonic.net> References: <7903f03c0601301849n395753er7cbc61623ff0df36@mail.gmail.com> <43DF0803.4060203@sonic.net> <7903f03c0601310631n31fcaf8bl5f61678ae181283f@mail.gmail.com> <43E059C5.6070900@sonic.net> Message-ID: <7903f03c0602010317hfecce57hf21494eec30d44fa@mail.gmail.com> On 2/1/06, Mark Wedel wrote: > Brendan Lally wrote: > actually, I don't think there is anything specific about using 16 colors. I > think it was just that 16 colors were used - it could very well be 12 or 25 - as > far as X is concerned, it doesn't care (unless someone only had 4 bit color, but > I don't know if such hardware ever existed). ega cards on (very) old IBM PCs support only 16 displayable colours, I don't know if they can run X though. - in any case their resolution probably wouldn't be enough to show the entire screen. > Private colormap is a leftover from 8 bit display - most 8 bit hardware could > only display 256 different colors at a time, but out of the palette of 16 > million (24 bit color). So one would use colormaps to determine what colors of > the palette your are drawing. Is that why I have seen colours shift with application focus on very old sparc systems running X? From lalo.martins at gmail.com Wed Feb 1 06:52:34 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Wed, 01 Feb 2006 20:52:34 +0800 Subject: [crossfire] Transports In-Reply-To: <43E058C1.6040202@sonic.net> References: <43DF1D3B.2000302@sonic.net> <43E058C1.6040202@sonic.net> Message-ID: And so says Mark Wedel on 01/02/06 14:44... > 4) Scale is always an issue. Arguably, players are too big for most stuff in > the bigworld map (or all buildings must use magic to be bigger on the inside > than they appear). For that matter, right now, things like the longships and > the like would appear out of scale - a longship could apparantly only hold 2 > people based on size, which obviously isn't correct. But I'd say it is > something that is hard to really get right given we still have varying scales in > the game. Me, I'm sticking with Brendan's "indoors square is 1 fathom, outdoors is 1 chain" scale. It makes the best sense, even if it makes the "continent" ridiculously small. BTW, I keep referring back to that message, and every time I have to search for it again, so I posted it here: http://wiki.metalforge.net/doku.php/map_scale > Also, thinking about this, probably necessary to have some flag to denote if > items can in fact be loaded into the transport. You can't necessarily pile > stuff onto a horse, but could on a wagon. Just a capacity, as already described in the proposal. You *can* pile some amount of stuff on a horse, after all. Which leads to another idea - some transports could be set up to behave as pets when unpiloted (behave as pets, not count as pets - killpets shouldn't kill them), so that you have 2 horses, you put your stuff on one, mount the other, and the "cargo" horse follows you. If on another adventure you have an ally, he can borrow your second horse and mount it normally. > 6) Damage - damaging transport requires a whole new set of code and > complication. Do transports now have resistances and the like? Do they heal, > etc? I'd say this could perhaps be done later, but not sure how compelling it > is to do it - may just really create more bother and complications. I think that would have to make a distinction between living and nonliving transports. Being able to fix nonliving transports would make skills (smithery) even more interesting. Living transports heal normally, and consequently can be healed. Nonliving transports, when damaged beyond their HP, break - you can use a skill to fix them, but you can't use them like that. Living transports die. Which suggests things like horse armor. But then, let's leave these ideas for the future. I agree initially they can just not take damage. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From brenlally at gmail.com Wed Feb 1 08:47:10 2006 From: brenlally at gmail.com (Brendan Lally) Date: Wed, 1 Feb 2006 14:47:10 +0000 Subject: [crossfire] Transports In-Reply-To: References: <43DF1D3B.2000302@sonic.net> <43E058C1.6040202@sonic.net> Message-ID: <7903f03c0602010647k5f5e5319u29e4545ce6698bb3@mail.gmail.com> On 2/1/06, Lalo Martins wrote: > Me, I'm sticking with Brendan's "indoors square is 1 fathom, outdoors is > 1 chain" scale. It makes the best sense, even if it makes the > "continent" ridiculously small. > > BTW, I keep referring back to that message, and every time I have to > search for it again, so I posted it here: > http://wiki.metalforge.net/doku.php/map_scale Yes, I forget to get around to committing the changed signposts/directions for that, thanks for reminding me. From mikeeusaa at yahoo.com Wed Feb 1 05:14:15 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Wed, 1 Feb 2006 03:14:15 -0800 (PST) Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <43E05D2D.4090306@sonic.net> Message-ID: <20060201111415.16450.qmail@web32705.mail.mud.yahoo.com> I think a better solution would be to, rather then show every attack message, only show one every 1 second or so. Friendly fire is setable in the settings file and can be set low to compensate. --- Mark Wedel wrote: > But this is also tied to player speed. Unless you > make attack speeds really > slow, but that doesn't work will with current > movement code - really, attack > speed I don't think has much effect if it is slower > than the players normal speed. > > So I think without some significant changes, hard > to slow it down to the point > you can read it out without some major > restructuring. If we say the player > speed is 0.5, that is still 4 attacks/second. > > I think to be at a 'readable' pace, it would need > to be closer to about 1 > attack/second. But you still want to move at a > reasonable pace. So to do that > 'slow' attack, you'd need some code restructuring - > basically, you'd have to > have a separate 'weapon_speed_left' variable or the > like - if you try to move > onto a monster, if your weapon_speed_left is less > than zero, you just can't move > there (right now, you'd attack the monster). > > I had suggested a long time ago adding something > like 'damage factor' as a > setting, which divides/multiplies damage > done/received. This provides a > convenient way to make adjustments without having to > change all the archetypes > and the like > > If we're going to start adjusting HP of > creatures/players, I'd state a primary > goal to be that monsters and players have more > similar HP. One of the problems > right now is monsters have so many more hp than > players that targeting spells at > other players become almost instant death. > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From alex_sch at telus.net Wed Feb 1 17:38:39 2006 From: alex_sch at telus.net (Alex Schultz) Date: Wed, 01 Feb 2006 16:38:39 -0700 Subject: [crossfire] Transports In-Reply-To: <43E058C1.6040202@sonic.net> References: <43DF1D3B.2000302@sonic.net> <43E058C1.6040202@sonic.net> Message-ID: <43E1467F.6020603@telus.net> Mark Wedel wrote: >1) I had thought about transports having maps associated with them (map of a >ship, etc). But that adds a lot of complication - first, you need to somehow >make those maps unique, update exits, etc. But also, you get issues of actual >appearance. IMO, when driving around/whatever, you just want a relative small >thing moving about. So you would have the case that you enter/board the ship, >it takes you to a new map, but then to sail it, you then have to transition back >to it just being the ship icon, not the entire map. To me, this just adds a lot >of complication without adding a whole bunch. > Well, IMHO this may not add too much for the player to use, but I can see it as something that would add alot of depth to the gameplay. Not sure how worth it it would be to do though, as it is indeed alot of complication, though I would say it would certainly improve the player experience. Alex Schultz From brenlally at gmail.com Wed Feb 1 17:49:37 2006 From: brenlally at gmail.com (Brendan Lally) Date: Wed, 1 Feb 2006 23:49:37 +0000 Subject: [crossfire] Transports In-Reply-To: <43E1467F.6020603@telus.net> References: <43DF1D3B.2000302@sonic.net> <43E058C1.6040202@sonic.net> <43E1467F.6020603@telus.net> Message-ID: <7903f03c0602011549t50e1d95eha4020f2f47378f60@mail.gmail.com> On 2/1/06, Alex Schultz wrote: > Well, IMHO this may not add too much for the player to use, but I can > see it as something that would add alot of depth to the gameplay. Not > sure how worth it it would be to do though, as it is indeed alot of > complication, though I would say it would certainly improve the player > experience. The small ships would be fine I think, as long as they can still 'attack' each other and have such an event create a 'battle' map, where there are two ships with all their occupants, plus cannons, etc to fight each other. (there could then be pirate ships patrolling just outside the main shipping lanes, and on PVP servers, groups of players could be pirates themselves). From antonoussik at gmail.com Wed Feb 1 18:19:19 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Thu, 2 Feb 2006 00:19:19 +0000 Subject: [crossfire] Transports In-Reply-To: <7903f03c0602011549t50e1d95eha4020f2f47378f60@mail.gmail.com> References: <43DF1D3B.2000302@sonic.net> <43E058C1.6040202@sonic.net> <43E1467F.6020603@telus.net> <7903f03c0602011549t50e1d95eha4020f2f47378f60@mail.gmail.com> Message-ID: On 01/02/06, Brendan Lally wrote: > On 2/1/06, Alex Schultz wrote: > > Well, IMHO this may not add too much for the player to use, but I can > > see it as something that would add alot of depth to the gameplay. Not > > sure how worth it it would be to do though, as it is indeed alot of > > complication, though I would say it would certainly improve the player > > experience. > > The small ships would be fine I think, as long as they can still > 'attack' each other and have such an event create a 'battle' map, > where there are two ships with all their occupants, plus cannons, etc > to fight each other. (there could then be pirate ships patrolling just > outside the main shipping lanes, and on PVP servers, groups of players > could be pirates themselves). By seperate map I meant something more along the lines of "pocket dimension" that a large transport will have, without any representation of the surrounding world. Yes, it would add a lot of complexity, so perhaps it would be best to leave that as a possible extension for the transport system in the future, and get a working transport system first. Also, how about setting up shipping routes and roads by placing directors for transport on them? From mikeeusaa at yahoo.com Wed Feb 1 11:38:34 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Wed, 1 Feb 2006 09:38:34 -0800 (PST) Subject: [crossfire] Bigworld-ized pupland status? Message-ID: <20060201173834.37985.qmail@web32708.mail.mud.yahoo.com> What's the status on bigworldized pupland (IE: when is it going in?). /me awaits the glorious addittion. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mikeeusaa at yahoo.com Wed Feb 1 11:43:52 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Wed, 1 Feb 2006 09:43:52 -0800 (PST) Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <7903f03c0601311533v1d9c54ebn5448d0ea0aba7025@mail.gmail.com> Message-ID: <20060201174352.77864.qmail@web32706.mail.mud.yahoo.com> I think we should have plots and reputation system in for 2.0. And a setting to show (by default) 1 attack message per second or so (rather then "char punches once, and again, and SUPRISE again!"). It would also be good if the int for hp, maxhp, sp, and maxsp (used for alters) was raised to int 32 (it's int 16 now, right?). I don't think we should mess with the amount of hp clients or monsters get nor the weap attributes. We may want to explore the use of regents or something for spells as talked about before (you need this before you can cast uber powerfull spell). More spells... such as circular spells (not 'nova spells', orbiting spells: ring of fireball, etc etc) might be nice too. Transports would be good too. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From brenlally at gmail.com Wed Feb 1 19:08:31 2006 From: brenlally at gmail.com (Brendan Lally) Date: Thu, 2 Feb 2006 01:08:31 +0000 Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <20060201174352.77864.qmail@web32706.mail.mud.yahoo.com> References: <7903f03c0601311533v1d9c54ebn5448d0ea0aba7025@mail.gmail.com> <20060201174352.77864.qmail@web32706.mail.mud.yahoo.com> Message-ID: <7903f03c0602011708s62d29dddg2ad220b5f09c1795@mail.gmail.com> On 2/1/06, Miguel Ghobangieno wrote: > And a setting to show (by default) 1 attack message > per second or so (rather then "char punches once, and > again, and SUPRISE again!"). I want the rate of attacks to be down to about one (or two at most) a second - at least for 'normal' weapons (like broadswords). Try swinging a sword more than twice a second consistantly, and then you will see why I think this a reasonable limit (yes, you can do more with a fencing sword like a foil or epee, but they don't do much damage anyway, if someone wants to add them with stupidly high weapon speeds, they could still do so). - having fewer attacks means more time to think in combat, less hack and slash, more strategy, and less CPU overhead too. > I > don't think we should mess with the amount of hp > clients or monsters get nor the weap attributes. I want to get rid of reflect spells and reflect arrows as abilities, I think they too effectively nerf lightning spells, and make cone spells to useful. However I would like to have a 'recast' spell, which would cast a copy of any spell that hits a player in the opposite direction for a short period of time (couple of seconds). From mwedel at sonic.net Thu Feb 2 00:46:49 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 01 Feb 2006 22:46:49 -0800 Subject: [crossfire] Transports In-Reply-To: References: <43DF1D3B.2000302@sonic.net> <43E058C1.6040202@sonic.net> <43E1467F.6020603@telus.net> <7903f03c0602011549t50e1d95eha4020f2f47378f60@mail.gmail.com> Message-ID: <43E1AAD9.5030306@sonic.net> > > Also, how about setting up shipping routes and roads by placing > directors for transport on them? Is the point here to have boats automatically sail from point A to B, or to give players a clue? If the idea is to give players a clue, I think some other things could be more useful - buoys to mark routes, light houses to mark points, etc. From mwedel at sonic.net Thu Feb 2 00:55:34 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 01 Feb 2006 22:55:34 -0800 Subject: [crossfire] Transports In-Reply-To: References: <43DF1D3B.2000302@sonic.net> <43E058C1.6040202@sonic.net> Message-ID: <43E1ACE6.1080709@sonic.net> Lalo Martins wrote: > Which leads to another idea - some transports could be set up to behave > as pets when unpiloted (behave as pets, not count as pets - killpets > shouldn't kill them), so that you have 2 horses, you put your stuff on > one, mount the other, and the "cargo" horse follows you. If on another > adventure you have an ally, he can borrow your second horse and mount it > normally. Probably wouldn't be too hard, but there may be some issues as related to the object actually moving and not (the object would have to have speed). But you also perhaps get odd issues - I shouldn't be able to load the horse to the max so I don't carry anything, and then run home and have that horse 'teleport' like pets do to keep up my pace. If I run away, that horse should just stop moving. The problem here is the map transitions - for example, if I'm returning to scorn, my horse should follow me into the gatehouse if nearby. But if he is 10 maps away, he shouldn't. The problem right now I think is that the pets don't catch up until they move. So what happens, players moves onto gatehouse, the pet moves, but it has no real clue how close/far it was from the player. This could perhaps get fixed by adding some special code for when the player changes map to also moves the pets at that moment. From mwedel at sonic.net Thu Feb 2 01:16:07 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 01 Feb 2006 23:16:07 -0800 Subject: [crossfire] cfclient colouring In-Reply-To: <7903f03c0602010317hfecce57hf21494eec30d44fa@mail.gmail.com> References: <7903f03c0601301849n395753er7cbc61623ff0df36@mail.gmail.com> <43DF0803.4060203@sonic.net> <7903f03c0601310631n31fcaf8bl5f61678ae181283f@mail.gmail.com> <43E059C5.6070900@sonic.net> <7903f03c0602010317hfecce57hf21494eec30d44fa@mail.gmail.com> Message-ID: <43E1B1B7.7030201@sonic.net> Brendan Lally wrote: > On 2/1/06, Mark Wedel wrote: >> Brendan Lally wrote: >> actually, I don't think there is anything specific about using 16 colors. I >> think it was just that 16 colors were used - it could very well be 12 or 25 - as >> far as X is concerned, it doesn't care (unless someone only had 4 bit color, but >> I don't know if such hardware ever existed). > > ega cards on (very) old IBM PCs support only 16 displayable colours, I > don't know if they can run X though. - in any case their resolution > probably wouldn't be enough to show the entire screen. And they'd have the same issue with all the graphics themselves - I can't imagine that the existing graphics reduced to 16 colors would look very good. > >> Private colormap is a leftover from 8 bit display - most 8 bit hardware could >> only display 256 different colors at a time, but out of the palette of 16 >> million (24 bit color). So one would use colormaps to determine what colors of >> the palette your are drawing. > > Is that why I have seen colours shift with application focus on very > old sparc systems running X? Yep. Since only 256 colors could be displayed at a time, if you want best image selection, you'd allocate a private colormap so one could get all 256 colors for their own application and not share those with other applications. From lalo.martins at gmail.com Thu Feb 2 01:17:57 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Thu, 02 Feb 2006 15:17:57 +0800 Subject: [crossfire] Bigworld-ized pupland status? In-Reply-To: <20060201173834.37985.qmail@web32708.mail.mud.yahoo.com> References: <20060201173834.37985.qmail@web32708.mail.mud.yahoo.com> Message-ID: And so says Miguel Ghobangieno on 02/02/06 01:38... > What's the status on bigworldized pupland (IE: when is > it going in?). /me awaits the glorious addittion. Snapshot is up at http://lalo.revisioncontrol.net/crossfire/ Next in the TODO list: - Re-do the Nurnberg castle, it's so out of scale it's ugly - Paste the contents of Lone Town - Add exits to the army camp, weapon research lab, tower of ordail, barbarian ruins - Add the freedom army's clandestine port - Fix all exits in /pup_land (isn't there a script to do this?) - Release/merge - Do the Rainbow Islands - Release/merge - Work on other quests on the continent best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Thu Feb 2 01:34:09 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 01 Feb 2006 23:34:09 -0800 Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <7903f03c0602011708s62d29dddg2ad220b5f09c1795@mail.gmail.com> References: <7903f03c0601311533v1d9c54ebn5448d0ea0aba7025@mail.gmail.com> <20060201174352.77864.qmail@web32706.mail.mud.yahoo.com> <7903f03c0602011708s62d29dddg2ad220b5f09c1795@mail.gmail.com> Message-ID: <43E1B5F1.2080605@sonic.net> Brendan Lally wrote: > On 2/1/06, Miguel Ghobangieno wrote: >> And a setting to show (by default) 1 attack message >> per second or so (rather then "char punches once, and >> again, and SUPRISE again!"). > > I want the rate of attacks to be down to about one (or two at most) a > second - at least for 'normal' weapons (like broadswords). Try > swinging a sword more than twice a second consistantly, and then you > will see why I think this a reasonable limit (yes, you can do more > with a fencing sword like a foil or epee, but they don't do much > damage anyway, if someone wants to add them with stupidly high weapon > speeds, they could still do so). - having fewer attacks means more > time to think in combat, less hack and slash, more strategy, and less > CPU overhead too. The counter of course is that crossfire doesn't mimic real time - IIRC, time in the crossfire world is 8-10 times faster than real-time. That said, I wholeheartedly agree that crossfire is too fast, so should be slowed down. Slowing it down would have another effect, that being that it would take longer to kill stuff, and thus money would be accumulated slower (As well as exp, and/or alternate ways of exp become more valuable). But if physical attacks are slowed downs, spells also have to be moderated in some way. And that can start to get trickier if the player has multiple wands/etc. That said, if the smooth movement stuff is a high priority item, I'd think that would completely redo movement and actions, and that could be the time to fix it then. From antonoussik at gmail.com Thu Feb 2 05:55:25 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Thu, 2 Feb 2006 11:55:25 +0000 Subject: [crossfire] Transports In-Reply-To: <43E1AAD9.5030306@sonic.net> References: <43DF1D3B.2000302@sonic.net> <43E058C1.6040202@sonic.net> <43E1467F.6020603@telus.net> <7903f03c0602011549t50e1d95eha4020f2f47378f60@mail.gmail.com> <43E1AAD9.5030306@sonic.net> Message-ID: On 02/02/06, Mark Wedel wrote: > > > > > Also, how about setting up shipping routes and roads by placing > > directors for transport on them? > > Is the point here to have boats automatically sail from point A to B, or to > give players a clue? Have boats/carts/horses sail automatically between crossings of routes or roads when on a road. There would need to be routes going in different directions, and sea routes would probably not be optimal (so a person doing it manually could get there faster). From antonoussik at gmail.com Thu Feb 2 06:13:35 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Thu, 2 Feb 2006 12:13:35 +0000 Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <43E1B5F1.2080605@sonic.net> References: <7903f03c0601311533v1d9c54ebn5448d0ea0aba7025@mail.gmail.com> <20060201174352.77864.qmail@web32706.mail.mud.yahoo.com> <7903f03c0602011708s62d29dddg2ad220b5f09c1795@mail.gmail.com> <43E1B5F1.2080605@sonic.net> Message-ID: On 02/02/06, Mark Wedel wrote: > That said, if the smooth movement stuff is a high priority item, I'd think > that would completely redo movement and actions, and that could be the time to > fix it then. I would say that a smooth moving slowed down crossfire where it takes time to kill things (with health bars over monsters, etc.) is a good general direction for the project. However the CrossFire of today seems quite different from that. I have very little understanding of the movement/map code, but I would guess changing that would be very close to a re-write. From mikeeusaa at yahoo.com Wed Feb 1 20:59:27 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Wed, 1 Feb 2006 18:59:27 -0800 (PST) Subject: [crossfire] Transports In-Reply-To: Message-ID: <20060202025927.81801.qmail@web32709.mail.mud.yahoo.com> Sea battles shouldn't go to a pocket reality, they should duke it out on bigworld seas and only if they get right next to eachother should the "inside" map(s (multiple levels on big ships)) of the other ship be tiled to the 1st ships maps. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mikeeusaa at yahoo.com Wed Feb 1 21:02:46 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Wed, 1 Feb 2006 19:02:46 -0800 (PST) Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <7903f03c0602011708s62d29dddg2ad220b5f09c1795@mail.gmail.com> Message-ID: <20060202030246.29636.qmail@web32715.mail.mud.yahoo.com> I don't want those abilities removed. Why shouldn't I beable to make a magic monster that can reflect spells or arrows that? Just remove the ability from the knights and gaurds and remove the reflecting amulet from circulation. I hate all this talk of removing everything from the game. Maybe crossfire should fork to crossfire-intact and crossfire-not-intact? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From alex_sch at telus.net Thu Feb 2 17:22:24 2006 From: alex_sch at telus.net (Alex Schultz) Date: Thu, 02 Feb 2006 16:22:24 -0700 Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <7903f03c0602011708s62d29dddg2ad220b5f09c1795@mail.gmail.com> References: <7903f03c0601311533v1d9c54ebn5448d0ea0aba7025@mail.gmail.com> <20060201174352.77864.qmail@web32706.mail.mud.yahoo.com> <7903f03c0602011708s62d29dddg2ad220b5f09c1795@mail.gmail.com> Message-ID: <43E29430.7000500@telus.net> Brendan Lally wrote: >think they too effectively nerf lightning spells, and make cone spells >to useful. > Instead, perhaps make it so it only has a chance of reflecting, and perhaps make the change with level of the attacking spell. Perhaps also allow different levels of reflectivity >However I would like to have a 'recast' spell, which would >cast a copy of any spell that hits a player in the opposite direction >for a short period of time (couple of seconds). > Ooh, neat idea. Alex Schultz From nicolas.weeger at laposte.net Thu Feb 2 17:41:27 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 03 Feb 2006 00:41:27 +0100 Subject: [crossfire] crossfire traffic In-Reply-To: <7903f03c0601310751w66491ebtd011ac1f45a3112a@mail.gmail.com> References: <7903f03c0601310751w66491ebtd011ac1f45a3112a@mail.gmail.com> Message-ID: <43E298A7.7000501@laposte.net> Hello. Really nice idea, it'll help me for the Windows snapshots :) Nicolas From mwedel at sonic.net Fri Feb 3 00:44:51 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 02 Feb 2006 22:44:51 -0800 Subject: [crossfire] Transports In-Reply-To: References: <43DF1D3B.2000302@sonic.net> <43E058C1.6040202@sonic.net> <43E1467F.6020603@telus.net> <7903f03c0602011549t50e1d95eha4020f2f47378f60@mail.gmail.com> <43E1AAD9.5030306@sonic.net> Message-ID: <43E2FBE3.8030604@sonic.net> Anton Oussik wrote: > On 02/02/06, Mark Wedel wrote: >>> Also, how about setting up shipping routes and roads by placing >>> directors for transport on them? >> Is the point here to have boats automatically sail from point A to B, or to >> give players a clue? > > Have boats/carts/horses sail automatically between crossings of routes > or roads when on a road. There would need to be routes going in > different directions, and sea routes would probably not be optimal (so > a person doing it manually could get there faster). Well, we don't currently have that code. The idea of using movers never appeals to me that much. I'd think this would be better done by scripting. Instead of having to put movers all over the place, a script with some basic waypoints could be done (move to x1,y1. Then move to x2,y2, etc) For most routes, you'd probably only need half a dozen or so waypoints (the script in question would just go in straight lines). A script also has the advantage it could have some basic logic to try to get around obstacles. If you just use movers, all it takes is one player to park something along the line of movers and you would get all the transports piling up. From mikeeusaa at yahoo.com Fri Feb 3 08:06:39 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Fri, 3 Feb 2006 06:06:39 -0800 (PST) Subject: [crossfire] Transports In-Reply-To: <43E2FBE3.8030604@sonic.net> Message-ID: <20060203140639.45695.qmail@web32709.mail.mud.yahoo.com> I like the way point + logic in a script idea. --- Mark Wedel wrote: > Anton Oussik wrote: > > On 02/02/06, Mark Wedel wrote: > >>> Also, how about setting up shipping routes and > roads by placing > >>> directors for transport on them? > >> Is the point here to have boats automatically > sail from point A to B, or to > >> give players a clue? > > > > Have boats/carts/horses sail automatically between > crossings of routes > > or roads when on a road. There would need to be > routes going in > > different directions, and sea routes would > probably not be optimal (so > > a person doing it manually could get there > faster). > > Well, we don't currently have that code. > > The idea of using movers never appeals to me that > much. > > I'd think this would be better done by scripting. > Instead of having to put > movers all over the place, a script with some basic > waypoints could be done > (move to x1,y1. Then move to x2,y2, etc) For most > routes, you'd probably only > need half a dozen or so waypoints (the script in > question would just go in > straight lines). A script also has the advantage it > could have some basic logic > to try to get around obstacles. > > If you just use movers, all it takes is one player > to park something along the > line of movers and you would get all the transports > piling up. > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From brenlally at gmail.com Fri Feb 3 12:30:01 2006 From: brenlally at gmail.com (Brendan Lally) Date: Fri, 3 Feb 2006 18:30:01 +0000 Subject: [crossfire] gcfclient info window text trimming crash. Message-ID: <7903f03c0602031030q1f0921eeq9f73064b8512fd17@mail.gmail.com> gcfclient can be made to crash reliably with the "Trims text in the information window" option set when compiled against 1.2.10. This was reported on #crossfire, and I have been able to reproduce it reliably (grab lots of items, and repeatedly pickup and drop them). Since this appears to be a GTK bug, which is presumably not present under gtk2, I therefore suggest that the patch which is connected to bug #1423605 - https://sourceforge.net/tracker/index.php?func=detail&aid=1423605&group_id=13833&atid=113833 as a work around. Basically I am adding #if GTK_MAJOR_VERSION > 1 ... #endif around the trimming code. (although there are also a couple of minor cleanups too). The reason I am posting this here, is to ask if there is a better way to do this (it works fine for me running gtk 1.2, but does it break windows builds)? Presumably 2.0 will compile gcfclient against gtk2, so there will be no further issue with this; however since this doesn't seem likely to be the case with 1.9 some way to stop it crashing seems to be in order. From fuchs.andy at gmail.com Fri Feb 3 14:36:19 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Fri, 3 Feb 2006 15:36:19 -0500 Subject: [crossfire] Transport, monster, player sizes Message-ID: On the topic of transports, and if they should be let through some exits, i think it would be a good idea to use a "size" field, in the exit, and object to be moved. This seems to have more advantages, and more ease of matinance than using a list of arches/races to exclude from using the exit. -- Andrew Fuchs From lalo.martins at gmail.com Sat Feb 4 00:10:55 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Sat, 04 Feb 2006 14:10:55 +0800 Subject: [crossfire] movement code feature request Message-ID: I'm using hidden movers to restrict monster movement on my continent. Bit it feels slightly hackish - as it paralises monsters, it makes them just so slightly easier to kill. I was thinking about the new movement code and I figured - maybe we could have a flag that makes a cell block monsters but not players, independent of movement type? That could then be used for marking monsters' "territory". best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Sat Feb 4 01:42:19 2006 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 03 Feb 2006 23:42:19 -0800 Subject: [crossfire] movement code feature request In-Reply-To: References: Message-ID: <43E45ADB.50903@sonic.net> Lalo Martins wrote: > I'm using hidden movers to restrict monster movement on my continent. > Bit it feels slightly hackish - as it paralises monsters, it makes them > just so slightly easier to kill. > > I was thinking about the new movement code and I figured - maybe we > could have a flag that makes a cell block monsters but not players, > independent of movement type? That could then be used for marking > monsters' "territory". Yes - that would work I believe (or if it doesn't, there is a bug). That said, there is no 'spare' movement types right now, but it is just an int, but a high enough value that doesn't conflict with anything else would work (it may make sense to allocate some bits of the mask for custom restrictions). That said, it probably still makes monsters easier to kill - if a player sits on the other side of that invisible barrier, they can just pick off the monsters with spells or arrows or the like. From mwedel at sonic.net Sat Feb 4 02:20:33 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 04 Feb 2006 00:20:33 -0800 Subject: [crossfire] gcfclient info window text trimming crash. In-Reply-To: <7903f03c0602031030q1f0921eeq9f73064b8512fd17@mail.gmail.com> References: <7903f03c0602031030q1f0921eeq9f73064b8512fd17@mail.gmail.com> Message-ID: <43E463D1.90405@sonic.net> Brendan Lally wrote: > gcfclient can be made to crash reliably with the "Trims text in the > information window" option set when compiled against 1.2.10. > > This was reported on #crossfire, and I have been able to reproduce it > reliably (grab lots of items, and repeatedly pickup and drop them). > > Since this appears to be a GTK bug, which is presumably not present > under gtk2, I therefore suggest that the patch which is connected to > bug #1423605 - https://sourceforge.net/tracker/index.php?func=detail&aid=1423605&group_id=13833&atid=113833 > as a work around. > > Basically I am adding > #if GTK_MAJOR_VERSION > 1 > ... > #endif > around the trimming code. (although there are also a couple of minor > cleanups too). > > The reason I am posting this here, is to ask if there is a better way > to do this (it works fine for me running gtk 1.2, but does it break > windows builds)? It is a little unclear what exactly the GTK_MAJOR_VERSION check is around. Does this mean that info trimming is completely disabled with version 1 of gtk? If so, I'd sort of say, what is the point - that is why there is a config option. Although, I suppose if that is the case, there isn't a big reason for a config option. > > Presumably 2.0 will compile gcfclient against gtk2, so there will be > no further issue with this; however since this doesn't seem likely to > be the case with 1.9 some way to stop it crashing seems to be in > order. Are you sure version 2.0+ of GTK fixes the problem? IIRC when doing the gtk2 client, there is a new widget for text stuff for gtk2, and the gtk2 docs specifically say don't use the old widget if at all possibly because it is severely broken. That said, it could be that that option get removed from the config page - if people want to muck with their config file, fair enough, but they are doing that at their own risk. IIRC, the config page specifically says it may cause crashes if you use that option. From mwedel at sonic.net Sat Feb 4 03:13:54 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 04 Feb 2006 01:13:54 -0800 Subject: [crossfire] crossfire 2.0, smooth movement, thoughts. Message-ID: <43E47052.6090100@sonic.net> In various 2.0 discussions, the idea of smooth movement has been brought up. Thinking about that, I wonder if it is better to aim for 3.0 for that. redoing it for smooth movement requires IMO a lot of code changes, and if we shoot for that in 2.0, I think 2.0 will be a long ways off. I think it also needs to be worked out a lot more. I have some thoughts on how to do it, but it needs to be worked out a lot more. For example, I was originally thinking that it could only pertain to players and perhaps monsters. But that doesn't work really wall - arrows should also move smoothly, and you should be able to roll boulders smoothly, or else it looks really weird. Underlying, I was thinking the idea of mapspace remains the same - at some level, you need some method to get to objects nearby. And splitting all the spaces into smaller spaces may not help - if you have to examine 200 spaces that the player is near for objects, that probably isn't an improvement. So my general though would be each object would have an offset within the space - presuming we want to match pixel offsets to position, it would be that each object would have an x and y offset for -15 to +15 - if the offset is more than that (say 16), it would move to the next space at a -15 offset. But what this does mean is that in many cases, you need to look at 4 spaces for objects/monsters (for example, if the player is at 15,15 offset, then objects on the neighboring space might be close enough to pick up). Likewise, movement for players get complicated. But the question also about how fine to reduce movement comes in. If we come into refining things to single pixel movement, we are talking about a 250 FPS redraw rate for the client, or about 4 ms to redraw the image. I don't think any of the clients on current hardware are capable at that rate (ignoring graphic performance, have to take into account the other things the client does). From mwedel at sonic.net Sat Feb 4 03:17:03 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 04 Feb 2006 01:17:03 -0800 Subject: [crossfire] gtkv2 client vs gtk client gap list. Message-ID: <43E4710F.8080402@sonic.net> Briefly discussed on irc, but also related to other discussions, is perhaps what client(s) to use going forward. To me, at some level, keeping the gtk(v1) client about may not make a lot of sense. Especially if we start going down the path of new character creation and other widgets - I don't look forward to trying to write those for the gtkv1 client. I know a lot of people still use the gtkv1 client. So my basic question is, for those of you that do, what needs to be changed/added/fixed in the gtkv2 client so you would use it. And anyone still using the old X11 client, same question. From yann.chachkoff at myrealbox.com Sat Feb 4 04:08:03 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sat, 04 Feb 2006 11:08:03 +0100 Subject: [crossfire] gtkv2 client vs gtk client gap list. Message-ID: <1139047683.c804a85cyann.chachkoff@myrealbox.com> > Briefly discussed on irc, but also related to other discussions, is perhaps what client(s) to use going forward. > To me, at some level, keeping the gtk(v1) client about may not make a lot of sense. I'm not sure about that, at least not on the short term. The gtkv2 is far from complete IMHO. On the longer term, it is probably correct that the gtkv1 would get superceded at some point, though. > Especially if we start going down the path of new character creation and other widgets - I don't look forward to trying to write those for the gtkv1 client. > I know a lot of people still use the gtkv1 client. Well, I think it is actually more accurate to say that it is the most used one :). > So my basic question is, for those of you that do, what needs to be changed/added/fixed in the gtkv2 client so you would use it. My most important complain is already well known: gtkv2 requires a 1280x1024 screen resolution, which is not available (or comfortable) on many screens. The resolution currently considered as standard is 1024x768 (a lot of laptops are limited to it, while a lot of 17''CRT monitors can only display 1280x1024 at rather low frequencies). Although I understand that people that got bigger screens would want a client best suited for them, let's not forget all those who cannot properly display such a big client: they'll have no other choice but quit playing, or deal with ugly things like virtual scrolling. I think that the problem comes down to the impossibility to reconfigure the client interface to suit your needs - not everybody needs/wants a 25x25 map display, for example; others may want to get bigger tiles instead of getting more. Before scrapping gtkv1, I think that the v2 must provide the same level of display configuration. From brenlally at gmail.com Sat Feb 4 09:37:38 2006 From: brenlally at gmail.com (Brendan Lally) Date: Sat, 4 Feb 2006 15:37:38 +0000 Subject: [crossfire] gtkv2 client vs gtk client gap list. In-Reply-To: <43E4710F.8080402@sonic.net> References: <43E4710F.8080402@sonic.net> Message-ID: <7903f03c0602040737t32240408k675dc449006454d9@mail.gmail.com> On 2/4/06, Mark Wedel wrote: > To me, at some level, keeping the gtk(v1) client about may not make a lot of > sense. Especially if we start going down the path of new character creation and > other widgets - I don't look forward to trying to write those for the gtkv1 client. I'd note at this point that the recent spell interface updates I did were for gcfclient not gcfclient2 - I find glade complex and confusing, gtk code is comparatively straightforward to write, at least for maintenance. > I know a lot of people still use the gtkv1 client. So my basic question is, > for those of you that do, what needs to be changed/added/fixed in the gtkv2 > client so you would use it. I'm not sure that is necessary, not so long ago there was a patch to gcfclient to make it compile against gtk2, I will assume that this gets accepted in the move towards 2.0, with the few bugs it isolates picked up on the way. If cfclient is removed, (and the broken gnome client also), then there would only be one toolkit in use. It would then be possible to restructure the client directories to have common/ gtk_common/ gtk-v1/ and gtk-v2/ mapping to: protocol parsing and storage, toolkit specific code, and interface respectively. These parts individually would not be so hard to maintain. From mwedel at sonic.net Sat Feb 4 21:24:25 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 04 Feb 2006 19:24:25 -0800 Subject: [crossfire] gtkv2 client vs gtk client gap list. In-Reply-To: <1139047683.c804a85cyann.chachkoff@myrealbox.com> References: <1139047683.c804a85cyann.chachkoff@myrealbox.com> Message-ID: <43E56FE9.5080704@sonic.net> Yann Chachkoff wrote: >> Briefly discussed on irc, but also related to other discussions, is perhaps >> what client(s) to use going forward. To me, at some level, keeping the >> gtk(v1) client about may not make a lot of sense. > > I'm not sure about that, at least not on the short term. The gtkv2 is far > from complete IMHO. On the longer term, it is probably correct that the gtkv1 > would get superceded at some point, though. But what at the main features that are missing? IMO, there is a lot of stuff in gtkv1 client that I'm not sure people use. One being the keybinding interface - do people use that very much, or do people just use command line. It doesn't make sense to add features that no one needs. > >> Especially if we start going down the path of new character creation and >> other widgets - I don't look forward to trying to write those for the gtkv1 >> client. > >> I know a lot of people still use the gtkv1 client. > > Well, I think it is actually more accurate to say that it is the most used > one :). Yes, numbers back you up - from metalforge: GTK Unix Client 6 GTK Unix Client 1.5.0 3 GTK Unix Client 1.7.0 1 GTK Unix Client 1.7.1 7 GTK Unix Client 1.8.0 22 GTK Win32 Client 1.7.0 1 GTK Win32 Client 1.7.1 2 GTK Win32 Client 1.8.0 7 GTK Win32 Client 1.8.0 snapshot 19 GTK2 Unix Client 1.8.0 6 Perl Bot 1 X11 Unix Client 4 X11 Unix Client 1.7.0 2 X11 Unix Client 1.8.0 11 These numbers are correlated with client and ip address - this likely isn't 100% accurate (there is a delay between the client connecting and player logging in, thus getting IP address), but probably gives an OK estimate. The number could also be skewed - people playing that connect via DHCP will be counted numerous times, compared to those on static IPs. > My most important complain is already well known: gtkv2 requires a 1280x1024 > screen resolution, which is not available (or comfortable) on many screens. > The resolution currently considered as standard is 1024x768 (a lot of laptops > are limited to it, while a lot of 17''CRT monitors can only display 1280x1024 > at rather low frequencies). Although I understand that people that got bigger > screens would want a client best suited for them, let's not forget all those > who cannot properly display such a big client: they'll have no other choice > but quit playing, or deal with ugly things like virtual scrolling. > > I think that the problem comes down to the impossibility to reconfigure the > client interface to suit your needs - not everybody needs/wants a 25x25 map > display, for example; others may want to get bigger tiles instead of getting > more. Before scrapping gtkv1, I think that the v2 must provide the same level > of display configuration. I'll look into this. Note it really comes down to the map display area - if the map area is made say ~550x550 pixels (instead of the 800x800 right now), that you could either get 17x17 display with full sized images, or 25x25 with images resized to be 22x22, or something in between. From mwedel at sonic.net Sat Feb 4 21:36:05 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 04 Feb 2006 19:36:05 -0800 Subject: [crossfire] gtkv2 client vs gtk client gap list. In-Reply-To: <7903f03c0602040737t32240408k675dc449006454d9@mail.gmail.com> References: <43E4710F.8080402@sonic.net> <7903f03c0602040737t32240408k675dc449006454d9@mail.gmail.com> Message-ID: <43E572A5.9060809@sonic.net> Brendan Lally wrote: > On 2/4/06, Mark Wedel wrote: >> To me, at some level, keeping the gtk(v1) client about may not make a lot of >> sense. Especially if we start going down the path of new character creation and >> other widgets - I don't look forward to trying to write those for the gtkv1 client. > > I'd note at this point that the recent spell interface updates I did > were for gcfclient not gcfclient2 - I find glade complex and > confusing, gtk code is comparatively straightforward to write, at > least for maintenance. And that is sort of the point - if/when more stuff is moved to the client, having to update multiple clients become more a burden. As long as we have peopel willing to keep updating all the clients, not as much a problem. Presuming of course those people stick around and are relatively responsive to making needed changes in a timely fashion. > >> I know a lot of people still use the gtkv1 client. So my basic question is, >> for those of you that do, what needs to be changed/added/fixed in the gtkv2 >> client so you would use it. > > I'm not sure that is necessary, not so long ago there was a patch to > gcfclient to make it compile against gtk2, I will assume that this > gets accepted in the move towards 2.0, with the few bugs it isolates > picked up on the way. I do wonder if at some point, gtk itself may drop support for the stuff from gtk1 they obsoleted. For example, if gtk3 is released, they may very well say 'gtk1 code is going away - we kept and entire released version, but we don't want it anymore'. I'd imagine that may be years away (and gtkv2 may continue to be commonly available on distributions for a while even after gtk3 is released), but a random thought. Note that I have no indication that this is actually going to happen, but I imagine at some point, the gtk1 stuff that they stopped supporting will go away. > > If cfclient is removed, (and the broken gnome client also), then there > would only be one toolkit in use. It would then be possible to > restructure the client directories to have common/ gtk_common/ gtk-v1/ > and gtk-v2/ mapping to: > protocol parsing and storage, toolkit specific code, and interface respectively. Maybe - I'm not 100% sure how big gtk-common would be. But this goes back to the original question, which is why keep the gtk-v1 client. If the gtkv2 client has all the same features, is there a reason to keep the gtk-v1 client (this is driven people using it, but then perhaps the question is why are people using it over gtkv2). If it is a matter of layout (I like the layout of gtk1 better), I wonder how hard it would be to do a 'gtk API' type of thing - take a glade config file, and say 'these are the callbacks you use' - one could whip up a new layout pretty darn quickly. IIRC, I did the entire layout of the gtkv2 client in glade in a single evening - it was the back end portion that was harder, and in some cases, because of the difference in gtk 1 and 2. IIRC, to be 100% gtk2, the text windows (messages) and the lists (inventory, look) use new widgets. If you take those pieces out, what is then left as common is the map (which does share code to a good extent right now), and the stat/resistances windows (which are pretty trivial). But what that does mean is that any change to inventory handling (say new attribute to display) would be separate code for the clients. Likewise, any changes to message handling couldn't share code. The map portion could share code, and I'd bet to some extent, right now, could pretty easily do so (in both cases, it is just going directly to a drawable, and in the case of the opengl and SDL drawing modes, doesn't even use GTK - gtk just provides the window, nothing else). From brenlally at gmail.com Sat Feb 4 21:50:56 2006 From: brenlally at gmail.com (Brendan Lally) Date: Sun, 5 Feb 2006 03:50:56 +0000 Subject: [crossfire] gtkv2 client vs gtk client gap list. In-Reply-To: <43E56FE9.5080704@sonic.net> References: <1139047683.c804a85cyann.chachkoff@myrealbox.com> <43E56FE9.5080704@sonic.net> Message-ID: <7903f03c0602041950u4f10d75fm7bebb6d651840abb@mail.gmail.com> On 2/5/06, Mark Wedel wrote: > But what at the main features that are missing? IMO, there is a lot of stuff > in gtkv1 client that I'm not sure people use. One being the keybinding > interface - do people use that very much, or do people just use command line. > It doesn't make sense to add features that no one needs. I use the keybinding interface on the occasions I run gcfclient. From brenlally at gmail.com Sat Feb 4 21:58:34 2006 From: brenlally at gmail.com (Brendan Lally) Date: Sun, 5 Feb 2006 03:58:34 +0000 Subject: [crossfire] gtkv2 client vs gtk client gap list. In-Reply-To: <43E572A5.9060809@sonic.net> References: <43E4710F.8080402@sonic.net> <7903f03c0602040737t32240408k675dc449006454d9@mail.gmail.com> <43E572A5.9060809@sonic.net> Message-ID: <7903f03c0602041958v6b947aeelacaf973356ea3922@mail.gmail.com> On 2/5/06, Mark Wedel wrote: > > I'm not sure that is necessary, not so long ago there was a patch to > > gcfclient to make it compile against gtk2, I will assume that this > > gets accepted in the move towards 2.0, with the few bugs it isolates > > picked up on the way. > > I do wonder if at some point, gtk itself may drop support for the stuff from > gtk1 they obsoleted. For example, if gtk3 is released, they may very well say > 'gtk1 code is going away - we kept and entire released version, but we don't > want it anymore'. I'd imagine that may be years away (and gtkv2 may continue to > be commonly available on distributions for a while even after gtk3 is released), > but a random thought. Note that I have no indication that this is actually > going to happen, but I imagine at some point, the gtk1 stuff that they stopped > supporting will go away. But long before that time, gcfclient can have been compiled against gtk2, and it can use a lot of the code from gcfclient2 to replace deprecated stuff. > Maybe - I'm not 100% sure how big gtk-common would be. But this goes back to > the original question, which is why keep the gtk-v1 client. If the gtkv2 client > has all the same features, is there a reason to keep the gtk-v1 client (this is > driven people using it, but then perhaps the question is why are people using it > over gtkv2). > > If it is a matter of layout (I like the layout of gtk1 better), I wonder how > hard it would be to do a 'gtk API' type of thing - take a glade config file, and > say 'these are the callbacks you use' - one could whip up a new layout pretty > darn quickly. That's pretty much the reasoning behind a gtk-common/ however, I'd rather have at least one client done manually, since glade is fairly complicated. > IIRC, I did the entire layout of the gtkv2 client in glade in a single evening > - it was the back end portion that was harder, and in some cases, because of the > difference in gtk 1 and 2. > IIRC, to be 100% gtk2, the text windows (messages) and the lists (inventory, > look) use new widgets. If you take those pieces out, what is then left as > common is the map (which does share code to a good extent right now), and the > stat/resistances windows (which are pretty trivial). If we assume that gcfclient is in future compiled against gtk2 by default then the inventory and text code could be taken directly from gcfclient2, given that they operate almost identically anyway. From lalo.martins at gmail.com Sat Feb 4 23:07:44 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Sun, 05 Feb 2006 13:07:44 +0800 Subject: [crossfire] gtkv2 client vs gtk client gap list. In-Reply-To: <43E56FE9.5080704@sonic.net> References: <1139047683.c804a85cyann.chachkoff@myrealbox.com> <43E56FE9.5080704@sonic.net> Message-ID: And so says Mark Wedel on 05/02/06 11:24... > But what at the main features that are missing? IMO, there is a lot of stuff > in gtkv1 client that I'm not sure people use. One being the keybinding > interface - do people use that very much, or do people just use command line. > It doesn't make sense to add features that no one needs. Sometimes I'll bind from the command line, specially if I'm in a hurry or I'm just pasting a binding (eg for a pickup mode or a spell I just learned). But usually I bind from the GUI, and I *always* unbind and edit bindings from the GUI. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From brenlally at gmail.com Sun Feb 5 11:02:07 2006 From: brenlally at gmail.com (Brendan Lally) Date: Sun, 5 Feb 2006 17:02:07 +0000 Subject: [crossfire] gcfclient info window text trimming crash. In-Reply-To: <43E463D1.90405@sonic.net> References: <7903f03c0602031030q1f0921eeq9f73064b8512fd17@mail.gmail.com> <43E463D1.90405@sonic.net> Message-ID: <7903f03c0602050902q53133ebdtdccbbd85e69724c4@mail.gmail.com> On 2/4/06, Mark Wedel wrote: > Does this mean that info trimming is completely disabled with version 1 of > gtk? If so, I'd sort of say, what is the point - that is why there is a config > option. Yes, but the config option causes crashes, and if that is the case, it shouldn't be an option when that will occur. > Are you sure version 2.0+ of GTK fixes the problem? IIRC when doing the gtk2 > client, there is a new widget for text stuff for gtk2, and the gtk2 docs > specifically say don't use the old widget if at all possibly because it is > severely broken. Trimming works when the client is compiled against gtk2 using maligor's patch found at: http://bluemist.ath.cx/~maligor/cf-gtk2.patch > That said, it could be that that option get removed from the config page - if > people want to muck with their config file, fair enough, but they are doing that > at their own risk. IIRC, the config page specifically says it may cause crashes > if you use that option. This approach will show the option if it is safe to use, and remove it if it isn't. From mikeeusaa at yahoo.com Sat Feb 4 17:09:29 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sat, 4 Feb 2006 15:09:29 -0800 (PST) Subject: [crossfire] Why have you banned my CVS access, And why do you hate mlab (I just finished mlabhell and I want mlab in for 1.9) Message-ID: <20060204230929.59727.qmail@web32706.mail.mud.yahoo.com> Why have you banned my CVS access, and why do you hate mlab? I just finished mlabhell and I want mlab in for 1.9. It's better to have it in non-dirified format for 1.9 then not in at all. Also I am offended at lauwernmark and errac's plot to change mlab's culture. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mikeeusaa at yahoo.com Sat Feb 4 21:39:53 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sat, 4 Feb 2006 19:39:53 -0800 (PST) Subject: [crossfire] gtkv2 client vs gtk client gap list. In-Reply-To: <43E56FE9.5080704@sonic.net> Message-ID: <20060205033953.15284.qmail@web32703.mail.mud.yahoo.com> I use the keybinding interface very often. I imagine others do too. --- Mark Wedel wrote: > Yann Chachkoff wrote: > >> Briefly discussed on irc, but also related to > other discussions, is perhaps > >> what client(s) to use going forward. To me, at > some level, keeping the > >> gtk(v1) client about may not make a lot of sense. > > > > I'm not sure about that, at least not on the short > term. The gtkv2 is far > > from complete IMHO. On the longer term, it is > probably correct that the gtkv1 > > would get superceded at some point, though. > > But what at the main features that are missing? > IMO, there is a lot of stuff > in gtkv1 client that I'm not sure people use. One > being the keybinding > interface - do people use that very much, or do > people just use command line. > It doesn't make sense to add features that no one > needs. > > > > >> Especially if we start going down the path of new > character creation and > >> other widgets - I don't look forward to trying to > write those for the gtkv1 > >> client. > > > >> I know a lot of people still use the gtkv1 > client. > > > > Well, I think it is actually more accurate to say > that it is the most used > > one :). > > Yes, numbers back you up - from metalforge: > GTK Unix Client 6 > GTK Unix Client 1.5.0 3 > GTK Unix Client 1.7.0 1 > GTK Unix Client 1.7.1 7 > GTK Unix Client 1.8.0 22 > GTK Win32 Client 1.7.0 1 > GTK Win32 Client 1.7.1 2 > GTK Win32 Client 1.8.0 7 > GTK Win32 Client 1.8.0 snapshot 19 > GTK2 Unix Client 1.8.0 6 > Perl Bot 1 > X11 Unix Client 4 > X11 Unix Client 1.7.0 2 > X11 Unix Client 1.8.0 11 > > These numbers are correlated with client and ip > address - this likely isn't > 100% accurate (there is a delay between the client > connecting and player logging > in, thus getting IP address), but probably gives an > OK estimate. The number > could also be skewed - people playing that connect > via DHCP will be counted > numerous times, compared to those on static IPs. > > > > > My most important complain is already well known: > gtkv2 requires a 1280x1024 > > screen resolution, which is not available (or > comfortable) on many screens. > > The resolution currently considered as standard is > 1024x768 (a lot of laptops > > are limited to it, while a lot of 17''CRT monitors > can only display 1280x1024 > > at rather low frequencies). Although I understand > that people that got bigger > > screens would want a client best suited for them, > let's not forget all those > > who cannot properly display such a big client: > they'll have no other choice > > but quit playing, or deal with ugly things like > virtual scrolling. > > > > I think that the problem comes down to the > impossibility to reconfigure the > > client interface to suit your needs - not > everybody needs/wants a 25x25 map > > display, for example; others may want to get > bigger tiles instead of getting > > more. Before scrapping gtkv1, I think that the v2 > must provide the same level > > of display configuration. > > I'll look into this. Note it really comes down to > the map display area - if > the map area is made say ~550x550 pixels (instead of > the 800x800 right now), > that you could either get 17x17 display with full > sized images, or 25x25 with > images resized to be 22x22, or something in between. > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From brenlally at gmail.com Sun Feb 5 15:43:37 2006 From: brenlally at gmail.com (Brendan Lally) Date: Sun, 5 Feb 2006 21:43:37 +0000 Subject: [crossfire] Why have you banned my CVS access, And why do you hate mlab (I just finished mlabhell and I want mlab in for 1.9) In-Reply-To: <20060204230929.59727.qmail@web32706.mail.mud.yahoo.com> References: <20060204230929.59727.qmail@web32706.mail.mud.yahoo.com> Message-ID: <7903f03c0602051343v65ee2a3fy20a6b8ae6083186e@mail.gmail.com> On 2/4/06, Miguel Ghobangieno wrote: > Why have you banned my CVS access, You'd need to ask the person who banned you, but criticising other developers in a cvs commit message would probably have a lot to do with it. > and why do you hate > mlab? I do not hate mlab, I think they are some of the most interesting maps in the game. > I just finished mlabhell and I want mlab in for > 1.9. It's better to have it in non-dirified format for > 1.9 then not in at all. That's a point of contention. > Also I am offended at lauwernmark and errac's plot to > change mlab's culture. To a great extent I would agree, but this does not excuse criticising them in a CVS commit message for a commit it is not clear should have been made. From mwedel at sonic.net Sun Feb 5 16:14:59 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 05 Feb 2006 14:14:59 -0800 Subject: [crossfire] Why have you banned my CVS access, And why do you hate mlab (I just finished mlabhell and I want mlab in for 1.9) In-Reply-To: <20060204230929.59727.qmail@web32706.mail.mud.yahoo.com> References: <20060204230929.59727.qmail@web32706.mail.mud.yahoo.com> Message-ID: <43E678E3.9080602@sonic.net> Miguel Ghobangieno wrote: > Why have you banned my CVS access, and why do you hate > mlab? I just finished mlabhell and I want mlab in for > 1.9. It's better to have it in non-dirified format for > 1.9 then not in at all. As per past discussions, some people would disagree with that statement. Past discussion was that mlab should get cleaned up, or certainly, not made any worse. > > Also I am offended at lauwernmark and errac's plot to > change mlab's culture. A lot of people are offended at the culture/plot line currently in mlab. I removed your CVS access for the following: 1) Using offensive language and criticizing other developers in a CVS commit message. That is not appropriate for the messages, or the right place for such comments. 2) Committing hundreds of new files into a flat directory structure when previous discussions was this is not appropriate. From yann.chachkoff at myrealbox.com Sun Feb 5 17:00:51 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Mon, 06 Feb 2006 00:00:51 +0100 Subject: [crossfire] Why have you banned my CVS access, And why do you hate mlab (I just finished mlabhell and I want mlab in for 1.9) Message-ID: <1139180451.c813ec9cyann.chachkoff@myrealbox.com> >> Also I am offended at lauwernmark and errac's plot to >> change mlab's culture. > >To a great extent I would agree, but this does not >excuse criticising >them in a CVS commit message for a commit it is not >clear should have been made. > Let's make it clear: - there is *no* "plot to change mlab's culture". All my interventions about the issues have been recorded by the IRC bot. You'll notice that I only said that any map that would promote things like slavery or xenophoby would be unacceptable in the CVS. You'll also note that I had in no way said that it was a decision that I wanted to take myself - I only expressed my personal opinion on the matter. And you'll also note that I wasn't specifically targetting mlab: I think the same for any map, regardless of its origin. - There *will* be legal issues if we are ready to accept material that promotes slavery of children, sexual discrimination or xenophoby in the game, and I'm pretty sensible to those. Since when having a concern about the possible legality of the material is a plot against a given scenario ? - Where did I say that I wanted to change the mlab's culture ? I expressed that anything *promoting* slavery of children should get scrapped. It is not the same as saying that a culture that allows slavery or that is highly sexually discriminatory should get removed from the game ! Now, if you agree with Mike to say that actively promoting things like xenophoby, child sex-slaves or revisionism in Crossfire is acceptable and that it offends you that I'm against it, then it probably means that I indeed have nothing to do here anymore. It also probably means that Mike didn't deserve getting banned, because, after all, he just insulted people on a public mailing list and spread lies - which looks definitely a minor point when compared to all what we should be ready to accept. Now, I'd like not to have to defend myself against false attacks in the future, or see others draw conclusions without even getting facts first. Maybe public lapidation is considered as common behavior in your culture, but it isn't in mine, so I hope you'll have the decency to respect at least that. Yours, From eracclists at bellsouth.net Sun Feb 5 17:32:53 2006 From: eracclists at bellsouth.net (ERACC) Date: Sun, 5 Feb 2006 17:32:53 -0600 Subject: [crossfire] Why have you banned my CVS access, And why do you hate mlab (I just finished mlabhell and I want mlab in for 1.9) In-Reply-To: <7903f03c0602051343v65ee2a3fy20a6b8ae6083186e@mail.gmail.com> References: <20060204230929.59727.qmail@web32706.mail.mud.yahoo.com> <7903f03c0602051343v65ee2a3fy20a6b8ae6083186e@mail.gmail.com> Message-ID: <200602051732.54908.eracclists@bellsouth.net> On Sunday 05 February 2006 03:43 pm Brendan Lally wrote: [...] > > Also I am offended at lauwernmark and errac's plot to > > change mlab's culture. > > To a great extent I would agree, but this does not excuse criticising > them in a CVS commit message for a commit it is not clear should have > been made. There is no "plot", fellows. Basically this is an overreaction to an IRC discussion. Since the entity known as "mikeeusa" is banned from the IRC channel in any guise this raises the question as to how "mikeeusa" was in the loop to even know about this. There was nothing said that would not be said if "mikeeusa" were in the IRC channel but even so one wonders how "mikeeusa" was informed. Regardless, the quote from IRC is: Speaking of mikeeee. Katia mentioned on private DM messages for metalforge that mikeeee said he had maps in the game in CVS that are anti-woman and one place where one gets a reward of a 14 year old girl in his maps. Anyone else know about this? eracc: I think that if such a thing is in CVS, then it needs to be corrected - and the offender banned. That's pretty much the kind of insulting stuff that's disgusting me Which does not even hint at a "plot to change mlab's culture". It is speculative discussion as to what may or may not be in "mlab" and whether or not it is appropriate for the game. In the opinion of myself and lauwenmark (likely others as well) such things are /not/ appropriate and should not be included in crossfire. I log the IRC channel for OP reasons and can provide context for anyone (not banned from the channel) who wants to see more of the conversation. Gene Alexander (aka eracc) -- Mandriva Linux release 2006.0 (Official) for i586 17:16:36 up 9 days, 2:33, 10 users, load average: 0.37, 0.40, 0.27 ERA Computers & Consulting - http://www.eracc.com/ eComStation, Linux, FreeBSD, OpenServer & UnixWare resellers From alex_sch at telus.net Sun Feb 5 18:48:32 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 05 Feb 2006 17:48:32 -0700 Subject: [crossfire] gtkv2 client vs gtk client gap list. In-Reply-To: <43E56FE9.5080704@sonic.net> References: <1139047683.c804a85cyann.chachkoff@myrealbox.com> <43E56FE9.5080704@sonic.net> Message-ID: <43E69CE0.7060709@telus.net> Mark Wedel wrote: > But what at the main features that are missing? IMO, there is a lot of stuff >in gtkv1 client that I'm not sure people use. One being the keybinding >interface - do people use that very much, or do people just use command line. >It doesn't make sense to add features that no one needs > I usually use the command to bind, however I ALWAYS use the keybinding interface to unbind and edit bindings. It would be a bit of a pain if removed. I expect many users who use custom keybindings alot make use of this. Alex Schultz From alex_sch at telus.net Sun Feb 5 19:08:30 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 05 Feb 2006 18:08:30 -0700 Subject: [crossfire] Why have you banned my CVS access, And why do you hate mlab (I just finished mlabhell and I want mlab in for 1.9) In-Reply-To: <43E678E3.9080602@sonic.net> References: <20060204230929.59727.qmail@web32706.mail.mud.yahoo.com> <43E678E3.9080602@sonic.net> Message-ID: <43E6A18E.4010501@telus.net> Mark Wedel wrote: >Miguel Ghobangieno wrote: > > >>Why have you banned my CVS access, and why do you hate >>mlab? I just finished mlabhell and I want mlab in for >>1.9. It's better to have it in non-dirified format for >>1.9 then not in at all. >> >> > As per past discussions, some people would disagree with that statement. Past >discussion was that mlab should get cleaned up, or certainly, not made any worse. > As a little side note to that, I do have a script for dir-ifying mlab mostly complete, that wouldn't take too much effort to finish. (note that this doesn't solve the debate on what is appropriate content for the game, which is something I am not in the mood to talk about myself currently) Alex Schultz From antonoussik at gmail.com Sun Feb 5 20:04:10 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Mon, 6 Feb 2006 02:04:10 +0000 Subject: [crossfire] gtkv2 client vs gtk client gap list. In-Reply-To: <43E69CE0.7060709@telus.net> References: <1139047683.c804a85cyann.chachkoff@myrealbox.com> <43E56FE9.5080704@sonic.net> <43E69CE0.7060709@telus.net> Message-ID: My biggest obstacle (grudge?) against using gtk-v2 client is no -split option. It is good for big/small/multiple screens, and I find playing without quite restrictive. Also (last I tried) it fails to compile on cygwin, but that is probably easily fixable if I were to seriously consider using it. I also use the GUI keybinding interface. From lalo.martins at gmail.com Sun Feb 5 20:35:47 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 06 Feb 2006 10:35:47 +0800 Subject: [crossfire] gtkv2 client vs gtk client gap list. In-Reply-To: References: <1139047683.c804a85cyann.chachkoff@myrealbox.com> <43E56FE9.5080704@sonic.net> <43E69CE0.7060709@telus.net> Message-ID: And so says Anton Oussik on 06/02/06 10:04... > My biggest obstacle (grudge?) against using gtk-v2 client is no -split > option. It is good for big/small/multiple screens, and I find playing > without quite restrictive. Ideally, I'd like to see the v2 client use GIMP docks. Unfortunately, AFAICS, those dock widgets are not available as a library :-( best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From leaf at real-time.com Mon Feb 6 17:45:56 2006 From: leaf at real-time.com (Rick Tanner) Date: Mon, 06 Feb 2006 17:45:56 -0600 Subject: [crossfire] Collaboration on a Java-based map editor? (repost) Message-ID: <43E7DFB4.7020901@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 About two weeks ago (or maybe longer..) on IRC one of the developers who worked on and updated the map editor for Daimonin asked about a collaboration on a Java based editor that had a central or common core with specific side packages(?) for Crossfire and one for Daimonin. For those who can *and* are willing to contribute Java development interested in persuing this? Or discussing it further? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD59+0hHyvgBp+vH4RAjJ3AJ43OMfHu9djDrEiPo/QdnkntbcbiQCgqJsa +XiyHOovOWixBbs+kvDUP70= =un0X -----END PGP SIGNATURE----- From mwedel at sonic.net Tue Feb 7 02:15:55 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 07 Feb 2006 00:15:55 -0800 Subject: [crossfire] transports committed. Message-ID: <43E8573B.8070400@sonic.net> I've just committed the code to handle transports. Detailed information can be found in the doc/Developers/object under Transports, so I won't reproduce that here, but some quick notes: 1) I added a new movement type - MOVE_BOAT. This isn't directly related to transports, but using boats as a test transport type seemed most interesting to me and would test most of the features. The only terrain right now that allows boat movement is normal sea and deep sea. Shallow sea does not allow it. 2) Tranports should be fully functional as described in the objects file. However, several things were mentioned in the discussion which may not be there yet. 3) I added a couple boats to Scorn that acts as transports for testing. Since boats can't move to shallow water, and there is a patch of shallow water between scorn and the main oceans, this effectively limits the range of these boats. This is fine for testing. If that patch of water is changed, these transports should be removed, since being able to sail to most anyplace open up some areas too easily. 4) There is no form of ownership on transports. If you park your boat, someone else could go and take it and sail away. Much like real life. 5) Currently, no control on who boards your transport, and no way right now to evict them. 6) It is possible, especially with boats, for players to be stranded in the middle of the ocean - on the bright side, there is no drowning. The most sure fire way this can happen is that if you are on board a ship and you exit the ship and the ship sails away, leaving you behind. Going forward: More transport objects are needed. This should be easy to do, and some could re-use existing movement (a pegasus to fly on?). Graphics are also needed - the code does support the idea of different graphics based on if the transport have people on it or not (horse being a very obvious case). Some thought needs to be given on movement types for objects - we don't really want to end up with 20 movement types. Off the top of my head, quick suggestions: MOVE_WHEEL - for wheeled objects (carts, wagons, cars, whatever). These should be blocked from a fair number of objects (staircases, mountains, jungles, perhaps even hills and forest). MOVE_HOOF (MOVE_4LEG?) horses, mules, etc lesser limit of the above, but probably not allowed on staircases. MOVE_SWIM - already there. Probably shoudl be allowed in shallow sea, but IMO some special code is needed for this - chance of drowning, etc. Not that interesting enough, right now with the way transport code is, it is not possible to apply objects on the map while on a transport. Thus, transports are effectively prohibited from shops. The said, exits or other move_on objects should work OK. This actually works out pretty well when one thinks about it. From mikeeusaa at yahoo.com Tue Feb 7 06:35:02 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Tue, 7 Feb 2006 04:35:02 -0800 (PST) Subject: [crossfire] transports committed. (diffs?) In-Reply-To: <43E8573B.8070400@sonic.net> Message-ID: <20060207123502.87154.qmail@web32714.mail.mud.yahoo.com> Does cvs provide diffs for this? I'm interested in this but don't want to also have to have that patch that was just applied that removes features. --- Mark Wedel wrote: > > I've just committed the code to handle transports. > Detailed information can > be found in the doc/Developers/object under > Transports, so I won't reproduce > that here, but some quick notes: > > 1) I added a new movement type - MOVE_BOAT. This > isn't directly related to > transports, but using boats as a test transport type > seemed most interesting to > me and would test most of the features. The only > terrain right now that allows > boat movement is normal sea and deep sea. Shallow > sea does not allow it. > > 2) Tranports should be fully functional as described > in the objects file. > However, several things were mentioned in the > discussion which may not be there yet. > > 3) I added a couple boats to Scorn that acts as > transports for testing. Since > boats can't move to shallow water, and there is a > patch of shallow water between > scorn and the main oceans, this effectively limits > the range of these boats. > This is fine for testing. If that patch of water is > changed, these transports > should be removed, since being able to sail to most > anyplace open up some areas > too easily. > > 4) There is no form of ownership on transports. If > you park your boat, someone > else could go and take it and sail away. Much like > real life. > > 5) Currently, no control on who boards your > transport, and no way right now to > evict them. > > 6) It is possible, especially with boats, for > players to be stranded in the > middle of the ocean - on the bright side, there is > no drowning. The most sure > fire way this can happen is that if you are on board > a ship and you exit the > ship and the ship sails away, leaving you behind. > > Going forward: > More transport objects are needed. This should be > easy to do, and some could > re-use existing movement (a pegasus to fly on?). > Graphics are also needed - the > code does support the idea of different graphics > based on if the transport have > people on it or not (horse being a very obvious > case). > > Some thought needs to be given on movement types > for objects - we don't really > want to end up with 20 movement types. Off the top > of my head, quick suggestions: > > MOVE_WHEEL - for wheeled objects (carts, wagons, > cars, whatever). These should > be blocked from a fair number of objects > (staircases, mountains, jungles, > perhaps even hills and forest). > > MOVE_HOOF (MOVE_4LEG?) horses, mules, etc lesser > limit of the above, but > probably not allowed on staircases. > > MOVE_SWIM - already there. Probably shoudl be > allowed in shallow sea, but IMO > some special code is needed for this - chance of > drowning, etc. > > Not that interesting enough, right now with the > way transport code is, it is > not possible to apply objects on the map while on a > transport. Thus, transports > are effectively prohibited from shops. The said, > exits or other move_on objects > should work OK. This actually works out pretty well > when one thinks about it. > > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mikeeusaa at yahoo.com Tue Feb 7 06:40:20 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Tue, 7 Feb 2006 04:40:20 -0800 (PST) Subject: [crossfire] transports committed. In-Reply-To: <43E8573B.8070400@sonic.net> Message-ID: <20060207124020.85813.qmail@web32701.mail.mud.yahoo.com> NM, the removals were only in the client tree. --- Mark Wedel wrote: > > I've just committed the code to handle transports. > Detailed information can > be found in the doc/Developers/object under > Transports, so I won't reproduce > that here, but some quick notes: > > 1) I added a new movement type - MOVE_BOAT. This > isn't directly related to > transports, but using boats as a test transport type > seemed most interesting to > me and would test most of the features. The only > terrain right now that allows > boat movement is normal sea and deep sea. Shallow > sea does not allow it. > > 2) Tranports should be fully functional as described > in the objects file. > However, several things were mentioned in the > discussion which may not be there yet. > > 3) I added a couple boats to Scorn that acts as > transports for testing. Since > boats can't move to shallow water, and there is a > patch of shallow water between > scorn and the main oceans, this effectively limits > the range of these boats. > This is fine for testing. If that patch of water is > changed, these transports > should be removed, since being able to sail to most > anyplace open up some areas > too easily. > > 4) There is no form of ownership on transports. If > you park your boat, someone > else could go and take it and sail away. Much like > real life. > > 5) Currently, no control on who boards your > transport, and no way right now to > evict them. > > 6) It is possible, especially with boats, for > players to be stranded in the > middle of the ocean - on the bright side, there is > no drowning. The most sure > fire way this can happen is that if you are on board > a ship and you exit the > ship and the ship sails away, leaving you behind. > > Going forward: > More transport objects are needed. This should be > easy to do, and some could > re-use existing movement (a pegasus to fly on?). > Graphics are also needed - the > code does support the idea of different graphics > based on if the transport have > people on it or not (horse being a very obvious > case). > > Some thought needs to be given on movement types > for objects - we don't really > want to end up with 20 movement types. Off the top > of my head, quick suggestions: > > MOVE_WHEEL - for wheeled objects (carts, wagons, > cars, whatever). These should > be blocked from a fair number of objects > (staircases, mountains, jungles, > perhaps even hills and forest). > > MOVE_HOOF (MOVE_4LEG?) horses, mules, etc lesser > limit of the above, but > probably not allowed on staircases. > > MOVE_SWIM - already there. Probably shoudl be > allowed in shallow sea, but IMO > some special code is needed for this - chance of > drowning, etc. > > Not that interesting enough, right now with the > way transport code is, it is > not possible to apply objects on the map while on a > transport. Thus, transports > are effectively prohibited from shops. The said, > exits or other move_on objects > should work OK. This actually works out pretty well > when one thinks about it. > > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From fuchs.andy at gmail.com Tue Feb 7 15:37:53 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Tue, 7 Feb 2006 16:37:53 -0500 Subject: [crossfire] Collaboration on a Java-based map editor? (repost) In-Reply-To: <43E7DFB4.7020901@real-time.com> References: <43E7DFB4.7020901@real-time.com> Message-ID: On 2/6/06, Rick Tanner wrote: > About two weeks ago (or maybe longer..) on IRC one of the developers who > worked on and updated the map editor for Daimonin asked about a > collaboration on a Java based editor that had a central or common core > with specific side packages(?) for Crossfire and one for Daimonin. > > For those who can *and* are willing to contribute Java development > interested in persuing this? Or discussing it further? Sounds like a good idea for me, anyone who actualy knows java and works on the editor want to comment? -- Andrew Fuchs From lalo.martins at gmail.com Thu Feb 9 05:29:59 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Thu, 09 Feb 2006 19:29:59 +0800 Subject: [crossfire] RFC: gtk client with gtk2 Message-ID: I've been running the gtk client compiling with gtk2 for about 3 months now; it works beautifully (better than with gtk1), sdl and all. The problems I know about seem to be: - SDL doesn't work for some people. I couldn't find one of those people to comment, though. It works for me. - If I turn off popups, I can't log in. Everything else works. I'm currently working around this by leaving popups on, then disabling it after I log in, and not saving the config. This should of course be fixed, but with the gtk2 code residing in a separate patch somewhere, it's somewhat hard, not to mention there's little incentive. - IIRC, there was some bogosity with the autotools support - the person who wrote the patch doesn't know enough autotools to add the proper checks. I can volunteer to do this, but if someone else who's better at it than me wants to do it, even better. So, if we can get around these three items, can we commit the gtk2 support to CVS? Maybe we should simply commit it right now, on a branch; I volunteer to keep the branch up-to-date with any client fixes that happen on the HEAD. Then when the three problems are fixed, we merge the branch. Thoughts? Anyone against it? best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From pip88nl at gmail.com Wed Feb 8 18:43:38 2006 From: pip88nl at gmail.com (Pippijn van Steenhoven) Date: Thu, 09 Feb 2006 00:43:38 +0000 Subject: [crossfire] [patch] fix inconstency between on_same_map and get_rangevector Message-ID: Greetings, while working on a script that would move an NPC, one bug was found in common/map.c. A diff is supplied at the following URL: http://data.plan9.de/adjacent.txt Basically, it's get_nearest_player which calls can_detect_enemy which then calls on_same_map and if that returns yes, it returns random crap. From kirschbaum at myrealbox.com Thu Feb 9 15:42:05 2006 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Thu, 9 Feb 2006 22:42:05 +0100 Subject: [crossfire] [patch] fix inconstency between on_same_map and get_rangevector In-Reply-To: References: Message-ID: <20060209214205.GA3136@kirschbaum.myrealbox.com> Pippijn van Steenhoven wrote: > while working on a script that would move an NPC, one bug was found in > common/map.c. A diff is supplied at the following URL: > http://data.plan9.de/adjacent.txt > Basically, it's get_nearest_player which calls can_detect_enemy which then > calls on_same_map and if that returns yes, it returns random crap. Thanks for the bugfix; I did apply the (modified) patch. Please add future patches to the Sourceforge tracker since patches sent to the mailing list have a high chance to be missed. Patches added to the tracker stay there until somebody looks at them. Some notes about the patch: - Please try to follow Ansi C (C89). This especially means that // comments are not acceptable. - I did rewrite parts of the code: it did contain lines like *dx = MAP_HEIGHT(...) which cannot be correct. - I did not had a map to check, but I think it now can handle tiled maps with differing sizes. (For example a 20x50 map tiled to a 50x50 map.) From kirschbaum at myrealbox.com Thu Feb 9 16:16:33 2006 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Thu, 9 Feb 2006 23:16:33 +0100 Subject: [crossfire] RFC: gtk client with gtk2 In-Reply-To: References: Message-ID: <20060209221633.GA3537@kirschbaum.myrealbox.com> Lalo Martins wrote: > I've been running the gtk client compiling with gtk2 for about 3 > months now; it works beautifully (better than with gtk1), sdl and all. > > The problems I know about seem to be: > > - SDL doesn't work for some people. I couldn't find one of those people > to comment, though. It works for me. If you cannot actually find somebody having these problems, I don't think it should prevent you from applying the patch: if there really is a problem, "those people" will (hopefully) complain and we can fix the bug then. > - If I turn off popups, I can't log in. Everything else works. I'm > currently working around this by leaving popups on, then disabling it > after I log in, and not saving the config. This should of course be > fixed, but with the gtk2 code residing in a separate patch somewhere, > it's somewhat hard, not to mention there's little incentive. To me, this would be a blocking reason: I've seen a few players on mf that presumably did die because of popups appearing at the "wrong" time. Therefore I think this option (enable/disable popups) really should work. > - IIRC, there was some bogosity with the autotools support - the > person who wrote the patch doesn't know enough autotools to add the > proper checks. I can volunteer to do this, but if someone else who's > better at it than me wants to do it, even better. Sorry, can't help here. > So, if we can get around these three items, can we commit the gtk2 > support to CVS? No objections from me (if the popup problem is fixed). > Maybe we should simply commit it right now, on a branch; I volunteer > to keep the branch up-to-date with any client fixes that happen on the > HEAD. Then when the three problems are fixed, we merge the branch. I would not recommend to create a branch: it is a lot of work to keep it up-to-date or to merge it afterwards. And I don't think many people will find/use it, thus it does not help much for testing. Instead, my preferred solution would be to commit it to the main branch. From kirschbaum at myrealbox.com Thu Feb 9 17:12:55 2006 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Fri, 10 Feb 2006 00:12:55 +0100 Subject: [crossfire] Collaboration on a Java-based map editor? (repost) In-Reply-To: <43E7DFB4.7020901@real-time.com> References: <43E7DFB4.7020901@real-time.com> Message-ID: <20060209231255.GB3537@kirschbaum.myrealbox.com> Rick Tanner wrote: > About two weeks ago (or maybe longer..) on IRC one of the developers > who worked on and updated the map editor for Daimonin asked about a > collaboration on a Java based editor that had a central or common core > with specific side packages(?) for Crossfire and one for Daimonin. > For those who can *and* are willing to contribute Java development > interested in persuing this? Or discussing it further? I'm interested since I did plan to fix/improve the editor for quite a while now (but never found time to really start work). And since both projects do not have that many developers, IMHO it would be a good idea to share resources. OTOH I still see some obstacles to consider when merging the editors: - Both editors are quite different (code-wise but maybe not feature-wise); it seems that both editors have been changed quite a bit since fork time. Since the Daimonin editor has no ChangeLog file, and the CF-Editor's ChangeLog file was not updated for all changes, it is probably not too easy to make sure all existing features are kept in a merge. - Into which repository should the merged code go? I don't think we should keep two copies (one in Crossfire, one in Daimonin) since it would be hard to maintain. Moving the CF-Editor into another project should not be hard to do since it is a standalone repository as far as I can tell. But the Daimonin editor is part of a combined server/client/editor/etc. repository. Therefore it probably has more dependencies to other parts of the project. - The Daimonin editor requires Java 1.5. The CF-Editor still works with Java 1.4. Since switching back to 1.4 does not really make sense to me, 1.5 would become a requirement for Crossfire. - I *think* some config files are not completely compatible anymore: - Spells are objects in Crossfire but (I think) still hardcoded as numbers in Daimonin. - Treasurelists in Daimonin use some "&" syntax (I think). Not sure if the treasurelist format has changed, or if it is only the syntax of the string referencing the treasures. From lalo.martins at gmail.com Thu Feb 9 20:44:03 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Fri, 10 Feb 2006 10:44:03 +0800 Subject: [crossfire] Collaboration on a Java-based map editor? (repost) In-Reply-To: <20060209231255.GB3537@kirschbaum.myrealbox.com> References: <43E7DFB4.7020901@real-time.com> <20060209231255.GB3537@kirschbaum.myrealbox.com> Message-ID: And so says Andreas Kirschbaum on 10/02/06 07:12... > - The Daimonin editor requires Java 1.5. The CF-Editor still works with > Java 1.4. Since switching back to 1.4 does not really make sense to > me, 1.5 would become a requirement for Crossfire. Java 1.4 doesn't work for me. And sorry for being the resident RMS, but IMHO, supporting 1.4 does make sense, until there is another 1.5 VM out there apart from Sun's. I already dislike Java strongly enough, I'd rather not run Sun's VM if I have a choice about it. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Fri Feb 10 00:01:48 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 09 Feb 2006 22:01:48 -0800 Subject: [crossfire] RFC: gtk client with gtk2 In-Reply-To: References: Message-ID: <43EC2C4C.2080504@sonic.net> Lalo Martins wrote: > > - IIRC, there was some bogosity with the autotools support - the person > who wrote the patch doesn't know enough autotools to add the proper > checks. I can volunteer to do this, but if someone else who's better at > it than me wants to do it, even better. There are already checks for gtk2 and the like for the gtk2 client - I'd think those defines coudl be re-used. > > So, if we can get around these three items, can we commit the gtk2 > support to CVS? One question I have is whether this removes the ability to compile the client with gtk1. Granted, gtk1 is fairly out of date, but if this change requires people have gtk2, that probably needs to be pretty clearly stated. IT may be reasonable to say we don't support gtk1 anymore. From lalo.martins at gmail.com Fri Feb 10 04:08:13 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Fri, 10 Feb 2006 18:08:13 +0800 Subject: [crossfire] RFC: gtk client with gtk2 In-Reply-To: <43EC2C4C.2080504@sonic.net> References: <43EC2C4C.2080504@sonic.net> Message-ID: <43EC660D.2020707@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (third attempt... for some reason, shadowknight's spam blocker scores this as 7.7 points... I wonder what's the criteria? Here's hoping signed messages somehow score a bit better...) And so says Mark Wedel on 10/02/06 14:01... > One question I have is whether this removes the ability to compile the client > with gtk1. Granted, gtk1 is fairly out of date, but if this change requires > people have gtk2, that probably needs to be pretty clearly stated. IT may be > reasonable to say we don't support gtk1 anymore. The existing patch doesn't remove gtk1 support; you can still compile both gtk1 and gtk2. I'm not against removing gtk1 support, but I'd put the gtk2 support in first, and remove gtk1 at least one release later, leaving us time to smoothen any wrinkles the new code may have. (Meaning, on the first release the gtk compile is released but labeled as "somewhat experimental", and people who want to live on the safe side can go with gtk1 instead.) best, Lalo Martins - -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD7GWtc+NusBpPPUkRAqpsAJ48QCijwFsjnM1c+ITh2bIDf1e3jgCfTiUN U59a+ykVtD5k9VOo9JZiKNY= =BeIv -----END PGP SIGNATURE----- From Christian.Hujer at itcqis.com Fri Feb 10 14:10:55 2006 From: Christian.Hujer at itcqis.com (Christian Hujer) Date: Fri, 10 Feb 2006 21:10:55 +0100 Subject: [crossfire] Collaboration on a Java-based map editor? (repost) In-Reply-To: References: <43E7DFB4.7020901@real-time.com> <20060209231255.GB3537@kirschbaum.myrealbox.com> Message-ID: <200602102110.56177.Christian.Hujer@itcqis.com> Am Freitag, 10. Februar 2006 03:44 schrieb Lalo Martins: > And so says Andreas Kirschbaum on 10/02/06 07:12... > > > - The Daimonin editor requires Java 1.5. The CF-Editor still works with > > Java 1.4. Since switching back to 1.4 does not really make sense to > > me, 1.5 would become a requirement for Crossfire. > > Java 1.4 doesn't work for me. > > And sorry for being the resident RMS, but IMHO, supporting 1.4 does make > sense, until there is another 1.5 VM out there apart from Sun's. I > already dislike Java strongly enough, I'd rather not run Sun's VM if I > have a choice about it. I am the maintainer of the Daimonin map editor. (Cher in IRC) We migrated to 1.5 a year ago. From a developer point of view, 1.5 is vital: * Final Fixes in the PNG libraries * Generics * Foreach Loops * Auto(un)boxing * Vararg methods * Annotations (the editor still lives without annotations apart from @SuppressWarnings, @Override and @Deprecation, but this might change) * Static Import (okay this one is only to get a complete list, I could live without static imports) * XML DOM Level 3 including XInclude, DOM Level 3 L+S, XML Schema (both, WXS and RELAX) and Bootstrapping This list definitely is incomplete. The numbers of developers working on such projects already is small enough. That's why I suggested rejoining our editor development efforts. The new features save development time at several stages: writing code, debugging and maintenance. I will NOT port back anything to a Java version prior to 1.5. We (devs) are trying to make our software useful for the users, but we can also expect that users make our life easier by supporting our (developer's) needs, and for Java this is upgrading to a newer VM - at least, if supporting our needs is, apart from downloading something and some time and effort to install it, free of any costs. You don't need to buy new hardware for running Java 5.0 instead of 1.4.2. Besides, for a Java 5.0 that's not from SUN, look at http://www-128.ibm.com/developerworks/java/jdk/linux/download.html (I assume you use Linux or an operating system capable of executing Linux-ELF). Cher -- Christian Hujer Free software developer E-Mail: Christian.Hujer at itcqis.com WWW: http://www.itcqis.com/ http://daimonin.sf.net/ From maligor at gmail.com Sat Feb 11 09:30:33 2006 From: maligor at gmail.com (Veli-Matti Valtonen) Date: Sat, 11 Feb 2006 17:30:33 +0200 Subject: [crossfire] RFC: gtk client with gtk2 In-Reply-To: <43EC2C4C.2080504@sonic.net> References: <43EC2C4C.2080504@sonic.net> Message-ID: On 2/10/06, Mark Wedel wrote: > There are already checks for gtk2 and the like for the gtk2 client - I'd think > those defines coudl be re-used. Yes, I totally agree, I'm not that profient in autoconf so I didn't want to around changing the gtk v2 autoconf code since it was rather well packed. I rather suspect it'll look rather messy by even autoconf standards nontheless, since it'll require two paths and one source tree. I've also been writing a scons based build system that does look quite a lot more elegant but doesn't really work properly yet. The whole install system is a bit broken at the moment. I'm sure there are people thinking: Oh not, not another build system, or aargh, yet another build dependency, or what ever you like. But it's compact, looks good (Can't think of anything that'd look worse than autoconf) and works, and this was rather done to see how a rather odd build setup would work on it. I'll possibly post it once I get the installer working. > One question I have is whether this removes the ability to compile the client > with gtk1. Granted, gtk1 is fairly out of date, but if this change requires > people have gtk2, that probably needs to be pretty clearly stated. IT may be > reasonable to say we don't support gtk1 anymore. Just like the win32 version of the gtk client, it uses code marked BROKEN in gtk 2.0, which is hardly elegant. And it is broken, I've found that the mouse scrollwheel will not work on the multiline text widgets. I tried porting this once when I originally wrote a patch for it (which was never posted anywhere). The result was a rather messy widget that didn't work quite right. I abandoned that project after that. From antonoussik at gmail.com Tue Feb 14 12:54:00 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Tue, 14 Feb 2006 18:54:00 +0000 Subject: [crossfire] RFC: gtk client with gtk2 In-Reply-To: <20060209221633.GA3537@kirschbaum.myrealbox.com> References: <20060209221633.GA3537@kirschbaum.myrealbox.com> Message-ID: On 09/02/06, Andreas Kirschbaum wrote: > Lalo Martins wrote: > > I've been running the gtk client compiling with gtk2 for about 3 > > months now; it works beautifully (better than with gtk1), sdl and all. > > > > The problems I know about seem to be: > > > > - SDL doesn't work for some people. I couldn't find one of those people > > to comment, though. It works for me. > > If you cannot actually find somebody having these problems, I don't > think it should prevent you from applying the patch: if there really is > a problem, "those people" will (hopefully) complain and we can fix the > bug then. SDL in CVS gcfclient has been broken for me for a long time now, producing this crash when connecting to a server with SDL enabled: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1081633664 (LWP 5070)] 0x403637c6 in SDL_LowerBlit () from /usr/lib/libSDL-1.2.so.0 (gdb) bt #0 0x403637c6 in SDL_LowerBlit () from /usr/lib/libSDL-1.2.so.0 #1 0x40363ae2 in SDL_UpperBlit () from /usr/lib/libSDL-1.2.so.0 #2 0x0806e342 in display_mapcell (ax=5, ay=7, mx=249, my=251) at sdl.c:806 #3 0x0806e4bc in sdl_gen_map (redraw=0) at sdl.c:932 #4 0x0807262b in map1_common (data=0x8477398 "", len=1798, rev=1) at commands.c:958 #5 0x08072791 in Map1aCmd (data=0x840c2b8 "", len=138461880) at commands.c:973 #6 0x080701f0 in DoClient (csocket=0x83985a0) at client.c:156 #7 0x08054c29 in do_network () at gx11.c:320 #8 0x401a98ce in gdk_get_show_events () from /opt/gnome/lib/libgdk-1.2.so.0 #9 0x083985a0 in style_fixed () #10 0x0000000c in ?? () #11 0x00000001 in ?? () #12 0x401f3130 in ?? () from /opt/gnome/lib/libglib-1.2.so.0 #13 0x00000000 in ?? () #14 0x083b1ac0 in ?? () #15 0xbfc22b38 in ?? () #16 0x401dea36 in g_io_add_watch () from /opt/gnome/lib/libglib-1.2.so.0 #17 0x401dea36 in g_io_add_watch () from /opt/gnome/lib/libglib-1.2.so.0 #18 0x401e03cf in g_get_current_time () from /opt/gnome/lib/libglib-1.2.so.0 #19 0x401e0f69 in g_main_add_poll () from /opt/gnome/lib/libglib-1.2.so.0 #20 0x401e126f in g_main_run () from /opt/gnome/lib/libglib-1.2.so.0 #21 0x400e2b4f in gtk_main () from /opt/gnome/lib/libgtk-1.2.so.0 #22 0x08054d31 in event_loop () at gx11.c:372 #23 0x080648f1 in main (argc=138461880, argv=0x840c2b8) at gx11.c:5290 (If you want more info about the crash poke me on IRC or reply to this) From nicolas.weeger at laposte.net Tue Feb 14 15:17:30 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 14 Feb 2006 22:17:30 +0100 Subject: [crossfire] Weather Message-ID: <43F248EA.80509@laposte.net> Hello. I just tried running the server with dynamiclevel set to 5 (max weather), and I didn't see any issue looking like the following bugs: * https://sourceforge.net/tracker/index.php?func=detail&aid=1155590&group_id=13833&atid=113833 * https://sourceforge.net/tracker/index.php?func=detail&aid=1404512&group_id=13833&atid=113833 Anyone has those issue? Nicolas From nicolas.weeger at laposte.net Tue Feb 14 15:29:15 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 14 Feb 2006 22:29:15 +0100 Subject: [crossfire] New DM command Message-ID: <43F24BAB.20304@laposte.net> Hello. Since there was no commit mail (i killed CVS when i saw it was committing archetypes files, but it had already committed other files), I'll just point out there's a new DM command, "insert_into". It takes 2 arguments, and puts the 2nd in the 1st's inventory. Pretty simple. Note that you can't put a player in something, to avoid weird issues :) Note that I haven't checked all cases for updating object's information, if something is weird tell me and I'll fix. Nicolas From alex_sch at telus.net Tue Feb 14 17:25:21 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 14 Feb 2006 16:25:21 -0700 Subject: [crossfire] Weather In-Reply-To: <43F248EA.80509@laposte.net> References: <43F248EA.80509@laposte.net> Message-ID: <43F266E1.2050808@telus.net> Nicolas Weeger wrote: >Hello. > >I just tried running the server with dynamiclevel set to 5 (max >weather), and I didn't see any issue looking like the following bugs: >* >https://sourceforge.net/tracker/index.php?func=detail&aid=1155590&group_id=13833&atid=113833 >* >https://sourceforge.net/tracker/index.php?func=detail&aid=1404512&group_id=13833&atid=113833 > >Anyone has those issue? > >Nicolas > I have saw the second one at least on my private test server. It doesn't happen in all places though. One example, in the water north of scorn you might see a little bit of pine trees growing in the water. Also, in the 'azimundo' maps, the weather covers up things all over the place and causes a big mess. Alex Schultz From mwedel at sonic.net Wed Feb 15 02:42:49 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 15 Feb 2006 00:42:49 -0800 Subject: [crossfire] gtkv2 client vs gtk client gap list. In-Reply-To: <43E4710F.8080402@sonic.net> References: <43E4710F.8080402@sonic.net> Message-ID: <43F2E989.1060006@sonic.net> Briefly played with trying to get gcfclient2 to work at 1024x768 resolution (or thereabouts). The biggest issue is related to the layouts - since the gtk2 client stacks the info (text) window above the inventory above the look all in one vertical axis - this then doesn't given much space for all that - see link below: http://img204.imageshack.us/my.php?image=gclient29tj.png Now that can perhaps be improved to some extent by reducing the icon image size (16x16 would double images in the look and inventory window). I through this out for more discussion - to me, with that small a look and inventory window isn't that useful. At the same time, relative to new users, telling them the 10 things they need to change to get it to look reasonable on at 1024x768 resolution probably isn't that friendly. Maybe something like -lowres or the like which does the following: Sets icon scale to 50 Sets map window to be 15x15 (or maybe sets map scale to 60?) Adjusts layout accordingly (smaller map area, moves the spacers appropriately, etc). These could of course be adjusted by the player to their specific needs - it just seems that some form of easier to use configuration for this would be need out of the box. From won_fang at yahoo.com.au Thu Feb 16 16:50:26 2006 From: won_fang at yahoo.com.au (David Seikel) Date: Fri, 17 Feb 2006 08:50:26 +1000 Subject: [crossfire] Ice Castle up for grabs. In-Reply-To: <20060106215829.1dc7331b@cluster.meeting.humbug.org.au> References: <20060106215829.1dc7331b@cluster.meeting.humbug.org.au> Message-ID: <20060217085026.366a270c@cluster.meeting.humbug.org.au> On Fri, 6 Jan 2006 21:58:29 +1000 David Seikel wrote: > I really should have done this a long time ago. > > I vaguely recall announcing that my life was too busy to do any > Crossfire work some time ago. The situation is the same, and I > haven't even had time to patch up the Ice Castle and hand it to > someone. So I've dumped it to a server, and who ever wants it can > take over ownership of it. If no one wants it, feel free to steal > stuff from it, as there are some interesting things in it. There is > an IceCastle.txt file with some notes about what needs fixing and > stuff. > > http://matrix-rad.net/IceCastle.tar.bz2 > Although people have downloaded the file, there has been no feedback about it. Could be that everybody got distracted by recent threads. I'll pull it off my server at the end of the month as I have limited space and bandwidth on it. -- Stuff I have no control over could be added after this line. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20060217/fcfa0629/attachment.pgp From gabriele.diniciacci at gmail.com Thu Feb 16 17:59:49 2006 From: gabriele.diniciacci at gmail.com (Gabriele Dini Ciacci) Date: Fri, 17 Feb 2006 00:59:49 +0100 Subject: [crossfire] Ice Castle up for grabs. Message-ID: Reply to: dark.schneider at iol.it or to cf list I have unlimited band and space, if you want I can keep a copy of it there and you can link to it... Or I'll make a page for that if you prefer On Fri, 17 Feb 2006 08:50:26 +1000 David Seikel wrote: > On Fri, 6 Jan 2006 21:58:29 +1000 David Seikel > wrote: > > > I really should have done this a long time ago. > > > > I vaguely recall announcing that my life was too busy to do any > > Crossfire work some time ago. The situation is the same, and I > > haven't even had time to patch up the Ice Castle and hand it to > > someone. So I've dumped it to a server, and who ever wants it can > > take over ownership of it. If no one wants it, feel free to steal > > stuff from it, as there are some interesting things in it. There is > > an IceCastle.txt file with some notes about what needs fixing and > > stuff. > > > > http://matrix-rad.net/IceCastle.tar.bz2 > > > > Although people have downloaded the file, there has been no feedback > about it. Could be that everybody got distracted by recent threads. > I'll pull it off my server at the end of the month as I have limited > space and bandwidth on it. > > -- > Stuff I have no control over could be added after this line. > ----------- http://linux-wildo.sf.net http://www.diniciacci.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.metalforge.org/pipermail/crossfire/attachments/20060217/da5a5847/attachment.htm From won_fang at yahoo.com.au Thu Feb 16 18:22:14 2006 From: won_fang at yahoo.com.au (David Seikel) Date: Fri, 17 Feb 2006 10:22:14 +1000 Subject: [crossfire] Ice Castle up for grabs. In-Reply-To: References: Message-ID: <20060217102214.76e79603@cluster.meeting.humbug.org.au> On Fri, 17 Feb 2006 00:59:49 +0100 Gabriele Dini Ciacci wrote: > On Fri, 17 Feb 2006 08:50:26 +1000 > David Seikel wrote: > > > On Fri, 6 Jan 2006 21:58:29 +1000 David Seikel > > wrote: > > > > > I really should have done this a long time ago. > > > > > > I vaguely recall announcing that my life was too busy to do any > > > Crossfire work some time ago. The situation is the same, and I > > > haven't even had time to patch up the Ice Castle and hand it to > > > someone. So I've dumped it to a server, and who ever wants it can > > > take over ownership of it. If no one wants it, feel free to steal > > > stuff from it, as there are some interesting things in it. There > > > is an IceCastle.txt file with some notes about what needs fixing > > > and stuff. > > > > > > http://matrix-rad.net/IceCastle.tar.bz2 > > > > > > > Although people have downloaded the file, there has been no feedback > > about it. Could be that everybody got distracted by recent threads. > > I'll pull it off my server at the end of the month as I have limited > > space and bandwidth on it. > > Reply to: dark.schneider at iol.it or to cf list > > I have unlimited band and space, if you want I can keep a copy of it > there and you can link to it... > Or I'll make a page for that if you prefer A page is probably over the top. If you could copy the file to your server, and send the URL of the file on your server to this list in reply to this thread that would be wonderful. Thanks. -- Stuff I have no control over could be added after this line. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20060217/46397b95/attachment.pgp From mikeeusaa at yahoo.com Thu Feb 16 18:24:17 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Thu, 16 Feb 2006 16:24:17 -0800 (PST) Subject: [crossfire] Ice Castle up for grabs. In-Reply-To: <20060217085026.366a270c@cluster.meeting.humbug.org.au> Message-ID: <20060217002417.8385.qmail@web32705.mail.mud.yahoo.com> (continued) Also I see you have alot of dirs in there, how are they to be? maps/onefang/(1.4,TEMP,AntFarm) maps/python/stuff arch/ ? --- David Seikel wrote: > On Fri, 6 Jan 2006 21:58:29 +1000 David Seikel > > wrote: > > > I really should have done this a long time ago. > > > > I vaguely recall announcing that my life was too > busy to do any > > Crossfire work some time ago. The situation is > the same, and I > > haven't even had time to patch up the Ice Castle > and hand it to > > someone. So I've dumped it to a server, and who > ever wants it can > > take over ownership of it. If no one wants it, > feel free to steal > > stuff from it, as there are some interesting > things in it. There is > > an IceCastle.txt file with some notes about what > needs fixing and > > stuff. > > > > http://matrix-rad.net/IceCastle.tar.bz2 > > > > Although people have downloaded the file, there has > been no feedback > about it. Could be that everybody got distracted by > recent threads. > I'll pull it off my server at the end of the month > as I have limited > space and bandwidth on it. > > -- > Stuff I have no control over could be added after > this line. > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From eracclists at bellsouth.net Thu Feb 16 23:35:54 2006 From: eracclists at bellsouth.net (ERACC) Date: Thu, 16 Feb 2006 23:35:54 -0600 Subject: [crossfire] Ice Castle up for grabs. In-Reply-To: <20060217102214.76e79603@cluster.meeting.humbug.org.au> References: <20060217102214.76e79603@cluster.meeting.humbug.org.au> Message-ID: <200602162335.55102.eracclists@bellsouth.net> On Thursday 16 February 2006 06:22 pm David Seikel wrote: > A page is probably over the top. ?If you could copy the file to your > server, and send the URL of the file on your server to this list in > reply to this thread that would be wonderful. ?Thanks. I got it too. It is here: http://www.eracc.com/files/crossfire/IceCastle.tar.bz2 Gene Alexander -- Mandriva Linux release 2006.0 (Official) for i586 23:34:48 up 20 days, 8:51, 9 users, load average: 0.35, 0.93, 1.23 ERA Computers & Consulting - http://www.eracc.com/ eComStation, Linux, FreeBSD, OpenServer & UnixWare resellers From won_fang at yahoo.com.au Thu Feb 16 23:56:53 2006 From: won_fang at yahoo.com.au (David Seikel) Date: Fri, 17 Feb 2006 15:56:53 +1000 Subject: [crossfire] Ice Castle up for grabs. In-Reply-To: <200602162335.55102.eracclists@bellsouth.net> References: <20060217102214.76e79603@cluster.meeting.humbug.org.au> <200602162335.55102.eracclists@bellsouth.net> Message-ID: <20060217155653.132368bc@cluster.meeting.humbug.org.au> On Thu, 16 Feb 2006 23:35:54 -0600 ERACC wrote: > On Thursday 16 February 2006 06:22 pm > David Seikel wrote: > > > A page is probably over the top. ?If you could copy the file to your > > server, and send the URL of the file on your server to this list in > > reply to this thread that would be wonderful. ?Thanks. > > I got it too. It is here: > > http://www.eracc.com/files/crossfire/IceCastle.tar.bz2 Thank you for hosting it. To re iterate - I vaguely recall announcing that my life was too busy to do any Crossfire work some time ago. The situation is the same, and I haven't even had time to patch up the Ice Castle and hand it to someone. So I've dumped it to a server (now kindly hosted by ERACC), and who ever wants it can take over ownership of it. If no one wants it, feel free to steal stuff from it, as there are some interesting things in it. There is an IceCastle.txt file with some notes about what needs fixing and stuff. -- Stuff I have no control over could be added after this line. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20060217/410eb0f8/attachment-0001.pgp From philipp.neubeck at web.de Fri Feb 17 09:06:20 2006 From: philipp.neubeck at web.de (philipp.neubeck@web.de) Date: Fri, 17 Feb 2006 16:06:20 +0100 Subject: [crossfire] wrong cvs checkout command for world map Message-ID: <20060217160620.5ae91860@alpha.lan> hi, the checkout command cvs -z3 -d:pserver:anonymous at cvs.crossfire.sourceforge.net:/cvsroot/crossfire co maps-bigworld on http://crossfire.real-time.com/world_map/index.html should perhaps be changed to cvs -z3 -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/crossfire co maps-bigworld at least the second works for me and the first does not. bye Philipp Neubeck From gabriele.diniciacci at gmail.com Thu Feb 16 22:18:31 2006 From: gabriele.diniciacci at gmail.com (Gabriele Dini Ciacci) Date: Fri, 17 Feb 2006 05:18:31 +0100 Subject: [crossfire] Ice Castle up for grabs. Message-ID: File is now located at: www.diniciacci.org/projects/crossfire/IceCastle.tar.bz2 Location is stable and should be available for a long time Salutes Gabriele On Fri, 17 Feb 2006 10:22:14 +1000 David Seikel wrote: > On Fri, 17 Feb 2006 00:59:49 +0100 Gabriele Dini Ciacci > wrote: > > > On Fri, 17 Feb 2006 08:50:26 +1000 > > David Seikel wrote: > > > > > On Fri, 6 Jan 2006 21:58:29 +1000 David Seikel > > > wrote: > > > > > > > I really should have done this a long time ago. > > > > > > > > I vaguely recall announcing that my life was too busy to do any > > > > Crossfire work some time ago. The situation is the same, and I > > > > haven't even had time to patch up the Ice Castle and hand it to > > > > someone. So I've dumped it to a server, and who ever wants it can > > > > take over ownership of it. If no one wants it, feel free to steal > > > > stuff from it, as there are some interesting things in it. There > > > > is an IceCastle.txt file with some notes about what needs fixing > > > > and stuff. > > > > > > > > http://matrix-rad.net/IceCastle.tar.bz2 > > > > > > > > > > Although people have downloaded the file, there has been no feedback > > > about it. Could be that everybody got distracted by recent threads. > > > I'll pull it off my server at the end of the month as I have limited > > > space and bandwidth on it. > > > > Reply to: dark.schneider at iol.it or to cf list > > > > I have unlimited band and space, if you want I can keep a copy of it > > there and you can link to it... > > Or I'll make a page for that if you prefer > > A page is probably over the top. If you could copy the file to your > server, and send the URL of the file on your server to this list in > reply to this thread that would be wonderful. Thanks. > > -- > Stuff I have no control over could be added after this line. > ----------- http://linux-wildo.sf.net http://www.diniciacci.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.metalforge.org/pipermail/crossfire/attachments/20060217/3b91f37b/attachment.htm From brenlally at gmail.com Fri Feb 17 11:25:56 2006 From: brenlally at gmail.com (Brendan Lally) Date: Fri, 17 Feb 2006 17:25:56 +0000 Subject: [crossfire] Ice Castle up for grabs. In-Reply-To: References: Message-ID: <7903f03c0602170925p3fc3db1fu9a20ac591695ac35@mail.gmail.com> On 2/17/06, Gabriele Dini Ciacci wrote: > File is now located at: > www.diniciacci.org/projects/crossfire/IceCastle.tar.bz2 > > Location is stable and should be available for a long time Which leads to the question, is this map, as is, suitable for including in the unlinked directory of maps-bigworld? From fuchs.andy at gmail.com Fri Feb 17 16:34:35 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Fri, 17 Feb 2006 17:34:35 -0500 Subject: [crossfire] wrong cvs checkout command for world map In-Reply-To: <20060217160620.5ae91860@alpha.lan> References: <20060217160620.5ae91860@alpha.lan> Message-ID: On 2/17/06, philipp.neubeck at web.de wrote: > hi, > > the checkout command > cvs -z3 -d:pserver:anonymous at cvs.crossfire.sourceforge.net:/cvsroot/crossfire co maps-bigworld > on http://crossfire.real-time.com/world_map/index.html should perhaps be changed to > cvs -z3 -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/crossfire co maps-bigworld > > at least the second works for me and the first does not. I aggree with changing it, i doubt "cvs.crossfire.sourceforge.net" resolves to anything, while "cvs.sourceforge.net" is sourceforge's cvs server(s). -- Andrew Fuchs From mwedel at sonic.net Sat Feb 18 02:59:28 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 18 Feb 2006 00:59:28 -0800 Subject: [crossfire] wrong cvs checkout command for world map In-Reply-To: References: <20060217160620.5ae91860@alpha.lan> Message-ID: <43F6E1F0.9040603@sonic.net> Andrew Fuchs wrote: > On 2/17/06, philipp.neubeck at web.de wrote: >> hi, >> >> the checkout command >> cvs -z3 -d:pserver:anonymous at cvs.crossfire.sourceforge.net:/cvsroot/crossfire co maps-bigworld >> on http://crossfire.real-time.com/world_map/index.html should perhaps be changed to >> cvs -z3 -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/crossfire co maps-bigworld >> >> at least the second works for me and the first does not. > > I aggree with changing it, i doubt "cvs.crossfire.sourceforge.net" > resolves to anything, while "cvs.sourceforge.net" is sourceforge's cvs > server(s). Is there a specific doc or file that needs to be updated? > > -- > Andrew Fuchs > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From brenlally at gmail.com Sat Feb 18 14:12:36 2006 From: brenlally at gmail.com (Brendan Lally) Date: Sat, 18 Feb 2006 20:12:36 +0000 Subject: [crossfire] requestable spell lists. In-Reply-To: <7903f03c0601052001y12a5ae0at75790760192e72f@mail.gmail.com> References: <1134836084.c7d9c5dcyann.chachkoff@myrealbox.com> <43A6565C.8080204@sonic.net> <7903f03c0601052001y12a5ae0at75790760192e72f@mail.gmail.com> Message-ID: <7903f03c0602181212lc6d4d66leb23367008d961bb@mail.gmail.com> Spell listing support allows the sending of a message along with spells, however, currently a substantial number of spells lack a description. In order to rectify this I have been going through all the spells in the arch tree, and for those that are lacking them, writing some. I have now finished writing, and yet the writing is not finished. I have posted the complete list of spells which I intend to modify or add descriptions to on the wiki http://wiki.metalforge.net/doku.php/user/cavesomething/todo/spelldescriptions and am writing this as a general call to anyone so interested to fix/modify/improve anything they feel able to. I believe this represents a complete list of spells learnable during normal play, however, if any are missing, then I would much appriciate their addition (either directly to CVS or else to the same page as the rest of them). From philipp.neubeck at web.de Sun Feb 19 06:33:12 2006 From: philipp.neubeck at web.de (philipp.neubeck@web.de) Date: Sun, 19 Feb 2006 13:33:12 +0100 Subject: [crossfire] wrong cvs checkout command for world map In-Reply-To: <43F6E1F0.9040603@sonic.net> References: <20060217160620.5ae91860@alpha.lan> <43F6E1F0.9040603@sonic.net> Message-ID: <20060219133312.7dcba41d@alpha.lan> On Sat, 18 Feb 2006 00:59:28 -0800 Mark Wedel wrote: > Andrew Fuchs wrote: > > On 2/17/06, philipp.neubeck at web.de wrote: > >> hi, > >> > >> the checkout command > >> cvs -z3 -d:pserver:anonymous at cvs.crossfire.sourceforge.net:/cvsroot/crossfire co maps-bigworld > >> on http://crossfire.real-time.com/world_map/index.html should perhaps be changed to > >> cvs -z3 -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/crossfire co maps-bigworld > >> > >> at least the second works for me and the first does not. > > > > I aggree with changing it, i doubt "cvs.crossfire.sourceforge.net" > > resolves to anything, while "cvs.sourceforge.net" is sourceforge's cvs > > server(s). > > Is there a specific doc or file that needs to be updated? Yes: http://crossfire.real-time.com/world_map/index.html From mwedel at sonic.net Mon Feb 20 23:38:22 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 20 Feb 2006 21:38:22 -0800 Subject: [crossfire] RFC: gtk client with gtk2 In-Reply-To: References: <20060209221633.GA3537@kirschbaum.myrealbox.com> Message-ID: <43FAA74E.4040005@sonic.net> Anton Oussik wrote: > On 09/02/06, Andreas Kirschbaum wrote: >> Lalo Martins wrote: >>> I've been running the gtk client compiling with gtk2 for about 3 >>> months now; it works beautifully (better than with gtk1), sdl and all. >>> >>> The problems I know about seem to be: >>> >>> - SDL doesn't work for some people. I couldn't find one of those people >>> to comment, though. It works for me. >> If you cannot actually find somebody having these problems, I don't >> think it should prevent you from applying the patch: if there really is >> a problem, "those people" will (hopefully) complain and we can fix the >> bug then. > > SDL in CVS gcfclient has been broken for me for a long time now, > producing this crash when connecting to a server with SDL enabled: Well, I just tried gcfclient -sdl on my system, and had no problems - at least not an immediate crash. That said, while unrelated to this particular topic, we should perhaps decide on what graphic engine(s) to support. Does it really make sense to support both SDL & Opengl? I know SDL is suppose to be cross platform, but I'm not sure if the window ports/releases Ryo does actually support SDL. And on my system, for whatever reason, SDL isn't really much faster than native gtk drawing mode. which is why I did the opengl port (which is a lot faster than gtk or sdl modes). That said, for the bug in question, would probably be useful to know your system type, as well options passed to gcfclient and your gdefaults file. From mwedel at sonic.net Mon Feb 20 23:49:38 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 20 Feb 2006 21:49:38 -0800 Subject: [crossfire] RFC: gtk client with gtk2 In-Reply-To: References: <43EC2C4C.2080504@sonic.net> Message-ID: <43FAA9F2.4000101@sonic.net> Veli-Matti Valtonen wrote: > On 2/10/06, Mark Wedel wrote: >> There are already checks for gtk2 and the like for the gtk2 client - I'd think >> those defines coudl be re-used. > > Yes, I totally agree, I'm not that profient in autoconf so I didn't > want to around changing the gtk v2 autoconf code since it was rather > well packed. I rather suspect it'll look rather messy by even autoconf > standards nontheless, since it'll require two paths and one source > tree. Actually, should be pretty simple - as said, all the checks for gtk2 are already there, it is just a matter to use them in the gtkv1 client instead of the gtkv1 libs. I think this basically amounts to replacing the $(GTK_...) with @PACKAGE_..@ in the Makefile.am in the gtk directory. One question would be what to do after this patch is in place - is it better to link in with the gtkv2 libraries if they exist instead of the gtkv1? If only one set of libraries exist, then it makes sense to use what is available. But what to do if both are around? Handling this switching logic is marginally more difficult, but I can make the modifications to do that. > > I've also been writing a scons based build system that does look quite > a lot more elegant but doesn't really work properly yet. The whole > install system is a bit broken at the moment. I'm sure there are > people thinking: Oh not, not another build system, or aargh, yet > another build dependency, or what ever you like. But it's compact, > looks good (Can't think of anything that'd look worse than autoconf) > and works, and this was rather done to see how a rather odd build > setup would work on it. I'll possibly post it once I get the installer > working. Well, for better or worse, autoconf/automake is fairly standard. I know for myself, it would be easier to update autoconf/automake than to use yet another build system. It is also nice from a user standpoint - as a person that compiles a fair amount of stuff from source, it is very convenient to be able to do './configure ' and have it do what I want. It always bugs me a little when I have to figure out some other build environment. From mwedel at sonic.net Tue Feb 21 00:02:17 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 20 Feb 2006 22:02:17 -0800 Subject: [crossfire] Ice Castle up for grabs. In-Reply-To: <7903f03c0602170925p3fc3db1fu9a20ac591695ac35@mail.gmail.com> References: <7903f03c0602170925p3fc3db1fu9a20ac591695ac35@mail.gmail.com> Message-ID: <43FAACE9.7010508@sonic.net> Brendan Lally wrote: > On 2/17/06, Gabriele Dini Ciacci wrote: >> File is now located at: >> www.diniciacci.org/projects/crossfire/IceCastle.tar.bz2 >> >> Location is stable and should be available for a long time > > Which leads to the question, is this map, as is, suitable for > including in the unlinked directory of maps-bigworld? Perhaps, but I think it would be better to make whatever changes, etc, to put it into the game. The unlinked directory was originally used to hold a few maps from the old map distribution that just didn't really make there way into the bigworld maps. It then sort of became a place to hold maps like this - ones that should perhaps be added to crossfire, but need work. The problem here is that stuff goes into unlinked, and never comes out. Greyshield was put there 3.5 years ago. I'm not familiar enough with the ice castle to know how much work it needs, but at some level, if it is just put into the unlinked directory and then forgotten, that is only marginally more useful than having it on a server someplace. I haven't looked at the unlinked maps in quite a while, but that could be an easy place to find some new maps to add to crossfire - there is always the issue of 'we need more maps', and here are about 100 maps in unlinked that could perhaps be added with less working than creating brand new maps. From mwedel at sonic.net Tue Feb 21 00:29:17 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 20 Feb 2006 22:29:17 -0800 Subject: [crossfire] gtkv2 client vs gtk client gap list. In-Reply-To: <43F2E989.1060006@sonic.net> References: <43E4710F.8080402@sonic.net> <43F2E989.1060006@sonic.net> Message-ID: <43FAB33D.80900@sonic.net> For those of you not on the cvs commit list, a day or so back I did update the gtkv2 client so it does now have a keybinding gui interface. That seems to have been one of the most common things people said were missing. I'd be interested in people trying it out and making sure it works and meets needs. As a note, the gtkv2 interface now supports using the meta and alt keys as additional bind modifiers. Thus, you could bind Alt-F1 to one command, Meta-F1 to another command, control-F1 to a third command, shift-F1 to a fourth command, and just plain F1 to yet a fifth command. This should provide a lot more flexibility in binding. However, one issue is that the gtkv1 and gtkv2 share the same keymapping file. the gtkv2 client introduces some new modifiers for Alt and Meta. The result is that if you use the gtkv2 client and bind with those modifiers and then run the gtkv1 client, it will strip out those bindings because it doesn't understand that line. This support for meta/alt should probably be back ported to the gtkv1 client. I don't think it would be that hard to do, since the code from the gtkv2 client could be used to a good extent. Any volunteers? From nicolas.weeger at laposte.net Tue Feb 21 15:55:51 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 21 Feb 2006 22:55:51 +0100 Subject: [crossfire] RFC: gtk client with gtk2 In-Reply-To: <43FAA74E.4040005@sonic.net> References: <20060209221633.GA3537@kirschbaum.myrealbox.com> <43FAA74E.4040005@sonic.net> Message-ID: <43FB8C67.1030302@laposte.net> Hello. > Does it really make sense to support both SDL & Opengl? I know SDL is suppose > to be cross platform, but I'm not sure if the window ports/releases Ryo does > actually support SDL. Current Windows build don't use SDL for graphics, no (not talking music here, though it could be used for that) The issue is embedding the displayed picture in the GTK dialog. There's a hack for it under Linux, and I couldn't make it work under Windows. I know samples exist of that, but no luck so far. Therefore I just decided to use the GTK approach. Nicolas From nicolas.weeger at laposte.net Thu Feb 23 16:06:45 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 23 Feb 2006 23:06:45 +0100 Subject: [crossfire] Perl plugin Message-ID: <43FE31F5.5030609@laposte.net> Hello. I just committed the Perl plugin, courtesy Marc Lehmann (see https://sourceforge.net/tracker/index.php?func=detail&aid=1423431&group_id=13833&atid=313833 for more info). But I haven't yet figure how to make it compile with the autoconf / automake and such (my black magic level isn't high enough yet :p) Could someone tweak that, please? Note that I didn't test the Perl plugin, but it works according to pippijn Nicolas From fuchs.andy at gmail.com Fri Feb 24 15:14:26 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Fri, 24 Feb 2006 16:14:26 -0500 Subject: [crossfire] [Crossfire-cvs] CVS commit: maps-bigworld/scorn/shops In-Reply-To: <20060224210929.3550.qmail@web53306.mail.yahoo.com> References: <20060224210929.3550.qmail@web53306.mail.yahoo.com> Message-ID: It is possible to obtain unpaid items from the scorn sale shop. Simpily sell them on the seccond floor in the booths , then pick up what you just sold. After that just go downstairs and WoR out. The only other soulution i can think of other than blocking spells in the back, would be to put more shop mats on the seccond floor > Module Name: maps-bigworld > Committed By: eracc > Date: Fri Feb 24 03:58:02 UTC 2006 > > Modified Files: > maps-bigworld/scorn/shops: scorn.sale1 > > Log Message: > One is /supposed/ to be able to cast spells in the back of the shop. I > designed it that way on purpose in the last edit I made. The mats > already prevent one from using Word of Recall to remove unpaid items. > I am changing it back. > > > The following files had too many changes to show the context diffs here: > cvs rdiff -r1.10 -r1.11 > maps-bigworld/scorn/shops/scorn.sale1 -- Andrew Fuchs From eracclists at bellsouth.net Fri Feb 24 16:35:07 2006 From: eracclists at bellsouth.net (ERACC) Date: Fri, 24 Feb 2006 16:35:07 -0600 Subject: [crossfire] [Crossfire-cvs] CVS commit: maps-bigworld/scorn/shops In-Reply-To: References: <20060224210929.3550.qmail@web53306.mail.yahoo.com> Message-ID: <200602241635.08314.eracclists@bellsouth.net> On Friday 24 February 2006 03:14 pm Andrew Fuchs wrote: > It is possible to obtain unpaid items from the scorn sale shop. > Simpily sell them on the seccond floor in the booths , then pick up > what you just sold. ?After that just go downstairs and WoR out. Ah, then that is a problem with the redesigned second floor and it should be addressed there. I did not create the booth system and so have never tested it for flaws. Good catch. > The only other soulution i can think of other than blocking spells in > the back, would be to put more shop mats on the seccond floor I'll take a look at it right after sending this message. Gene Alexander -- Mandriva Linux release 2006.0 (Official) for i586 16:33:10 up 28 days, 1:49, 9 users, load average: 0.04, 0.05, 0.06 ERA Computers & Consulting - http://www.eracc.com/ eComStation, Linux, FreeBSD, OpenServer & UnixWare resellers From gabriele.diniciacci at gmail.com Sun Feb 26 08:26:16 2006 From: gabriele.diniciacci at gmail.com (Gabriele Dini Ciacci) Date: Sun, 26 Feb 2006 15:26:16 +0100 Subject: [crossfire] Crossfire 2.0+ features/priorities Message-ID: On Sun, 29 Jan 2006 14:38:55 -0800 Mark Wedel wrote: > the current method of 'press keys to swap stats', 'press spacebar to cycle > through classes', 'move your now created character to choose a class', and then > heading to the nexus are all a little hokey. (Here is my char creation draft, another of my series, if someone thinks I should gather all the drafts I wrote on the wiki, say me, so they are all near, instead that sparse on the list) Me and lalo did lot of discussion about that, and we ended up with a design to still use in-game creation system (that I personally do not like, but many seem to like it in cf comunity) withotu sacrifing flexibility. Lalo created different rooms for class selection each with a different wall and decoration layout based in yoru race. Those rooms can miss the conflicting/owerpowered race/class combos too. (many rooms are allready created, work just need to be finished) Race selection is done in another room before this one, with each path that has a decoration that matches the one used in the class selection. Each "way to a race" has a magic mouth that tells you the stat mods, so the player has just to step on it to read the description of that race. The player starts in the race selection room as a new arch named something like "life force" (or energy). Note: A nice romantic notice on ghostish races should be something like "life force sacrifice and converts to a death force" After that, each race receive a cerain ammount of tokens (non dropable inventory item) to spend on skills. Each class is teleported in a different room with many paths, each path rapresent a skill, at the path start you get a magic mouth that explain you the use of the skill and what you will be able to do with it. Each skill cost a different amount of tokens, based on class (room is per class as said above), then the player chooses one skill stepping on the teleporter at the end of the path, if he still has tokens he get the skill and then is teleported back in the room to choose another skill. There is a special teleporter that bring you to startgin point directly, converting all your tokens in money (like 500gp per token), this is for players that prefer having no skills, but more startign money. Notice that only common skills are here, skills for casting are not supposed to be bougth in this room, this is for "professional" skills like smithing, woodsman, mountanering and so on It woudl be fair for the avarae skill to cost 2 tokens, with less improtant skills costing 1 token and complex skills costing 3 tokens (like smithing). This is the basic common for all classes. Casters classes will do one more step and go in a room with many paths where they can use their "magic study tokens" (or "devotion tokens" if churches become like magic schools) to acquire different caster skills like piromacy, sorcery... The number of "magic study tokens" you get is based on the class, class that "studied magic obsessiverly" get 3 tokens, so he can get 3 magic schools, intermediate magic user get 2 tokens, and basic magic user gets 1 token. Special races get in a room with "race tokens" (each special rage get 1) where they can buy race skills, like dwarfs can buy for just one token smithering or jewlercrafting as starting skill. Fireborns can buy piromacy, elves can buy woodsman. Or again they can convert those tokens to money takeing the exit. I think that's all, code changes requided should be minimal, but since I am on the side of plugininzation I add that there is a way to make map changes minimal too. If random map generation becomes plugin, you can just add a layout that is "char creation room layout" that automatically generates the path rooms, given a list of skills that need a path wtih the skill token cost, the name of the token items. Then the teleporters will have all the same token checking algo. So those maps are dynamic and generated only when a player step in, this is cause this model has many maps and keeping them all loaded allways sound terible. Morover keeping them in sync with game engine is sad too, cause we want to be able to add new skills. Generating the map on the fly solve both issures cause if you want to add a skill to a class you just have to edit the class generation file (where the plugin read the configuration) and you are done. This extra plugin idea adds more code now, but reduce the ammount of mapper work needed (considering that we have few mappers and bad mapping tools, it sound good to me). Morover it nearly zeros the ammount of mapper work requided in the future in case of skill change, and personally, thinking about mantainability, this is the only way to have a char generation that can be keep in sync with the engine. Notive that since the plugins is dynamic, each server can configure char generation, so a server that do not want to allow smithing as a starting skill for example, can jsut remove it from the list in teh configuration file of the plugin. Char generation merely becomes a plugin, that is lovely, someone could just create a new in-game class generation system this way. Ok, it's allready enougth long. Hope you like this, I really love this idea :) Salutes, Gabriele Dini Ciacci ----------- http://linux-wildo.sf.net http://www.diniciacci.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.metalforge.org/pipermail/crossfire/attachments/20060226/d8369fef/attachment.htm From alex_sch at telus.net Sun Feb 26 14:44:50 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 26 Feb 2006 13:44:50 -0700 Subject: [crossfire] Code cleanlieness and server stability Message-ID: <44021342.9050604@telus.net> Hi, Lately, I was reminded a bit of how there often seems to be many bugs in CVS and server stability is in some ways rather poor. I was thinking a bit, and a large part of it is, runaway null pointers, and developers not thinking of all the areas that they might be affecting when making changes to some part. I was thinking that it would be a good idea to brainstorm some ideas on how these issues could be reduced. Here are some ideas that came to mind for me, feel free to suggest your own of course. -Encourage use of doxygen generated code documentation to verify what things you may be affecting: I.e. http://crossfire.real-time.com/code/server/index.html (would need a more uptodate version than that to be of much help though) -Sometimes when a bug gets fixed, the person who caused it might not know, and therefore the developer is more likely to do similar things again without knowing it. It might not be very difficult to make a small script that can check with cvs commit last changed a given line of code or function in the code, and one could easily notify the person who made the mistake of what they did wrong. This might be a bit of an over-engineered thing, but right now, just brainstorming ideas. -Clean up the code structure: IMHO, the first step would be moving functions around between files and making that organization a bit clearer. Also, though plugins might have some merits, they are not the way to go for achieving cleaner code. Greater separation of parts would be good, but plugins will just have a bit of overhead and similar separation can be achieved just moving around which code is in what files. After the code is moved around between files, I think the next step to do would be removing redundant code which there seems to be a bit of (i.e. in many places, there are many separate implementation of very similar functions that should be implemented as a single function, with perhaps some extra arguments to very slight variants). Alex Schultz (the onomatopoeia in the subject was mere coincidence) From mwedel at sonic.net Sun Feb 26 20:34:26 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 26 Feb 2006 18:34:26 -0800 Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: References: Message-ID: <44026532.5080202@sonic.net> Gabriele Dini Ciacci wrote: > Me and lalo did lot of discussion about that, and we ended up with a design > to still use in-game creation system (that I personally do not like, but > many seem > to like it in cf comunity) withotu sacrifing flexibility. For the record, I think an in game creation method is desirable. One thing to keep in mind in this discussion is ease for new players. I'd tend to bet a person unfamilar to crossfire may download the RPM and fire it up and try to start and play. But the amount of time they'd spend before saying 'this just isn't worth the effort' could be less than 5 minutes. So a method that is easy and intuitive is pretty high on the feature list. > Lalo created different rooms for class selection each with a different > wall and > decoration layout based in yoru race. Those rooms can miss the > conflicting/owerpowered race/class combos too. > (many rooms are allready created, work just need to be finished) > > Race selection is done in another room before this one, with each path > that has > a decoration that matches the one used in the class selection. > Each "way to a race" has a magic mouth that tells you the stat mods, so the > player has just to step on it to read the description of that race. One problem I have with that method, and which exists in the current method, is it isn't clear to effect of all these choices on the character. Choosing a race affects your stats in some way. Choosing a class also does so, yet you can't really know that effect until you've chosen your race. > > After that, each race receive a cerain ammount of tokens (non dropable > inventory > item) to spend on skills. Each class is teleported in a different room > with many paths, > each path rapresent a skill, at the path start you get a magic mouth > that explain you the > use of the skill and what you will be able to do with it. > Each skill cost a different amount of tokens, based on class (room is > per class as said > above), then the player chooses one skill stepping on the teleporter at > the end of the > path, if he still has tokens he get the skill and then is teleported > back in the room to > choose another skill. this also seems to increase complexity in creating a new character, which I'm not really sure is desirable. Going back to that new to crossfire player, are they really going to be able to make good decisions on skill selection? > There is a special teleporter that bring you to startgin point directly, > converting all your > tokens in money (like 500gp per token), this is for players that prefer > having no skills, > but more startign money. > Notice that only common skills are here, skills for casting are not > supposed to be bougth > in this room, this is for "professional" skills like smithing, woodsman, > mountanering and > so on I wonder if it would make more sense to just set up a mini store and give the players the money in the first place (that mini store could also stock some first level spellbooks, and some armor and weapons). Then just give that player the money to spend on what they want to spend. Note I'd forsee this mini store to be staticly defined items - nothing random, but rather a store with set objects. Thus, prices can be adjusted, and object given special flag to make learning the spell or skill automatic. Overall, this seems to make the character creation much more complex, both from a map point of view, as well as a player point of view. OTOH, I'm firmly in the camp that I'd like a nice popup window on the client where the player chooses his stats, race, class, and if we want to go in the direction of choosing skills, that also. I think from an interface solution, this is much better, as player can easily see what changing race or class does to stats as well as skill selection. Thus, they can easily play around with stuff, yet one could still create a character pretty quickly. The downside is that all the client(s) need to support this interface. From mwedel at sonic.net Sun Feb 26 22:17:08 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 26 Feb 2006 20:17:08 -0800 Subject: [crossfire] Code cleanlieness and server stability In-Reply-To: <44021342.9050604@telus.net> References: <44021342.9050604@telus.net> Message-ID: <44027D44.1030904@sonic.net> Alex Schultz wrote: > Hi, > > Lately, I was reminded a bit of how there often seems to be many bugs in > CVS and server stability is in some ways rather poor. I was thinking a > bit, and a large part of it is, runaway null pointers, and developers > not thinking of all the areas that they might be affecting when making > changes to some part. I was thinking that it would be a good idea to > brainstorm some ideas on how these issues could be reduced. Here are > some ideas that came to mind for me, feel free to suggest your own of > course. Actually, the server has been relatively stable (in terms of crashes) recently, IMO. The null pointer crashes, while annoying, are also relatively easy to fix and find. I'll include the more difficult bugs at the end. > > -Encourage use of doxygen generated code documentation to verify what > things you may be affecting: I.e. > http://crossfire.real-time.com/code/server/index.html (would need a more > uptodate version than that to be of much help though) Yes - that would seem to be easy to do. I'm not that familar with doxygen, but I'd also think that it should be possible to use makefiles to generate the data? If so, keeping that information up to date should end up being pretty easy. > > -Sometimes when a bug gets fixed, the person who caused it might not > know, and therefore the developer is more likely to do similar things > again without knowing it. It might not be very difficult to make a small > script that can check with cvs commit last changed a given line of code > or function in the code, and one could easily notify the person who made > the mistake of what they did wrong. This might be a bit of an > over-engineered thing, but right now, just brainstorming ideas. I'd think such a script could be tricky and/or error prone. For example, whitespace (or other minor formatting changes) could show foo as the last person that modified it, but that isn't the real source of the bug. The other case, which is also likely to confuse scripts, is when someone changes code near the bad line, but not the line itself. Also, the notification to this previous person would have to be carefully done so as not to look like a blame game. There is also the problem that some code may no longer have an active developer. One easy thing I would suggest is that all code developers be on the crossfire-CVS mailing list so they see the commits, and thus can keep an eye out for what things have been changed/fixed, and whether that was their code. However, this still doesn't really fix the problem itself, which is good coding practices. > > -Clean up the code structure: IMHO, the first step would be moving > functions around between files and making that organization a bit > clearer. Also, though plugins might have some merits, they are not the > way to go for achieving cleaner code. Greater separation of parts would > be good, but plugins will just have a bit of overhead and similar > separation can be achieved just moving around which code is in what > files. After the code is moved around between files, I think the next > step to do would be removing redundant code which there seems to be a > bit of (i.e. in many places, there are many separate implementation of > very similar functions that should be implemented as a single function, > with perhaps some extra arguments to very slight variants). To some extent, I agree, but this also seems to be going back to the code cleanup discussion. One thing I'd add to such a code cleanup is that there should be the willingness to break things (that can be fixed on the map level) for cleaner code. A lot of functions are overly complicated because code was put in place to fix map bug X, Y, and Z. As for other common bugs that could be cleaned up: 1) buffer overruns - snprintf, strncpy, etc, should always be used. Buffer overruns are often very hard to find, because they blow away the stack. And often, while the code seems safe (sprintf(buf,"abc %s", foo) because foo will never be longer enough be cause an overflow of buf), things change such that foo now can become long enough to cause that overflow. 2) Presumption that valid result will be found in time. The recent hangs (infinite loops) on metalforge where caused by the movement code, but also because the random map code presumes that if tries enough, it will eventually find an unblocked space to put the item. There are/were perhaps other cases - I'll eventually generate a treasure, etc. All such loops should probably have some count on the number of tries, and time out at some point (and print out an error message). 3) Functions that stores results in a static string and return that. Aside from not being thread safe,non threaded code still run into issues, like: cp1 = foo(abc); some code; cp2 = foo(def); now so something with cp1, which isn't what we expect The real fix here is to modify all such functions to take as a paremeter the buffer to store the data into. If a null is passed as such a buffer, the function could do a malloc/strdup for us (although, this may not be a good solution - creates more code issues (up there, they did a free() on the return. Do I need to do that) 4) It may be worthwhile to revisit the entire shared string functions - it saves some cpu and memory, but also makes things a lot harder to track down if some code things it can modify op->name for example. In addition, it isn't 100% consistently used - most code uses it, yet there is other code that just uses strdup (for different variables mind you), but it could help simplify code if the strdup method was just used everything. Certainly, this current mix causes problems when some code does op->name = strdup(). From alex_sch at telus.net Sun Feb 26 23:34:49 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 26 Feb 2006 22:34:49 -0700 Subject: [crossfire] Code cleanlieness and server stability In-Reply-To: <44027D44.1030904@sonic.net> References: <44021342.9050604@telus.net> <44027D44.1030904@sonic.net> Message-ID: <44028F79.5070405@telus.net> Mark Wedel wrote: > Actually, the server has been relatively stable (in terms of crashes) >recently, IMO. > > Well, lately it has been reletively crash free compared to some other times in the past, though compared to many other applications and such, crossfire does seem to be a bit flakier both bug and crash wise. > The null pointer crashes, while annoying, are also relatively easy to fix and >find. I'll include the more difficult bugs at the end. > > Yes, was just using that as an example, because however easy to fix they are, they are rather easy to stumble upon too and thus a higher profile example. > One easy thing I would suggest is that all code developers be on the >crossfire-CVS mailing list so they see the commits, and thus can keep an eye out >for what things have been changed/fixed, and whether that was their code. > > Agreed, the thing I was proposing above for that was certainly over-engineered and what you're saying alone should be sufficent (and already in practice for most people to my knowledge) > One thing I'd add to such a code cleanup is that there should be the >willingness to break things (that can be fixed on the map level) for cleaner code. > > A lot of functions are overly complicated because code was put in place to fix >map bug X, Y, and Z. > > I'm curious, I haven't heard of any of these cases. Could you give an example? Alex Schultz From mwedel at sonic.net Mon Feb 27 01:09:16 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 26 Feb 2006 23:09:16 -0800 Subject: [crossfire] Code cleanlieness and server stability In-Reply-To: <44028F79.5070405@telus.net> References: <44021342.9050604@telus.net> <44027D44.1030904@sonic.net> <44028F79.5070405@telus.net> Message-ID: <4402A59C.1020100@sonic.net> Alex Schultz wrote: > Mark Wedel wrote: > >> Actually, the server has been relatively stable (in terms of crashes) >> recently, IMO. >> >> > Well, lately it has been reletively crash free compared to some other > times in the past, though compared to many other applications and such, > crossfire does seem to be a bit flakier both bug and crash wise. Perhaps, but this is sometimes hard to measure (and depends what we compare it against). However, IMO, there is no such thing as having the server too stable. I doubt anyone would complain if it could run for years at a time. >> One easy thing I would suggest is that all code developers be on the >> crossfire-CVS mailing list so they see the commits, and thus can keep an eye out >> for what things have been changed/fixed, and whether that was their code. >> >> > Agreed, the thing I was proposing above for that was certainly > over-engineered and what you're saying alone should be sufficent (and > already in practice for most people to my knowledge) Right - but there may be a few not on it. > >> One thing I'd add to such a code cleanup is that there should be the >> willingness to break things (that can be fixed on the map level) for cleaner code. >> >> A lot of functions are overly complicated because code was put in place to fix >> map bug X, Y, and Z. >> >> > I'm curious, I haven't heard of any of these cases. Could you give an > example? Recently, some of the movement stuff might be in this case - I don't know specifically if I did any this, but that would be such a situation - some object may not work or something, and rather than update 500 maps or 200 archetypes, easier to put in a few lines of codes so things work. I also don't have any examples, but I know more than once I've been making modifications and run across some line of code and look at it for a few minutes and thing 'what the heck does this line of code do', or, in many cases, it could be clear what it does, and the question is then 'why the heck doe we need to have this line of code here'. I'd think as part of code cleanup, we'd run across those, and rather than try to figure out why we have that line of code there, should just remove it and see what breaks. Especially, if given by the line of code, the behavior could be controlled via object/archetype changes. From elmex at x-paste.de Mon Feb 27 03:22:44 2006 From: elmex at x-paste.de (Robin Redeker) Date: Mon, 27 Feb 2006 10:22:44 +0100 Subject: [crossfire] Code cleanlieness and server stability In-Reply-To: <4402A59C.1020100@sonic.net> References: <44021342.9050604@telus.net> <44027D44.1030904@sonic.net> <44028F79.5070405@telus.net> <4402A59C.1020100@sonic.net> Message-ID: <20060227092244.GA1814@elmex> Hi! On Sun, Feb 26, 2006 at 11:09:16PM -0800, Mark Wedel wrote: > Alex Schultz wrote: > > Mark Wedel wrote: > > > >> Actually, the server has been relatively stable (in terms of crashes) > >> recently, IMO. > >> > >> > > Well, lately it has been reletively crash free compared to some other > > times in the past, though compared to many other applications and such, > > crossfire does seem to be a bit flakier both bug and crash wise. > > Perhaps, but this is sometimes hard to measure (and depends what we compare it > against). > > However, IMO, there is no such thing as having the server too stable. I doubt > anyone would complain if it could run for years at a time. > I want to say, that crossfire is _not_ 'relatively' stable. We are running cf.schmorp.de. The server crashes so often that we have to run crossfire in a loop so it restarts automatically after a crash. We also disabled the weather system because the crashes. And this is NOT hard to measure. Maybe if you compare it agains the java editor or Mozilla it really doesn't crash that much... but the aim should not be to be as crash free as much crashing software, the aim should be as crash free as possible. And there is no week we not find and fix a bug in the server code. Most surprisingly the bugs aren't hard to find, they are pretty easy, things like: Map access outside the map can be easily fixed by looking at the core dump. eg. the forked lightning patch i submitted 5 days ago. (crash occured when the lighning wanted to fork on map boundaries) And also the patch i just submitted to sourceforge is just a fix of out-of-boundaries access... (btw. it would be easier for us to submit those patches directly to the mailing list) I hope i can find the time to submit our bug fixes to the sourceforge tracker, it would be much easier to just drop a mail to a mailing list than logging in at sf.net, finding the correct tracker, filling in the forms, adding the file and submitting it. Another problem was with the perl plugin that was just applied. The link http://data.plan9.de/cfperl.diff explictly said: See http://cvs.schmorp.de/browse/cf.schmorp.de/crossfire/plugins/cfperl/, but please contact cf at schmorp.de before copying it. We were _not_ contacted, the result is a broken perl plugin in crossfire now which doesn't build correctly. cya, Robin -- elmex at ta-sa.org / robin at nethype.de / r.redeker at gmail.com Robin Redeker From kirschbaum at myrealbox.com Mon Feb 27 14:48:15 2006 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Mon, 27 Feb 2006 21:48:15 +0100 Subject: [crossfire] Ideas needed to fix exploit Message-ID: <20060227204815.GA4887@kirschbaum.myrealbox.com> On #crossfire it was reported that killing other players can be exploited (and currently is exploited on cat2) to level really fast. The cause is that kill_object() calculates the exp gain through calc_skill_exp(). This value is *not* limited/related to the exp the victim actually loses. This especially holds if the victim already has reached permanent exp limit: the killer gains up to 5 million exp for every kill (which is the upper limit kill_object() allows) but the victim does not lose anything. I'm not sure what the "right" solution could be. Some ideas: a) Do not reward (pk) with exp. This is probably the safest "solution" and is very easy to implement. Not sure if that is an appropriate solution for servers that allow pvp. b) Reward a (pk) with MIN(5 million, (exp loss of victim)/10). I'm not sure if that really is a good idea since it probably creates another exploit: kill a player with some hard to train skill and gain lots of exp in that skill. Another (probably quite hard to exploit) problem is that a victim player can be killed but not actually die. Thus if a player is very careful to kill the victim at -1 hp and the victim regains hp very fast, the victim will not actually die but the attacker will gain exp. Thus the attacker would gain more exp in total than expected. (I'm not sure if this problem still exists but it did exist last time I did check.) Another possible exploit could be to abuse the force inserted into a killed player to prevent multiple deaths at his savebed. c) Something else. Any ideas? From nicolas.weeger at laposte.net Mon Feb 27 14:52:10 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 27 Feb 2006 21:52:10 +0100 Subject: [crossfire] Code cleanlieness and server stability In-Reply-To: <20060227092244.GA1814@elmex> References: <44021342.9050604@telus.net> <44027D44.1030904@sonic.net> <44028F79.5070405@telus.net> <4402A59C.1020100@sonic.net> <20060227092244.GA1814@elmex> Message-ID: <4403667A.20200@laposte.net> Hello. > Another problem was with the perl plugin that was just applied. The link > http://data.plan9.de/cfperl.diff explictly said: > > See http://cvs.schmorp.de/browse/cf.schmorp.de/crossfire/plugins/cfperl/, > but please contact cf at schmorp.de before copying it. > > We were _not_ contacted, the result is a broken perl plugin in crossfire > now which doesn't build correctly. I'm the one to blame for that. I thought I had taken the latest version, but apparently no - or the code in the cvs wasn't uptodate :) Besides, the Perl plugin isn't included in current compilation. Nicolas From elmex at ta-sa.org Mon Feb 27 15:35:58 2006 From: elmex at ta-sa.org (Robin Redeker) Date: Mon, 27 Feb 2006 22:35:58 +0100 Subject: [crossfire] Code cleanlieness and server stability In-Reply-To: <4403667A.20200@laposte.net> References: <44021342.9050604@telus.net> <44027D44.1030904@sonic.net> <44028F79.5070405@telus.net> <4402A59C.1020100@sonic.net> <20060227092244.GA1814@elmex> <4403667A.20200@laposte.net> Message-ID: <20060227213558.GA10126@elmex> On Mon, Feb 27, 2006 at 09:52:10PM +0100, Nicolas Weeger wrote: > Hello. > > > Another problem was with the perl plugin that was just applied. The link > > http://data.plan9.de/cfperl.diff explictly said: > > > > See http://cvs.schmorp.de/browse/cf.schmorp.de/crossfire/plugins/cfperl/, > > but please contact cf at schmorp.de before copying it. > > > > We were _not_ contacted, the result is a broken perl plugin in crossfire > > now which doesn't build correctly. > > I'm the one to blame for that. I thought I had taken the latest version, > but apparently no - or the code in the cvs wasn't uptodate :) > > Besides, the Perl plugin isn't included in current compilation. > Ah, ok. As i'm not the author of the plugin send a mail to cf at schmorp.de and ask about how to apply and include it in the building process. cu, Robin -- elmex at ta-sa.org / robin at nethype.de / r.redeker at gmail.com Robin Redeker From alex_sch at telus.net Mon Feb 27 18:29:04 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 27 Feb 2006 17:29:04 -0700 Subject: [crossfire] Unit tests (was: Code cleanlieness and server stability) In-Reply-To: <44021342.9050604@telus.net> References: <44021342.9050604@telus.net> Message-ID: <44039950.8080304@telus.net> I was reading up a little bit on unit tests, and I was thinking, that it might be an interesting idea to integrate some unit testing into the server. The difficulty is, it would be difficult to create tests that could work in a useful way with something as complex as the crossfire server, however I feel that it might be possibly to be able to create some sort of unit testing that may be of worth. To test something like the crossfire server, an awful lot of tests would need to be implemented and it would take alot of planning. Some possible unit tests could be: -'Boulder' mechanics test: Have a basic map with some of the 'boulder mechanics', as a test of various classic map elements like teleporters, buttons, check invs, gates, pits, and such things. Perhaps also have the testing 'script' test magic mouths and ears. This test may not the most useful for finding bugs, but some things like some edge-of-map scenarios could be included. It would also not involve much effort other than creating the map, and having the script test for certain end conditions. -Spellcasting test: This is in my opinion a more useful test for discovering crashes. The test would have a test map that would have a variety of conditions, including some monsters, edge-of-map situations, and teleporters. The test could teleport a fake player between almost every map square, and casts every spell on each square. This could if designed properly test many different conditions. -Weather/Map loading test: This test would rapidly load several bigworld maps into memory, and process the weather on them a few times each, swapping out from time to time, and verifying that no original map squares have been lost in memory. (This test may currently fail in some cases) -Random map generator test: This test would quickly generate and load many random maps with a mix of parameters, using ever combination of styles in the maps and varying other parameters like size and style. And other tests could be done too of course, mostly limited by what one could think of. The big question is, is this worth it? Well, in my opinion, it would take a significant amount of effort to make, and useful results might not be seen very often with it, however I feel that it might be good to have some sort of 'stress test' like this, pushing game conditions to their limits, and use that as yet another way to find some of the more subtle bugs as them occur. I think that if this is implemented as a plugin of some sort that can be optionally built, it wouldn't cutter the server code too much either. This said, I'm not sure its the greatest idea, but right now I'm brainstorming a bit and it does seem plausible anyways and might have some benefits. Alex Schultz From alex_sch at telus.net Mon Feb 27 19:28:10 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 27 Feb 2006 18:28:10 -0700 Subject: [crossfire] Unit tests In-Reply-To: <44039950.8080304@telus.net> References: <44021342.9050604@telus.net> <44039950.8080304@telus.net> Message-ID: <4403A72A.8090303@telus.net> On IRC, Leaf just forwarded me to an old conversation about unit testing a bit. Seems like one of those things that most people thought was a good idea, but nobody actually got around to doing it. (This message and some others in thread) http://mailman.metalforge.org/pipermail/crossfire/2002-January/005940.html Alex Schultz From mikeeusaa at yahoo.com Mon Feb 27 17:40:19 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Mon, 27 Feb 2006 15:40:19 -0800 (PST) Subject: [crossfire] Ideas needed to fix exploit In-Reply-To: <20060227204815.GA4887@kirschbaum.myrealbox.com> Message-ID: <20060227234019.16513.qmail@web32709.mail.mud.yahoo.com> Force inserted at death to prevent aquiring tons of xp from multiple deaths is best IMHO. Should be if player died within x tiles then you don't get xp. Another possibility is this. If you kill someone who is at their perm exp you don't get any points. --- Andreas Kirschbaum wrote: > On #crossfire it was reported that killing other > players can be > exploited (and currently is exploited on cat2) to > level really fast. > > The cause is that kill_object() calculates the exp > gain through > calc_skill_exp(). This value is *not* > limited/related to the exp the > victim actually loses. This especially holds if the > victim already has > reached permanent exp limit: the killer gains up to > 5 million exp for > every kill (which is the upper limit kill_object() > allows) but the > victim does not lose anything. > > I'm not sure what the "right" solution could be. > Some ideas: > > a) Do not reward (pk) with exp. > > This is probably the safest "solution" and is > very easy to > implement. Not sure if that is an appropriate > solution for servers > that allow pvp. > > b) Reward a (pk) with MIN(5 million, (exp loss of > victim)/10). > > I'm not sure if that really is a good idea since > it probably creates > another exploit: kill a player with some hard to > train skill and > gain lots of exp in that skill. > > Another (probably quite hard to exploit) problem > is that a victim > player can be killed but not actually die. Thus > if a player is very > careful to kill the victim at -1 hp and the > victim regains hp very > fast, the victim will not actually die but the > attacker will gain > exp. Thus the attacker would gain more exp in > total than expected. > (I'm not sure if this problem still exists but > it did exist last > time I did check.) > > Another possible exploit could be to abuse the > force inserted into a > killed player to prevent multiple deaths at his > savebed. > > c) Something else. > > Any ideas? > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mwedel at sonic.net Tue Feb 28 00:29:14 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 27 Feb 2006 22:29:14 -0800 Subject: [crossfire] Code cleanlieness and server stability In-Reply-To: <20060227092244.GA1814@elmex> References: <44021342.9050604@telus.net> <44027D44.1030904@sonic.net> <44028F79.5070405@telus.net> <4402A59C.1020100@sonic.net> <20060227092244.GA1814@elmex> Message-ID: <4403EDBA.8040606@sonic.net> Robin Redeker wrote: > (btw. it would be easier for us to submit those patches directly to the > mailing list) > > I hope i can find the time to submit our bug fixes to the sourceforge > tracker, it would be much easier to just drop a mail to a mailing list > than logging in at sf.net, finding the correct tracker, filling in the > forms, adding the file and submitting it. The problem with submitting to the mailing list is that it is too easy for things to just get lost. Simplest example being that every thinks someone else will take and apply the patch, and no one ever does, and thus the patch is no longer applied. While the tracker may be less convenient, at least there is a definite record - it is open until someone takes some action on it. No way for it to really fall through the cracks. From mwedel at sonic.net Tue Feb 28 00:44:29 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 27 Feb 2006 22:44:29 -0800 Subject: [crossfire] Ideas needed to fix exploit In-Reply-To: <20060227204815.GA4887@kirschbaum.myrealbox.com> References: <20060227204815.GA4887@kirschbaum.myrealbox.com> Message-ID: <4403F14D.2060708@sonic.net> Andreas Kirschbaum wrote: > a) Do not reward (pk) with exp. > > This is probably the safest "solution" and is very easy to > implement. Not sure if that is an appropriate solution for servers > that allow pvp. could be something that is set in the settings file. Maybe even have this act as some modifier to amount of exp gained (as a percentage). so if 0, you get 0% (0) of the exp you would normally. If 50, you would get 50% of exp, etc. > > b) Reward a (pk) with MIN(5 million, (exp loss of victim)/10). > > I'm not sure if that really is a good idea since it probably creates > another exploit: kill a player with some hard to train skill and > gain lots of exp in that skill. I'm not sure I follow that logic - it doesn't seem to be any worse than now. If I can (hypothetically) kill someone with bad singing, that change above doesn't make things any easier or harder. I won't get any more exp than I did before that change, and will likely get less. If the player being killed is down to having only permanent exp left (thus doesn't lose anything), I gain no exp. > Another (probably quite hard to exploit) problem is that a victim > player can be killed but not actually die. Thus if a player is very > careful to kill the victim at -1 hp and the victim regains hp very > fast, the victim will not actually die but the attacker will gain > exp. Thus the attacker would gain more exp in total than expected. > (I'm not sure if this problem still exists but it did exist last > time I did check.) It may still exist, since I think the examination of death happens when the player does his action. That would be easy to fix - just move the check for op->stats.hp<0 to the start of do_some_living instead of the end. That said, in the right situation, a combo of 3 players could still observe this. This requires some knowledge of the processing order of the players - player A kills player C, gets exp. player B heals player C player C goes - do_some_living() never called for him with less than 0 exp, thus never loses exp This may not actually be as hard to set up as one might thing - the order players join in defines the order they are processed in. And what is important here is overall order, not per tick order. The, and order like CAB would still work - player C would be dead for a tick, but doesn't make a difference. I'd think this abuse would be easier to pull off, as now you don't have to align to -1 hp - if the healer can heal a good amount, that works. That said, I'd think that trying to do this would be time consuming - basically player A has to attack, and there probably isn't enough time for player B to see the results, so he has to always case healing. So if A's attack didn't kill, could take a while to get C down to a dangerous level of HP. > > Another possible exploit could be to abuse the force inserted into a > killed player to prevent multiple deaths at his savebed. One question I have is why even need a force. Is there any potential abuse just saying a player can't die when on his savebed? However, this change would be affected above - you have to make sure that the player doing the killing can't get the exp, since that is the real abuse. If the killer gets exp, but in do_some_living(), the player doesn't really die, this doesn't fix the problem. From mwedel at sonic.net Tue Feb 28 00:59:28 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 27 Feb 2006 22:59:28 -0800 Subject: [crossfire] Unit tests In-Reply-To: <44039950.8080304@telus.net> References: <44021342.9050604@telus.net> <44039950.8080304@telus.net> Message-ID: <4403F4D0.1050307@sonic.net> I think this is a very good idea, and I do think a plugin is the way to go. In the past, I have made up some simplistic test maps to test broken things in a controlled environment - it also makes it easier to very that it is now working correctly. However, I certainly don't go back and re-run those tests manually. Having a plugin do it wouldn't necessarily be hard. The plugin would I imagine read some form of command file, which could be something like: load_map ... activate_trigger x1,y1 sleep 10 (this in game ticks or something) check_for_object x2,y2 boulder As a basic test to make sure a trigger activating spikes moves the boulder. I think a plugin is necessary because whatever is running the tests needs some way to look at the internal structures - what is on x2,y2. Other commands I see would be inserting/removing items (to check handling of altars, buttons, etc) Such a plugin could actually handle a fair number of tests you describe. IF there is a way for the plugin to be called every tick (as a global event), this can even cover things like spellcasting (the script could check for the presence of the spell on any number of spaces to confirm correct behavior). I do not envision running these unit tests on a server with players. So if this plugin means it now takes 5 seconds for a tick to complete (say for complex spell tests where it is looking at a lot of spaces), that wouldn't be a big deal. Ideally, this test mode should be able to be started from command line, eg, crossfire -testscript .... which automatically loads the test plugin and runs it with testscript. I say this because some method of having this happen easily is highly desirable. If I can do something like 'make tests', even if those tests take an hour, I could fire it off before I go to bed or something. If I have to do special stuff to run the tests, this goes back to the test maps, nice to have, but doesn't do much good if never used. From alex_sch at telus.net Tue Feb 28 03:02:03 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 28 Feb 2006 02:02:03 -0700 Subject: [crossfire] Ideas needed to fix exploit In-Reply-To: <4403F14D.2060708@sonic.net> References: <20060227204815.GA4887@kirschbaum.myrealbox.com> <4403F14D.2060708@sonic.net> Message-ID: <4404118B.6070008@telus.net> Mark Wedel wrote: > One question I have is why even need a force. Is there any potential abuse >just saying a player can't die when on his savebed? > Well, it would be trivial to make a small script on the dying player to keep moving off of the savebed. Alex Schultz From nicolas.weeger at laposte.net Tue Feb 28 12:54:01 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 28 Feb 2006 19:54:01 +0100 Subject: [crossfire] Unit tests In-Reply-To: <44039950.8080304@telus.net> References: <44021342.9050604@telus.net> <44039950.8080304@telus.net> Message-ID: <44049C49.8000103@laposte.net> Hello. There are some maps in the 'test' subdirectory, I guess. At least, there is a map and script related to Python, to test things :) Maybe we could first test through Python? It'll probably uncover some bugs there, but once fixed we'll be able to test the server itself. Nicolas From alex_sch at telus.net Tue Feb 28 18:03:35 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 28 Feb 2006 17:03:35 -0700 Subject: [crossfire] Unit tests In-Reply-To: <44049C49.8000103@laposte.net> References: <44021342.9050604@telus.net> <44039950.8080304@telus.net> <44049C49.8000103@laposte.net> Message-ID: <4404E4D7.5010203@telus.net> Nicolas Weeger wrote: >Hello. > >There are some maps in the 'test' subdirectory, I guess. >At least, there is a map and script related to Python, to test things :) > >Maybe we could first test through Python? It'll probably uncover some >bugs there, but once fixed we'll be able to test the server itself. > >Nicolas > Most of the tests in that directory are small tests of a specific function, but are not very robust and have no automation. However they may still be useful to look at for ideas of what to test and possibly base some of the test maps off of. That python one seems like a decent unit test of the python plugin, but not of other functions. Personally, I think the most robust way to set up a unit test system would be writing it mainly in C, reading from a text based script file of what to do. The high level tests would be done mainly by map files and python code, but I think the unit test framework should be in C as a server plugin, so then could also have it run some lower level tests of some individual functions of the server much easier. Also, I was thinking that when the server starts up with the unit test plugin, it should fork a new copy of the server. This way, if a segfault occurs, it can core dump, fail that test, and resume with the next test. It also keeps the server states between the tests more separate and helps to make sure one failed test doesn't cause other tests to fail when they are fine. Alex Schultz From bogus@does.not.exist.com Fri Feb 3 01:49:57 2006 From: bogus@does.not.exist.com () Date: Fri, 03 Feb 2006 07:49:57 -0000 Subject: No subject Message-ID: surprising bugs, less time to spend wandering in code to find out which of your call in your code does something wrong, and so on) > In my ideal world, I'd love for there to be unit tests for everything.= I'm=20 >just not sure what level we can really achieve. If we create/enforce dr= aconian=20 >policies, I think the more likely scenario is people just stop writing n= ew code,=20 >and not that they write unit tests (and/or they fork the code to a versi= on such=20 >that they don't have to write unit tests). > > I'm certainly not saying unit tests are a bad thing. But I think we h= ave to=20 >keep in mind the people who are likely to write the tests. > > All that said, quick thoughts: > >1) Basic function/API tests should be easy to write in most cases (if I = call=20 >xyz(a,b) does it do the right thing). Those shouldn't be much an issue. > >2) A lot of the code operates on extensive external state (map data, arc= hetypes,=20 >etc). So to test the function, you need to have a map set up in the rig= ht way=20 >(right objects on the map, etc). > > In this case, you want something that makes such a test easy. What ma= y be=20 >easiest is in fact just a large set of test maps, and the unit test coul= d=20 >effectively hard code those, with known coordinates (test object being o= nly=20 >object at 0,0 and I know I want to insert that at 5,5) > =20 > That's the idea. If you want to test map behaviour X (like, let's say, the 'connected' behaviour in code), you write a map (with a few connected object), and write a test that check specific object status (the connection) after loading. Of course, as part of unit testing framework you need to write some helper methods like init_test_using_map(path_to_map). So along with the framework we need to provide a toolkit that will help writting testcase in specific area (eg, a network toolkit, map based test toolkit, a server initialisation toolkit and so on, that's the part that will take much of the time, but it will also be written only once) > My thinking here is that if I can write the basic test to reproduce th= e bug in=20 ><10 minutes, I'll probably write the test. IF the framework is such tha= t it=20 >will take me an hour, then I probably wouldn't. > =20 > If it take an hour to write a testcase for a specific bug that mean either it took you this time to find in which conditions a bug arise (i could even argue in some cases here writting a unit test helped us find those conditions faster) or the framework is so difficult to use that noone can use it (which is not the case for most framework). basically a unittest is just this - init needed server code (with toolkits, take 2 or 3 lines) - do some methods calls - check_for_some_condition(boolean condition, char* error_message_if_condition_not_met) - do some methods calls - check_for_some_condition(boolean condition, char* error_message_if_condition_not_met) - do some methods calls - check_for_some_condition(boolean condition, char* error_message_if_condition_not_met) - do some methods calls - check_for_some_condition(boolean condition, char* error_message_if_condition_not_met) - ... - test finished The main and the fixture creating code can nearly be cut and paste from any existing unit test. >3) If the number of tests grow, it is probably desirable to be able to r= un some=20 >specific subset of tests, eg, I don't want to have to wait 15 minutes fo= r the=20 >server to run all the tests when I'm trying to fix some specific bug - I= just=20 >want it to run my test. After all is done, then perhaps running all tes= ts=20 >before commit makes sense. > > =20 > Of course, you should be able to run a specific fixture, not all fixtures. Here at work, running all unit tests can take a few hours (well that's mainly because we also use a code test coverage tool which run all unit tests in debug mode). When we are doing changes, we only test them on a specific fixture or set of fixture, we do not run all testcase. Running all test cases is done at night from a cvs checkout an we get the report online. This way we can keep an eye on what's wrong. It is a good thing, for example, to run all those tests before a release. >_______________________________________________ >crossfire mailing list >crossfire at metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire > > =20 >