Re: [crossfire] 2.0 release, was Re: Code restructuring
Alex Schultz wrote: But that can then lead to rapid turnover of major releases. Eg, I do major code restructure, make 3.0.0 release. Then some other change is made (maybe compatibility breakage, maybe some other code restructure) - do you make a 4.0.0 release 3 months later then? I think there needs to be some minimum/maximum gap between major releases. This is true, however I can't see major code restructures working well as part of a minor release. What I see as ideal though, is if the trunk gets a few major features almost worthy of a major release, then a code restructure happens, and a release happens afterwards. Of course, timing may not work out so ideally, but perhaps it might be good for people to try to time their major code restructures to finish about just before when a major release is anticipated. Well, a major code restructure can't go into a minor release. Under the proposed model, the only thing that comes from the main branch is major releases - when a major release is done, then a new stable branch is set up where the minor releases come from. Going back to the original issue is code drifting apart - if a major restructure is done in the main branch, it makes fixing any bugs in both the main and stable branch more difficult. It could just be we live with that difficulty. Or if a major restructure is done shortly after a major release, still have to wait for the 6 months or whatever. I don't really want to try to say 'major code restructures happen near the end of the cycle' - I think if someone has the code ready and it is on the list of things to do, it should be committed. Yes, this is true, however despite that, not all major releases need break things, and no sense breaking things unless there is a logical reason to. (random thought about old clients: There are a good number of people who still use the plain X client, the gnome client though, I don't think is in usage though I may be mistaken) However, as per gros's comment, there needs to be sufficient changes between the releases to warrant a major release. We probably don't want to do a new major release if there are not any signficant changes - I suppose this may be a matter of opinion, but if we go in this model, I think that sort of needs to be the case, as otherwise we get into confusion at what each branch/release means. There can still certainly be major releases which don't break compatiblity in any way but still hold other significant changes (new features, or changing of existing features/expanding them). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 release, was Re: Code restructuring
Le vendredi 21 juillet 2006 07:37, Mark Wedel a écrit : Yann Chachkoff wrote: The biggest danger is that given there are only a handful of servers, if the first release of 2.0 (or whatever major version) has serious problems, it might be hard convincing people to try 2.1, etc Well, at least for the code side of things, it seems to me that a software that shows serious problems should not get released. Now, you could say that there is no way to be sure that the server works before trying it; I'd answer to this that (1) we developers are supposed to do at least some rough beta testing and (2) nothing prevents us to set a single beta-testing server clearly flagged as such to get player's feedback and spot what could have been missed during development. I'd also like to underline that other games suffered serious problems at times, but it wasn't hard to convince people to try the next step, provided that they initially found the game promising/fun/interesting enough. If we are not sure of this, then we may have a content problem that needs to be put on the table. And if the changes break compatibility, that makes it even less likely for servers to switch over. As long as an old version will only get bugfixes, servers will switch over anyway, to have access to the new cool and shiny features. But again, the interest of the new stuff should be strong enough and, if we believe it may not, then we have a problem regarding the content of the game and our relationship towards the player side of the community: it would basically mean that we work without understanding what players need/want/await for. I suppose it depends on how often we plan to do major releases. If only every couple years, this can lead to other problems: 1) To players/users, the project may appear dead (nothing new in the past 12 months) Sorry if I sound rude by saying this, but that's ridiculous. Since when a project that mostly releases revisions of a given version is considered 'dead' ? To take a simple example, PHP 4.0 was released in 2000, and PHP 5.0 'only' in 2004 - did people consider it a 'dead project' in the meantime ? Again, I am not saying we should provide nothing new - but simply not include major changes. And I think there are plenty of smaller-scale stuff to keep us busy to provide minor releases anyway. 2) To developers, less satisfaction making changes if no one (outside perhaps a very limited set of developers) will see it for 12 months First, there are changes that can be introduced by each minor release. Second, major changes worth an upgrade of the major version number are likely to take a long time to complete, maybe months, so the waiting time is unlikely to be a problem - you cannot be upset that your code isn't used if you haven't even got enough time to finish it. This can be solved by doing major releases every 6 months (or a year at max) - but that then limits number of changes that can be done in each for each major release. Which may not be a bad thing, but just a note. Why would we ever need to base major releases on arbitrary dates ? That's a terrible idea, IMHO. Such changes should be based on the features first, and *then* on some kind of deadline to complete the work, not the reverse. But last point is scope of changes - if major changes break compatibility, you probably don't want to do them too often - players (and server admins) probably don't want to have to start from scratch every 6 months. Sure. I was more thinking about a rather long cycle for majors - one every two years or so, possibly even longer. That more or less matches what I said for the CVS branch. I guess if we're not really concerned about stability of major releases, doing pre-releases isn't necessary. But given that major releases will have much larger scale changes, I'd see that number of severity of bugs to potentially be larger. Likewise, if the code isn't being used very much until it is released, it means that a bug for a big change may not be discovered until a year after that change is made. I know from my own developing perspective, I'd much rather find bugs for code I do relatively shortly after I do the code, because the code will be fresher in my mind than if I have to look back at something I did 6 months ago. Then simply open a public beta server using the last usable CVS code. There's no need to play with pre-xxx labels of any kind for that. I suppose in short what I'm saying is it is really nice to have all code actually exercised/used somewhat shortly after the code is written. Yes, indeed. But that would also include some testing made by the developer(s) it(them)selves. Often, changes made in the CVS currently result in an unusable code because of gross errors that could have been avoided if the coder had spent ten more minutes to build, install and test his/her new addition. At the same time, the number of
Re: [crossfire] 2.0 release, was Re: Code restructuring
Andrew Fuchs wrote: On the community side, we need to encourage player interaction, both in and out of the game. One way to boost in game interaction would be bolstering the player economy. However, that will probably not be done in time for cf2.0. For the community out of game, make it easier to find resources like the forums, and the wiki. Some of this could be done by including notes/links to that in the client itself (perhaps in the about tab). I think most servers may report that info in the motd, but a lot of other info is also displayed at login time, so may not be obvious to everyone (one of those things that when you get shown a bunch of info at one time, becomes more common to just ignore it.) There is also nothing preventing server admins from changing the motd so that it doesn't contain that information. Additionally, make it easier to join irc channels, possibly by putting a java applet somewhere. Not 100% sure about that - presumably most everyone playing will have some irc client available - we should probably make it more obvious (again) on pointing out that the irc channel exists. I personally don't think we want to write/maintain our own irc interface. There might be libraries to make it pretty easy, in which case doing it may not be that hard. But in that case, it should be a pretty specific interface (only connect to the crossfire channel, etc - don't get things too complicated by implementing a complete irc client). If a person is serious about using irc, they should be able (or probably already have) a fully featured irc client. Another thing that could be done to aid the community, both in-game and outside of the game, would be to setup a method to connect to servers, just for the purpose of chatting with people who are playing (oldsocketmode uses food iirc). IMO, oldsocketmode should just go away - part of the code cleanup. But a simple change for this would be if your on a savebed and not regaining sp/grace/hp, you don't use food. I don't think that would hurt balance and people could be logged in and never eat a bite but still take in conversations, etc. If you want to go out and trade items, whatever, then you would use some food. Another topic of communication between players, would be the inter-server chat discussed a while ago. I think that falls into a major project - not as simple as one might thing - this needs to be properly thought out in many ways. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 release, was Re: Code restructuring
Le vendredi 21 juillet 2006 20:15, Andrew Fuchs a écrit : What I'm inferring, and my op pinions: Summary: While 2.0 should be a significant release, the majority opinion is that it should not take years. This makes it difficult to implement what everyone wants, etc. True. I think 2.0 should be the point at which most issues that we have known about, but haven't fixed, should be fixed. I'd get furthermore by saying that the last 1.x should be the point where most issues should be solved. And then, we can start making massive changes leading to the 2.0 version. Additionally, the game should be made easier to use (more graphical interfaces on the client side instead of typing in commands constantly), Yep - some proposals for the ergonomy of the client would be more than welcome. Gaining developers: snip Agree on all this, although gathering more devs is probably not the most important point ATM. Strengthening the community: On the community side, we need to encourage player interaction, both in and out of the game. One way to boost in game interaction would be bolstering the player economy. I think that, before entering into such details, we should ask ourselves what is fun in the game and what isn't. And more important, as players what they find fun, and what they don't. I am also doubtful that changing game mechanisms is the top issue for a stronger community - rather, that's making the game attractive and fun, by proposing events in and around them. Many MMORPGs feature special events around their games (contests, one-time special quests, etc). I think that should be investigated for Crossfire. However, that will probably not be done in time for cf2.0. Indeed. But that's probably a good time to start thinking about that part, and try to produce a list of what should be done. For the community out of game, make it easier to find resources like the forums, and the wiki. Additionally, make it easier to join irc channels, possibly by putting a java applet somewhere. Good idea. Probably make the Forum and Wiki more visible on the front page would also help. Another thing that could be done to aid the community, both in-game and outside of the game, would be to setup a method to connect to servers, just for the purpose of chatting with people who are playing (oldsocketmode uses food iirc). Agree. Another topic of communication between players, would be the inter-server chat discussed a while ago. Yep, although that's a little more complex issue to solve. Maybe bridges with the IRC could solve the issue. My opinion on release numbers: Once we have more developers and enough are willing to volunteer, it may be a good idea to appoint some people to maintain the stable branches. Maybe. Note that I don't think we should maintain several stable branches concurrently - only the last release made. I doubt we'd really need specific maintainers in such a scheme. Micro releases: bug fixes, and addition of small features Minor releases: Features involving significant changes Major releases: Huge changes in game play, major overhauls, milestones in development I mostly agree with this. Just for the record, I think micro releases probably wont require any CVS branching. I'd put small features as minor release ones, though - else, we're taking the risk of a slide where most changes become considered as micro release ones to make them happen faster. Finally, i just want to note that our next release could be 1.10.0 instead of 2.0 if we need more time for cf2.0. Quite probably. I think we should first fix all the remaining problems, release that as 1.10, and then work on that strong code basis to get a 2.0. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 release, was Re: Code restructuring
Mark Wedel wrote: Well, a major code restructure can't go into a minor release. Under the proposed model, the only thing that comes from the main branch is major releases - when a major release is done, then a new stable branch is set up where the minor releases come from. Going back to the original issue is code drifting apart - if a major restructure is done in the main branch, it makes fixing any bugs in both the main and stable branch more difficult. It could just be we live with that difficulty. Or if a major restructure is done shortly after a major release, still have to wait for the 6 months or whatever. I don't really want to try to say 'major code restructures happen near the end of the cycle' - I think if someone has the code ready and it is on the list of things to do, it should be committed. Agreed, I was just nitpicking about what would be the ideal circumstances, and if someone does have code ready right after a major release, it should indeed still be committed. Personally I think this difficulty would be perfectly fine to live with, provided that those who do the restructuring make sure they keep detailed logs of what functionality of the code moved where in the changelog (i.e. along the lines of Moved weapon behavior from apply_ob() in item.c to type_weapon_apply() in types/weapons.c), to make it easier to people to deal with. However, as per gros's comment, there needs to be sufficient changes between the releases to warrant a major release. We probably don't want to do a new major release if there are not any signficant changes - I suppose this may be a matter of opinion, but if we go in this model, I think that sort of needs to be the case, as otherwise we get into confusion at what each branch/release means. There can still certainly be major releases which don't break compatiblity in any way but still hold other significant changes (new features, or changing of existing features/expanding them). Agreed, I was just pointing out that even with major releases, we should think before breaking things, and if there is a reasonable way to get things done, without breaking, or without making the code messy, etc. then it should be considered. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 release, was Re: Code restructuring
Andrew Fuchs wrote: Finally, i just want to note that our next release could be 1.10.0 instead of 2.0 if we need more time for cf2.0. And that is something I strongly believe should be the case. I personally do not believe that we are ready for 2.0 for a while (I'm thinking about 6 months or so if not a little more), and I believe in the meantime that we should do at least one release such as 1.10.0. However I believe the point of another release between 2.0 and now to gain more time, is fairly moot unless people can work on 2.0 in cvs starting fairly soon, hence, I believe that the best solution would be to create create a new cvs branch for working on 1.10.0, and then work on 2.0 things in the main branch. In terms of debate between making a branch for each major version, or each minor version, I personally don't have much preference on, but I feel that a branch of some sort is needed. Also, I believe the type of code restructure I mentioned a little earlier on the mailing list, should be something to target for 2.0, though I personally wait about a month to start work on it to allow people to get used to usage of the branches and possibly to apply pending patches that have been lying around for a while already. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Server setup an Debian - newbie
Good morning all. I have installed the server from the Debian apt-get and it installed fine, or so I thought. It seems that the .deb package does not install the plugins. Where can I find the doc's for an old fart just learning Linux to get the plugins compiled? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Ideas to make DM quests easier to manage and setup, was Re: 2.0 release
On 7/22/06, Nicolas Weeger (Laposte) [EMAIL PROTECTED] wrote: I am also doubtful that changing game mechanisms is the top issue for a stronger community - rather, that's making the game attractive and fun, by proposing events in and around them. Many MMORPGs feature special events around their games (contests, one-time special quests, etc). I think that should be investigated for Crossfire. IMO, we need more of these. Adding some way for mappers to use the date to control events on their maps could have a somewhat similar effect, but would be less interesting to players. We did that on Metalforge a few times, a few DMs. Drawbacks: * it takes time to plan * it takes time to actually eg put items, create stuff, and so on I don't have the time to do this, but would some semi-standardized quest types, and premade maps (containing objects requiring minimum modification, and/or a script to check player's status) to aid with those quests help? * it takes time to run, because people will connect to the game and want to play Possibly make the event last for a day or two, but that would make things harder to plan. * it takes many people to handle everything Would some premade scripts to manage dm quests help? * also note time zone issue, too Another reason to make events that last a few days. But i'd be ready (and eager!) to help do some events from time to time. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Server setup an Debian - newbie
On 7/22/06, Penbrock [EMAIL PROTECTED] wrote: Good morning all. I have installed the server from the Debian apt-get and it installed fine, or so I thought. It seems that the .deb package does not install the plugins. Weird, usually the plugins are includes with the server, and run by default. It could be that they where placed in another package, but I doubt that (only packages that look like they would logically include them are crossfire-server and crossfire-common). Where can I find the doc's for an old fart just learning Linux to get the plugins compiled? No such documentation exists AFAIK (plugins are application specific most of the time). Also I don't know of anywhere to get a individual plugin, except for the source code. So ultimately the easiest solution (for those who know how to) would probably be to compile the server from source. P.S.: Anyone want to get hold of the maintainer of the crossfire Debian packages, and see what he knows? -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Server setup an Debian - newbie
Ok, it seems like the package has been fixed, and is waiting to be uploaded to the debain servers/mirrors. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=379348 -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Server setup an Debian - newbie
Andrew Fuchs wrote: Ok, it seems like the package has been fixed, and is waiting to be uploaded to the debain servers/mirrors. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=379348 I found the maintainer on IRC and he is fixing it. Thanks ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
