From nicolas.weeger at laposte.net Sat Nov 1 07:32:22 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 1 Nov 2008 13:32:22 +0100 Subject: [crossfire] Seeking life... Message-ID: <200811011332.27334.nicolas.weeger@laposte.net> Hello. So, anyone working on something? Anyone having plans for working on CF? Or can we close the shop down? I admit I'm not motivated at all lately. The code is a real mess, maps are pretty boring usually, and the game is going nowhere. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081101/cfa59ab4/attachment.pgp From leaf at real-time.com Sat Nov 1 13:51:13 2008 From: leaf at real-time.com (Rick Tanner) Date: Sat, 01 Nov 2008 13:51:13 -0500 Subject: [crossfire] Seeking life... In-Reply-To: <200811011332.27334.nicolas.weeger@laposte.net> References: <200811011332.27334.nicolas.weeger@laposte.net> Message-ID: <490CA521.4080104@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Weeger wrote: > Hello. > > So, anyone working on something? I've been working (and still working) on: * Giving maps unique names so the Map Index in Mapper is somewhat easier to use & find the map * Creating new regions, applying said region to maps * Updating descriptions for existing regions * I went through all the trunk maps and updated their level to something more appropriate; "Method" for this is documented in the wiki * Also, all the trunk maps had their entrance x & y coordinates corrected * Added shop header code to stores that was missing this; this still needs to happen with some of the shop template maps (these are the shops found in random maps) * Fixed a number of map bugs in the Chaos Lair * I plan on backporting the previous 4 changes to branches/1.x based on testing and feedback * Currently working on replacing the faces|graphics to Lake and River archetypes * Now that the server code has been updated, convert all payment altars so they accept all coins as payment instead of 1 particular coin type -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJDKUghHyvgBp+vH4RAtIHAJ4w/H3MGkc2FN6+o1mNs2LujOVYtQCg68ET BK22r5gkJAlTsLdP2biyxf4= =5/Sx -----END PGP SIGNATURE----- From mwedel at sonic.net Sun Nov 2 22:35:01 2008 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 02 Nov 2008 20:35:01 -0800 Subject: [crossfire] Seeking life... In-Reply-To: <200811011332.27334.nicolas.weeger@laposte.net> References: <200811011332.27334.nicolas.weeger@laposte.net> Message-ID: <490E7F75.7060802@sonic.net> Nicolas Weeger wrote: > Hello. > > So, anyone working on something? Anyone having plans for working on CF? Or can > we close the shop down? I've been fairly busy for the past few months on a kitchen remodel which took away my time from other projects - that's finishing up just now, so will be getting more into crossfire work again. I plan to resume work on rebalancing the spells. > I admit I'm not motivated at all lately. The code is a real mess, maps are > pretty boring usually, and the game is going nowhere. I can certainly understand some of that. I've run into th same feeling now and again. The one that we usually always come back to is new maps. As a long term player/developer, I've played most all the maps, and playing them over and over again isn't that interesting (when I do player commercial games, I'll tend to play them through once - it doesn't really interesting me to play the game again with a different character or play the same areas over and over again with that first character - I might go explore areas I haven't done yet, but more often than not, just stop playing that game. Given how often I play such games, that tends to work out - something new will come out. At some level, it is probably unrealistic to think that new maps can be created at a pace faster than they can be played - a lot of map makers would be needed. It takes quite a bit of time to make up a good map - certainly longer than it takes to play it. And perhaps the other side of that is that it can often be difficult to come up with good maps. Everyone could sit down and spend several hours a week doing new maps, but if they are uninspired maps (more of the same), I'm not sure how much is gained. One could just play the random maps for that type of experience. The flip side is that many of the maps are so old that they predate many features since added (lighting immediately comes to mind, but probably many other aspects), so even new maps of the same type of things may still be an improvement. From nicolas.weeger at laposte.net Mon Nov 3 11:57:02 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 3 Nov 2008 18:57:02 +0100 Subject: [crossfire] Seeking life... In-Reply-To: <490E7F75.7060802@sonic.net> References: <200811011332.27334.nicolas.weeger@laposte.net> <490E7F75.7060802@sonic.net> Message-ID: <200811031857.07657.nicolas.weeger@laposte.net> To sum up a discussion on the channel this morning: - there is no common goal, so everyone is doing his own stuff - there is no leadership who could define areas solutions: - define a common goal => need some leaders - enforce content rules (reject maps that don't integrate into the timeline / overall story) Nicolas Le lundi 03 novembre 2008, Mark Wedel a ?crit?: > Nicolas Weeger wrote: > > Hello. > > > > So, anyone working on something? Anyone having plans for working on CF? > > Or can we close the shop down? > > I've been fairly busy for the past few months on a kitchen remodel which > took away my time from other projects - that's finishing up just now, so > will be getting more into crossfire work again. > > I plan to resume work on rebalancing the spells. > > > I admit I'm not motivated at all lately. The code is a real mess, maps > > are pretty boring usually, and the game is going nowhere. > > I can certainly understand some of that. I've run into th same feeling > now and again. > > The one that we usually always come back to is new maps. As a long term > player/developer, I've played most all the maps, and playing them over and > over again isn't that interesting (when I do player commercial games, I'll > tend to play them through once - it doesn't really interesting me to play > the game again with a different character or play the same areas over and > over again with that first character - I might go explore areas I haven't > done yet, but more often than not, just stop playing that game. Given how > often I play such games, that tends to work out - something new will come > out. > > At some level, it is probably unrealistic to think that new maps can be > created at a pace faster than they can be played - a lot of map makers > would be needed. It takes quite a bit of time to make up a good map - > certainly longer than it takes to play it. And perhaps the other side of > that is that it can often be difficult to come up with good maps. Everyone > could sit down and spend several hours a week doing new maps, but if they > are uninspired maps (more of the same), I'm not sure how much is gained. > One could just play the random maps for that type of experience. > > The flip side is that many of the maps are so old that they predate many > features since added (lighting immediately comes to mind, but probably many > other aspects), so even new maps of the same type of things may still be an > improvement. > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081103/d3ab44be/attachment.pgp From juhaj at iki.fi Mon Nov 3 14:27:15 2008 From: juhaj at iki.fi (Juha =?utf-8?q?J=C3=A4ykk=C3=A4?=) Date: Mon, 03 Nov 2008 22:27:15 +0200 Subject: [crossfire] Seeking life... In-Reply-To: <200811031857.07657.nicolas.weeger@laposte.net> References: <200811011332.27334.nicolas.weeger@laposte.net> <490E7F75.7060802@sonic.net> <200811031857.07657.nicolas.weeger@laposte.net> Message-ID: <200811032227.24079.juhaj@iki.fi> > - there is no common goal, so everyone is doing his own stuff > - there is no leadership who could define areas > > solutions: > - define a common goal => need some leaders > - enforce content rules (reject maps that don't integrate into the timeline > / overall story) Heartily agreed! I have had no time for cf (I haven't even played it!) for over a year now. Expect this state of affairs to continue until next summer (with *very* good luck, just next January). At that point I'd be more than happy to take on any task given me by the leader(s). Do we need a leader election?-o -Juha -- ----------------------------------------------- | Juha J?ykk?, juolja at utu.fi | | home: http://www.utu.fi/~juolja/ | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081103/eae9a32c/attachment.pgp From leaf at real-time.com Mon Nov 3 14:31:25 2008 From: leaf at real-time.com (Rick Tanner) Date: Mon, 03 Nov 2008 14:31:25 -0600 Subject: [crossfire] Seeking life... In-Reply-To: <200811031857.07657.nicolas.weeger@laposte.net> References: <200811011332.27334.nicolas.weeger@laposte.net> <490E7F75.7060802@sonic.net> <200811031857.07657.nicolas.weeger@laposte.net> Message-ID: <490F5F9D.1030601@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Weeger wrote: > > - enforce content rules (reject maps that don't integrate into the timeline / > overall story) There was a in-game timeline related discussion on the IRC channel earlier today (Nov-03). I proposed, and will now be writing, lore that relates to and explains a possible reason or cause for maps to reset and allow players to run through them over and over again, why sometimes the server crashes, why player characters seem to be unaffected by these events. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJD1+dhHyvgBp+vH4RAnkJAKDuE2xbmIQkVz1V3YZVjGbWjx/7/QCg0wwb 38vo0oMki0wgl1Oi4jAuaUk= =cr+/ -----END PGP SIGNATURE----- From leaf at real-time.com Mon Nov 3 14:40:58 2008 From: leaf at real-time.com (Rick Tanner) Date: Mon, 03 Nov 2008 14:40:58 -0600 Subject: [crossfire] Seeking life... In-Reply-To: <200811031857.07657.nicolas.weeger@laposte.net> References: <200811011332.27334.nicolas.weeger@laposte.net> <490E7F75.7060802@sonic.net> <200811031857.07657.nicolas.weeger@laposte.net> Message-ID: <490F61DA.4090609@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Weeger wrote: > > - there is no common goal, so everyone is doing his own stuff What about the TODO list(s) on the wiki? http://wiki.metalforge.net/doku.php/dev_todo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJD2HZhHyvgBp+vH4RAk5KAKDVi7ZhotWz3eKv4mqU3DNPNtaHRACg97D7 4KZ9tsWRa06hxmqfvjzRkcI= =sDaS -----END PGP SIGNATURE----- From crossfire at ailesse.com Tue Nov 4 00:27:42 2008 From: crossfire at ailesse.com (Lauwenmark Akkendrittae) Date: Tue, 4 Nov 2008 07:27:42 +0100 Subject: [crossfire] Seeking life... In-Reply-To: <490F61DA.4090609@real-time.com> References: <200811011332.27334.nicolas.weeger@laposte.net> <200811031857.07657.nicolas.weeger@laposte.net> <490F61DA.4090609@real-time.com> Message-ID: <200811040728.05437.crossfire@ailesse.com> Le lundi 3 novembre 2008, Rick Tanner a ?crit : > Nicolas Weeger wrote: > > - there is no common goal, so everyone is doing his own stuff > > What about the TODO list(s) on the wiki? > > http://wiki.metalforge.net/doku.php/dev_todo > The TODO list is nothing more than the recollection of all ideas that were thought about. It makes no effort to coordinate the work, doesn't deal with feature priorities, and covers so many areas that it fails to give the project a clear direction to follow. What is worse is that - as you yourself underlined in your message - there is not *a* TODO List; there are *several* ones: Majro Releases, Fixes/Revamps, Feature-Based, Concepts, and even a User-based one! This is exactly what Nicolas was writing about: no common goal, everybody doing its own stuff (in this case, TODO lists). A clarified, cleaned-up TODO is of course a useful tool to coordinate project efforts - but as it stands now, it is IMHO not even usable for that simple purpose. -- Lauwenmark. ------------ "Drive defensively: buy a tank." -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081104/f46548d7/attachment.pgp From crossfire at ailesse.com Tue Nov 4 00:38:16 2008 From: crossfire at ailesse.com (Lauwenmark Akkendrittae) Date: Tue, 4 Nov 2008 07:38:16 +0100 Subject: [crossfire] Seeking life... In-Reply-To: <490F5F9D.1030601@real-time.com> References: <200811011332.27334.nicolas.weeger@laposte.net> <200811031857.07657.nicolas.weeger@laposte.net> <490F5F9D.1030601@real-time.com> Message-ID: <200811040738.17667.crossfire@ailesse.com> Le lundi 3 novembre 2008, Rick Tanner a ?crit : > Nicolas Weeger wrote: > > - enforce content rules (reject maps that don't integrate into the > > timeline / overall story) > > There was a in-game timeline related discussion on the IRC channel > earlier today (Nov-03). > > I proposed, and will now be writing, lore that relates to and explains a > possible reason or cause for maps to reset and allow players to run > through them over and over again, why sometimes the server crashes, why > player characters seem to be unaffected by these events. > Are we sure it is a good idea to make that ? Quoting what somebody else said about such an idea: "I figured it would detract from suspension of disbelief and immersibility of the game" Something I tend to agree with. Thoughts ? -- Lauwenmark. ------------ "Drive defensively: buy a tank." -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081104/245de2ff/attachment-0001.pgp From mwedel at sonic.net Thu Nov 6 00:12:58 2008 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 05 Nov 2008 22:12:58 -0800 Subject: [crossfire] Seeking life... In-Reply-To: <200811031857.07657.nicolas.weeger@laposte.net> References: <200811011332.27334.nicolas.weeger@laposte.net> <490E7F75.7060802@sonic.net> <200811031857.07657.nicolas.weeger@laposte.net> Message-ID: <49128AEA.7090603@sonic.net> Nicolas Weeger wrote: > To sum up a discussion on the channel this morning: > > - there is no common goal, so everyone is doing his own stuff > - there is no leadership who could define areas > > solutions: > - define a common goal => need some leaders > - enforce content rules (reject maps that don't integrate into the timeline / > overall story) The harder part is perhaps that first one - finding leaders. I know I'm the current maintainer of crossfire, but when I took that job way back when, I had a lot more time on my hands than I do now. And to be honest, the administrative aspect is one of the less interesting aspects of all of this. Given the number of current developers, the number of leaders needed probably isn't that great. If we had 100 developers, you'd clearly want multiple leaders handling different aspects (as that 100 people would be working on different parts most likely - even if everyone was doing maps, it would be different areas, so you could have the person in charge of scorn, person in charge of navar city area, etc). I'd actually say that the common goal(s) could likely be sorted out in e-mail or on IRC - that perhaps isn't so much a job for the leader. The leader is more on the second point - to make sure that contributions don't conflict with the goal. From nicolas.weeger at laposte.net Sat Nov 8 04:45:01 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 8 Nov 2008 11:45:01 +0100 Subject: [crossfire] Seeking life... In-Reply-To: <49128AEA.7090603@sonic.net> References: <200811011332.27334.nicolas.weeger@laposte.net> <200811031857.07657.nicolas.weeger@laposte.net> <49128AEA.7090603@sonic.net> Message-ID: <200811081145.05849.nicolas.weeger@laposte.net> Hello. > The harder part is perhaps that first one - finding leaders. I wouldn't mind being coding leader, but then right now the conditions aren't really met. Code is here to be used for the game, it is not the game. Therefore, if there is nothing going on game-wise, then it's no use having a "living" code. I do admit liking coding, which is sometimes more important for me than content, unfortunately. Therefore we'd need a good game content leader who can make the game really fun and drive development needs. I mean by "content leader" someone who can point out needs to be filled (missing a town linked to such and such story), accept or reject (saying why it is rejected) content submissions, who takes into account the whole coherence of the world and the background story, and such. And lately since there is no new content, no need to drive the development, nothing really going on, coding for CF has become some really uninteresting idea (and I admit the code is starting to be quite messy which is not helping, either). For the record here is what I'd like to do technically-wise: - stable server, few bugs (obvious, and not that far a goal right now) - distributed server, crash-recovery systems: server crashes, clients dynamically or transparently switch to another and go on playing maybe without even noticing - at least with minimal loss - dynamic updating of resources - no need to recollect archetypes to take into account an archetype change, or a pic change - regular releases (anyone remembers when the last one was?), as long as there is justification for that and in coordination with content leader And to achieve this: - well documented code, potentially linked to game features (monks shouldn't be able to wear weapons: how is it managed in the code, at which places? and such things) - unit tests where applicable - automate many things (win32 building and packaging, ...) - split the code to make it less messy. Do small atomic tasks, and chain them, instead of having one big code mess that does a zillion things and can't be easily replaced - move to C++, use Trolltech's Qt toolkit, and make a massive code refactoring (note: please don't start discussing those last points / how I'd like to do things, this is not the thread for such a discussion that I will happily ignore anyway) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081108/8879fa85/attachment.pgp From nicolas.weeger at laposte.net Sat Nov 8 13:05:51 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 8 Nov 2008 20:05:51 +0100 Subject: [crossfire] Crossfire Resource Editor Message-ID: <200811082005.55330.nicolas.weeger@laposte.net> Hello. I've just committed to trunk utils/cre a first basic version of a tool I've called "Crossfire Resource Editor". This is for now a mere display of animations, archetypes, treasures, artifacts, alchemy formulea, but it may someday become something enabling edition (simple things like formulea aren't that hard I think). There is some framework around that, don't worry if you find buttons or such. This tool is written in C++/Qt (probably requiring a recent version of this toolkit), and is not part of CF's standard build process. Just "cd utils/cre && qmake && make" to build it (need to have CF itself built before, at least the "common" directory). Suggestions for improvements are welcome, bug reports too :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081108/7c4f1552/attachment.pgp From nicolas.weeger at laposte.net Sun Nov 9 02:43:39 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 9 Nov 2008 09:43:39 +0100 Subject: [crossfire] Seeking life... In-Reply-To: <200811040738.17667.crossfire@ailesse.com> References: <200811011332.27334.nicolas.weeger@laposte.net> <490F5F9D.1030601@real-time.com> <200811040738.17667.crossfire@ailesse.com> Message-ID: <200811090943.43186.nicolas.weeger@laposte.net> > Are we sure it is a good idea to make that ? Quoting what somebody else > said about such an idea: > > "I figured it would detract from suspension of disbelief and immersibility > of the game" > > Something I tend to agree with. Thoughts ? I would say it really depends how it is written :) On the other hand, it would be nice to have explanations for word of recall, the bed to reality, death penalty, and such ^_- Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081109/616a27dd/attachment.pgp From nicolas.weeger at laposte.net Sun Nov 9 12:21:00 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 9 Nov 2008 19:21:00 +0100 Subject: [crossfire] Suggestion from the feature request tracker Message-ID: <200811091921.03893.nicolas.weeger@laposte.net> Hello. There are quite ideas on the feature request tracker, if anyone feels like using some? Assuming they fit CF, of course :) https://sourceforge.net/tracker/index.php?func=detail&aid=2092692&group_id=13833&atid=363833 monk rebalance https://sourceforge.net/tracker/index.php?func=detail&aid=2084791&group_id=13833&atid=363833 farming https://sourceforge.net/tracker/index.php?func=detail&aid=2022608&group_id=13833&atid=363833 no regen cap perk https://sourceforge.net/tracker/index.php?func=detail&aid=2022597&group_id=13833&atid=363833 https://sourceforge.net/tracker/index.php?func=detail&aid=2022576&group_id=13833&atid=363833 and such we definitely need some content leader that could direct the development team and maybe put those ideas to use :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081109/589887f1/attachment.pgp From mwedel at sonic.net Sun Nov 9 22:37:43 2008 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 09 Nov 2008 20:37:43 -0800 Subject: [crossfire] Seeking life... In-Reply-To: <200811081145.05849.nicolas.weeger@laposte.net> References: <200811011332.27334.nicolas.weeger@laposte.net> <200811031857.07657.nicolas.weeger@laposte.net> <49128AEA.7090603@sonic.net> <200811081145.05849.nicolas.weeger@laposte.net> Message-ID: <4917BA97.8060601@sonic.net> Nicolas Weeger wrote: > Hello. > >> The harder part is perhaps that first one - finding leaders. > > I wouldn't mind being coding leader, but then right now the conditions aren't > really met. > Code is here to be used for the game, it is not the game. Therefore, if there > is nothing going on game-wise, then it's no use having a "living" code. > > I do admit liking coding, which is sometimes more important for me than > content, unfortunately. > > Therefore we'd need a good game content leader who can make the game really > fun and drive development needs. I think that is really the crux of the problem - it seems to me that most of the developers are code developers, not content developers. I certainly include myself in that category. There are certainly some folks out there that do work on content - I don't mean to say that there aren't. Having a leader of content doesn't do a lot if there are not many folks willing to write that content. So the question may be how many folks would move from doing code to content if that was the drive, and how many really just want to do code. > > I mean by "content leader" someone who can point out needs to be filled > (missing a town linked to such and such story), accept or reject (saying why > it is rejected) content submissions, who takes into account the whole > coherence of the world and the background story, and such. > > And lately since there is no new content, no need to drive the development, > nothing really going on, coding for CF has become some really uninteresting > idea (and I admit the code is starting to be quite messy which is not > helping, either). I don't necessarily know of those two are related. I know various folks have done various big projects that were not really driven by content, but rather this would be a nice feature. And in fact, your list below also falls into that - those are not drive by content, but rather features that might be nice. > > > For the record here is what I'd like to do technically-wise: > - stable server, few bugs (obvious, and not that far a goal right now) > - distributed server, crash-recovery systems: server crashes, clients > dynamically or transparently switch to another and go on playing maybe > without even noticing - at least with minimal loss > - dynamic updating of resources - no need to recollect archetypes to take into > account an archetype change, or a pic change > - regular releases (anyone remembers when the last one was?), as long as there > is justification for that and in coordination with content leader IMO, this sort of falls back to the past problems - from discussions, it seems that the most pressing need/desire in crossfire is new/better content, but that list above doesn't really address that at all. I don't mean to say that those are bad ideas, and in fact some may be quite good, and at least for some of them, I would have comments/questions, but that doesn't really seem to be a focus right now (and you say so yourself). There are some other things I'd add to that also. From crossfire at ailesse.com Mon Nov 10 07:46:24 2008 From: crossfire at ailesse.com (Lauwenmark Akkendrittae) Date: Mon, 10 Nov 2008 14:46:24 +0100 Subject: [crossfire] Seeking life... In-Reply-To: <4917BA97.8060601@sonic.net> References: <200811011332.27334.nicolas.weeger@laposte.net> <200811081145.05849.nicolas.weeger@laposte.net> <4917BA97.8060601@sonic.net> Message-ID: <200811101446.25458.crossfire@ailesse.com> Le lundi 10 novembre 2008, Mark Wedel a ?crit : > I think that is really the crux of the problem - it seems to me that most > of the developers are code developers, not content developers. I certainly > include myself in that category. > > There are certainly some folks out there that do work on content - I > don't mean to say that there aren't. > Frankly, it is hard to keep working on content if nobody follows. Or, for what matters, if everybody keeps ignoring what the others are doing. It makes the writing of consistent material impossible, plain and simple. > Having a leader of content doesn't do a lot if there are not many folks > willing to write that content. So the question may be how many folks would > move from doing code to content if that was the drive, and how many really > just want to do code. > I doubt counting the devs and the map designers would solve the issue at hand. We need somebody that establishes coordination and allocate the limited content development resources we have in the best way. Somebody that can also organize advertisement to gather more content makers. Besides that, resuming the issue as a lack of content-makers is somewhat dodging the central point of coordination and cooperation. We obviously have more than enough coders available, yet how many major changes happened recently in the source ? > IMO, this sort of falls back to the past problems - from discussions, it > seems that the most pressing need/desire in crossfire is new/better > content, but that list above doesn't really address that at all. > Again, the problem is not what kind of features are needed, but how we can organize the development resources so those features can be implemented (being scenarios, maps, graphisms or code parts). Lauwenmark. ------------ "Drive defensively: buy a tank." -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081110/149fd996/attachment.pgp From leaf at real-time.com Mon Nov 10 12:35:02 2008 From: leaf at real-time.com (Rick Tanner) Date: Mon, 10 Nov 2008 12:35:02 -0600 Subject: [crossfire] Crossfire Resource Editor In-Reply-To: <200811082005.55330.nicolas.weeger@laposte.net> References: <200811082005.55330.nicolas.weeger@laposte.net> Message-ID: <49187ED6.8010602@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Weeger wrote: > > This tool is written in C++/Qt (probably requiring a recent version of this > toolkit), and is not part of CF's standard build process. Just "cd utils/cre > && qmake && make" to build it (need to have CF itself built before, at least > the "common" directory). I had to install qt4-dev-tools (Ubuntu Intrepid Ibex 8.10) for the compile to work. The compile failed with qt3-dev-tools. Just passing this along in case anyone else runs in to this as well. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJGH7WhHyvgBp+vH4RAtCqAJsEaYBGSSOI0BC5OBFiKLGYJJbV6gCeOzUE 4OomvaLK31AsqfT+fMAnmBo= =0qyw -----END PGP SIGNATURE----- From leaf at real-time.com Tue Nov 11 13:23:26 2008 From: leaf at real-time.com (Rick Tanner) Date: Tue, 11 Nov 2008 13:23:26 -0600 Subject: [crossfire] Recent archetype and server change Message-ID: <4919DBAE.70705@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Two recent changes were made to the server artifact file and archetype treasure and orc treasure file in an attempt to make Crossfire more friendly to new players and to close an abused item in another. These changes were only made in Trunk. Revision: 10395 http://crossfire.svn.sourceforge.net/crossfire/?rev=10395&view=rev arch/trunk/monster/goblin/orc.trs arch/trunk/treasures.trs This change will hopefully make more money available for new players so they can afford to use the detect magic, detect curse and ID altars. Acquiring money at low levels is very challenging to a new & low level player. Revision: 10396 http://crossfire.svn.sourceforge.net/crossfire/?rev=10396&view=rev server/trunk/lib/artifacts Gourmet Mushrooms are very easy to make and sell for a very high cost. This is often abused (exploited?) and results in massive fortune for the player who takes the time (or uses scripts) to make these items. The selling cost of the mushroom has been reduced. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJGduuhHyvgBp+vH4RAnYHAKDMdEXHKOsLroaH0Us49kXijcm2lgCgm4q9 DN6WO5QmJ+gX0OQ3RXo2Z5c= =vlVL -----END PGP SIGNATURE----- From nicolas.weeger at laposte.net Thu Nov 13 16:50:59 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 13 Nov 2008 23:50:59 +0100 Subject: [crossfire] Gameplay Message-ID: <200811132351.05888.nicolas.weeger@laposte.net> Hello. Currently, Crossfire is the kind "many monsters, much loot, fast gameplay". Wouldn't it make sense to change that? Have less monsters, with combats not so fast, so strategy/tactics do play a role - put a trap, try to lure the monster? use a dagger for close combat, versus a sword for long distance? Think of where to drive monsters so only one can hit you, and such? As for loot, wouldn't it make sense to drastically reduce it, and let players create new things (items, spells, buildings maybe?) quite freely? But with some limits, probably. Also, wouldn't it make sense to really improve in game building, so players can have a real impact on the world, really change things? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081113/b38c6fe8/attachment.pgp From mwedel at sonic.net Fri Nov 14 00:32:11 2008 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 13 Nov 2008 22:32:11 -0800 Subject: [crossfire] Gameplay In-Reply-To: <200811132351.05888.nicolas.weeger@laposte.net> References: <200811132351.05888.nicolas.weeger@laposte.net> Message-ID: <491D1B6B.7050507@sonic.net> Nicolas Weeger wrote: > Hello. > > Currently, Crossfire is the kind "many monsters, much loot, fast gameplay". > > Wouldn't it make sense to change that? Yes - in fact, the combat changes I made many months back did that a bit for combat - in general, just normal combat is slower than before. However, there are stills gobs of monsters (and I still need to redo spells) > > Have less monsters, with combats not so fast, so strategy/tactics do play a > role - put a trap, try to lure the monster? use a dagger for close combat, > versus a sword for long distance? Think of where to drive monsters so only > one can hit you, and such? Yes to all of those. Some are certainly easier than others. It is a little less clear where close vs far come in - I'd think that both dagger and sword would be close (vs bow being far) - with the granularity of one space, distance is a little odd in that regard. But one could clearly extend things beyond what they are - able to increase your chance of hit but you do less damage. Or another method to increase your damage, but maybe you're AC is worse. Or maybe various combos. This actually could be useful in many ways - when rebalancing combat, sorting out AC for monsters vs WC for players can be a challenge. When the random element is from the range of 1-20, figuring out what the correct value is gets hard - I generally targeted it at about 10-15 range If it is too low (say 5) then player is hitting most of the time, and things that improve your chance to hit don't have much impact (the number of additional hits you get isn't that great). If it is too high (say 18), then player hits pretty infrequently - makes for long combat, but also means attacks that don't have to hit the creature (like spells) are much more useful. It also means that other characters that maybe do not have the right items or stats, and thus need a 20, hit only 1/3rd the time, and the monster is that much tougher. If player can give up damager to hit better, it helps that out - player who needs an 18 can use that attack form to need a 15 (lets say) and hit twice as often, but maybe at only a 25% decrease in damage. But if the player needs a 5 to hit, reducing that a 2 may not be a worth while tradeoff - it does put more strategy in to best ways to kill monsters, and give more choices for monsters that may seem too tough. But improved monster smarts is also needed - the monsters right now all think individually (what can I do to hurt that player). Most games have the group of monsters actually work together - some may sit back casting spells while others engage the player. And they may actually cast beneficial spells on the other creatures - right now, the monster logic doesn't even look at that possibility. > > > As for loot, wouldn't it make sense to drastically reduce it, and let players > create new things (items, spells, buildings maybe?) quite freely? But with > some limits, probably. Yes on both. Perhaps the basic flaw in the crossfire logic is that all equipment a monster may attack with ends up as loot to scavenge. So you fight those 20 orcs, and get 20 long swords. But I'd be more tempted to do the reduction of monsters first, and see how loot looks after that. If a level only had 20 monsters and not 100, that a big reduction right there - maybe much more isn't needed. The other big problem is that crossfire doesn't have much to spend money on - presumably some of those other points (making new things) is a money sink. Another may be more consumable objects that players would actually want to buy. > > Also, wouldn't it make sense to really improve in game building, so players > can have a real impact on the world, really change things? Yes, but also trickier. In game building has been discussed (and even developed) many times, but that is a hard problem to solve. By my above comments (hard problems) I don't mean in any way to say that they shouldn't be done - just trying put the problem in some degree of difficulty. Of that list, reducing monsters is probably the easiest to do - that just means going through maps and removing monsters and generators. As an add-on to that, I'd still like to see a quest management system that also provides rewards in exp or spells or the like, so that the only way to get that isn't by killing monsters (this can also be done now just by updating maps). From nicolas.weeger at laposte.net Sat Nov 15 12:09:13 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 15 Nov 2008 19:09:13 +0100 Subject: [crossfire] Gameplay In-Reply-To: <491D1B6B.7050507@sonic.net> References: <200811132351.05888.nicolas.weeger@laposte.net> <491D1B6B.7050507@sonic.net> Message-ID: <200811151909.17187.nicolas.weeger@laposte.net> > As an add-on to that, I'd still like to see a quest management system > that also provides rewards in exp or spells or the like, so that the only > way to get that isn't by killing monsters (this can also be done now just > by updating maps). Yet again I'll remind you: YOU CAN ALREADY GIVE EXPERIENCE FOR SOME EVENTS See http://wiki.metalforge.net/doku.php/dev_todo:experience_rewarder But of course no one is actually using it, not like it's useful is it? Also, I'll YET AGAIN tell on the list that, if map makers actually need scripts, I'm ready to write them, or help when needed. BUT I WON'T WRITE SCRIPTS FOR THE SAKE OF IT, IT MUST BE FOR SOME SPECIFIC NEED - I'm fed up writing things "for the sake of it that no one will use". Nicolas, pissed off -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081115/bb927823/attachment.pgp From nicolas.weeger at laposte.net Sun Nov 16 13:05:18 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 16 Nov 2008 20:05:18 +0100 Subject: [crossfire] Turning transport Message-ID: <200811162005.22575.nicolas.weeger@laposte.net> Hello. I've just committed an archetype, a test map and some server code enabling to have transports that don't occupy the same space depending on the facing. Check arch/transport/turningboat.* for an example, or maps/test/boat to see it into action. Warning: this only works for a transport that is defined as a square (the code will simply *assert* if this isn't the case - you don't want that :)). Basically, the server will update the move_type of the various parts according to the direction. This is slightly hacky, but I can live with that (for now). Note that, in the future, it should probably be expanded to eg monsters. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081116/b9d9e29a/attachment.pgp From nicolas.weeger at laposte.net Mon Nov 17 13:07:37 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 17 Nov 2008 20:07:37 +0100 Subject: [crossfire] C++/Qt server version Message-ID: <200811172007.40625.nicolas.weeger@laposte.net> Hello. I do plan to have a C++/Qt (core only, no X dependency) version of the server, with advanced stuff (dynamic archetype loading, ...). I do expect / want this version to become the official server ("winning" on features, hopefully :)). But I definitely don't want a fork, so I'd like to work on CF's SVN server. So two options: - I work directly on trunk - my preferred option, considering it's "unstable" since some years, and doesn't seem to be soon stable, not much work going on it - I make a branch and work there - and if needed / when we want we merge to trunk Opinions? Note that this isn't for tomorrow, some stuff to finish before, maybe in a few weeks :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081117/5fd7be94/attachment.pgp From lalo.martins at gmail.com Mon Nov 17 17:49:07 2008 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 17 Nov 2008 23:49:07 +0000 (UTC) Subject: [crossfire] C++/Qt server version References: <200811172007.40625.nicolas.weeger@laposte.net> Message-ID: quoth Nicolas Weeger (Mon, 17 Nov 2008 20:07:37 +0100): > So two options: > - I work directly on trunk - my preferred option, considering it's > "unstable" since some years, and doesn't seem to be soon stable, not > much work going on it > - I make a branch and work there - and if needed / when we want we merge > to trunk I'd like to propose that the best alternative is a third one: You work on trunk, but tag (or even branch) the last revision before the C++ transition. -- I'm using a laptop and forgot to copy my signature file. For the moment, whatever info you want is probably at http://lalomartins.info/ or thereabouts... From kbulgrien at worldnet.att.net Mon Nov 17 18:03:00 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Mon, 17 Nov 2008 18:03:00 -0600 Subject: [crossfire] C++/Qt server version In-Reply-To: <200811172007.40625.nicolas.weeger@laposte.net> References: <200811172007.40625.nicolas.weeger@laposte.net> Message-ID: <200811171803.00738.kbulgrien@worldnet.att.net> > I do plan to have a C++/Qt (core only, no X dependency) version of the > server, with advanced stuff (dynamic archetype loading, ...). I have seen C++ messes that I would hate to see in CF, but then it is well known that you see current CF code as a mess in itself, so perhaps it has potential for cleaning up the code... > I do expect / want this version to become the official server ("winning" on > features, hopefully :)). > > But I definitely don't want a fork, so I'd like to work on CF's SVN server. > > So two options: > - I work directly on trunk - my preferred option, considering it's > "unstable" since some years, and doesn't seem to be soon stable, not much > work going on it I depend on trunk not being broken so that I can test and develop things on trunk. I no longer have interest in working on branch. I play only 2.x servers. I do not want trunk broken (for long periods) as that will only be a detriment to play testing and developing what is on trunk now. This is how I work on content - a topic on which you are most vociferous. > - I make a branch and work there - and if needed / when we want we merge to > trunk While I recognize branching is a pain at times from my libglade effort in the client, it is my preference if I read your intentions correctly - it sounds basically like a huge rewrite. Whether the branch be of the whole project or only portions that will be broken for some time is not really a concern. > Opinions? > > Note that this isn't for tomorrow, some stuff to finish before, maybe in a > few weeks :) > > Nicolas Kevin From kbulgrien at worldnet.att.net Mon Nov 17 18:56:05 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Mon, 17 Nov 2008 18:56:05 -0600 Subject: [crossfire] C++/Qt server version In-Reply-To: <200811171803.00738.kbulgrien@worldnet.att.net> References: <200811172007.40625.nicolas.weeger@laposte.net> <200811171803.00738.kbulgrien@worldnet.att.net> Message-ID: <200811171856.05241.kbulgrien@worldnet.att.net> > > So two options: > > - I work directly on trunk - my preferred option, considering it's > > "unstable" since some years, and doesn't seem to be soon stable, not much > > work going on it > > I depend on trunk not being broken so that I can test and develop things on > trunk. I no longer have interest in working on branch. I play only 2.x > servers. I do not want trunk broken (for long periods) as that will only > be a detriment to play testing and developing what is on trunk now. This > is how I work on content - a topic on which you are most vociferous. > > > - I make a branch and work there - and if needed / when we want we merge > > to trunk > > While I recognize branching is a pain at times from my libglade effort in > the client, it is my preference if I read your intentions correctly - it > sounds basically like a huge rewrite. Whether the branch be of the whole > project or only portions that will be broken for some time is not really a > concern. > > > Opinions? I guess a better way to say it is similar to Lalo's reply. It would not be that big of a deal if the rewrite left the present 2.x operational in some way... so branching what is now 2.x could be viable to reduce the pain of working a total rewrite without sacrificing the ability to advance 2.x in case the rewrite takes a long time to get functional. Kevin From mwedel at sonic.net Tue Nov 18 01:42:14 2008 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 17 Nov 2008 23:42:14 -0800 Subject: [crossfire] Gameplay In-Reply-To: <200811151909.17187.nicolas.weeger@laposte.net> References: <200811132351.05888.nicolas.weeger@laposte.net> <491D1B6B.7050507@sonic.net> <200811151909.17187.nicolas.weeger@laposte.net> Message-ID: <492271D6.10509@sonic.net> Nicolas Weeger wrote: >> As an add-on to that, I'd still like to see a quest management system >> that also provides rewards in exp or spells or the like, so that the only >> way to get that isn't by killing monsters (this can also be done now just >> by updating maps). > > Yet again I'll remind you: YOU CAN ALREADY GIVE EXPERIENCE FOR SOME EVENTS > See http://wiki.metalforge.net/doku.php/dev_todo:experience_rewarder > But of course no one is actually using it, not like it's useful is it Yes - I know about that - but there isn't any mechanism to actually manage quests in any way. What quests is my character working on? Status of those quests (granted, vast majority of crossfire quests are simple quests - you get the quest, go out and do some single item, and return for reward). Better quests are more sophisticated - several steps to go through before completing it. The experience rewarder is a piece of good quests that is done - but still nothing there to manage/track quests. A problem I think this results in is very linear/directed gameplay - once I learn about something, I'm going to go off and do it, because I don't otherwise have a good way to track different things (other than copying them to out of game mechanisms). I remember a quest management system was written, and then removed with something better to replace it. That better thing to replace it hasn't shown up yet. And I think that would be one of those things to improve gameplay, which is what started this discussion. From mwedel at sonic.net Tue Nov 18 02:01:47 2008 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 18 Nov 2008 00:01:47 -0800 Subject: [crossfire] C++/Qt server version In-Reply-To: <200811172007.40625.nicolas.weeger@laposte.net> References: <200811172007.40625.nicolas.weeger@laposte.net> Message-ID: <4922766B.1050903@sonic.net> Nicolas Weeger wrote: > Hello. > > I do plan to have a C++/Qt (core only, no X dependency) version of the server, > with advanced stuff (dynamic archetype loading, ...). > > I do expect / want this version to become the official server ("winning" on > features, hopefully :)). > > But I definitely don't want a fork, so I'd like to work on CF's SVN server. Seems like a sort of odd decision since most recent conversations have seemed to have decided that more content and less code work is what is really needed to be done, but this seems to be a big code project... And just given the size and changes of the project, I'd like to see more detailed information - this isn't a minor change being made here. I also wonder that given such a rewrite if maybe a more drastic approach is needed. IMO, one reason for the messy/bad code is to maintain compatibility - new things are added, but don't want to break old maps/archetypes/whatever. I think some things could be simplified a great deal (or made more efficient) if it was considered OK to break some of that compatibility - this may mean lots of maps need updating, but if you're going to do a major rewrite, it may be an overall plus just to give up on some of that compatility for clean code. I do remember a long time ago someone else looked at doing crossfire in C++, and his decision was basically to do it from scratch - better to write something that meets the functional spec than to try and figure out what all that code does, etc. But that is clearly a larger project. A plus is that with a complete re-write, one could at least architect it for certain things. But then you start asking questions on what is crossfire really, etc. > > So two options: > - I work directly on trunk - my preferred option, considering it's "unstable" > since some years, and doesn't seem to be soon stable, not much work going on > it unstable can have various meanings. One could be it constantly crashes/is unreliable. Another could be that that the interfaces/features are not fixed and can change with short notice. I'd consider the trunk in that second category - I don't think it cores all the time, but rather it was made unstable so changes could be made without worrying about breaking existing characters, etc. > - I make a branch and work there - and if needed / when we want we merge to > trunk > > Opinions? I think it sort of depends on the expected development model. But I'd generally say do it as a branch. If individual changes were limited in scope to a few files and were basically complete at each commit, then maybe working directly in trunk would be OK. But changing languages would seem that that is less likely case. . The flip side is also that if not many changes are being made in the trunk, it should generally be fairly easy to keep up to sync (there aren't changes be made that requires syncing up, etc) I do have some concerns like Kevin's, in that the rewrite could take a long time (I have no idea on your expected schedule on this, so maybe not). I'd actually be more concerned that the trunk gets left in some hybrid state - some stuff rewritten, some stuff not, and unclear if having 30% of it rewritten in C++/Qt and rest be old C is better than 100% in old C. From crossfire at ailesse.com Tue Nov 18 06:24:45 2008 From: crossfire at ailesse.com (Lauwenmark Akkendrittae) Date: Tue, 18 Nov 2008 13:24:45 +0100 Subject: [crossfire] C++/Qt server version In-Reply-To: <200811172007.40625.nicolas.weeger@laposte.net> References: <200811172007.40625.nicolas.weeger@laposte.net> Message-ID: <200811181324.57493.crossfire@ailesse.com> Le lundi 17 novembre 2008, Nicolas Weeger a ?crit : > Hello. > > I do plan to have a C++/Qt (core only, no X dependency) version of the > server, with advanced stuff (dynamic archetype loading, ...). > > I do expect / want this version to become the official server ("winning" on > features, hopefully :)). > > But I definitely don't want a fork, so I'd like to work on CF's SVN server. > > So two options: > - I work directly on trunk - my preferred option, considering it's > "unstable" since some years, and doesn't seem to be soon stable, not much > work going on it > - I make a branch and work there - and if needed / when we want we merge to > trunk > > Opinions? > > Note that this isn't for tomorrow, some stuff to finish before, maybe in a > few weeks :) > > Nicolas From past experience, I'd tend to lean towards writing a server code "from scratch", possibly recycling various elements by cut'n'paste, instead of evolving a codebase that is already of questionable cleanliness. This would also need to lay down a code architecture, split this into tasks, and establish a development schedule. It also obviously require a coding team - the scale of the task would require it to achieve decent results in an acceptable development time. My main concern is that by using the current code base without a solid design map, the result would mostly be a "Crossfire with Qt extensions" - most griefs I have towards the current code are architectural, and I'm not sure an incremental approach would allow to really solve them. Finally, from your message content, it is hard not to see the intend as being more "using Qt" than "providing something new". Although I strongly believe myself that the use of C++/Qt can lead to a more flexible, less complex code, I wouldn't go on Qt just for the sake of it: why you want to do that and with which planned advantages in terms of features/stability is what I'd want to be defined before judging on my position about this. -- Lauwenmark. ------------ "Drive defensively: buy a tank." -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081118/8931c236/attachment.pgp From agschult at ucalgary.ca Thu Nov 20 02:20:00 2008 From: agschult at ucalgary.ca (Alex Schultz) Date: Thu, 20 Nov 2008 01:20:00 -0700 Subject: [crossfire] C++/Qt server version In-Reply-To: <200811172007.40625.nicolas.weeger@laposte.net> References: <200811172007.40625.nicolas.weeger@laposte.net> Message-ID: <20081120012000.0ceea73b@ucalgary.ca> On Mon, 17 Nov 2008 20:07:37 +0100 Nicolas Weeger wrote: > Hello. > > I do plan to have a C++/Qt (core only, no X dependency) version of > the server, with advanced stuff (dynamic archetype loading, ...). Well, one thought, is there any reason Qt-core as opposed Boost C++ perhaps? If I understand correctly, they provide similar faculties but Boost C++ also provides some rather nice looking python bindings that may make it far easier to move cfpython to a C++ code style. I'm not saying anything is wrong with Qt-core, and I've never actually used it or Boost C++ for that matter, but I'm just wondering if should maybe be considered, as it may have merits. That said, as you're likely going to be the main person in this code effort, simply having more experience with QT-core than Boost C++ can be a significant and quite valid factor. > So two options: > - I work directly on trunk - my preferred option, considering it's > "unstable" since some years, and doesn't seem to be soon stable, not > much work going on it > - I make a branch and work there - and if needed / when we want we > merge to trunk Not too much of a strong opinion, except that if you do work on trunk there should be either a tag or branch made for the current state of trunk. Best of luck, Alex Schultz From nicolas.weeger at laposte.net Mon Nov 24 09:19:04 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 24 Nov 2008 16:19:04 +0100 Subject: [crossfire] C++/Qt server version In-Reply-To: <200811171803.00738.kbulgrien@worldnet.att.net> References: <200811172007.40625.nicolas.weeger@laposte.net> <200811171803.00738.kbulgrien@worldnet.att.net> Message-ID: <200811241619.07770.nicolas.weeger@laposte.net> > I have seen C++ messes that I would hate to see in CF, but then it is well > known that you see current CF code as a mess in itself, so perhaps it has > potential for cleaning up the code... Well, that is one of the points of the rewrite I'm proposing, indeed... > I depend on trunk not being broken so that I can test and develop things on > trunk. I no longer have interest in working on branch. I play only 2.x > servers. I do not want trunk broken (for long periods) as that will only > be a detriment to play testing and developing what is on trunk now. This > is how I work on content - a topic on which you are most vociferous. Yes, I'm vociferous on content. It seems lately some moves are made in this field, so I'm trying to prepare the (bright !) future for the ambitious content people are thinking of :) (something that current CF code doesn't always enable us to write easily, IMO). But the (partial/full/total/global/[insert word]) rewrite I'm talking about is not immediately, it's in some months, after some design work and such. From the various points on this list, I think I'll work on a separate branch, so it's easier to work on content. (and as you I try to not work on branch/1.x anymore) > While I recognize branching is a pain at times from my libglade effort in > the client, it is my preference if I read your intentions correctly - it > sounds basically like a huge rewrite. Whether the branch be of the whole > project or only portions that will be broken for some time is not really a > concern. Yup. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081124/a43aaa15/attachment.pgp From nicolas.weeger at laposte.net Mon Nov 24 09:24:02 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 24 Nov 2008 16:24:02 +0100 Subject: [crossfire] C++/Qt server version In-Reply-To: <4922766B.1050903@sonic.net> References: <200811172007.40625.nicolas.weeger@laposte.net> <4922766B.1050903@sonic.net> Message-ID: <200811241624.02191.nicolas.weeger@laposte.net> > Seems like a sort of odd decision since most recent conversations have > seemed to have decided that more content and less code work is what is > really needed to be done, but this seems to be a big code project... Yes, it has the potential to be ambitious. > And just given the size and changes of the project, I'd like to see more > detailed information - this isn't a minor change being made here. I plan on having design documents before coding, so hopefully we'll have time to think things over. So I can't give much details now, as I don't know them all :) Is that a satisfactory anwser? :) > I also wonder that given such a rewrite if maybe a more drastic approach > is needed. IMO, one reason for the messy/bad code is to maintain > compatibility - new things are added, but don't want to break old > maps/archetypes/whatever. I think some things could be simplified a great > deal (or made more efficient) if it was considered OK to break some of that > compatibility - this may mean lots of maps need updating, but if you're > going to do a major rewrite, it may be an overall plus just to give up on > some of that compatility for clean code. Indeed, but then let's do the whole thing and convert *ALL* things. One of the reasons for the mess is that people (me included, quite certainly) don't do the conversion globally, and only change a few maps/archs, thus we need to keep old compatibility code. > I do remember a long time ago someone else looked at doing crossfire in > C++, and his decision was basically to do it from scratch - better to write > something that meets the functional spec than to try and figure out what > all that code does, etc. But that is clearly a larger project. A plus is > that with a complete re-write, one could at least architect it for certain > things. But then you start asking questions on what is crossfire really, > etc. As Yann mentioned in another mail, rewriting from the ground up with copy / paste can be a solution. > I think it sort of depends on the expected development model. But I'd > generally say do it as a branch. > > If individual changes were limited in scope to a few files and were > basically complete at each commit, then maybe working directly in trunk > would be OK. But changing languages would seem that that is less likely > case. . > > The flip side is also that if not many changes are being made in the > trunk, it should generally be fairly easy to keep up to sync (there aren't > changes be made that requires syncing up, etc) I think it'll be on a branch, yes. > I do have some concerns like Kevin's, in that the rewrite could take a > long time (I have no idea on your expected schedule on this, so maybe not). > I'd actually be more concerned that the trunk gets left in some hybrid > state - some stuff rewritten, some stuff not, and unclear if having 30% of > it rewritten in C++/Qt and rest be old C is better than 100% in old C. Doesn't matter. Current C code builds in C++ easily, so no "is that C or C++?" philosophical question :) (and that's not a theoritical reply, I did test a few months ago - code didn't change enough to warrant another test) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081124/e96d3842/attachment.pgp From nicolas.weeger at laposte.net Mon Nov 24 09:50:17 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 24 Nov 2008 16:50:17 +0100 Subject: [crossfire] C++/Qt server version In-Reply-To: <200811181324.57493.crossfire@ailesse.com> References: <200811172007.40625.nicolas.weeger@laposte.net> <200811181324.57493.crossfire@ailesse.com> Message-ID: <200811241650.21312.nicolas.weeger@laposte.net> > From past experience, I'd tend to lean towards writing a server code "from > scratch", possibly recycling various elements by cut'n'paste, instead of > evolving a codebase that is already of questionable cleanliness. Yes, that's indeed a solution I can see, and it may be the choice I (and others if people participate :)) make. > This would also need to lay down a code architecture, split this into > tasks, and establish a development schedule. It also obviously require a > coding team - the scale of the task would require it to achieve decent > results in an acceptable development time. Yes. Design documents, planning, documentation and such (unit tests, ...) are needed, required before coding. As well as a relation to the content, to know what the code needs to support and how it supports it :) So clearly coordination with the "content leader". > My main concern is that by using the current code base without a solid > design map, the result would mostly be a "Crossfire with Qt extensions" - > most griefs I have towards the current code are architectural, and I'm not > sure an incremental approach would allow to really solve them. Yes, so a rewrite from scratch with cut'n' paste is quite a possibility. My opinion is that first we think about the design / architecture we want, then estimate / decide if it's better to do cut'n'paste, or merely adding to the code. > Finally, from your message content, it is hard not to see the intend as > being more "using Qt" than "providing something new". Although I strongly > believe myself that the use of C++/Qt can lead to a more flexible, less > complex code, I wouldn't go on Qt just for the sake of it: why you want to > do that and with which planned advantages in terms of features/stability is > what I'd want to be defined before judging on my position about this. Some rationale I can see for using C++: - the game structure (in my eyes) easily and almost naturally fits a class hierarchy : map, objects, player or monster controlling an object - things like shared strings or stringbuffer are easier to write in C++ than C, and look "more natural" (again, to my eyes) Concerning the choice to use an existing framework, I'd say we're making a game, not a framework, so using an existing one which does bring advantages is a big plus when applicable. So why Qt: - cross-platform - well tested through KDE and many applications - has all the basics we need: strings (including shared strings for memory reduction unless I'm mistaking), sockets, file / directory, threads and locks, multilanguage support - modular so we can only use what we need (no GUI for server, definitely) - easy to plug in GUI if needed with class coherence - signal/slot mechanism that could be used for plugins or archetype reloading - existing unit test framework (not that advanced, but enough for almost all our needs I think) As for the features I'd see that would be easier to write in C++/Qt than current C code: - dynamic archetype reloading - no need to restart the server or even collect archetypes - possibly a distributed server architecture, with recovery mechanisms (server instance crashes, clients get routed to other ones with minimum content loss) - multithreaded server, or at least some thread-related mechanisms, to avoid "lag by multiple meteor storm" issues Of course we could do this in C, in C/GTK, with many things (Java, assembly language, whatever :)), I'm not saying C++/Qt is the reply to everything or maybe even the right choice here. So to be honest, my proposal could be seen as: "let's redesign / rearchitecture the whole server to add nice features, and while we're at it let's use C++/Qt to simplify our life and make the code more compact!" Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081124/69338c7e/attachment-0001.pgp From nicolas.weeger at laposte.net Mon Nov 24 09:57:50 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 24 Nov 2008 16:57:50 +0100 Subject: [crossfire] C++/Qt server version In-Reply-To: <20081120012000.0ceea73b@ucalgary.ca> References: <200811172007.40625.nicolas.weeger@laposte.net> <20081120012000.0ceea73b@ucalgary.ca> Message-ID: <200811241657.50346.nicolas.weeger@laposte.net> > Well, one thought, is there any reason Qt-core as opposed Boost C++ > perhaps? If I understand correctly, they provide similar faculties but > Boost C++ also provides some rather nice looking python bindings that > may make it far easier to move cfpython to a C++ code style. > > I'm not saying anything is wrong with Qt-core, and I've never actually > used it or Boost C++ for that matter, but I'm just wondering if should > maybe be considered, as it may have merits. That said, as you're likely > going to be the main person in this code effort, simply having more > experience with QT-core than Boost C++ can be a significant and quite > valid factor. I'm not a Boost specialist either (and that can have an impact on my preference for Qt), but from what I gather, here are Qt features Boost doesn't have (someone will correct me if I'm wrong): - multilanguage support - GUI classes - modular, so you can disable if not needed, and if you need you're using the same base classes - image manipulation - crossplatform build system Note that C++/Qt and Python interact decently with some tests, there doesn't seem to be any issue there. > Not too much of a strong opinion, except that if you do work on trunk > there should be either a tag or branch made for the current state of > trunk. Yup. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081124/d7690162/attachment.pgp From lalo.martins at gmail.com Mon Nov 24 10:32:19 2008 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 24 Nov 2008 16:32:19 +0000 (UTC) Subject: [crossfire] C++/Qt server version References: <200811172007.40625.nicolas.weeger@laposte.net> <4922766B.1050903@sonic.net> <200811241624.02191.nicolas.weeger@laposte.net> Message-ID: quoth Nicolas Weeger as of Mon, 24 Nov 2008 16:24:02 +0100: > Doesn't matter. Current C code builds in C++ easily, so no "is that C or > C++?" philosophical question :) > (and that's not a theoritical reply, I did test a few months ago - code > didn't change enough to warrant another test) That was my argument for doing it on trunk. As I see it, steps are: 1. convert build system to use C++ without any real code changes 2. interactively and concurrently: 2a. document how things work 2b. convert discrete parts of the code to C++ 3c. write tests if the code you converted didn't have them yet 3. until you reach a point where we're happy with the design as a C++ app 4. refactor: now that we're fully C++, I'm sure there are many simplifications that can be made to the codebase 5. happiness, peace on earth, cure for cancer/HIV, end of hunger, and no more reality shows Also, since the plan is gradual and interactive, other people than Nicolas can help here and there, which will certainly help it move forward a lot faster. 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. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From lalo.martins at gmail.com Mon Nov 24 11:04:59 2008 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 24 Nov 2008 17:04:59 +0000 (UTC) Subject: [crossfire] C++/Qt server version References: <200811172007.40625.nicolas.weeger@laposte.net> <200811181324.57493.crossfire@ailesse.com> <200811241650.21312.nicolas.weeger@laposte.net> Message-ID: quoth Nicolas Weeger as of Mon, 24 Nov 2008 16:50:17 +0100: > So why Qt: > - cross-platform > - well tested through KDE and many applications - has all the basics we > need: strings (including shared strings for memory reduction unless I'm > mistaking), sockets, file / directory, threads and locks, multilanguage > support > - modular so we can only use what we need (no GUI for server, > definitely) - easy to plug in GUI if needed with class coherence - > signal/slot mechanism that could be used for plugins or archetype > reloading - existing unit test framework (not that advanced, but enough > for almost all our needs I think) All your arguments are also true of Boost, thought ;-) with the added benefit (IMHO) that probably more people already have Boost installed than Qt. (Probably more people already know it, too.) Then again, as I said before, whatever you pick is fine... you're the one writing the code! 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. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From lalo.martins at gmail.com Mon Nov 24 11:25:40 2008 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 24 Nov 2008 17:25:40 +0000 (UTC) Subject: [crossfire] C++/Qt server version References: <200811172007.40625.nicolas.weeger@laposte.net> <20081120012000.0ceea73b@ucalgary.ca> <200811241657.50346.nicolas.weeger@laposte.net> Message-ID: Before anyone gets the impression I'm turning this into a Boost holy war... let me reiterate I don't feel that strongly about it, just answering Nicolas' questions here. quoth Nicolas Weeger as of Mon, 24 Nov 2008 16:57:50 +0100: > I'm not a Boost specialist either (and that can have an impact on my > preference for Qt), but from what I gather, here are Qt features Boost > doesn't have (someone will correct me if I'm wrong): > - multilanguage support Meaning? Like gettext? It *seems* most non-Qt people use ICU for i18n and l10n, although I do have a bit of a problem with that, in that ICU has its own string object, with an API different from the STL string... It does integrate nicely with Boost though. > - GUI classes - modular, so you can disable if not needed, and if you > need you're using the same base classes It doesn't, and that's a good thing in my book ;-) > - image manipulation http://www.boost.org/doc/libs/1_37_0/libs/gil/doc/index.html > - crossplatform build system Jam, one of the best crossplatform build systems out there at the moment, used by a lot of non-boost-related projects. > Note that C++/Qt and Python interact decently with some tests, there > doesn't seem to be any issue there. Well, you *can* simply use libpython from C++. But Boost::Python is a whole new level of integration, it allows you to directly wrap classes and other cool magic. That may not be an issue for us, though, since we're filtering our Python stuff through the plug-in API anyway. Depends, I guess, on how C++ we want to convert the plug-in API to. It may also turn out that once everything is classes, there's no need for the plug-in isolation API anymore. 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. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From agschult at ucalgary.ca Mon Nov 24 12:10:47 2008 From: agschult at ucalgary.ca (Alex Schultz) Date: Mon, 24 Nov 2008 11:10:47 -0700 Subject: [crossfire] C++/Qt server version In-Reply-To: References: <200811172007.40625.nicolas.weeger@laposte.net> <20081120012000.0ceea73b@ucalgary.ca> <200811241657.50346.nicolas.weeger@laposte.net> Message-ID: <20081124111047.3822a87d@ucalgary.ca> On Mon, 24 Nov 2008 17:25:40 +0000 (UTC) Lalo Martins wrote: > > Note that C++/Qt and Python interact decently with some tests, there > > doesn't seem to be any issue there. > > Well, you *can* simply use libpython from C++. But Boost::Python is > a whole new level of integration, it allows you to directly wrap > classes and other cool magic. > > That may not be an issue for us, though, since we're filtering our > Python stuff through the plug-in API anyway. Depends, I guess, on > how C++ we want to convert the plug-in API to. It may also turn > out that once everything is classes, there's no need for the > plug-in isolation API anymore. Yep, that automagical wrapping in Boost::Python is one of the biggest things that made me consider bringing up Boost in the first place, considering how cfpython seems to be becoming increasingly used. That said, a little searching shows that if we want similar automagical wrapping and go with Qt-core, apparently "QtScript" (an ECMAScript based scripting language which has been included in the Qt toolkit since 4.3.0), appears to be able to provide some kinds of similar things. Of course, it would also be plausible to use Qt-core for the bulk of the rewrite and Boost::Python for cfpython, but that could cause difficulties with differing string types and plain add redundant bloat to the dependencies. Alex From crossfire at ailesse.com Mon Nov 24 12:49:15 2008 From: crossfire at ailesse.com (Lauwenmark Akkendrittae) Date: Mon, 24 Nov 2008 19:49:15 +0100 Subject: [crossfire] C++/Qt server version In-Reply-To: <20081124111047.3822a87d@ucalgary.ca> References: <200811172007.40625.nicolas.weeger@laposte.net> <20081124111047.3822a87d@ucalgary.ca> Message-ID: <200811241949.28773.crossfire@ailesse.com> Le lundi 24 novembre 2008, Alex Schultz a ?crit : > That said, a little searching shows that if we want similar automagical > wrapping and go with Qt-core, apparently "QtScript" (an ECMAScript based > scripting language which has been included in the Qt toolkit since > 4.3.0), appears to be able to provide some kinds of similar > things. Of course, it would also be plausible to use Qt-core for the > bulk of the rewrite and Boost::Python for cfpython, but that could > cause difficulties with differing string types and plain add redundant > bloat to the dependencies. > See http://pythonqt.sourceforge.net/ , which is a Python binding for QtScript. -- Lauwenmark. ------------ "Drive defensively: buy a tank." -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081124/c693dc25/attachment.pgp From crossfire at ailesse.com Mon Nov 24 13:02:49 2008 From: crossfire at ailesse.com (Lauwenmark Akkendrittae) Date: Mon, 24 Nov 2008 20:02:49 +0100 Subject: [crossfire] C++/Qt server version In-Reply-To: References: <200811172007.40625.nicolas.weeger@laposte.net> <200811241657.50346.nicolas.weeger@laposte.net> Message-ID: <200811242002.50550.crossfire@ailesse.com> Le lundi 24 novembre 2008, Lalo Martins a ?crit : > Before anyone gets the impression I'm turning this into a Boost holy > war... let me reiterate I don't feel that strongly about it, just > answering Nicolas' questions here. > I see two good reasons for Nicolas favouring Qt over Boost: - He's more familiar with Qt, and having to learn another toolkit, especially something as complex as Boost, would be somewhat of a waste of time; - Although you mentioned several things that integrate nicely with Boost, providing Internationalization or a crossplatform building system, the whole point is that all of this is provided inside the Qt tool suite, and requires no external/3rd party dependency. This is a significant advantage to me. My own, personal tastes lean towards Qt more than Boost, mostly for the way Qt extended the C++ language to make some fundamental mechanisms more accessible. It provides a level of simplicity more in touch with the capabilities of my old braincells :). Just my 0.02? :) -- Lauwenmark. ------------ "Drive defensively: buy a tank." -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081124/49b292c5/attachment.pgp From agschult at ucalgary.ca Mon Nov 24 13:09:30 2008 From: agschult at ucalgary.ca (Alex Schultz) Date: Mon, 24 Nov 2008 12:09:30 -0700 Subject: [crossfire] C++/Qt server version In-Reply-To: <200811241949.28773.crossfire@ailesse.com> References: <200811172007.40625.nicolas.weeger@laposte.net> <20081124111047.3822a87d@ucalgary.ca> <200811241949.28773.crossfire@ailesse.com> Message-ID: <20081124120930.1aaa613a@ucalgary.ca> On Mon, 24 Nov 2008 19:49:15 +0100 Lauwenmark Akkendrittae wrote: > Le lundi 24 novembre 2008, Alex Schultz a ?crit : > > That said, a little searching shows that if we want similar > > automagical wrapping and go with Qt-core, apparently "QtScript" (an > > ECMAScript based scripting language which has been included in the > > Qt toolkit since 4.3.0), appears to be able to provide some kinds > > of similar things. Of course, it would also be plausible to use > > Qt-core for the bulk of the rewrite and Boost::Python for cfpython, > > but that could cause difficulties with differing string types and > > plain add redundant bloat to the dependencies. > > > See http://pythonqt.sourceforge.net/ , which is a Python binding for > QtScript. Aha, that does look like suitable fit for doing cfpython in a Qt framework. I'm a little wary of that particular option though, due to how it appears to have been unmaintained since May 2007. Unless it's particularly bug-free, or we wish to take up maintenance of it, I'm not sure if I'd consider it a good option or not. From mwedel at sonic.net Tue Nov 25 00:06:40 2008 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 24 Nov 2008 22:06:40 -0800 Subject: [crossfire] C++/Qt server version In-Reply-To: <200811172007.40625.nicolas.weeger@laposte.net> References: <200811172007.40625.nicolas.weeger@laposte.net> Message-ID: <492B95F0.60503@sonic.net> Some various musings I wanted to write up before I forget about them :) They don't directly relate to this conversation, but were brushed upon in certain messages. Backward compatibility and rewrite: Given the number of maps and archetypes, it is certainly desirable that those still work - we don't want to have to go through and update every map just so it loads. However, there could certainly be some maps using behavior that is undocumented, or there could even be code to handle certain things so they don't break. But for some things, having clean code may be more desirable than maintaining some behavior that 2 maps use (and those 2 maps could get updated/fixed). Shared strings: While perhaps no reason to get rid of them, I also wonder how necessary they are now days. They do simplify comparisons. And with C++ and proper class descriptions, they can be made to be safe (have to use class functions to modify the name, and it knows to do the right thing). But shared strings date back a long time in crossfire, to when systems had much less memory and this was more a concern. They certainly do still save space, but the amount of space saved may not be worth the extra handling. It should certainly be reviewed - many design decisions date back to when computers where much less capable than they are now, and may not make much sense. Quick thought on features you mention: Dynamic arch loading: This makes sense, especially if/when images want to include new archetypes/images/animations/whatever else. Handling changing archetypes on a running server gets weird - need to have a fairly clear understanding what should happen there (if I'm fighting a monster and an arch reload happens and monster now changes, that would be odd) Distributed server archetype: Need more details - having redundancy (client rerouting with minimal data loss) might not be worth the effort - have to make sure you don't have two servers trying to control the same area, recovery when one comes back on-line, etc. But being distributed (this server is responsible for scorn region, this one for navar city, etc) to reduce load may make sense, with there being smarts to transfer character detail between those, etc. In terms of server failure/crash, the client could improve that experience - most servers restart when they crash, so it is really to the client to pop up a window with something like 'connection lost - trying to reconnect (with spinning disk or something)'. Multithread server: I think this is a must - computers are moving more and more towards multiple cores, and less towards raw speed, and for crossfire to make use of those really requires multithreading. I always thought that multithreading at the map level would make the most sense - this potentially lets one use many threads (and thus cores) and is probably the simplest way to go. From agschult at ucalgary.ca Tue Nov 25 00:28:50 2008 From: agschult at ucalgary.ca (Alex Schultz) Date: Mon, 24 Nov 2008 23:28:50 -0700 Subject: [crossfire] C++/Qt server version In-Reply-To: <492B95F0.60503@sonic.net> References: <200811172007.40625.nicolas.weeger@laposte.net> <492B95F0.60503@sonic.net> Message-ID: <20081124232850.6a4128b0@ucalgary.ca> On Mon, 24 Nov 2008 22:06:40 -0800 Mark Wedel wrote: > Shared strings: While perhaps no reason to get rid of them, I also > wonder how necessary they are now days. They do simplify > comparisons. And with C++ and proper class descriptions, they can be > made to be safe (have to use class functions to modify the name, > and it knows to do the right thing). But shared strings date back a > long time in crossfire, to when systems had much less memory and this > wasmore a concern. They certainly do still save space, but the amount > of space saved may not be worth the extra handling. It should > certainly be reviewed - many design decisions date back to when > computers where much less capable than they are now, and may not make > much sense. I'm note sure exactly how much space is saved, but I think there's a high chance they may still be desirable due to the shear amount of floor tile objects and such in CF if someone is running through a large number of large maps. Now it's possible the benefit might be small these days but in any case, I don't think that making decisions about shared strings can go much further without getting real data on how much space they save. > Distributed server archetype: Need more details - having redundancy > (client rerouting with minimal data loss) might not be worth the > effort - have to make sure you don't have two servers trying to > control the same area, recovery when one comes back on-line, etc. > But being distributed (this server is responsible for scorn region, > this one for navar city, etc) to reduce load may make sense, with > there being smarts to transfer character detail between those, etc. > In terms of server failure/crash, the client could improve that > experience - most servers restart when they crash, so it is really to > the client to pop up a window with something like 'connection lost - > trying to reconnect (with spinning disk or something)'. > > Multithread server: I think this is a must - computers are moving > more and more towards multiple cores, and less towards raw speed, and > for crossfire to make use of those really requires multithreading. I > always thought that multithreading at the map level would make the > most sense - this potentially lets one use many threads (and thus > cores) and is probably the simplest way to go. I was recently thinking about server multithreading, and now I'm thinking, why bother with threads? Why not do a model like one-process-per-every-few-maps instead of multithreading? It eliminates potential issues with mutexes and locking and such, transfering things between the processes could be done by IPC. The further advantage of going with a multi-process model instead of multi-thread model, is that much of the very same code could be adapted to make a distributed server possible if anyone ever thinks there's a need. I don't currently think there's a need for a distributed server system, but a multi-process model would lend well to adapting to distributed at a later date. Furthermore, a multi-process model would also make server crashes less disruptive because they'd usually just kill off a map or 3 instead of everywhere. Perhaps we should make a pros/cons chart to outline the merits of multi-process and multi-thread to compare? Alex Schultz From mwedel at sonic.net Tue Nov 25 02:20:38 2008 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 25 Nov 2008 00:20:38 -0800 Subject: [crossfire] C++/Qt server version In-Reply-To: <20081124232850.6a4128b0@ucalgary.ca> References: <200811172007.40625.nicolas.weeger@laposte.net> <492B95F0.60503@sonic.net> <20081124232850.6a4128b0@ucalgary.ca> Message-ID: <492BB556.1070203@sonic.net> Alex Schultz wrote: > On Mon, 24 Nov 2008 22:06:40 -0800 > Mark Wedel wrote: > >> Shared strings: While perhaps no reason to get rid of them, I also >> wonder how necessary they are now days. They do simplify >> comparisons. And with C++ and proper class descriptions, they can be >> made to be safe (have to use class functions to modify the name, >> and it knows to do the right thing). But shared strings date back a >> long time in crossfire, to when systems had much less memory and this >> wasmore a concern. They certainly do still save space, but the amount >> of space saved may not be worth the extra handling. It should >> certainly be reviewed - many design decisions date back to when >> computers where much less capable than they are now, and may not make >> much sense. > > I'm note sure exactly how much space is saved, but I think there's a > high chance they may still be desirable due to the shear amount of > floor tile objects and such in CF if someone is running through a large > number of large maps. Now it's possible the benefit might be small > these days but in any case, I don't think that making decisions about > shared strings can go much further without getting real data on how > much space they save. I looked on metalforge, and with the strings command, this is what came back: 3879 entries, 2476263 refs, 8196 links. So a good amount of space is being saved. But if we presume an average length of 10 for the strings, it amounts to 24 MB. The calculation is trickier - on the one side, there is overhead of the shared string structure itself in crossfire, but the counter is that if malloc is being used, it has some overhead of its own, so the difference there may not be that great. I suspect a much greater space savings may result in using C++ classes for objects, and allocating the type specific section of the object as needed. For example, for all those floor tiles, they really don't use much beyond the most basic fields of the object structure (name, x, y, etc). They don't need anything of the str, dex, hp fields, resistances, etc. So if objects were redone such that it was like 'oh, this is an equippable object - let me allocate the pointer for that', and 'oh, this is a floor object - nothing more is needed', one could get a pretty big space savings. Because of those 2476263 strings, probably almost every one of them is attached to some object. In fact, looking at metalforge, it looks like about 70 MB of space is used for objects. So C++ inheritance could save a lot of that space. > > > >> Distributed server archetype: Need more details - having redundancy >> (client rerouting with minimal data loss) might not be worth the >> effort - have to make sure you don't have two servers trying to >> control the same area, recovery when one comes back on-line, etc. >> But being distributed (this server is responsible for scorn region, >> this one for navar city, etc) to reduce load may make sense, with >> there being smarts to transfer character detail between those, etc. >> In terms of server failure/crash, the client could improve that >> experience - most servers restart when they crash, so it is really to >> the client to pop up a window with something like 'connection lost - >> trying to reconnect (with spinning disk or something)'. >> >> Multithread server: I think this is a must - computers are moving >> more and more towards multiple cores, and less towards raw speed, and >> for crossfire to make use of those really requires multithreading. I >> always thought that multithreading at the map level would make the >> most sense - this potentially lets one use many threads (and thus >> cores) and is probably the simplest way to go. > > I was recently thinking about server multithreading, and now I'm > thinking, why bother with threads? Why not do a model like > one-process-per-every-few-maps instead of multithreading? It eliminates > potential issues with mutexes and locking and such, transfering things > between the processes could be done by IPC. The further advantage of > going with a multi-process model instead of multi-thread model, is that > much of the very same code could be adapted to make a distributed > server possible if anyone ever thinks there's a need. I don't > currently think there's a need for a distributed server system, but a > multi-process model would lend well to adapting to distributed at a > later date. Furthermore, a multi-process model would also make server > crashes less disruptive because they'd usually just kill off a map or 3 > instead of everywhere. Perhaps we should make a pros/cons chart to > outline the merits of multi-process and multi-thread to compare? Maybe. Note that being able to run on a single box is a necessity, since that probably would be the way many folks run the system. note that processes tend to be a lot heavier than threads. And moving data back and forth is trickier. In a multithreaded model, you'd make a few locks, and could move the player structure from one map to the next. In a multi process model, you'd need to transfer all of the data - not just the player, but all the inventory, statistics on all of those, etc. And you may need to given them new inventory tags, since the ones they had in the old server may conflict (which then requires some extra work in the protocol - object tag 12345 is now 5678) Also, I think re-joining existing servers may be more difficult. If I'm in scorn and go off into a new building, and that building is not currently active, it goes and forks off a new process and the existing file descriptor lives OK. However, if that building already has process associated with it (another player entered it), we can't fork - instead, my client has to get directed to that other process. And most likely, that means a different port (13329, 13330, ...) on that server. That is doable, but does require yet some other process to monitor all those forked processes out there to know what is available and what to connect to. Also, for folks running servers behind firewalls (probably most everyone) it means opening a potentially large number of ports. For same reason, it makes things like chats harder - one could make a good case those could/should get moved out of bad in any case, but in the current model, each process would only really be able to talk to clients it knows about. All of this is doable - may require proxy type programs. It's unclear if its really a simpler solution. Note that most of these issues apply in the distributed model, but I'd personally see that as more static (if it is region based, probably a config file that says what the different regions are and ip:port number they run on - if I'm running that on my single server, I'd know what ports to open up). And for some of that, the limitations may make sense (a person can't chat with someone in navar, etc). If things are rewritten in C++ with classes, then locking probably gets done in the base classes, so may not be that hard - don't really know. There is the disadvantage that if one thread crashes, it basically takes all the threads with it (one could try to recover, but probably make things worse not better because data may be in a bad state - perhaps depends on the nature of the fault. If something in the malloc or other low level libraries, you're in bad shape. But if it is something in crossfire which it considers fatal but doesn't necessarily mean data corruption, it may just be a case of freeing what data one can and terminating that thread). You're probably still better off restarting the server - it doesn't take that long now days. From agschult at ucalgary.ca Tue Nov 25 02:45:45 2008 From: agschult at ucalgary.ca (Alex Schultz) Date: Tue, 25 Nov 2008 01:45:45 -0700 Subject: [crossfire] C++/Qt server version In-Reply-To: <492BB556.1070203@sonic.net> References: <200811172007.40625.nicolas.weeger@laposte.net> <492B95F0.60503@sonic.net> <20081124232850.6a4128b0@ucalgary.ca> <492BB556.1070203@sonic.net> Message-ID: <20081125014545.105902f6@ucalgary.ca> On Tue, 25 Nov 2008 00:20:38 -0800 Mark Wedel wrote: > Also, I think re-joining existing servers may be more difficult. > If I'm in scorn and go off into a new building, and that building is > not currently active, it goes and forks off a new process and the > existing file descriptor lives OK. However, if that building already > has process associated with it (another player entered it), we can't > fork - instead, my client has to get directed to that other process. > And most likely, that means a different port (13329, 13330, ...) on > that server. > > That is doable, but does require yet some other process to monitor > all those forked processes out there to know what is available and > what to connect to. Also, for folks running servers behind firewalls > (probably most everyone) it means opening a potentially large number > of ports. Well a few comments on these aspects. I don't think we need to mess around with opening more ports. One option is the supervising process could just proxy the connections through IPC. If this isn't good enough and we want direct connections to the process, it actually IS possible under both *nix and win32 to my understanding, to transfer file descriptors, and hence TCP/IP sockets, to another process, without disruption/disconnection/etc. This could also be used, so really, new ports or client changes would *not* be needed at all to support a multi-process model. (Note that all this said, I'm not current which approach I'd consider best, but I'm noting that one way or another, we wouldn't need additional ports or messing with the client or any of that kind of stuff, to achieve a multi-process model) Alex From lalo.martins at gmail.com Tue Nov 25 14:47:43 2008 From: lalo.martins at gmail.com (Lalo Martins) Date: Tue, 25 Nov 2008 20:47:43 +0000 (UTC) Subject: [crossfire] C++/Qt server version References: <200811172007.40625.nicolas.weeger@laposte.net> <200811241657.50346.nicolas.weeger@laposte.net> <200811242002.50550.crossfire@ailesse.com> Message-ID: quoth Lauwenmark Akkendrittae as of Mon, 24 Nov 2008 20:02:49 +0100: > Le lundi 24 novembre 2008, Lalo Martins a ?crit : > I see two good reasons for Nicolas favouring Qt over Boost: > > - He's more familiar with Qt, and having to learn another toolkit, > especially something as complex as Boost, would be somewhat of a waste > of time; Agreed. > - Although you mentioned several things that integrate nicely with > Boost, providing Internationalization or a crossplatform building > system, the whole point is that all of this is provided inside the Qt > tool suite, and requires no external/3rd party dependency. This is a > significant advantage to me. That's true for ICU, but not Jam; Jam *is* part of the Boost tool suite. > My own, personal tastes lean towards Qt more than Boost, mostly for the > way Qt extended the C++ language to make some fundamental mechanisms > more accessible. It provides a level of simplicity more in touch with > the capabilities of my old braincells :). Hmm... the same could be said for Boost, and the improvements in Boost are more likely to be in future versions of the C++ standard, since there's a huge overlap in membership between the C++ committee and the Boost project. That's one of the main reasons I favour Boost. Also, here's something I forgot before: would use Qt imply using Trolltech's bastard C++ dialect, and MOC? Or is that already dead and outdated? If we'll have to code in a C++ dialect and require a toolset that not many people will already have installed, then I'm strongly opposed to Qt. 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. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From crossfire at ailesse.com Wed Nov 26 10:18:45 2008 From: crossfire at ailesse.com (Lauwenmark Akkendrittae) Date: Wed, 26 Nov 2008 17:18:45 +0100 Subject: [crossfire] C++/Qt server version In-Reply-To: References: <200811172007.40625.nicolas.weeger@laposte.net> <200811242002.50550.crossfire@ailesse.com> Message-ID: <200811261718.56178.crossfire@ailesse.com> Le mardi 25 novembre 2008, Lalo Martins a ?crit : > quoth Lauwenmark Akkendrittae as of Mon, 24 Nov 2008 20:02:49 +0100: > > Le lundi 24 novembre 2008, Lalo Martins a ?crit : > > I see two good reasons for Nicolas favouring Qt over Boost: > > > > - He's more familiar with Qt, and having to learn another toolkit, > > especially something as complex as Boost, would be somewhat of a waste > > of time; > > Agreed. > > > - Although you mentioned several things that integrate nicely with > > Boost, providing Internationalization or a crossplatform building > > system, the whole point is that all of this is provided inside the Qt > > tool suite, and requires no external/3rd party dependency. This is a > > significant advantage to me. > > That's true for ICU, but not Jam; Jam *is* part of the Boost tool suite. > True only if you were speaking of the Boost version of Jam. I had the Perforce version in mind, which is an independent tool. > > My own, personal tastes lean towards Qt more than Boost, mostly for the > > way Qt extended the C++ language to make some fundamental mechanisms > > more accessible. It provides a level of simplicity more in touch with > > the capabilities of my old braincells :). > > Hmm... the same could be said for Boost, > Nope. I have worked (and still does) with Boost; it mostly builts upon existing language structures. From my personal experience (note the "personal" both here and my initial comment), Boost was not as easy to use as Qt. So yes, Boost provides an extensive, consistent library; yes, it allows using C++ in a very powerful way; no, it doesn't fundamentally make any of the language mechanisms simpler. > and the improvements in Boost > are more likely to be in future versions of the C++ standard, since > there's a huge overlap in membership between the C++ committee and the > Boost project. That's one of the main reasons I favour Boost. > I don't see how what a future C++ standard may someday include would be of any relevance here. Being Qt or Boost, the code would still be C++ anyway. > Also, here's something I forgot before: would use Qt imply using > Trolltech's bastard C++ dialect, and MOC? > There we hit your real issue, don't we? Short answer: yes, you have to use MOC, and yes, it implies using its language extensions. I see no point in commenting the "bastard" qualifier here - I care about the efficiency of a dialect, not about its possibly illegitimate origins. > Or is that already dead and outdated? > This simple question tends to demonstrate your quite superficial knowledge of Qt, else you wouldn't even have asked. Maybe you should evaluate both libraries before actually placing a judgement of their respective qualities/flaws ? > If we'll have to code in a C++ dialect and require a toolset > that not many people will already have installed, then I'm strongly > opposed to Qt. > The dialect point could indeed have been an issue - nobody wants to learn a variety of C++ just for a single project. But the changes are actually extremely limited - the most important being the addition of signal/slot mechanisms. It doesn't invalidate any of the existing C++ language definition. So far, I haven't seen many C++ coders complaining that the "Qt Dialect" was difficult to grasp. Regarding the toolset, I don't see where the problem is, since the required tools are shipped with the Qt SDK. Since the Boost libraries themselves are not installed by default on most platforms, I don't really get where the difference is. -- Lauwenmark. ------------ "Drive defensively: buy a tank." -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081126/2f552e32/attachment.pgp From antonoussik at gmail.com Wed Nov 26 11:53:58 2008 From: antonoussik at gmail.com (Anton Oussik) Date: Wed, 26 Nov 2008 17:53:58 +0000 Subject: [crossfire] C++/Qt server version In-Reply-To: <20081124232850.6a4128b0@ucalgary.ca> References: <200811172007.40625.nicolas.weeger@laposte.net> <492B95F0.60503@sonic.net> <20081124232850.6a4128b0@ucalgary.ca> Message-ID: 2008/11/25 Alex Schultz : > On Mon, 24 Nov 2008 22:06:40 -0800 > Mark Wedel wrote: > >> Shared strings: While perhaps no reason to get rid of them, I also >> wonder how necessary they are now days. They do simplify >> comparisons. And with C++ and proper class descriptions, they can be >> made to be safe (have to use class functions to modify the name, >> and it knows to do the right thing). But shared strings date back a >> long time in crossfire, to when systems had much less memory and this >> wasmore a concern. They certainly do still save space, but the amount >> of space saved may not be worth the extra handling. It should >> certainly be reviewed - many design decisions date back to when >> computers where much less capable than they are now, and may not make >> much sense. > > I'm note sure exactly how much space is saved, but I think there's a > high chance they may still be desirable due to the shear amount of > floor tile objects and such in CF if someone is running through a large > number of large maps. Now it's possible the benefit might be small > these days but in any case, I don't think that making decisions about > shared strings can go much further without getting real data on how > much space they save. > > > >> Distributed server archetype: Need more details - having redundancy >> (client rerouting with minimal data loss) might not be worth the >> effort - have to make sure you don't have two servers trying to >> control the same area, recovery when one comes back on-line, etc. >> But being distributed (this server is responsible for scorn region, >> this one for navar city, etc) to reduce load may make sense, with >> there being smarts to transfer character detail between those, etc. >> In terms of server failure/crash, the client could improve that >> experience - most servers restart when they crash, so it is really to >> the client to pop up a window with something like 'connection lost - >> trying to reconnect (with spinning disk or something)'. >> >> Multithread server: I think this is a must - computers are moving >> more and more towards multiple cores, and less towards raw speed, and >> for crossfire to make use of those really requires multithreading. I >> always thought that multithreading at the map level would make the >> most sense - this potentially lets one use many threads (and thus >> cores) and is probably the simplest way to go. > > I was recently thinking about server multithreading, and now I'm > thinking, why bother with threads? Why not do a model like > one-process-per-every-few-maps instead of multithreading? It eliminates > potential issues with mutexes and locking and such, transfering things > between the processes could be done by IPC. The further advantage of > going with a multi-process model instead of multi-thread model, is that > much of the very same code could be adapted to make a distributed > server possible if anyone ever thinks there's a need. I don't > currently think there's a need for a distributed server system, but a > multi-process model would lend well to adapting to distributed at a > later date. Furthermore, a multi-process model would also make server > crashes less disruptive because they'd usually just kill off a map or 3 > instead of everywhere. Perhaps we should make a pros/cons chart to > outline the merits of multi-process and multi-thread to compare? I think an multiprocess architecture that is capable of being run on multiple machines is a good direction to move in. I propose to have one process that handles connections from clients, keeps them connected, keeps track of who is on which map, and is capable of kicking off map processes as needed. Then, have one process per map, which can potentially run on a remote machine. As some tasks (like logging in) put a lot of strain on the main process (which would have a lot going through it anyways), perhaps some other things could be migrated off it into their own processes, instead going for a pure message passing process, which maintains the mapping of which player is connected to what map, and passes messages in both directions. Maps talking to maps could be done simply by a map asking where another map is running, and then connecting directly to transfer data between maps. This would allow spells to work across maps without overloading the central process etc. This has the advantages of splitting the load of running maps over multiple machines/cores. Only one process would need to listen on a port, so firewalling a server from outside would be easy. Another advantage would be allowing maps to crash without bringing down any other maps. One recovery method would be to place players in a limbo map, giving them the option to return to the restarted version of the map, or go home to their savebed. If the recovery map crashes too we know there is something wrong with the player, and they should not be allowed on any new maps until something is done about it. The central process can be kept small and clean, making it fast and stable, meaning "the server" as the players see it won't ever go down, even when upgrading, since upgrades can then be applied to a running server without the need to restart it. Most changes would be to the map running processes, which will be automatically applied when maps are restarted. The disadvantages of this are: extra level of IPC is potentially slow. The configuration can get complex unless thought out well in advance. From lalo.martins at gmail.com Wed Nov 26 12:31:12 2008 From: lalo.martins at gmail.com (Lalo Martins) Date: Wed, 26 Nov 2008 18:31:12 +0000 (UTC) Subject: [crossfire] C++/Qt server version References: <200811172007.40625.nicolas.weeger@laposte.net> <200811242002.50550.crossfire@ailesse.com> <200811261718.56178.crossfire@ailesse.com> Message-ID: quoth Lauwenmark Akkendrittae as of Wed, 26 Nov 2008 17:18:45 +0100: >> Also, here's something I forgot before: would use Qt imply using >> Trolltech's bastard C++ dialect, and MOC? >> > There we hit your real issue, don't we? Short answer: yes, you have to > use MOC, and yes, it implies using its language extensions. I see no > point in commenting the "bastard" qualifier here - I care about the > efficiency of a dialect, not about its possibly illegitimate origins. Sorry, but I do care about its illegitimate origins, for the same reason that I care about future versions of C++. This project will probably take at least an year, more realistically three or four, to complete; it would be silly if in five years, or ten, it was already difficult to maintain due to tool/language obsolescence. >> Or is that already dead and outdated? >> > This simple question tends to demonstrate your quite superficial > knowledge of Qt, else you wouldn't even have asked. Maybe you should > evaluate both libraries before actually placing a judgement of their > respective qualities/flaws ? No, the word is not superficial, but outdated. I gave up on Qt years ago and haven't checked again (before even Qt3), one of the reasons being MOC. And I assumed there was a chance it would be gone by now, since IMO an idea so clearly idiotic as language extensions and pre-compiling couldn't stay around for too long in a library used by so many people. Apparently, I was wrong. Oh well. I'm now strongly opposed to using Qt. Strongly opposed as in: if Qt is chosen, I'll stop contributing, because I don't want to learn it. And I'll probably end up forking as well, if the uses I have in mind for the server require code changes. 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. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From lalo.martins at gmail.com Wed Nov 26 14:46:55 2008 From: lalo.martins at gmail.com (Lalo Martins) Date: Wed, 26 Nov 2008 20:46:55 +0000 (UTC) Subject: [crossfire] not yanttf (Re: C++/Qt server version) References: <200811172007.40625.nicolas.weeger@laposte.net> <200811242002.50550.crossfire@ailesse.com> <200811261718.56178.crossfire@ailesse.com> Message-ID: quoth Lalo Martins as of Wed, 26 Nov 2008 18:31:12 +0000: > I'm now strongly opposed to using Qt. Strongly opposed as in: if Qt is > chosen, I'll stop contributing, because I don't want to learn it. And > I'll probably end up forking as well, if the uses I have in mind for the > server require code changes. kbulgrien pointed out on irc this came of as yanttf (yet another threat to fork). So let me clarify. I wouldn't fork for the sake of forking, just because I disagree with the code leader's decision. Next year, I intend to use the crossfire server code for a different project. My original plan was to use the upstream code, contributing any improvements I need to make that work, which means both projects get a richer server and there's less code to maintain. But that was before the whole C++ conversation started. To be fair I'm happier with a TrollC++ server than the current C server, from the POV of a Crossfire player, and if that's the path chosen, I wouldn't stop contributing to content or clients, or stop playing. But as a developer, a TrollC++ server would be unsuitable for my project, so I'd base it off the latest C version; therefore, it's technically a fork. 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. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From nicolas.weeger at laposte.net Wed Nov 26 15:54:00 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 26 Nov 2008 22:54:00 +0100 Subject: [crossfire] C++/Qt server version In-Reply-To: <200811242002.50550.crossfire@ailesse.com> References: <200811172007.40625.nicolas.weeger@laposte.net> <200811242002.50550.crossfire@ailesse.com> Message-ID: <200811262254.06397.nicolas.weeger@laposte.net> > I see two good reasons for Nicolas favouring Qt over Boost: > > - He's more familiar with Qt, and having to learn another toolkit, > especially something as complex as Boost, would be somewhat of a waste of > time; This is true, but I'm hopefully not the only one writing the server code :) Therefore others' point of view should be taken into account. Of course, if people choose for instance COBOL for the server, I still reserve the right to work on a version that suits be better ^_- > - Although you mentioned several things that integrate nicely with Boost, > providing Internationalization or a crossplatform building system, the > whole point is that all of this is provided inside the Qt tool suite, and > requires no external/3rd party dependency. This is a significant advantage > to me. Yes, that's a point I like too, and this is also why I mentioned Qt in the first mail, because you can avoid some evil dependency-related issues (Windows is bad for that, for instance :)) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081126/02914223/attachment.pgp From mwedel at sonic.net Wed Nov 26 23:22:41 2008 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 26 Nov 2008 21:22:41 -0800 Subject: [crossfire] multithread vs multi process In-Reply-To: References: <200811172007.40625.nicolas.weeger@laposte.net> <492B95F0.60503@sonic.net> <20081124232850.6a4128b0@ucalgary.ca> Message-ID: <492E2EA1.1090809@sonic.net> Changing the subject to more accurately note the discussion.. I think there are pros & cons to each approach. And in fact, the end result may be a mix. Clearly, good design, looking at pros & cons, and what would actually be used is needed. Off the top of my head, these are so pros/cons to each method. I'm sure this isn't a complete list. From what I know of the code (which I know pretty good) I personally think multithreading would be easier to do than multiprocess. Multiple processes pros: - Each map being its own process provides crash resistance - if one map/process crashes, everyone else keeps on playing. - Allows for distributed servers (having a cluster of boxes each running some processes). I do wonder how many folks would really use this however. One use for this could be for experimental/custom maps (connect to someones test server that has a new area, etc). - Don't have to deal with thread locking. - Because of no locking, each individual process may scale better on mulitple cores (no thread contention) Multiple process cons: - Extra overhead of IPC between processes is needed - not just to move objects, but also messages, like shouts, etc. This also means writing new code that doesn't currently exist. - May still need some locking for common files (basically anything stored in the var directory, like highscores, banking, etc) - Would need client (and protocol) updates in addition to server updates. - Can not run as many processes as threads - larger memory footprint for each process (vs thread) so would still need each of these processes to handle multiple maps. - Have potential issue of data consistency - if as suggested in Ryo's message that run time loading of new archetypes/other data is added, keep all processes in sync could be tricky. Multiple process mixed (has both pros & cons): - Need a proxy process to handle communication between client and these processes. Client can keep client access even if a process dies. However, this proxy is a new set of code, and if it does die, all clients lose their connection. Multiple thread pros: - Less code changes - other than creation and deletion of threads, only changes really needed is addition of locks - no new IPC code, client updates, etc. - Much more memory friendly - running 1 thread per map, even if that is 1000 threads, is completely doable. - One could even do multiple threads per map, for example a thread run every 60 seconds that does a backup of the map/player/etc. - Multiple threads still fix problem of meteor shower or other slowdowns - would be limited to that one thread (and thus map) and not hit everyone. - Since all threads share same address space, updates to archetypes/images/whatever while running would just work. Multiple thread cons: - Still limited to a single server - can't run distributed. - If one thread crashes, all threads crash. - Can be harder to debug problems (missing locks could lead to odd state of variables which is hard to pinpoint cause of) Multiple thread other notes: - Even with multiple threads, one could have a very simple proxy process, so that if the server does die, that proxy is still running and can re-connect clients to server when it is up again. From agschult at ucalgary.ca Wed Nov 26 23:59:35 2008 From: agschult at ucalgary.ca (Alex Schultz) Date: Wed, 26 Nov 2008 22:59:35 -0700 Subject: [crossfire] multithread vs multi process In-Reply-To: <492E2EA1.1090809@sonic.net> References: <200811172007.40625.nicolas.weeger@laposte.net> <492B95F0.60503@sonic.net> <20081124232850.6a4128b0@ucalgary.ca> <492E2EA1.1090809@sonic.net> Message-ID: <20081126225935.38f790c4@ucalgary.ca> On Wed, 26 Nov 2008 21:22:41 -0800 Mark Wedel wrote: > Multiple process cons: > - Would need client (and protocol) updates in addition to server > updates. I don't have much comment right on the other points, they make sense. However I strongly disagree on this one point. No protocol/client changes would really be needed at all unless it was distributed over separate physical servers (which I don't think is necessary to support). Like I said in another email, it's not hard for one process to "hand-off" TCP-IP sockets to another process while keeping it open. Alex From mwedel at sonic.net Thu Nov 27 00:26:10 2008 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 26 Nov 2008 22:26:10 -0800 Subject: [crossfire] multithread vs multi process In-Reply-To: <20081126225935.38f790c4@ucalgary.ca> References: <200811172007.40625.nicolas.weeger@laposte.net> <492B95F0.60503@sonic.net> <20081124232850.6a4128b0@ucalgary.ca> <492E2EA1.1090809@sonic.net> <20081126225935.38f790c4@ucalgary.ca> Message-ID: <492E3D82.9020406@sonic.net> Alex Schultz wrote: > On Wed, 26 Nov 2008 21:22:41 -0800 > Mark Wedel wrote: > >> Multiple process cons: > >> - Would need client (and protocol) updates in addition to server >> updates. > > I don't have much comment right on the other points, they make sense. > However I strongly disagree on this one point. No protocol/client > changes would really be needed at all unless it was distributed over > separate physical servers (which I don't think is necessary to > support). Like I said in another email, it's not hard for one process > to "hand-off" TCP-IP sockets to another process while keeping it open. The issue is related to the connection, the issue is related to objects and tagging. For example, process A has used tags 1-1000. Some items in the players inventory also uses those tags. Player moves from whatever map to what process A is now using. Those items in the players inventory needs to be retagged. Now in fairness, this could be done by deleting everything in players inventory and then re-sending it (and would be easiest), but that isn't especially bandwidth friendly. A more narrow case would be to delete and re-send those objects. But in the simplest case, all objects in the players inventory would get re-tagged (unique tags for process A) - process A would most similarly act as if a new player logged in, as that is effectively what has happened, so all those get_object calls would almost certainly not have the same tags as before. Now you could come up with some mechanism like 'get_object_but_prefer_tag..()' - the problem is that right now, other than searching through every object, you don't know if that tag is in use. And doing that search for a few hundred objects might be slow. And you still have to cover the case where items do get retagged. And you probably don't want that to be slow - you don't want process A to slow down whenever a new player joins it, since the most likely scenario for this is player returning to the various towns. So in fairness, you don't need protocol changes, and instead replace it with this con: - Very bandwidth intensive when player changes maps (have to re-send entire inventory) There are also other solutions - you could have some central process responsible for handing out unique tags to all objects on all the servers, but I have a feeling the performance hit (due to needing to do IPC on that) probably wouldn't be tolerable. From mwedel at sonic.net Thu Nov 27 01:12:35 2008 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 26 Nov 2008 23:12:35 -0800 Subject: [crossfire] multithread vs multi process In-Reply-To: <492E3D82.9020406@sonic.net> References: <200811172007.40625.nicolas.weeger@laposte.net> <492B95F0.60503@sonic.net> <20081124232850.6a4128b0@ucalgary.ca> <492E2EA1.1090809@sonic.net> <20081126225935.38f790c4@ucalgary.ca> <492E3D82.9020406@sonic.net> Message-ID: <492E4863.5020005@sonic.net> Mark Wedel wrote: > - Very bandwidth intensive when player changes maps (have to re-send entire > inventory) > I was thinking about this more, and inventory is only one of the issues. The server records a lot of information about what it has sent to the client (animations, faces, etc). In a multi process model, you either have to communicate all that between the processes, or have that proxy program take care of it. The problem with having the proxy take care of it is that the more it does, potential for more bugs and thus it crashing. Also, if it starts doing too much, then it can perhaps become a bottleneck itself. And on this topic, this also adds an extra complication to the multi server setup - how (or do you) deal with cases where those multiple servers have assigned different numbers to the images, etc. The multiprocess setup (running on same server and forked off) might not have this problem, since presumably all those processes started with same data files. But if running on different servers, then likely those are reading up arch data, etc, from local files, and could be different. Dealing with a case where grass image is 156 on one server and 158 on another is a new headache. You're almost better off in that case in not trying to hide it from the player - basically have some automatic redirection, but as far as the client is concerned, it is a completely new server and thus shouldn't rely on old image data. This is certainly an area that would need further thought for multi server support. From nicolas.weeger at laposte.net Thu Nov 27 12:09:27 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 27 Nov 2008 19:09:27 +0100 Subject: [crossfire] C++/Qt server version In-Reply-To: <200811172007.40625.nicolas.weeger@laposte.net> References: <200811172007.40625.nicolas.weeger@laposte.net> Message-ID: <200811271909.30878.nicolas.weeger@laposte.net> Hello. Ok, from what I gather, people aren't against massive changes on the server. Reminder, though: content goes first, always :) So feel free to ignore all the technical aspects if you only want to make content :D So here is what we'll do: - put on a wiki page what kind of game we want (quick gameplay? slow combat? combat only? other things?), so we all know what we aim for - put on a wiki page features we want from a technical point of view - put down design ideas for those features - select which one we'll use - then decide whether to start from the current base, from scratch with copy'n'paste, what to use, and so on I guess I'm the one to start the wiki page, since I launched the discussion in the first place :) I shall do this soon, just a few things to think over before proposing things :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081127/cbc58eec/attachment.pgp From kbulgrien at worldnet.att.net Sat Nov 29 02:45:49 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 29 Nov 2008 02:45:49 -0600 Subject: [crossfire] (Automated) Client Snapshot Releases Message-ID: <200811290245.49880.kbulgrien@worldnet.att.net> A script has been developed that automatically creates (debuggable with sources) snapshot builds of the crossfire clients (tarballs and RPMs, but no Win32 support). It has logic to initialize a build environment from SVN and to update from SVN for each snapshot. It has been run through a lot of paces and is far from being a pile of ugly, but some work could be put into polishing it up to detect/handle build errors, etc., as it matures. Presently it does not validate the snapshots in any way. It is written to document the release process in code, and to take the pain out of building (snapshot) releases. It is reasonable to think that it can be enhanced to better assist with official release functions as well. Though the script produces client tarballs, etc. It does have to work in the server code base to produce the client files, so already has some of the functions needed to do a server release. What might it take to break the blockade on 2.x client releases? Snapshot builds have been mentioned before, and a lot of work on the release process has been done in response to a general complaint expressed last time this was brought up. Are there any good reasons left to avoiding putting the 2.x client out there? We're going on two years of client enhancements with no releases. That can't be helping project exposure any. What next? With this script, and with access to another system I could post snapshots periodically manually, or via some cron process, or, the script could be opened up to anyone who wanted to support snapshot builds themselves. Offers? Suggestions? The idea of checking scripts into SVN has been brought up in the past and has gotten mixed reviews. This script is one that is really tied in to a particular aspect of development, so perhaps is more suited to SVN if only because should facilitate shorter release cycles that have been discussed from time to time. While the script could be subordinated to the client directory, it may be better to have a separate tools/packaging area that can be used to support client and server releases. Are there any objections to creating a tools/trunk/packaging area in SVN, or alternate specific suggestions? P.S. Right now my build system is x86_64, and unfortunately x86_64 RPMs seems to have the "[ 1876788 ] Doubled characters in GTK clients" bug. This script makes it easier for people to get involved in collecting data or working on this client issue, and was part of the motivation to write the script - to remove the pain of rebuilding the client RPMs to test code changes. From crossfire at ailesse.com Sat Nov 29 03:24:00 2008 From: crossfire at ailesse.com (Lauwenmark Akkendrittae) Date: Sat, 29 Nov 2008 10:24:00 +0100 Subject: [crossfire] (Automated) Client Snapshot Releases In-Reply-To: <200811290245.49880.kbulgrien@worldnet.att.net> References: <200811290245.49880.kbulgrien@worldnet.att.net> Message-ID: <200811291024.22579.crossfire@ailesse.com> Le samedi 29 novembre 2008, Kevin R. Bulgrien a ?crit : > A script has been developed that automatically creates (debuggable with > sources) snapshot builds of the crossfire clients (tarballs and RPMs, > but no Win32 support). It has logic to initialize a build environment > from SVN and to update from SVN for each snapshot. Such a scripted packaging system has been tested on ailesse for the binary client (Just like the current Gridarta/JXClient daily builds, it generated Debian packages, then RPM ones through Alien). It had been removed last year for basically two reasons: - Architecture portability issues: although the client could be cross-compiled for other architectures than x86 (at least x86_64, ARM and PPC were supported), there was no way to ensure the non-x86 packages produced a working result. Since a package version always automatically replaced the previous one, chances to screw up a non-x86 installation were estimated too high to be acceptable; - Distribution portability issues: Packages could only be built reliably for Linux. I wasn't able to implement cross-building for Solaris, FreeBSD or OSX; Given the time it would have taken to properly fix those issues - and I'm actually not sure they could have been - and also given that another client was already available as a daily package, daily packaging of the C clients has been abandoned. This experience showed that what was difficult was not the packaging process itself, but ensuring that it gets supported outside the Linux/x86(_64) world. > Are there any good reasons left to avoiding putting the > 2.x client out there? We're going on two years of client enhancements > with no releases. That can't be helping project exposure any. > The fact that the 2.x server itself is still a highly moving target, and thus that a release would be very prematurate. To me, it seems that a release, unless marked specifically as "alpha/beta", needs to be relatively stable and finished. -- Lauwenmark. ------------ "Drive defensively: buy a tank." -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081129/e6079317/attachment.pgp From kbulgrien at worldnet.att.net Sat Nov 29 10:24:48 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 29 Nov 2008 10:24:48 -0600 Subject: [crossfire] (Automated) Client Snapshot Releases In-Reply-To: <200811291024.22579.crossfire@ailesse.com> References: <200811290245.49880.kbulgrien@worldnet.att.net> <200811291024.22579.crossfire@ailesse.com> Message-ID: <200811291024.48583.kbulgrien@worldnet.att.net> > Such a scripted packaging system has been tested on ailesse for the binary > client (Just like the current Gridarta/JXClient daily builds, it generated > Debian packages, then RPM ones through Alien). It had been removed last > year for basically two reasons: > - Architecture portability issues: although the client could be > cross-compiled for other architectures than x86 (at least x86_64, ARM and > PPC were supported), there was no way to ensure the non-x86 packages > produced a working result. Since a package version always automatically > replaced the previous one, chances to screw up a non-x86 installation were > estimated too high to be acceptable; > > - Distribution portability issues: Packages could only be built reliably > for Linux. I wasn't able to implement cross-building for Solaris, FreeBSD > or OSX; Non-Linux builds are always hazards. AFAIK, releasing has little to do with breakage. The more serious breakage is due to incremental development and a failure to release in a timely manner. Frankly, I see this as a lesser issue than the failure to make current development available Further, automated releases were only one possibility mentioned. The other was for periodic release. From what has been said in the past, it seems releases are not done because it is difficult. The script makes it not difficult. > Given the time it would have taken to properly fix those issues - and I'm > actually not sure they could have been - and also given that another client > was already available as a daily package, daily packaging of the C clients > has been abandoned. Not everyone is satisfied with the current state of affairs, and one of these is trying to contribute something positive. > This experience showed that what was difficult was not the packaging > process itself, but ensuring that it gets supported outside the > Linux/x86(_64) world. If there is something new released, and if someone cares about non-x86, they can deal with and contribute to build and packaging. If no one cares, then... what good reason is there to care about such an ideological issue? Besides, people should be able care less whether some niche group happens to like a different x86 client while the rest of the world explores the cross-platform nirvana demonstrated by the other client. > > Are there any good reasons left to avoiding putting the > > 2.x client out there? We're going on two years of client enhancements > > with no releases. That can't be helping project exposure any. > > The fact that the 2.x server itself is still a highly moving target, and > thus that a release would be very prematurate. To me, it seems that a > release, unless marked specifically as "alpha/beta", needs to be relatively > stable and finished. Firstly, this ignores the fact that the "2.x" client is still branch compatible many months after 2.x was created, and it has many enhancements that should be available to branch players. When this is no longer the case this will seem more like an relevant comment. Secondly, the script builds RPMs and binaries that are marked with the SVN revision number. If this is not clear enough, it is trivial to add other static markings. In summary, though the arguments presented make it sound reasonable to dispense with the idea unattended builds, they do not seem to provide a reason to continue to leave a perfectly good client with improvements unreleased. The script is presented primarily because when I have lobbied for release previously, one of the reasons given was that it was so difficult to make a release. I aimed to remove the possibility of being given that reason again. At this point, to my knowledge, the branch clients have the same instabilities as what is on trunk, but offer fewer options to players. I did a lot of work on that client. I'd like to see it getting put out there for people to use. I think that's easy to understand, and do not see why it should be so quickly argued against. From nicolas.weeger at laposte.net Sun Nov 30 02:35:04 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 30 Nov 2008 09:35:04 +0100 Subject: [crossfire] C++/Qt server version In-Reply-To: <200811271909.30878.nicolas.weeger@laposte.net> References: <200811172007.40625.nicolas.weeger@laposte.net> <200811271909.30878.nicolas.weeger@laposte.net> Message-ID: <200811300935.08586.nicolas.weeger@laposte.net> Hello. I've put a first basic draft at http://wiki.metalforge.net/doku.php/dev%3Aserver_design The first step, though, would be to define the exact kind of game we want, obviously :) Feel free to tweak the page and add stuff you think is missing! (note: the dates are informative, can be changed by some days/weeks if needed - but I don't expect those design steps to take years, actually) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081130/693f1aee/attachment.pgp From crossfire at ailesse.com Sun Nov 30 05:06:10 2008 From: crossfire at ailesse.com (Lauwenmark Akkendrittae) Date: Sun, 30 Nov 2008 12:06:10 +0100 Subject: [crossfire] (Automated) Client Snapshot Releases In-Reply-To: <200811291024.48583.kbulgrien@worldnet.att.net> References: <200811290245.49880.kbulgrien@worldnet.att.net> <200811291024.22579.crossfire@ailesse.com> <200811291024.48583.kbulgrien@worldnet.att.net> Message-ID: <200811301206.18344.crossfire@ailesse.com> Le samedi 29 novembre 2008, Kevin R. Bulgrien a ?crit : > Non-Linux builds are always hazards. > Not at all. They are only difficult because they require availability of each platform. Or, to formulate it differently: it is hard to build a Win32/FreeBSD/Solaris/OSX package without a working installation of Win32/FreeBSD/Solaris/OSX. > AFAIK, releasing has little to do with breakage. > What I tried to explain was that it was not a good idea to make a release when you don't have the guarantee that it works at least good enough for common, daily use. That's also why the ailesse daily builds were never advertised as "releases", but as "builds" - they don't meet the necessary quality checks of a stable release. Their only purpose is to allow non-programmers to test them and provide feedback. That's also why the Gridarta page on the Crossfire website says "No release yet", despite daily builds having been available for months. In short: "experimental build != release" by far. > The more serious breakage is due to incremental development > and a failure to release in a timely manner. Frankly, I see this as a > lesser issue than the failure to make current development available > The current development can easily be made available through a system of daily builds, again in the same fashion as Gridarta or JXClient, with the caveat that shipping packages for something else than Linux/x86(_64) may be made difficult due to lack of a proper testing infrastructure. > Further, automated releases were only one possibility mentioned. The other > was for periodic release. From what has been said in the past, it seems > releases are not done because it is difficult. The script makes it not > difficult. > Frankly, I don't get what would make releases so difficult, from the strict package creation side of things. As I've said, generating proper packages from the SVN is not the difficult part of making a release, provided you have the matching environment available (Windows to create Win32 packages, OSX for the Mac ones, etc). > > Given the time it would have taken to properly fix those issues - and I'm > > actually not sure they could have been - and also given that another > > client was already available as a daily package, daily packaging of the C > > clients has been abandoned. > > Not everyone is satisfied with the current state of affairs, and one of > these is trying to contribute something positive. > I simply exposed why the C client was not part of the public daily packaging process anymore. My explanation had nothing to do with being satisfied or not with a morale situation. > If there is something new released, and if someone cares about non-x86, > they can deal with and contribute to build and packaging. > Not everybody is a developer, or is willing to invest time in learning the necessary techniques. > If no one cares, > then... what good reason is there to care about such an ideological issue? > Just because nobody steps in to support a given environment doesn't mean nobody would be interested to see the game available on those. Just as a side note, a reminder from the Wiki front page: "Crossfire works on: - Linux - Windows - All *BSD?s - Mac OSX (Server and clients compile, in testing)" So, if we advertise the game as supporting those platforms, then I consider it is our duty to ensure that the releases support them. Note again that I'm considering "releases" here, not "builds". > Besides, people should be able care less whether some niche group happens > to like a different x86 client while the rest of the world explores the > cross-platform nirvana demonstrated by the other client. > I don't think I ever mentioned any kind of "cross-platform nirvana" - JXClient has its own share of issues, some being related to portability. I don't think I denied you the right of enjoying another client, either. My points were that IMHO: (1) Package creation on an available platform was not a problem; (2) Package creation on a not available platform was a problem; (3) C code daily packages were not made public on ailesse due to (2). Given that your scripting solution didn't seem to adress (2), I found important to underline the issues I encountered with the daily package generation process on ailesse. Now, you can consider those issues as irrelevant - I've no problem with that. But then, it means that the new scripts will not make my task as a packager any simpler, making me wondering what purpose they'd then be supposed to fullfill. > > The fact that the 2.x server itself is still a highly moving target, and > > thus that a release would be very prematurate. To me, it seems that a > > release, unless marked specifically as "alpha/beta", needs to be > > relatively stable and finished. > > Firstly, this ignores the fact that the "2.x" client is still branch > compatible many months after 2.x was created, and it has many enhancements > that should be available to branch players. > Then make a 1.12 branch out of that code, and release it under a 1.12 version, with the added benefit of deprecating the client 1.11 branch, ending its support. My comment was just about releasing the client code under the "2.x" code, and using trunk as the codebase instead of first making a stable branch out of it. > In summary, though the arguments presented make it sound reasonable to > dispense with the idea unattended builds, they do not seem to provide a > reason to continue to leave a perfectly good client with improvements > unreleased. > I've never commented against making a release of the current C client code. I've only commented against doing it as a "2.x client". > The script is presented primarily because when I have lobbied for release > previously, one of the reasons given was that it was so difficult to make > a release. I aimed to remove the possibility of being given that reason > again. > Let's be clear on this: I do agree that it is difficult to make a proper release. But indeed, we obviously disagree on where the difficulty lies. You also seem to confuse the notions of "release" and "periodic snapshots". To me, both are quite different, and don't have the same quality requirements. > At this point, to my knowledge, the branch clients have the same > instabilities as what is on trunk, but offer fewer options to players. > Then why not make a new branch release by taking a snapshot of the current trunk content, and number it 1.12 ? To that, I indeed agree. > I did a lot of work on that client. I'd like to see it getting put out > there for people to use. I think that's easy to understand, and do not > see why it should be so quickly argued against. > No, I'm basically questioning the usefulness of the proposed scripts. In which way would they make my life as a packager easier ? So far, I'm unsure of the answer, so yes, I'm rather cold to the idea. I'm also arguing against releasing anything under the 2.x version mark at this stage. Quoting myself again, "it seems that a release, unless marked specifically as "alpha/beta", needs to be relatively stable and finished.". Is 2.O stable and finished ? no - thus, don't make a 2.0 release. But again, I see nothing wrong in releasing the client as a member of the 1.x family, since this is what we have today, and that it works pretty well with the current servers in use. -- Lauwenmark. ------------ "Drive defensively: buy a tank." -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081130/cfa50f93/attachment.pgp From kbulgrien at att.net Sun Nov 30 09:16:41 2008 From: kbulgrien at att.net (Kevin R. Bulgrien) Date: Sun, 30 Nov 2008 09:16:41 -0600 Subject: [crossfire] Client Snapshot Builds References: <200811290245.49880.kbulgrien@worldnet.att.net> <200811291024.22579.crossfire@ailesse.com> <200811291024.48583.kbulgrien@worldnet.att.net> <200811301206.18344.crossfire@ailesse.com> Message-ID: > Not at all. They are only difficult because they require availability of > each platform. Or, to formulate it differently: it is hard to build a > Win32/FreeBSD/Solaris/OSX package without a working installation of > Win32/FreeBSD/Solaris/OSX. > >> AFAIK, releasing has little to do with breakage. >> > What I tried to explain was that it was not a good idea to make a release > when you don't have the guarantee that it works at least good enough for > common, daily use. > > That's also why the ailesse daily builds were never advertised as > "releases", but as "builds" - they don't meet the necessary quality checks > of a stable release. Their only purpose is to allow non-programmers to > test them and provide feedback. That's also why the Gridarta page on the > Crossfire website says "No release yet", despite daily builds having been > available for months. > > In short: "experimental build != release" by far. Agreed, it appears the use of the word "release" and "automated" in the subject is the primary concern. They need need not be there. The release procedure mentions nothing about cross-platform checks. Perhaps it should, but if a releaser checks all the platforms at the moment, it is undocumented, and I suspect, not done, by looking at the website client page, so sticking on that point might cause all releasing to stop. I have a Sparcstation I could set up, and enough old hardware for a BSD, but will never have a Mac. >> The more serious breakage is due to incremental development >> and a failure to release in a timely manner. Frankly, I see this as a >> lesser issue than the failure to make current development available >> > The current development can easily be made available through a system of > daily builds, again in the same fashion as Gridarta or JXClient, with the > caveat that shipping packages for something else than Linux/x86(_64) may > be made difficult due to lack of a proper testing infrastructure. > >> Further, automated releases were only one possibility mentioned. The >> other >> was for periodic release. From what has been said in the past, it seems >> releases are not done because it is difficult. The script makes it not >> difficult. >> > Frankly, I don't get what would make releases so difficult, from the > strict package creation side of things. The releaser said it was difficult, and since he does the releases, that's what matters. Its in list history. In response, I addressed the issues I understood to be problems. > Just as a side note, a reminder from the Wiki front page: > > "Crossfire works on: > - Linux > - Windows > - All *BSD?s > - Mac OSX (Server and clients compile, in testing)" > > So, if we advertise the game as supporting those platforms, then I > consider it is our duty to ensure that the releases support them. > Note again that I'm considering "releases" here, not "builds". I see from the web site that clients of varying versions are there, demonstrating that we have not stuck to ideals in the past, and probably need not be idealistic at this point even if we do try to improve incrementally. Debian, and other packaging formats are also missing, implying some external effort is understood to be required, but then this is probably approaching the point of beating on dead horses. >> Besides, people should be able care less whether some niche group happens >> to like a different x86 client while the rest of the world explores the >> cross-platform nirvana demonstrated by the other client. >> > I don't think I ever mentioned any kind of "cross-platform nirvana" - > JXClient has its own share of issues, some being related to portability. I > don't think I denied you the right of enjoying another client, either. > > My points were that IMHO: > (1) Package creation on an available platform was not a problem; > (2) Package creation on a not available platform was a problem; > (3) C code daily packages were not made public on ailesse due to (2). > > Given that your scripting solution didn't seem to adress (2), I found > important to underline the issues I encountered with the daily package > generation process on ailesse. Got to start somewhere... thats how most problems are tackled... You had a solution, not made public, I did not know about... I had to redo effort. Now I have something, but because it is not perfect must we force the next guy to start from square one? > Now, you can consider those issues as irrelevant - I've no problem with > that. But then, it means that the new scripts will not make my task as a > packager any simpler, making me wondering what purpose they'd then be > supposed to fullfill. Many projects do not attempt to package for all platforms but rely on interested parties to care for that and report issues. That's not the same thing as being irrelevent in the purest sense of the word. I would like to see cross platform builds, but I don't want to see the project continue as-is if that is the only reason. Some of the distribution packagers believe that packaging is not something a project should attempt as I have personally gotten grief for that sort of thing. I happen to be a bit more in the middle. I'd hope being on the other extreme did not retard the projects ability to move forward. > Then make a 1.12 branch out of that code, and release it under a 1.12 > version, with the added benefit of deprecating the client 1.11 branch, > ending its support. > > My comment was just about releasing the client code under the "2.x" code, > and using trunk as the codebase instead of first making a stable branch > out of it. Ok, now we're getting somewhere. I had a similar thought the other day. > No, I'm basically questioning the usefulness of the proposed scripts. In > which way would they make my life as a packager easier ? So far, I'm > unsure of the answer, so yes, I'm rather cold to the idea. Apparently not everyone thinks making packages is easy. I did not, and would have not wasted my time making a script if it were as easy as seems to be implied. Without further interest, there is obviously no point in continuing to banter about it between us. We need to agree to disagree. > I'm also arguing against releasing anything under the 2.x version mark at > this stage. Quoting myself again, "it seems that a release, unless marked > specifically as "alpha/beta", needs to be relatively stable and > finished.". Is 2.O stable and finished ? no - thus, don't make a 2.0 > release. But again, I see nothing wrong in releasing the client as a > member of the 1.x family, since this is what we have today, and that it > works pretty well with the current servers in use. Thanks for the reply. It helps show positions are not as far apart as they initially seemed to be. I do think the slow release cycles hurt the project. I'm not sure people see that. Since I think that, some attempt was made to proactively deal with it. Perhaps the initial ideas were flawed here and there, but the basic intent still seems reasonable, and we apparently will continue to disagree on automation as been something that improves the project because it does not support all platforms we claim to support.