From nicolas.weeger at laposte.net Thu Jun 12 13:35:55 2014 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 12 Jun 2014 20:35:55 +0200 Subject: [crossfire] Game change proposals Message-ID: <201406122036.00186.nicolas.weeger@laposte.net> Hello. I'd like to change various things in the game, to make it funnier (IMO) in non combat aspects. So here are random proposals. What about "mini-games"? For instance, instead of a mere lockpicking, you actually have to use the picks in the right order in a limited time to pick a lock - if you fail, you trigger the traps, of course. [bonus points to who knows the old game I'm getting inspiration from :)] What about changing alchemy (including the jeweler etc. variants)? For each formulae you start with a ~3% chance of success. You succeed? Get 3 to 5 points. Failure? Get 0-1 point (failure is a valuable lesson, after all :)). Capped to ~90%. And maybe not giving global experience. What about random (ie player-dependant) parameters? You have more success during certain hours, or outside vs inside, or...? Then reduce the dropped items. I mean, so much junk! Then, slowing (a lot) combat, making it more tactical. Instead of a zillion monsters, some hard to defeat monsters, where you can use all your skills and items, and attempt various combinations. Then various effects on weapons: stun, knock back, confuse, slow, etc. Reduce the zillion elemental attacks to a lower number (6? 8?), other things are side effects. Thoughts? Flames? Ideas? Regard Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From kevinz5000 at gmail.com Thu Jun 12 14:08:46 2014 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Thu, 12 Jun 2014 14:08:46 -0500 Subject: [crossfire] Game change proposals In-Reply-To: <201406122036.00186.nicolas.weeger@laposte.net> References: <201406122036.00186.nicolas.weeger@laposte.net> Message-ID: <5399FABE.2060308@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/12/2014 13:35, Nicolas Weeger wrote: > What about "mini-games"? > > For instance, instead of a mere lockpicking, you actually have to > use the picks in the right order in a limited time to pick a lock - > if you fail, you trigger the traps, of course. > > [bonus points to who knows the old game I'm getting inspiration > from :)] I like mini-games, and if there were more mini-games I would play Crossfire a whole lot more. My schedule no longer allows me to sit down for 4 hours straight hacking through a dungeon. I think short pickup multiplayer mini-games would be best. A handful of single-player games would be good, too. > What about changing alchemy (including the jeweler etc. variants)? > > For each formulae you start with a ~3% chance of success. You > succeed? Get 3 to 5 points. Failure? Get 0-1 point (failure is a > valuable lesson, after all :)). Capped to ~90%. And maybe not > giving global experience. I'm not sure, I'd need more time/discussion to decide. Currently a lot of ingredients are difficult to come by, so I'm afraid this will make alchemy too unattractive. This would at least help fix the issue of out-of-game knowledge of recipes, though. > What about random (ie player-dependant) parameters? You have more > success during certain hours, or outside vs inside, or...? YES! There should be a certain spot in the world where producing a certain recipe yields extra. Or, certain (hard) recipes should depend on the phase of the moon. Really, this would encourage alchemists to go explore the world for once instead of sit in apartments all day. > Then reduce the dropped items. I mean, so much junk! Yes, and make more useful items appear once in a while. This will probably require balancing, too. > Then, slowing (a lot) combat, making it more tactical. Instead of a > zillion monsters, some hard to defeat monsters, where you can use > all your skills and items, and attempt various combinations. Yes, although I'm not entirely sure how to go about it. Many games that have combat involve clicking the enemy you want to kill, killing it, and then moving on to the next. I'm not sure if this suits Crossfire. > Then various effects on weapons: stun, knock back, confuse, slow, > etc. And certain special attacks that take time to recharge, perhaps. But this would definitely make other spells more useful. > Reduce the zillion elemental attacks to a lower number (6? 8?), > other things are side effects. This would make handling special attacks easier. Thanks, Kevin Zheng -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTmfq+AAoJEOrPD3bCLhCQpekIAIxj7AeJDa0MJhKCumPKZW7Z WHCFHlobVDLqeeHXSDWTRC+n07gRowEs2TEvRpmSntFw6WJGGp0H5Mbq/OGijKt2 PhXKR9/ZZgW4ViBOxqW/Qc9bzZswYKgSVA99skMVfrIAu2QHAhpJ7T6Cb46Sujwc MrTgEt80V7s2smbzndLE5Mw8rqWJgWBJfnEWhm67OkTM5cYQnzxkQzL70GETjR0p ryLOfPE3Hnd1/unPPO0SH61nS1OJ6dvk84d92TrkbDRr1UbveqqlbFk00OxvSJlr zUUkhHOcptgXTgW0JLMRoj0hf9GPQuuLwIItVrLtCkc+ECoVx+oZ7iOUBx6TTd8= =SmBt -----END PGP SIGNATURE----- From tolga.dalman at googlemail.com Thu Jun 12 14:49:05 2014 From: tolga.dalman at googlemail.com (Tolga Dalman) Date: Thu, 12 Jun 2014 21:49:05 +0200 Subject: [crossfire] Game change proposals In-Reply-To: <5399FABE.2060308@gmail.com> References: <201406122036.00186.nicolas.weeger@laposte.net> <5399FABE.2060308@gmail.com> Message-ID: <539A0431.9020408@project-psi.org> On 06/12/2014 09:08 PM, Kevin Zheng wrote: > On 06/12/2014 13:35, Nicolas Weeger wrote: >> What about "mini-games"? > >> For instance, instead of a mere lockpicking, you actually have to use the >> picks in the right order in a limited time to pick a lock - if you fail, >> you trigger the traps, of course. > >> [bonus points to who knows the old game I'm getting inspiration from :)] > > I like mini-games, and if there were more mini-games I would play Crossfire > a whole lot more. My schedule no longer allows me to sit down for 4 hours > straight hacking through a dungeon. > > I think short pickup multiplayer mini-games would be best. A handful of > single-player games would be good, too. I agree. Also, some skills are pretty useless right now. This situation could be alleviated at the same time. >> What about changing alchemy (including the jeweler etc. variants)? > >> For each formulae you start with a ~3% chance of success. You succeed? >> Get 3 to 5 points. Failure? Get 0-1 point (failure is a valuable lesson, >> after all :)). Capped to ~90%. And maybe not giving global experience. > > I'm not sure, I'd need more time/discussion to decide. Currently a lot of > ingredients are difficult to come by, so I'm afraid this will make alchemy > too unattractive. This would at least help fix the issue of out-of-game > knowledge of recipes, though. Alchemy is right now rather static, so I agree that there should be added a little bit of randomness. Adding failure/success is one part of the story, another one could be to create more random item (properties) with alchemy. Thus, a high-level crafter could create completely new and unique items. In any case, I'd also like more discussion about the technical details. >> What about random (ie player-dependant) parameters? You have more success >> during certain hours, or outside vs inside, or...? > > YES! There should be a certain spot in the world where producing a certain > recipe yields extra. Or, certain (hard) recipes should depend on the phase > of the moon. Really, this would encourage alchemists to go explore the > world for once instead of sit in apartments all day. Yes, adding more randomness is good. However, I suppose that this could lead players to exploit these events once they are found out (which shouldn't be difficult after all). It should be possible to turn this feature on or off via a server-side parameter (or compile-time macro), IMHO. >> Then reduce the dropped items. I mean, so much junk! > > Yes, and make more useful items appear once in a while. This will probably > require balancing, too. Yes, please do! >> Then, slowing (a lot) combat, making it more tactical. Instead of a >> zillion monsters, some hard to defeat monsters, where you can use all >> your skills and items, and attempt various combinations. > > Yes, although I'm not entirely sure how to go about it. Many games that > have combat involve clicking the enemy you want to kill, killing it, and > then moving on to the next. I'm not sure if this suits Crossfire. While I don't actually see a problem with an adapted user interface (e.g., the player automatically continues to attack the next enemy in melee), this idea really changes crossfire. I certainly would appreciate more "tactical" combats/magic since slaughtering masses of monsters becomes dull after a time. However, this change includes a lot of work and experimenting with balancing, modified maps, experience, pantheon, etc. I do support this if you really are going this way. But my feeling is, that it will be tough. >> Then various effects on weapons: stun, knock back, confuse, slow, etc. > > And certain special attacks that take time to recharge, perhaps. But this > would definitely make other spells more useful. This makes only sense with the tactial change you proposed above. I like it :) >> Reduce the zillion elemental attacks to a lower number (6? 8?), other >> things are side effects. > > This would make handling special attacks easier. Sounds good to me. From mwedel at sonic.net Fri Jun 13 01:08:37 2014 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 12 Jun 2014 23:08:37 -0700 Subject: [crossfire] Game change proposals In-Reply-To: <201406122036.00186.nicolas.weeger@laposte.net> References: <201406122036.00186.nicolas.weeger@laposte.net> Message-ID: <539A9565.4000902@sonic.net> On 06/12/14 11:35 AM, Nicolas Weeger wrote: > Hello. > > > I'd like to change various things in the game, to make it funnier (IMO) in non > combat aspects. So here are random proposals. > > > > What about "mini-games"? > > For instance, instead of a mere lockpicking, you actually have to use the > picks in the right order in a limited time to pick a lock - if you fail, you > trigger the traps, of course. > > [bonus points to who knows the old game I'm getting inspiration from :)] I'm not familiar to the original game, but I'd be careful with anything that is too time sensitive. I'd also like a better idea of what you envision. Is it something like there are 10 (or 20) different lockpicks in the game, and the character has to use them in the right order? Presumably, the lockpick skill should still come in to play in some way for this also (amount of time to pick the lock, or perhaps some amount of not needing the precise lockpicks or something) Of course, lockpicking and doors in general could use a bit of a revamp - too much is 'you must do the dungeon in this order, meaning get key A, which lets you get key B, etc'. let those doors be pickable - perhaps they have really nasty traps if you don't use the key, or perhaps they are just really tough. This might require redesign of some maps (treasure room near the start that is protected by a locked door may not be a good idea), but would make more sense. Another easy thing would be to have most chests locked - the player could bash them open, but might destroy the items inside. > > > > > > > What about changing alchemy (including the jeweler etc. variants)? > > For each formulae you start with a ~3% chance of success. You succeed? Get 3 > to 5 points. Failure? Get 0-1 point (failure is a valuable lesson, after all > :)). Capped to ~90%. And maybe not giving global experience. I don't mind so much the global experience, and I still like the idea of the alchemy skill itself having a level (until you get to level 10, some recipes may just not be possible). But tracking individual recipes and bonus for each seems like a fine idea. It might also be reasonable that common/simple recipes are globally known (or are automatically learned at certain levels), so that the alchemy recipes out there are for rare and unusual items. Otherwise, playing only with in game knowledge always seems very difficult. > > What about random (ie player-dependant) parameters? You have more success > during certain hours, or outside vs inside, or...? Totally reasonable for different things - one could certainly imagine that scribing at a desk should be easier than out in the wilderness. > Then reduce the dropped items. I mean, so much junk! That is a big change, and probably fairly simple to do - most other games do this (those creatures may be attacking you with axes, but you don't get all those weapons when you kill them). Likewise, even of the items that are out there, one could reasonably ask do we really need the number of different swords out there that vary by a minor detail. I know some games do this, but that is more related to skins (this sword looks cool) - with the way crossfire is, that really isn't the case. ] > Then, slowing (a lot) combat, making it more tactical. Instead of a zillion > monsters, some hard to defeat monsters, where you can use all your skills and > items, and attempt various combinations. That would be good, but is also a major change - the vast majority of maps would need to be refactored (maps with gobs of monsters would just be unplayable). > > Then various effects on weapons: stun, knock back, confuse, slow, etc. Seems reasonable, though than in itself creates yet different issues (if a player can use a weapon effectively enough to constantly keep a monster stunned, probably makes for an easy combat) > > Reduce the zillion elemental attacks to a lower number (6? 8?), other things > are side effects. Agree - most of those are side effects. The trickier part on some of those is whether resistances should exist and how to then factor them in - the number of attacks and number of resistances sort of go hand in hand. While one could certainly come up with different logic to handle those, that solution may just be more complicated. Note that if you did all the above changes, that is some fairly radical changes to the game (attack rate and item drop). Though perhaps the second comes from the first - if combat is a lot slower, that would then suggest there are a lot fewer monsters, which should then mean a lot lower item drop. From kevinz5000 at gmail.com Fri Jun 13 08:13:22 2014 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Fri, 13 Jun 2014 08:13:22 -0500 Subject: [crossfire] Crossfire should use Git Message-ID: <539AF8F2.10005@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, Crossfire originally lived in the world of CVS, until a handful of brave knights ventured to move it to SVN. Today I believe it is time to move again, and this time to Git. Git is a distributed version control system, which means that checking out an old revision or reading the commit log does not require accessing the sometimes painfully slow servers on the Internet. Each 'clone' of the repository is a fully-functioning repository on its own. This means that developers, even those who do not have commit access, can work on projects at their own pace and submit them with tools such as `git format-patch` and others. Git makes branching easy. It makes maintaining them manageable. As an example, several important fixes were made in 'trunk', which have yet to be backported to 1.12.0. In addition, there are no release engineering branches, which means that each release is simply cut from the next 'trunk' state in line. Even "trivial" fixes could benefit from topic branches, but SVN does not make this easy, convenient, or fun. Using Git branches would help create a more stable codebase by improving release engineering and adopting intermediate "stable" branches that servers can track. A recent autotools bug that wiped server configuration files, for example, could have been prevented if changes on the bleeding edge were evaluated by test servers first. Git is not terribly difficult to use. Right now I access the SVN repository through a local Git clone, but this is inadequate because I cannot publish my topic branches (without considerably difficulty). A migration that preserves tags, branches, and full revision history can be made as fast as the revisions are pulled from SVN. In summary, a few important benefits of using Git: - - Contributors can work on the code easier, with revision control. - - Distributed, so works without (slow) Internet access. - - Encourages branching -> more stable codebase. - - Easy to use and migrate to. - - Full (all revision history) repository size: 21.7 MiB (server), 13.9 MiB (client), 106.1 MiB (maps) However, there are a few immediate problems: Most projects using SVN make extensive use of the revision number identifiers. Crossfire is no different. Git has revision (commit) identifiers, but they are meaningless without the repository, whereas SVN increments the number for each commit. I do not believe this is an issue, because client compatibility is not determined by this specifier, plugin versions are only checked to match, and other uses of the identifier can be removed. Of course, comments, questions, and hate mail are always welcome. Thanks, Kevin Zheng -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTmvjyAAoJEOrPD3bCLhCQsEIH/2CnCPs/FmKlGmgkMw98zo/b vIFMiFiMZsuEteKUajXZb3+OfabyvCTBJZc3nVOlVwxt6xT+9NcspmdPYIofqt2M 24fhSY7LqSF5Odc/afQX6JrA21fgF/ryU6jc1Iri2+13Wk6TDEhQqZ/ASdSmaaZm IXd9iPb8D7EbSmp0pqvAGKriExVZDSIuukXmOQzbjG8mqFgczBnNdxP62bPh2H03 NyMbd+nCFfaaXAca/5wGZgrqmx0OU8DiRx9FTKzwp1/Ku3t09PT9aUbuOY6qUKAU kdOQfdp8naAxCbf38B/9k+IU5lk+JFcbs576X3lreU0xyr1byZyparkfNOLk3XE= =lsHS -----END PGP SIGNATURE----- From bloodyshade at gmail.com Fri Jun 13 08:29:27 2014 From: bloodyshade at gmail.com (Bloody Shade) Date: Fri, 13 Jun 2014 10:29:27 -0300 Subject: [crossfire] Crossfire should use Git In-Reply-To: <539AF8F2.10005@gmail.com> References: <539AF8F2.10005@gmail.com> Message-ID: <539AFCB7.7000806@gmail.com> I'm not sure I can agree with a move to Git, personally. There's plenty of drawbacks that also come with git (not that other version controls don't). I personally use mercurial (hg) for my projects and you can find more info on it and see if you like it at: http://hginit.com/ I found this article with some things I also don't like about git, in case anybody else is wondering (although I'm sure there's more): http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ Then again, I'm not a regular contributor, so feel free to ignore this, but I thought it would be worth throwing my 2 cents. On 6/13/2014 10:13 AM, Kevin Zheng wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > > Crossfire originally lived in the world of CVS, until a handful of brave > knights ventured to move it to SVN. Today I believe it is time to move > again, and this time to Git. > > Git is a distributed version control system, which means that checking > out an old revision or reading the commit log does not require accessing > the sometimes painfully slow servers on the Internet. Each 'clone' of > the repository is a fully-functioning repository on its own. This means > that developers, even those who do not have commit access, can work on > projects at their own pace and submit them with tools such as `git > format-patch` and others. > > Git makes branching easy. It makes maintaining them manageable. As an > example, several important fixes were made in 'trunk', which have yet to > be backported to 1.12.0. In addition, there are no release engineering > branches, which means that each release is simply cut from the next > 'trunk' state in line. Even "trivial" fixes could benefit from topic > branches, but SVN does not make this easy, convenient, or fun. Using Git > branches would help create a more stable codebase by improving release > engineering and adopting intermediate "stable" branches that servers can > track. A recent autotools bug that wiped server configuration files, for > example, could have been prevented if changes on the bleeding edge were > evaluated by test servers first. > > Git is not terribly difficult to use. Right now I access the SVN > repository through a local Git clone, but this is inadequate because I > cannot publish my topic branches (without considerably difficulty). A > migration that preserves tags, branches, and full revision history can > be made as fast as the revisions are pulled from SVN. > > In summary, a few important benefits of using Git: > > - - Contributors can work on the code easier, with revision control. > - - Distributed, so works without (slow) Internet access. > - - Encourages branching -> more stable codebase. > - - Easy to use and migrate to. > - - Full (all revision history) repository size: 21.7 MiB (server), 13.9 > MiB (client), 106.1 MiB (maps) > > However, there are a few immediate problems: > > Most projects using SVN make extensive use of the revision number > identifiers. Crossfire is no different. Git has revision (commit) > identifiers, but they are meaningless without the repository, whereas > SVN increments the number for each commit. I do not believe this is an > issue, because client compatibility is not determined by this > specifier, plugin versions are only checked to match, and other uses > of the identifier can be removed. > > Of course, comments, questions, and hate mail are always welcome. > > Thanks, > Kevin Zheng > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJTmvjyAAoJEOrPD3bCLhCQsEIH/2CnCPs/FmKlGmgkMw98zo/b > vIFMiFiMZsuEteKUajXZb3+OfabyvCTBJZc3nVOlVwxt6xT+9NcspmdPYIofqt2M > 24fhSY7LqSF5Odc/afQX6JrA21fgF/ryU6jc1Iri2+13Wk6TDEhQqZ/ASdSmaaZm > IXd9iPb8D7EbSmp0pqvAGKriExVZDSIuukXmOQzbjG8mqFgczBnNdxP62bPh2H03 > NyMbd+nCFfaaXAca/5wGZgrqmx0OU8DiRx9FTKzwp1/Ku3t09PT9aUbuOY6qUKAU > kdOQfdp8naAxCbf38B/9k+IU5lk+JFcbs576X3lreU0xyr1byZyparkfNOLk3XE= > =lsHS > -----END PGP SIGNATURE----- > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From shjohnson.pi at gmail.com Fri Jun 13 08:52:02 2014 From: shjohnson.pi at gmail.com (Steven Johnson) Date: Fri, 13 Jun 2014 09:52:02 -0400 Subject: [crossfire] Crossfire should use Git In-Reply-To: <539AFCB7.7000806@gmail.com> References: <539AF8F2.10005@gmail.com> <539AFCB7.7000806@gmail.com> Message-ID: I'm not a regular contributor either but I believe mercurial (hg) is the better choice as well. Plus the site Bloody Shade mentioned http://hginit.com/ easily explains the transition from svn to hg. On Jun 13, 2014 9:29 AM, "Bloody Shade" wrote: > I'm not sure I can agree with a move to Git, personally. > > There's plenty of drawbacks that also come with git (not that other > version controls don't). > I personally use mercurial (hg) for my projects and you can find more info > on it and see if you like it at: http://hginit.com/ > > I found this article with some things I also don't like about git, in case > anybody else is wondering (although I'm sure there's more): > http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ > > Then again, I'm not a regular contributor, so feel free to ignore this, > but I thought it would be worth throwing my 2 cents. > > On 6/13/2014 10:13 AM, Kevin Zheng wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi all, >> >> Crossfire originally lived in the world of CVS, until a handful of brave >> knights ventured to move it to SVN. Today I believe it is time to move >> again, and this time to Git. >> >> Git is a distributed version control system, which means that checking >> out an old revision or reading the commit log does not require accessing >> the sometimes painfully slow servers on the Internet. Each 'clone' of >> the repository is a fully-functioning repository on its own. This means >> that developers, even those who do not have commit access, can work on >> projects at their own pace and submit them with tools such as `git >> format-patch` and others. >> >> Git makes branching easy. It makes maintaining them manageable. As an >> example, several important fixes were made in 'trunk', which have yet to >> be backported to 1.12.0. In addition, there are no release engineering >> branches, which means that each release is simply cut from the next >> 'trunk' state in line. Even "trivial" fixes could benefit from topic >> branches, but SVN does not make this easy, convenient, or fun. Using Git >> branches would help create a more stable codebase by improving release >> engineering and adopting intermediate "stable" branches that servers can >> track. A recent autotools bug that wiped server configuration files, for >> example, could have been prevented if changes on the bleeding edge were >> evaluated by test servers first. >> >> Git is not terribly difficult to use. Right now I access the SVN >> repository through a local Git clone, but this is inadequate because I >> cannot publish my topic branches (without considerably difficulty). A >> migration that preserves tags, branches, and full revision history can >> be made as fast as the revisions are pulled from SVN. >> >> In summary, a few important benefits of using Git: >> >> - - Contributors can work on the code easier, with revision control. >> - - Distributed, so works without (slow) Internet access. >> - - Encourages branching -> more stable codebase. >> - - Easy to use and migrate to. >> - - Full (all revision history) repository size: 21.7 MiB (server), 13.9 >> MiB (client), 106.1 MiB (maps) >> >> However, there are a few immediate problems: >> >> Most projects using SVN make extensive use of the revision number >> identifiers. Crossfire is no different. Git has revision (commit) >> identifiers, but they are meaningless without the repository, whereas >> SVN increments the number for each commit. I do not believe this is an >> issue, because client compatibility is not determined by this >> specifier, plugin versions are only checked to match, and other uses >> of the identifier can be removed. >> >> Of course, comments, questions, and hate mail are always welcome. >> >> Thanks, >> Kevin Zheng >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2 >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQEcBAEBAgAGBQJTmvjyAAoJEOrPD3bCLhCQsEIH/2CnCPs/FmKlGmgkMw98zo/b >> vIFMiFiMZsuEteKUajXZb3+OfabyvCTBJZc3nVOlVwxt6xT+9NcspmdPYIofqt2M >> 24fhSY7LqSF5Odc/afQX6JrA21fgF/ryU6jc1Iri2+13Wk6TDEhQqZ/ASdSmaaZm >> IXd9iPb8D7EbSmp0pqvAGKriExVZDSIuukXmOQzbjG8mqFgczBnNdxP62bPh2H03 >> NyMbd+nCFfaaXAca/5wGZgrqmx0OU8DiRx9FTKzwp1/Ku3t09PT9aUbuOY6qUKAU >> kdOQfdp8naAxCbf38B/9k+IU5lk+JFcbs576X3lreU0xyr1byZyparkfNOLk3XE= >> =lsHS >> -----END PGP SIGNATURE----- >> _______________________________________________ >> crossfire mailing list >> crossfire at metalforge.org >> http://mailman.metalforge.org/mailman/listinfo/crossfire >> >> > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leaf at real-time.com Fri Jun 13 18:03:56 2014 From: leaf at real-time.com (Rick Tanner) Date: Fri, 13 Jun 2014 18:03:56 -0500 Subject: [crossfire] Crossfire should use Git In-Reply-To: <539AF8F2.10005@gmail.com> References: <539AF8F2.10005@gmail.com> Message-ID: <539B835C.2070102@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My questions on going with a distributed revision control has to do with how does all these changes in a branch make it back to the main code base? This is not a question in regards to command syntax and code merging practices. It's more on a administrative or QA level. Perhaps I'm asking "who" brings in all the changes from the branches to the main code base? Thank you, Rick Tanner -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iD8DBQFTm4NQhHyvgBp+vH4RAvepAKCmTqzcsL28o6Q96Xm2CbxgNr1/QQCfUzY1 BjzHRN1yAdfmRHPBkU7OtmU= =KBE3 -----END PGP SIGNATURE----- From kbulgrien at att.net Fri Jun 13 18:11:11 2014 From: kbulgrien at att.net (Kevin R. Bulgrien) Date: Fri, 13 Jun 2014 18:11:11 -0500 Subject: [crossfire] Crossfire should use Git In-Reply-To: References: <539AF8F2.10005@gmail.com> <539AFCB7.7000806@gmail.com> Message-ID: <20140613181111.2aace744@matrix.kbulgrien.att.net> On Fri, 13 Jun 2014 09:52:02 -0400 Steven Johnson wrote: > I'm not a regular contributor either but I believe mercurial (hg) is > the better choice as well. Plus the site Bloody Shade mentioned > http://hginit.com/ easily explains the transition from svn to hg. > On Jun 13, 2014 9:29 AM, "Bloody Shade" wrote: > > > I'm not sure I can agree with a move to Git, personally. I am not a fan of git. I had a co-worker that used it and expressed pros of a distributed VCS. I agreed in principle with various ideas. At one point, I decided to try git out for maintaining a web site that was deployed on multiple servers (test/production). I stuck with it for two weeks. It was a horrible two weeks during which I wasted much time dredging through horrible documentation to figure out how to do seemingly basic things. The sheer number of commands was a huge put-off. I destroyed my repository multiple times while learning. At one point, I wanted to do something that was easy peasy in CVS and SVN, but it was a brick wall in git. I researched for hours, and ultimately learned git will not do it. Though I could have obliged git's (IMO) retarded limitation quite easily, my experience was so hard already, that I decided then and there to try either bazaar or mercurial instead. I learned that mercurial (at that point) had the same issue as git with respect to the particular operation I wanted to do (add an empty directory). I don't know that this is presently an issue with mercurial, but it tipped the balance for me. I tried bazaar. In less than an hour, I converted my git repo to a bazaar repo and was using bazaar painlessly ... it worked just like I felt it should based on my years of experience with CVS and SVN. After two weeks of using git this never happened. If crossfire wants casual users to be able to use the VCS, then I cannot recommend git. If crossfire wants to limit VCS use to git-heads, then go ahead. A CVS/SVN/BZR user can pretty comfortably go from one VCS to another. I'd guess the same is true of Hg. It is clear to me that git is a horse of a different color. It solves a particular problem that does not fit most software project needs at the expense of being an easy to use tool. I am sure that one day it is almost inevitable that I will have to use it and be comfortable using it, but I will put off that day as long as I can. > > There's plenty of drawbacks that also come with git (not that other > > version controls don't). > > I personally use mercurial (hg) for my projects and you can find > > more info on it and see if you like it at: http://hginit.com/ > > > > I found this article with some things I also don't like about git, > > in case anybody else is wondering (although I'm sure there's more): > > http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ Right on. Excellent article. > > Then again, I'm not a regular contributor, so feel free to ignore > > this, but I thought it would be worth throwing my 2 cents. > > > > On 6/13/2014 10:13 AM, Kevin Zheng wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Hi all, > >> > >> Crossfire originally lived in the world of CVS, until a handful of > >> brave knights ventured to move it to SVN. Today I believe it is > >> time to move again, and this time to Git. I actually asked to get access to crossfire VCS at this time. I did not know SVN. The transition from CVS to SVN was easy. I did learn, however that I choose not to use SVN when possible, but whatever I dislike about SVN is small compared to what git brings to the table. > >> Git is a distributed version control system, which means that > >> checking out an old revision or reading the commit log does not > >> require accessing the sometimes painfully slow servers on the > >> Internet. Each 'clone' of the repository is a fully-functioning > >> repository on its own. This means that developers, even those who > >> do not have commit access, can work on projects at their own pace > >> and submit them with tools such as `git format-patch` and others. > >> > >> Git makes branching easy. It makes maintaining them manageable. As > >> an example, several important fixes were made in 'trunk', which > >> have yet to be backported to 1.12.0. In addition, there are no > >> release engineering branches, which means that each release is > >> simply cut from the next 'trunk' state in line. Even "trivial" > >> fixes could benefit from topic branches, but SVN does not make > >> this easy, convenient, or fun. Using Git branches would help > >> create a more stable codebase by improving release engineering and > >> adopting intermediate "stable" branches that servers can track. A > >> recent autotools bug that wiped server configuration files, for > >> example, could have been prevented if changes on the bleeding edge > >> were evaluated by test servers first. > >> > >> Git is not terribly difficult to use. Right now I access the SVN > >> repository through a local Git clone, but this is inadequate > >> because I cannot publish my topic branches (without considerably > >> difficulty). A migration that preserves tags, branches, and full > >> revision history can be made as fast as the revisions are pulled > >> from SVN. > >> > >> In summary, a few important benefits of using Git: > >> > >> - - Contributors can work on the code easier, with revision > >> control. > >> - - Distributed, so works without (slow) Internet access. > >> - - Encourages branching -> more stable codebase. > >> - - Easy to use and migrate to. > >> - - Full (all revision history) repository size: 21.7 MiB > >> (server), 13.9 MiB (client), 106.1 MiB (maps) I disagree with the assertion that git is easy. Sure, it's easy to checkout someone's project to compile. After that its not easy. Just because someone that uses it a lot is comfortable with it does not make something easy. Things are easy because they follow well thought out patterns that are echoed in other similar softwares or products. git breaks the mold. It is a beast unto itself. All these "git pros" are not git-specific. They are distributed VCS pros. I dare say that bazaar and mercurial bring the same pros to the table with much fewer cons. I know that bazaar sadly seems largely dead. I feel it is the best dvcs that does not force a user to work a certain way. It has some pain points, but I choose it still. I not tried Hg because I haven't a need. I'd try it in a heartbeat if an interesting project used it. I have no interest in git. I've had enough pain in two weeks. To be fair, I have had a bit of pain with bazaar, but nothing like with git. Distributed VCS brings a lot of complexity to VCS that doesn't exist for CVS and SVN. > >> However, there are a few immediate problems: > >> > >> Most projects using SVN make extensive use of the revision number > >> identifiers. Crossfire is no different. Git has revision (commit) > >> identifiers, but they are meaningless without the repository, > >> whereas SVN increments the number for each commit. I do not > >> believe this is an issue, because client compatibility is not > >> determined by this specifier, plugin versions are only checked to > >> match, and other uses of the identifier can be removed. > >> > >> Of course, comments, questions, and hate mail are always welcome. > >> > >> Thanks, > >> Kevin Zheng 2 cents also, from a formerly active contributor. Use of git will discourage a change from "formerly" to "once again". Just saying. And yes, I do version control heavily at work. I go out of my way to use a VCS for server configuration management, etc. The dislike is not for lack of experience, but rather because of a lack of inexperience with other VCS. Kevin From kevinz5000 at gmail.com Fri Jun 13 18:32:12 2014 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Fri, 13 Jun 2014 18:32:12 -0500 Subject: [crossfire] Crossfire should use Git In-Reply-To: <539B835C.2070102@real-time.com> References: <539AF8F2.10005@gmail.com> <539B835C.2070102@real-time.com> Message-ID: <539B89FC.8040604@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/13/2014 18:03, Rick Tanner wrote: > My questions on going with a distributed revision control has to > do with how does all these changes in a branch make it back to the > main code base? > > Perhaps I'm asking "who" brings in all the changes from the > branches to the main code base? I expect that branch maintenance and integration will remain pretty much the same. Developers who choose to publish topic branches should ultimately merge in changes when the code is ready. Contributors who wish to make changes should make local commits and generate patch sets. Contributors wishing to make extensive changes can seek the help of a developer with commit access. Keep in mind that it is not necessary to work in topic branches; the current workflow can stay the same. I expect that more people will use and publish branches, though. Thanks, Kevin Zheng -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTm4n8AAoJEOrPD3bCLhCQB9YIAL740CWrMriZ2Vi3JokSESxa CG7qAecR2ELrD61FpDiLY04g2fAZdAMDoxPzeRX4i3mY+uwaWrzdie74/J8ufqB5 6aFyB0YEXHXr07CFFyRJWa09FXuPXgVZxzYU4vFLCkUspBujVdGmUbrsZdLHFxvR qAxGSNhFVQyKUQvfJBrbu+mitJK2x2b15sigZOticKHfnkEQNCE3UKjBFM314QgQ ps++0nusn1nQX9MrP5tl/gJV3ScfRZW81Eh6GkAcZPANlsajK4Hlrw88S3t/6l24 Q5oDEJE19XdrCkzwNLPpQhlQ9lvfTi/0/xGB9+jmWAZ9K3kx0UIcxZu3guAPT1A= =6Axm -----END PGP SIGNATURE----- From leaf at real-time.com Fri Jun 13 18:35:54 2014 From: leaf at real-time.com (Rick Tanner) Date: Fri, 13 Jun 2014 18:35:54 -0500 Subject: [crossfire] Development dialogue Message-ID: <539B8ADA.4080006@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It has been quite some time since Crossfire has seen so many code tweaks and changes like we have seen the past couple of months. Thank you to everyone who is and has been contributing to this. Some recent discussion on IRC brought up some concerns with recent SVN commits and their impact on existing code, server setup practices, and performance gains or efficiency of such code changes. I'm making this post to open dialogue on these concerns so they get addressed, worked on, updated, etc. If a code rewrite is necessary, or a revert or something else - it should be made with some sort of agreement. I ask that we keep the discussion positive and productive. If you have an axe to grind, this is not the forum for that. ;-) Thank you, Rick Tanner -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iD8DBQFTm4rLhHyvgBp+vH4RAtOmAJ9Hd8G7knqQ+L8PhDmzEp3qMSGUqACgvLBB SYrqMk9wp1jY9cYX1hnCsPo= =YSMv -----END PGP SIGNATURE----- From mwedel at sonic.net Sat Jun 14 01:02:28 2014 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 13 Jun 2014 23:02:28 -0700 Subject: [crossfire] Crossfire should use Git In-Reply-To: <20140613181111.2aace744@matrix.kbulgrien.att.net> References: <539AF8F2.10005@gmail.com> <539AFCB7.7000806@gmail.com> <20140613181111.2aace744@matrix.kbulgrien.att.net> Message-ID: <539BE574.6000800@sonic.net> Whenever these discussions come up (this is probably the 3rd or 4th iteration), the general response is 'we should use the VCS that I'm most familiar with' So on that basis, I'd vote for mercurial (use it at work) or SVN (crossfire already uses it) All that being said, for the amount of commits crossfire gets, I'm really not convinced a distributed VCS is worth the effort. It is certainly useful for really big projects, or if making lots of changes such that you want to be able to do intermediate commits. To me, the only really compelling reason for a DVCS is that all the data is local, so you can do things like diff, history, etc, and still get data even if the master gate is down. I don't think it will make much difference in terms of maintaining branches - all systems I've seen have problems once branches drift apart - at some level, manual merging is possible. Its been a while, but I seem to remember that even for SVN, there was a pretty simple way to do that. The main problem (in general) with branches is people just generally don't want to do the extra steps to backport, even if the steps were pretty trivial. I'm really not convinced that a bunch of branches are desirable thing - whenever extra branches have shown up in SVN, they basically just languished, and I don't think it was because of the VCS, but rather there are not so many developers that your going to have 10 people working on the trunk and 8 playing on a branch - rather, everyone just works on trunk. Conceivably, this can be useful if working on a private branch, but a DVCS really doesn't help prevent merge hell if the branches drift too far apart (conflicts still need to be resolved by hand), though I suppose with a DVCS, they would need to be resolved less often vs trying to use SVN. mercurial at least can pull from a SVN repo, as it sounds like GIT can, but the issue is the push. I have no idea if git and mercurial can play well together (if the repo was mercurial, can git do most things it needs to do or vice versa). From kevinz5000 at gmail.com Sat Jun 14 13:30:13 2014 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Sat, 14 Jun 2014 13:30:13 -0500 Subject: [crossfire] Crossfire should use Git In-Reply-To: <539BE574.6000800@sonic.net> References: <539AF8F2.10005@gmail.com> <539AFCB7.7000806@gmail.com> <20140613181111.2aace744@matrix.kbulgrien.att.net> <539BE574.6000800@sonic.net> Message-ID: <539C94B5.9020606@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi again, First, a few responses: Many of the reasons I mentioned do extend to most DVCSs, and this is the fault of my own (thinking that Git == DVCS). I'll concede that Git has a fairly steep learning curve, although I'll assert that it is harder to use a pneumatic drill than a hammer. I learned Git after SVN and it was not a big problem for me. I believe the most compelling reason to use a DVCS is that it makes contributions easier. About a year ago a common complaint about my patches were that too many changes were lumped together in one patch, making it hard to review. While I could have used Git or Hg to make a local repository, I did not think that was worth the trouble. Next, an adventure: I've taken the liberty to install and attempt to learn Mercurial. Since I am brainwashed by the Git world, please correct me if I'm wrong. My current workflow involves putting all non-trivial or multi-commit projects in a separate branch. Then I "dangerously" reorder, squash, and otherwise mutilate my local branch until it can be laid on top of the SVN trunk, where I dump back the linear history. If I used Hg, this would likely involve making many copies of the repository (since each branch is an entire checkout) for minor changes. Since I make extensive use of the Git staging area, I would wind up using `hg record` (an extension) very often. I would also end up maintaining patch sets using message queues (another extension), in order to clean up my changes before committing. In addition, it would be impossible for me to rebase my commits, which means that every branch would require its own merge. If you take a look at my commits, most have been squashed versions of local branch work. I advocated Git because "we should use the VCS that I'm most familiar with." It works with the workflow that I'm most comfortable with. I welcome anyone familiar with Hg to reeducate my current workflow. If I am the only developer that makes use of such a workflow, then I apologize for being selfish and greedy. Git has a good SVN bridge. Hg has a good Git bridge. Git does NOT have a good Hg bridge (Git's fault). If I keep my current workflow, then I'd much rather stick with SVN and play with local Git branches. Thanks, Kevin Zheng -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTnJS1AAoJEOrPD3bCLhCQvq8H/RvwMBwd3N1F13IXM6URjAiE TVMQ/eFf3XjKq9048NOd64YTCsCRyBKZt7PUOVlaUnaIRAcblwMyGLWuvwIlQOwZ CImrQi+66YkeKoFB5GEH9bCLDhHzDNQu2GsZVNTnTF/AUeYpJdiwiOlaJMqpVKyh lhdzCNJNR2GAe/aT7HdDnlq/Z/CIvngpWQqc++WaLQLmoYvw0gqWWM5yGxiAzo+l +vR24q0LxSTvtAc1E8mLX15eQx3Z+8Q0/Dbdd0TT78AX1DDMH2teAkumWcuRGDot IMM6c9DofKvEL2B0I2Y15tH6RFYhzpcexKssP8h5zFAuFMBMbcY2QszvHy63jbY= =rfsf -----END PGP SIGNATURE----- From nicolas.weeger at laposte.net Sat Jun 14 16:08:26 2014 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 14 Jun 2014 23:08:26 +0200 Subject: [crossfire] Crossfire should use Git In-Reply-To: <539AF8F2.10005@gmail.com> References: <539AF8F2.10005@gmail.com> Message-ID: <201406142308.34359.nicolas.weeger@laposte.net> /me throws some plain non blessed water to squash the religious war Nicolas Le vendredi 13 juin 2014 15:13:22, Kevin Zheng a ?crit : > Hi all, > > Crossfire originally lived in the world of CVS, until a handful of brave > knights ventured to move it to SVN. Today I believe it is time to move > again, and this time to Git. > > Git is a distributed version control system, which means that checking > out an old revision or reading the commit log does not require accessing > the sometimes painfully slow servers on the Internet. Each 'clone' of > the repository is a fully-functioning repository on its own. This means > that developers, even those who do not have commit access, can work on > projects at their own pace and submit them with tools such as `git > format-patch` and others. > > Git makes branching easy. It makes maintaining them manageable. As an > example, several important fixes were made in 'trunk', which have yet to > be backported to 1.12.0. In addition, there are no release engineering > branches, which means that each release is simply cut from the next > 'trunk' state in line. Even "trivial" fixes could benefit from topic > branches, but SVN does not make this easy, convenient, or fun. Using Git > branches would help create a more stable codebase by improving release > engineering and adopting intermediate "stable" branches that servers can > track. A recent autotools bug that wiped server configuration files, for > example, could have been prevented if changes on the bleeding edge were > evaluated by test servers first. > > Git is not terribly difficult to use. Right now I access the SVN > repository through a local Git clone, but this is inadequate because I > cannot publish my topic branches (without considerably difficulty). A > migration that preserves tags, branches, and full revision history can > be made as fast as the revisions are pulled from SVN. > > In summary, a few important benefits of using Git: > > - Contributors can work on the code easier, with revision control. > - Distributed, so works without (slow) Internet access. > - Encourages branching -> more stable codebase. > - Easy to use and migrate to. > - Full (all revision history) repository size: 21.7 MiB (server), 13.9 > MiB (client), 106.1 MiB (maps) > > However, there are a few immediate problems: > > Most projects using SVN make extensive use of the revision number > identifiers. Crossfire is no different. Git has revision (commit) > identifiers, but they are meaningless without the repository, whereas > SVN increments the number for each commit. I do not believe this is an > issue, because client compatibility is not determined by this > specifier, plugin versions are only checked to match, and other uses > of the identifier can be removed. > > Of course, comments, questions, and hate mail are always welcome. > > Thanks, > Kevin Zheng > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Sat Jun 14 16:17:03 2014 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 14 Jun 2014 23:17:03 +0200 Subject: [crossfire] Game change proposals In-Reply-To: <539A9565.4000902@sonic.net> References: <201406122036.00186.nicolas.weeger@laposte.net> <539A9565.4000902@sonic.net> Message-ID: <201406142317.03298.nicolas.weeger@laposte.net> Hello. > I'm not familiar to the original game, but I'd be careful with anything > that is too time sensitive. I'd also like a better idea of what you > envision. Is it something like there are 10 (or 20) different lockpicks > in the game, and the character has to use them in the right order? > Presumably, the lockpick skill should still come in to play in some way > for this also (amount of time to pick the lock, or perhaps some amount of > not needing the precise lockpicks or something) Something like that, yes - you need to use the correct lockpicks in the correct order. So you could have special doors requiring a special lockpick found in a special place. > Another easy thing would be to have most chests locked - the player could > bash them open, but might destroy the items inside. Yes, could be done too :) > That is a big change, and probably fairly simple to do - most other games > do this (those creatures may be attacking you with axes, but you don't get > all those weapons when you kill them). Likewise, even of the items that > are out there, one could reasonably ask do we really need the number of > different swords out there that vary by a minor detail. I know some games > do this, but that is more related to skins (this sword looks cool) - with > the way crossfire is, that really isn't the case. I was thinking of adding a second treasure list to monsters, which contains items to drop at death. Would need to figure how to make steal work, though. > That would be good, but is also a major change - the vast majority of > maps would need to be refactored (maps with gobs of monsters would just be > unplayable). Yes. On the other hand, it'd make for a nice map review :) > Seems reasonable, though than in itself creates yet different issues (if > a player can use a weapon effectively enough to constantly keep a monster > stunned, probably makes for an easy combat) Then the monster isn't that high level, is it? Or make it so the time the player needs to launch the stun attack is longer that the actual stun. > Agree - most of those are side effects. The trickier part on some of > those is whether resistances should exist and how to then factor them in - > the number of attacks and number of resistances sort of go hand in hand. > While one could certainly come up with different logic to handle those, > that solution may just be more complicated. > > Note that if you did all the above changes, that is some fairly radical > changes to the game (attack rate and item drop). Though perhaps the second > comes from the first - if combat is a lot slower, that would then suggest > there are a lot fewer monsters, which should then mean a lot lower item > drop. Yes, radical changes is what I'm thinking of. There are a zillion hack-and-slash games. So maybe we should try something different? Regards Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mwedel at sonic.net Mon Jun 16 01:13:25 2014 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 15 Jun 2014 23:13:25 -0700 Subject: [crossfire] Game change proposals In-Reply-To: <201406142317.03298.nicolas.weeger@laposte.net> References: <201406122036.00186.nicolas.weeger@laposte.net> <539A9565.4000902@sonic.net> <201406142317.03298.nicolas.weeger@laposte.net> Message-ID: <539E8B05.1040704@sonic.net> On 06/14/14 02:17 PM, Nicolas Weeger wrote: > Hello. > > >> I'm not familiar to the original game, but I'd be careful with anything >> that is too time sensitive. I'd also like a better idea of what you >> envision. Is it something like there are 10 (or 20) different lockpicks >> in the game, and the character has to use them in the right order? >> Presumably, the lockpick skill should still come in to play in some way >> for this also (amount of time to pick the lock, or perhaps some amount of >> not needing the precise lockpicks or something) > > Something like that, yes - you need to use the correct lockpicks in the > correct order. > > So you could have special doors requiring a special lockpick found in a > special place. Makes sense - would the lockpicks be consumed (or perhaps break) on failed attempts? That might be another way to limit special door access - yes, you can pick it, but the lockpicks themselves are rare and/or expensive, so may not be worth it just for the sake of doing it. >> That is a big change, and probably fairly simple to do - most other games >> do this (those creatures may be attacking you with axes, but you don't get >> all those weapons when you kill them). Likewise, even of the items that >> are out there, one could reasonably ask do we really need the number of >> different swords out there that vary by a minor detail. I know some games >> do this, but that is more related to skins (this sword looks cool) - with >> the way crossfire is, that really isn't the case. > > I was thinking of adding a second treasure list to monsters, which contains > items to drop at death. > > Would need to figure how to make steal work, though. I had thought of the second treasure list - the problem, is you could get a case where the creature is firing arrows at you, but drops something completely unrelated. Other games do that (often getting items completely unrelated to what the creature is using), but IMO, it is nicer if what is dropped matches what the creature had. I know sometimes in crossfire you are fighting something and getting hit by some wand attack, and I think 'I want to kill that creature to get that wand'. With the proposed system, that might not happen, but would be nice to have a chance. So perhaps what could be done is the existing treasurelists modified with something like a 'drop_chance' value - if the item is generated, that represents that chance that the item actually drops. At treasure creation time, the item could get marked with a flag based on that (I think FLAG_NO_DROP might already exist) That chance may be low, but at least you have a chance of getting what the creature is using. For stealing, I think only allow items that will drop when the creature is killed to be stolen works, so that also fixes that problem. > > > >> That would be good, but is also a major change - the vast majority of >> maps would need to be refactored (maps with gobs of monsters would just be >> unplayable). > > Yes. On the other hand, it'd make for a nice map review :) Right - in some ways, it makes sense to do a bunch of big changes at one time for that reason - while reviewing maps for monster density, can also review them for doors, etc. > > > >> Seems reasonable, though than in itself creates yet different issues (if >> a player can use a weapon effectively enough to constantly keep a monster >> stunned, probably makes for an easy combat) > > Then the monster isn't that high level, is it? I guess it depends exactly how those chances work. Is it a level comparison + random factor? or you do the attack and it happens? > > Or make it so the time the player needs to launch the stun attack is longer > that the actual stun. Yep - some games also have other melee related stats (fatigue, adrenaline, etc), and one could imagine that the special attacks cost more fatigue, and fatigue only really recovers out of combat - so you could enter combat, do a flurry of special attacks, but after that, are basically just left doing normal attacks or something. >> Agree - most of those are side effects. The trickier part on some of >> those is whether resistances should exist and how to then factor them in - >> the number of attacks and number of resistances sort of go hand in hand. >> While one could certainly come up with different logic to handle those, >> that solution may just be more complicated. >> >> Note that if you did all the above changes, that is some fairly radical >> changes to the game (attack rate and item drop). Though perhaps the second >> comes from the first - if combat is a lot slower, that would then suggest >> there are a lot fewer monsters, which should then mean a lot lower item >> drop. > > Yes, radical changes is what I'm thinking of. > > There are a zillion hack-and-slash games. So maybe we should try something > different? Maybe - that has always been a bit of challenge - trying to figure out exactly what crossfire is or should be. From om at iki.fi Mon Jun 16 01:15:41 2014 From: om at iki.fi (Otto J. Makela) Date: Mon, 16 Jun 2014 09:15:41 +0300 Subject: [crossfire] Crossfire should use Git In-Reply-To: <20140613181111.2aace744@matrix.kbulgrien.att.net> References: <539AF8F2.10005@gmail.com> <539AFCB7.7000806@gmail.com> <20140613181111.2aace744@matrix.kbulgrien.att.net> Message-ID: <539E8B8D.9080005@iki.fi> On 2014-06-14 02:11, Kevin R. Bulgrien wrote: > I am not a fan of git. Not all of these are exactly correct, but I think you get the gist: http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ Then compare with this "git is great" article: http://merrigrove.blogspot.fi/2014/02/why-heck-is-git-so-hard-places-model-ok.html I have been using Git since about 2007 (6 years now). I am not great at it, mainly because I have not used it constantly. I often go months without programming or am forced to use a client?s source control system. Ie. unless you constantly use git, you WILL suck at it even after years. -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 01001111 01001011 * * * * * * */ From mwedel at sonic.net Mon Jun 16 01:43:17 2014 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 15 Jun 2014 23:43:17 -0700 Subject: [crossfire] Crossfire should use Git In-Reply-To: <539C94B5.9020606@gmail.com> References: <539AF8F2.10005@gmail.com> <539AFCB7.7000806@gmail.com> <20140613181111.2aace744@matrix.kbulgrien.att.net> <539BE574.6000800@sonic.net> <539C94B5.9020606@gmail.com> Message-ID: <539E9205.50205@sonic.net> On 06/14/14 11:30 AM, Kevin Zheng wrote: > I believe the most compelling reason to use a DVCS is that it makes > contributions easier. About a year ago a common complaint about my > patches were that too many changes were lumped together in one patch, > making it hard to review. While I could have used Git or Hg to make a > local repository, I did not think that was worth the trouble. True - a DVCS certainly makes it easier to have/make multiple unrelated changes and make them available as individual patches (presuming good practices were followed and the developer remembers to check them in their local repo separately). I also think DVCS is also better if one is making really big changes that will take a while to do, because of the better branching, local commits, and merging - for something like SVN, you would pretty much need to make your own branch, which then also shows up in the main repo. > > Next, an adventure: > > I've taken the liberty to install and attempt to learn Mercurial. > Since I am brainwashed by the Git world, please correct me if I'm wrong. > > My current workflow involves putting all non-trivial or multi-commit > projects in a separate branch. Then I "dangerously" reorder, squash, > and otherwise mutilate my local branch until it can be laid on top of > the SVN trunk, where I dump back the linear history. > > If I used Hg, this would likely involve making many copies of the > repository (since each branch is an entire checkout) for minor > changes. Since I make extensive use of the Git staging area, I would > wind up using `hg record` (an extension) very often. I would also end > up maintaining patch sets using message queues (another extension), in > order to clean up my changes before committing. In addition, it would > be impossible for me to rebase my commits, which means that every > branch would require its own merge. If you take a look at my commits, > most have been squashed versions of local branch work. I'm not at all familiar with git, so I'm 100% how to compare the 2. I'm not 1005 sure why you would need many copies of the repository - there is nothing that prevents making a clone, making one set of changes, doing a local commit, making another set of changes, doing a local commit, and repeat as necessary. The only reason you would need many copies of the repository is if you were making different changes to each one - you could still do that with hg, but that seems like a somewhat odd way to develop code. Note you can reparent with mercurial quite easily - presuming there is a common parent, it is just a matter of doing 'hg pull '. You can likewise do the same with the push, but you need to be up to date relative to the parent (mercurial will make sure this is the case). All that said, at work, we use the cadmium extensions which provide some nice features like 'recommit', which collapses all the commits in the branch into a single delta which can be pushed later. I'm not sure how available the cadmium tools are. But whether people use extensions or not for mercurial doesn't matter much - those extensions are local to them, and the main repo doesn't really care. So people can use whatever extensions work best for them. > > I advocated Git because "we should use the VCS that I'm most familiar > with." It works with the workflow that I'm most comfortable with. I > welcome anyone familiar with Hg to reeducate my current workflow. If I > am the only developer that makes use of such a workflow, then I > apologize for being selfish and greedy. The problem is that if I took that attitude several years ago, we probably we be on mercurial. Crossfire is a community project, so has to meet the needs of many developers. While SVN is pretty limiting, one thing it has going for it is that it is quite simple to use - non hardcore developers can understand and use git without much problem - from many of the other posts I've seen, that is not true with git (and mercurial for that matter). So having something simple and easy to use has lots of advantages, with limited disadvantages (main one being that SVN is not a DVCS) > > Git has a good SVN bridge. Hg has a good Git bridge. Git does NOT have > a good Hg bridge (Git's fault). If I keep my current workflow, then > I'd much rather stick with SVN and play with local Git branches. IMO, that may just be the simplest way to go - I understand it is more pain for you, but there is a fair amount of pain to switch what VCS crossfire uses (I did this one before) - aside from the different commands people need to know, everyone also has to point to the new repo, you have to make sure there are not any outstanding commits, etc. Plus, from the other people that replied, there clearly was not an unanimous chorus of everyone agreeing to a move to git - granted the number of replies was limited, but if anything, seemed to be more opposition to it than those in favor. From nicolas.weeger at laposte.net Tue Jun 17 15:33:56 2014 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 17 Jun 2014 22:33:56 +0200 Subject: [crossfire] Game change proposals In-Reply-To: <539E8B05.1040704@sonic.net> References: <201406122036.00186.nicolas.weeger@laposte.net> <201406142317.03298.nicolas.weeger@laposte.net> <539E8B05.1040704@sonic.net> Message-ID: <201406172234.02368.nicolas.weeger@laposte.net> Hello. > Makes sense - would the lockpicks be consumed (or perhaps break) on > failed attempts? That might be another way to limit special door access - > yes, you can pick it, but the lockpicks themselves are rare and/or > expensive, so may not be worth it just for the sake of doing it. Yup, breaking chance, especially if you use the wrong one :) > I had thought of the second treasure list - the problem, is you could get > a case where the creature is firing arrows at you, but drops something > completely unrelated. Other games do that (often getting items completely > unrelated to what the creature is using), but IMO, it is nicer if what is > dropped matches what the creature had. (snipped) Yes, that's indeed an issue... Though maybe we could make probabilities based on the item. If it's a "standard" item, low drop probability (so you don't get too much junk), but it's an artefact, or a special item, then 100% probability, or a much higher one. > I guess it depends exactly how those chances work. Is it a level > comparison + random factor? or you do the attack and it happens? Implementation details :) It really depends, not sure. Probably a random factor, maybe adjusted on level. > Maybe - that has always been a bit of challenge - trying to figure out > exactly what crossfire is or should be. Yes :) Which is why I'm thinking of doing something different ;) Regards Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: