Re: [crossfire] skill window

2010-04-16 Thread Kevin Bulgrien
> Ok, so taking all of that, then it is even less clarity over who can
> 'bless' a change to a layout, particularly if the author of a layout
> isn't the same thing as a user. Because there are multiple respondents,
> giving different verdicts, the mailing list probably isn't the ideal
> place to try and collate those, so I have created a wiki page:
> 
> 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?

> 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.

___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire


[crossfire] Auto ID on examine

2010-04-16 Thread Brendan Lally
Hello all,

Just wanted to get some opinions on the following patch:
https://sourceforge.net/tracker/?func=detail&aid=2988536&group_id=13833&atid=313833

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.

Brendan

___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire


Re: [crossfire] Material

2010-04-16 Thread Rick Tanner
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


> I'm not sure many people actually use the NEW_MATERIAL_CODE macro defined in 
> config.h...
> I don't even know who knows what it is supposed to do or if it was tested :)

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.

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.



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFLyKbFhHyvgBp+vH4RAg/TAJ9KynSdIDJ3vfBZoT9QIY39DHYBBACcDRYQ
uJXIfPp25t8wdfX9bIqLar8=
=dJzv
-END PGP SIGNATURE-

___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire


[crossfire] Material

2010-04-16 Thread Nicolas Weeger
Hello.

I'm not sure many people actually use the NEW_MATERIAL_CODE macro defined in 
config.h...
I don't even know who knows what it is supposed to do or if it was tested :)


So I'm proposing 2 alternatives:
1) remove this code, and forget about it
2) activate it and debug it.


For option 2), here is a proposal for a defined behaviour.

An object will have 2 properties, "real material" and "readable material".
The first will be used in the code, for various save throws and such.
The second (current "materialname") will be the name displayed to the player.


The "real material" will be a comma-separated list of either material name (as 
defined in the "lib/materials" file or material type (as defined in 
include/material.h).
If it is a name, this material is used ; if it is a type, a random one is 
chosen from the materials of this type.
For computing purposes, the average of a value will be computed - if you have 
2 materials, the eg fire saving throw will be the average of both values.

It is only possible to use one material from the same type (one skin only).


The readable name will be either defined by the archetype creator or map maker, 
or made from the real material(s). This is to let map makers have fun with 
names and still keep a real material underneath.


A flag will indicate if the material bonuses (to damage, to weight, ...) were 
already applied to the object or not.


Material will not be processed for archetypes or artifacts, to enable 
diversity.


Examples:
- "material 8" will select a random skin, from wolfhide, dragonhide, and so on
- "material 24" will select a random skin and a random wood
- "material "bamboo,64" will make a material from bamboo and a random stone.



Opinions?


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


Re: [crossfire] skill window

2010-04-16 Thread Brendan Lally
On Thu, 15 Apr 2010 22:17:24 -0500
Kevin Bulgrien  wrote:

> > Questions:
> > 
> > 1) Can the skills and experience pane now disappear?
> 
> Other layouts might be other player's favorites, so making sweeping
> changes seems to take some extra thought about who it affects.
 
Ok, so taking all of that, then it is even less clarity over who can
'bless' a change to a layout, particularly if the author of a layout
isn't the same thing as a user. Because there are multiple respondents,
giving different verdicts, the mailing list probably isn't the ideal
place to try and collate those, so I have created a wiki page:

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.

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.
 
> > icons for all of the skills (implemented by sending a face number
> > along with the reply_info skill_info response)
> 
> Its fine, but I'd note that graphics blows out the vertical space
> requirements, so some consideration might be given to allowing them to
> be turned off or made quite small so as not to expand every line.  The
> thing I like about your dialog now is that it is pretty tight and
> readable.  I'm not really sure that I see a lot of value in skill
> graphics myself except as eye candy - which tends to aggravate things
> if you happen to have a really small monitor, but can be nice if you
> have screen real estate to throw away.

Ok, I can certainly see that point, OTOH there are 44 skills and it is
a scrolled window which is sortable, a few of these are mutually
exclusive anyway, and a couple are switched off, so you are probably
looking at not more than 40x32 pixels = 1280 pixels

For many players on modern systems, that entire list probably fits on
screen or very close to it, for the rest, then sorting by level is
probably going to show them the skills they care about anyway (after
all, when was the last time you gained jumping experience?)

> > The 'character' pane on the client to show the icon for the skill
> > rather than the name, and clicking on the icon to trigger the
> > callback for the skill window in the same way that the menu entry
> > does.
> 
> Not sure I know what you mean by the 'character' pane.  If you mean
> the core stats, I'm not in favor of the text version of the readied
> skill going away on all the layouts... but maybe I'm not groking what
> you want to do.  Whereas some people like pictures, I tend to like
> text for that. I think graphics are ok for fairly static things like
> button bars, but I would find the readied skill shown only
> graphically to be frustrating.
 
That is what I meant, I can see why you might not like that, so maybe
it is something that should be altered on a per-layout basis.

Brendan

___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire