Re: [crossfire] skill window
Until other responses are made to this, there is really little point in continuing the discussion. It is evident that an agenda is being pushed when there are many other alternative paths and cooperative viewpoints that are less isolating and much more constructive. Policy is being proposed that is not applied to other areas of SVN. It gives the appearance that control is much more important than cooperation. There seems little point to argue when the agenda is so destructive. Freedom at the expense of relationship is not something that is going to help Crossfire. Copy a design you want to change, and modify it. Commit it, and expect that people will be respectful of the work that went into it, and will not attempt to wrest control of your efforts away from you, nor attempt to invalidate your tastes of how a client should look and feel while you are still active in the project. > > > http://wiki.metalforge.net/doku.php/gtk-v2_ui_updates > > > > > > Where these responses can be collected. > > > > > > The other advantage of this approach is that if no verdict or > > > comments are given after a month or two, then it is probably safe > > > to consider that layout unused and unloved, and then to consider it > > > for exclusion from future releases and ultimately removal from the > > > SVN repository. > > > > Surely you jest. Just how often is the quantity of wiki edits / > > month or two an accurate sampling of the entire crossfire player > > population's views on anything? > > I'm hoping the answer to that is, 'when there are a number of mailing > list, IRC and forum posts inviting, with ever escalating persistence, an > expression of such views. > > That probably means up to 4 mailing list posts & forum posts + > at least that quantity of IRC discussions which follow the following > form: > > 1) There is a proposal to change layouts, can all layout > owners/maintainers give their verdicts and interested users give > comments. > > [2-4 weeks later] > > 2) Please give all comments and verdicts to the layout change proposals > in the next 2 weeks, the following layouts are lacking any response: > > the following layouts have comments but no owner verdict. > ... > [2-4 weeks thereafter] > > 3) The following layouts have not received a response from the > owner/maintainer regarding the change n. > ... > Please can any commentators > who wish to take over maintenance of these layouts contact the mailing > list. > > [2-4 weeks thereafter] > > 4) The following layouts received no response at all to the proposed > layout change n, > ... > and are now considered abandoned, they will be removed > prior to the next release. > > There may also be a case for a crossfire-announce posting to be made in > the lead-up to a release, probably a couple of weeks beforehand so that > there is time for anyone who doesn't read the main mailing list to > yell. (Although then you might question how much such a person really > cares about the ongoing development of CF, and if they would really > notice). > > The overall aims here are: > 1) That the number of layouts remains fewer than the number of players, > preferably substantially fewer. > 2) That the majority of players using the majority of layouts should > benefit from work being done on client changes, unless they are > deliberately choosing layouts which are designed not to. > > My view would tend to be that if: > * There is a layout currently that is intended never to be updated, > * It is for the use of a single individual, who has decided that it is > perfect as it is > > Then that shouldn't be in SVN, and shouldn't be a choice in the > client as it is distributed by default. By all means keep a backup > somewhere globally accessible, along with instructions for using it > with a client, but for someone new to CF, who discovers the layout > selection widget for the first time, they should expect that the > selections they choose from correspond vaguely with the documentation > that they will read, and not have something which is hugely different > (other than in the ways that are a design feature of the layout) > > The case of an underused layout where there is a desire to see it > actively maintained is a different matter, I'd hope that all the > current layouts fall into this category, and the only question is over > how to implement such maintenance (if at all). > > > > Obviously if there are vastly differing and strongly held > > > sentiments in terms of what should be done for any given layout, > > > then that makes the case for creating another new layout. > > If no one cares to express such views over the course of several > months, the conclusion must be that they are not strongly held. > > Brendan. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Auto ID on examine
Brendan Lally wrote: > This changes the way the examine command (triggered by left > clicking on an object) works so that if the object is unidentified, > and the player has the appropriate skill, then an attempt to identify > the object is automatically made. > > The intention is that this should make the ID process much smoother for > new players, and less likely to be discovered after wasting money on ID > tables or selling items that were useful. This does change the overall game balance a bit (making it easier to use skills automatically), but all-in-all I think it is a good change. What I would like to also see is having a class "identified" (similar in function to "cursed" and "magic") in the inventory, so that you could more easily manipulate items which you have identified. -- /* * * Otto J. Makela * * * * * * * * * * * * * * * */ /* Phone: +358 40 765 5772, FAX: +358 42 7655772, ICBM: 60N 25E */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki, FINLAND */ /* * * Computers Rule 0100 01001011 * * * * * * * * * * * * */ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] skill window
On Fri, 16 Apr 2010 18:30:56 -0500 Kevin Bulgrien wrote: > > > > http://wiki.metalforge.net/doku.php/gtk-v2_ui_updates > > > > Where these responses can be collected. > > > > The other advantage of this approach is that if no verdict or > > comments are given after a month or two, then it is probably safe > > to consider that layout unused and unloved, and then to consider it > > for exclusion from future releases and ultimately removal from the > > SVN repository. > > Surely you jest. Just how often is the quantity of wiki edits / > month or two an accurate sampling of the entire crossfire player > population's views on anything? I'm hoping the answer to that is, 'when there are a number of mailing list, IRC and forum posts inviting, with ever escalating persistence, an expression of such views. That probably means up to 4 mailing list posts & forum posts + at least that quantity of IRC discussions which follow the following form: 1) There is a proposal to change layouts, can all layout owners/maintainers give their verdicts and interested users give comments. [2-4 weeks later] 2) Please give all comments and verdicts to the layout change proposals in the next 2 weeks, the following layouts are lacking any response: the following layouts have comments but no owner verdict. ... [2-4 weeks thereafter] 3) The following layouts have not received a response from the owner/maintainer regarding the change n. ... Please can any commentators who wish to take over maintenance of these layouts contact the mailing list. [2-4 weeks thereafter] 4) The following layouts received no response at all to the proposed layout change n, ... and are now considered abandoned, they will be removed prior to the next release. There may also be a case for a crossfire-announce posting to be made in the lead-up to a release, probably a couple of weeks beforehand so that there is time for anyone who doesn't read the main mailing list to yell. (Although then you might question how much such a person really cares about the ongoing development of CF, and if they would really notice). The overall aims here are: 1) That the number of layouts remains fewer than the number of players, preferably substantially fewer. 2) That the majority of players using the majority of layouts should benefit from work being done on client changes, unless they are deliberately choosing layouts which are designed not to. My view would tend to be that if: * There is a layout currently that is intended never to be updated, * It is for the use of a single individual, who has decided that it is perfect as it is Then that shouldn't be in SVN, and shouldn't be a choice in the client as it is distributed by default. By all means keep a backup somewhere globally accessible, along with instructions for using it with a client, but for someone new to CF, who discovers the layout selection widget for the first time, they should expect that the selections they choose from correspond vaguely with the documentation that they will read, and not have something which is hugely different (other than in the ways that are a design feature of the layout) The case of an underused layout where there is a desire to see it actively maintained is a different matter, I'd hope that all the current layouts fall into this category, and the only question is over how to implement such maintenance (if at all). > > Obviously if there are vastly differing and strongly held > > sentiments in terms of what should be done for any given layout, > > then that makes the case for creating another new layout. If no one cares to express such views over the course of several months, the conclusion must be that they are not strongly held. Brendan. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Material
Hello. > Quite some time ago, it was enabled on Metalforge but removed due to > player complaints. > > What people didn't like about it was merging issues in their inventory > window. They would (for instance) have 8 different Boots of Speed all > because they would not merge together to be Boots of Speed x8; the > material types (different hides; dragon, wolf, serpent, etc.) was > determined to have caused this. My opinion is that almost all archetypes should have a fixed precise material, eg fixed wood, or metal, or other material. Using random ones should be limited to specific cases, including maybe quests items... > The goal or hope of the original developer for this feature was to > implement task quests in the game like find a NPC a stone amulet, a gold > sword, serpent skin leather armour, etc. and then collect a reward. Indeed, this could be done. This can already be done, though, through the 'materialname' and 'material' things. Currently, right now, the material is used for two things: - when animate weapon is used, to give resistances to the golem - for throw saves to know if an item is destroyed or not by an attack Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire