Re: [crossfire] GTK V2 client default layout and map size

2008-02-14 Thread Raphaël Quinet
On Tue, 12 Feb 2008 21:44:02 -0800, Mark Wedel [EMAIL PROTECTED] wrote:
   If you only have a display that does 1024x768, then the Oroboros is the 
 likely 
 winner.  But if you have a higher res display, that probably isn't a first 
 choice, as you have a lot more display area than it uses.

It depends.  Since I play from time to time using different computers, I end
up using different screen resolutions: 1024x768, 1280x1024, 1600x1200, etc.
I think that the original gtk v2 layout isn't too bad and I can even use it
at 1024x768 using a few tricks to save space.

If you look carefully, you will see that the gtk v2 and the Oroboros layout
are almost the same, except that the map area is moved from the top left to
the bottom right.  Otherwise, both are based on a basic 2-columns layout, with
one column containing the same 3 rows (messages, inventory, floor view) and
the other other one containing the map and the stats/skills/etc.  One
difference is that Oroboros puts the HP/SP/Gr/Food/Exp bars inside one of the
tabs instead of besides the tabs.  I do not like this choice because it means
that I cannot view these very important bars as easily when I am viewing the
other tabs, so that's why I still prefer the v2 layout.

I think that before we try to pick the best layout, there are two things
that should be investigated:
1) What information is important to the players?  What should always be
   visible on the screen and what can be toggled in/out of view using tabs or
   using any other appropriate mechanism?  I would like to have a discussion
   on what we need to show before having a discussion about how it should be
   shown.
2) Is it possible to make the layout more flexible?  Instead of having to
   select among a predefined set of layouts, could we find a way to provide a
   good default layout while still allowing the user to change it easily?

After discussing these two points, then we can go back to the selection of
the best layout if this is still relevant.

I will start with a few comments on point 2) because this is related to what
Mark wrote:
   Now it may be that the client should try and be smart and choose a best 
 default layout based on various factors, like screen resolution.  Same could 
 be 
 said for things like map size.
 
   A better approach may be to have a basic configuration program (or window) 
 that is used first time client is run by user (no .crossfire file).  A fair 
 number of commercial games use that approach - configure the display 
 resolution/quality you want to use, configure sound, etc.

This is not an ideal approach because it forces to to select (automatically
or via some configuration program) among a set of predefined layouts and
maybe none of them is perfect for you.  Instead, I would prefer to start with
a good layout that can work well at low resolutions (a 2-columns layout) and
then allow the user to add or remove a third column at any time and pick the
tabs that should be in that column.

I have some experience with that in GIMP: instead of having a fixed layout
for all tools and dialogs, you can create any number of docks and drag tabs
into these docks or out of them.  GIMP uses separate top-level windows for
the docks, but this could also be done using columns belonging to the same
top-level window.  Once you have done the initial effort to replace/subclass
the GtkNotebook widgets, you get a lot more flexibility and then you do not
have to worry anymore about what layout is best, because you know that the
users will be able to re-organize the tabs according to their preferences.

The main concern would be to select the best initial layout, but we would not
need to worry about how a 2-columns layout wastes space on a widescreen
display because we will know that it is easy to add a third column if the
user wants it.

   I'm also not wild about the way the stats are displayed in all the layouts 
 (which really isn't changed) - that is to say being in a single row:
 Str 5 Dex 6 Con 10, etc
 
   as that never seems really easy to find for me, and I can't think of any 
 other 
 game that displays them - doing them as a column, with column to the right 
 (or 
 maybe several) may be more readable and more effective use of space, eg:
 
 Str 6 Speed   0.50
 Dex 10Weapon Speed0.80
 Con 18Damage  15
 Int 14WC  6
 
   and so on.  As an aside, since exp now has its own statbar, there really 
 isn't 
 much reason for there also to be a display in the stat area.

A column layout might be nice for the stats.  But regarding the point 1) that
I mentioned above, I would be interested in a discussion about what we
consider to be the most important information.  Besides the map, messages and
inventory, I would consider the following information to be important
especially during combat and I would like a layout that allows me to see all
of these things at the same time:

Most important (sorted 

Re: [crossfire] Using svnmerge for backporting to branch?

2008-02-14 Thread Nicolas Weeger
Hello.

 After applying a trivial bug fix for the manual pages of the clients, I
 thought about merging the patch to the 1.x branch.  However, it looks like
 all previous merges have been done by hand (hopefully using svn merge)
 instead of using automated tools like svnmerge (no space).  Or at least,
 I was unable to find the svn properties that are usually stored by
 svnmerge when it is used.

I have no objection to use svnmerge, but as you point out *everyone* should it 
if we decide to use it.

I would say for current trunk/branch it may not be that required, as I fully 
expect branch To Die Soon (tm) :)
Except for bugfixes, of course.

So maybe for the future 3.0 branch?

Nicolas
-- 
http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de 
l'aléatoire !]


signature.asc
Description: This is a digitally signed message part.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire


[crossfire] New field: race_restriction

2008-02-14 Thread Nicolas Weeger
Hello.

Just added what I hope is a fun feature: race restriction on items.


From the wiki:


Everything that can be applied, including items, exits, handles, and thus can 
have a ‘race_restriction’ key. The value should be set to a : delimited list 
of races that will be able to use/apply/open this item. The list is in the 
form: 
:race1:race2:...:racen:
 with leading and trailing :. 
 Note that that this only applies to players - monsters can always apply 
everything. Also, Dungeon Masters are immune.



Enjoy :)

Nicolas
-- 
http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de 
l'aléatoire !]


signature.asc
Description: This is a digitally signed message part.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire


[crossfire] Race / class animations

2008-02-14 Thread Nicolas Weeger
Hello.

I committed a few days ago a change that enables to have specific animations 
for all race/classe combinations.

The animations should be called base race animation_class_name, so for 
instance a Fenx warrior will use animation fenx_player_class_warrior.

So now we just need pics for all combos :)


Nicolas
-- 
http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de 
l'aléatoire !]


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] GTK V2 client default layout and map size

2008-02-14 Thread Mark Wedel
Raphaël Quinet wrote:
ther tabs, so that's why I still prefer the v2 layout.
 
 I think that before we try to pick the best layout, there are two things
 that should be investigated:
 1) What information is important to the players?  What should always be
visible on the screen and what can be toggled in/out of view using tabs or
using any other appropriate mechanism?  I would like to have a discussion
on what we need to show before having a discussion about how it should be
shown.
 2) Is it possible to make the layout more flexible?  Instead of having to
select among a predefined set of layouts, could we find a way to provide a
good default layout while still allowing the user to change it easily?

  Agree on both points.  There may also be other things that make the client 
easier to use.  Some of how the client works dates all the way back to it just 
be X11, where some more complicated things would have been very hard to do, but 
are quite easy to do with the widgets provided by GTK.


   A better approach may be to have a basic configuration program (or window) 
 that is used first time client is run by user (no .crossfire file).  A fair 
 number of commercial games use that approach - configure the display 
 resolution/quality you want to use, configure sound, etc.
 
 This is not an ideal approach because it forces to to select (automatically
 or via some configuration program) among a set of predefined layouts and
 maybe none of them is perfect for you.  Instead, I would prefer to start with
 a good layout that can work well at low resolutions (a 2-columns layout) and
 then allow the user to add or remove a third column at any time and pick the
 tabs that should be in that column.

  Yes, that is a better solution.  I guess it depends on how much work it is to 
do.

  One nice thing right now is that all the layout work is done in glade.  This 
makes it very easy to try different things, but also makes it very easy to add 
onto the layout.  So while things could be done better, I'd want to make sure 
we 
don't drift away from also being able to manage the layouts within glade. 
Having thousands of lines of handwritten code to handle ideal layouts may be 
nice from an end user perspective, but starts to get really unmanagable from a 
developer perspective.

  At the same time, the first time a person runs the client, popping up some 
config options may still not be a bad thing, as right now, for lots of the 
config options, the client chooses defaults which may not be ideal.


 A column layout might be nice for the stats.  But regarding the point 1) that
 I mentioned above, I would be interested in a discussion about what we
 consider to be the most important information.  Besides the map, messages and
 inventory, I would consider the following information to be important
 especially during combat and I would like a layout that allows me to see all
 of these things at the same time:

  I'd make some adjustments even on those key points - inventory can/should be 
done better.  Its been discussed, but what is really needed is ability to make 
up a custom list of objects I care about.  In combat, there are probably less 
than 20 items I really need to see in my inventory - things like certain 
scrolls 
and potions, and maybe a few different weapons.  I don't need to see all my 
items, and in fact, seeing all my items often makes it difficult to get to the 
ones I really need.

 
 Most important (sorted by order of importance):
   - HP/SP/Gr/Food bars
   - range (current spell or bow) - important if I have the wrong thing active
 and I am wondering why the monsters around me are not harmed
   - protections (percentages for all current protections, armor) - important
 especially when they change because I have been hit or a spell expires.

  Pretty much agree.  But I also think a better way to manage the protections 
is 
needed.  While I want to be able to see them, being able to easily notice that 
my resist fire has gone from 90 to 20 may be difficult.

  Ideally something like a spell monitor would be nice - protections on my 
character are almost certainly controlled by various potions the character 
drinks.  Because the duration of these potions can not really change, it is a 
fairly simple matter for the server to inform the client that 'Joe drank a 
potion of fire resistance, it will last for 30 seconds'.  Clearly it would be 
done in a more concise term than that, but you get the point.

  So maybe some space in the statbar area could be used for this.  A simple 
solution would be to use different icons for the different resistances/spell 
effects, and the client draw a little stat along with the icon, so one can see 
how much time is left on the spell.

   - AC
   - damage
   - speed
   - weapon speed
   - WC

  While the above are handy, they also typically are not things that change in 
combat, so I don't really need to see them in a glance.  At some point, less