colossus-developers Mailing List for Colossus (Page 228)

David Ripton wrote:

> I moved the assignTowers() call to after MasterBoard initialization in
> Game.newGame().  This required small changes in GetPlayers, Client, and
> Server.  You should be able to safely commit the rest of your change.

I'll commit it next week (I don't have the new code ATM).

> That's okay.  Just remember to increment Options.saveGameVersion.

will do that.

> I like the BattlelandsBuilder. Minor bug report: it needs to check for
> a null neighbor hex before trying to add hexside features.

I've changed the logic, now the HexSide popup won't appear on the
outside sides, the Terrain popup is displayed instead.

-- 
DOLBEAU Romain            | For a hill, men would kill, Why ?          
ENS Cachan / Ker Lann     | They do not know.                          
Thesard IRISA / CAPS      | -- Metallica in 'For Whom The Bell Tolls'  
dol...@cl... |

Romain Dolbeau wrote:

> Weel, I coded a new, improved Game::assignTowers(), that uses the Tower
> Set, and it works.
> 
> The bad news is, where assignTowers() is called, the MasterBoard isn't
> yet set up, so, of course, it can't work. If I push it later, after
> Server::allInitBoard, other things break. And that's pretty much all I
> can do, as the order for other initializations is constrained...
> 
> I didn't commit the (broken) code. I'm willing to listen to any
> suggestion...


I moved the assignTowers() call to after MasterBoard initialization in 
Game.newGame().  This required small changes in GetPlayers, Client, and 
Server.  You should be able to safely commit the rest of your change.

> BTW, changing startingTower from a int (between 1 and 6) to an Hex Label
> is going to change the SaveFile format...


That's okay.  Just remember to increment Options.saveGameVersion.


I like the BattlelandsBuilder.  Minor bug report: it needs to check for 
a null neighbor hex before trying to add hexside features.

-- 
David Ripton   dr...@wi...

bruce sherrod wrote:


> The minimax code is pretty much a loss, I'm guessing.   


I got it basically working, and moved all the minimax move code into a 
MinimaxAI subclass of SimpleAI.  It's usable (well, not this week 
because it hasn't yet been updated to work with the latest battle 
restructuring, but usually), but a lot slower than SimpleAI and a bit 
dumber.  But I have this gut feeling that it's only a few changes away 
from being stronger than SimpleAI, and the code is much prettier, so I 
haven't wanted to remove it.  (Except when it generates bug reports.)


>>I suspect that a better Titan battle AI would have to use two stages, 
>>first a one-creature-at-a-time move function to pick the best N 
>>candidate moves for each creature (where N is determined so that 
>>numMovingCreatures ^ N is small enough for minimax to finish in a 
>>reasonable amount of time) and then minimax with the pruned move lists 
>>to take teamwork into account.  Does this sound reasonable to you?

> I'm not sure.  I think minimax with massive amount of forward
> pruning for the first few turns might be computationally feasible.

An attacking legion of 7 different 4-skill creatures entering the plains 
  against a defender who hung back has 20! / 13! = 391 million possible 
first-turn legion moves (ignoring leaving anything offboard).  Just 
generating them all takes forever.  So you have to generate only a 
sample of them to feed to the evaluation function.

But if you just stop after generating the first N of them, you might get 
stuck with the best of a clump of similar bad moves.

So one option is generating and evaluating all creature moves in 
isolation (20 * 7 = 140) using the quick-and-dirty logic I already have, 
and returning only the locally-best ~7 moves for each creature.  Then 
the minimax generateMoves() only has 7! = 5040 moves to deal with in the 
first ply, which should be skewed towards good ones if the 
pre-evaluation function is decent.

And the other option is skipping the pre-evaluation and just using a 
legion move generator that really scrambles the sequence of creature 
moves in the legion moves, so that after iterating through only 0.0001% 
of the possible legion moves, you probably have a decent one in there 
somewhere.

My guess is that in some positions where there are a very small number 
of truly superior moves, the first way will probably find a good move 
and the second might not.  So it's probably worth the extra time for the 
screening evaluation.

I'm pretty sure I can get a decent two-tier one-ply lookahead, but the 
real challenge is pruning well enough to be able to usefully look ahead 
a couple of turns.  Maybe if the AI is aggressive enough that most stuff 
is either locked in melee or dead quickly.  :->

-- 
David Ripton   dr...@wi...

Weel, I coded a new, improved Game::assignTowers(), that uses the Tower
Set, and it works.

The bad news is, where assignTowers() is called, the MasterBoard isn't
yet set up, so, of course, it can't work. If I push it later, after
Server::allInitBoard, other things break. And that's pretty much all I
can do, as the order for other initializations is constrained...

I didn't commit the (broken) code. I'm willing to listen to any
suggestion...

BTW, changing startingTower from a int (between 1 and 6) to an Hex Label
is going to change the SaveFile format...

-- 
DOLBEAU Romain               | Who'd believe we'd spend more
ENS Cachan / Ker Lann        | Shippin' drugs and guns
Thesard IRISA / CAPS         | Than to educate our sons?
dol...@cl...    |   -- Megadeth, 'Youthanasia'

> Okay.  So we need to put a set of tower hex labels in MasterBoard, 
> initialize it just after we read in the board from the map file 
> (populating it as we parse the file would be slightly more efficient,
> but I think separating this code from the parsing is cleaner), add a 
> public getTowers() method that returns 
> Collections.unmodifiableSet(towers), modify the tower teleport method to
> iterate through this set, and modify Game.assignTowers() to use the set.
>   (Either with N-sided dice, or by ditching the dice entirely and just
> using a shuffling algorithm.)
> 
> I will do this over the weekend, unless you do it first.

Well, I've commited the first (easy) part ; finding the Tower, and using
the Set for t-port purpose. Unfortunately, Game doesn't have access to a
MasterBoard instance, so I had to make the Set static - Game use a lof
of stuff that are static in MasterBoard anyway :-(

The second part is going to be a little tougher ; I think I'm simply
going to replace Player::startingTower by a String (the Label of the
starting hex), and fix everything that depend on it.

-- 
DOLBEAU Romain               | Brothers of Metal will always be there
ENS Cachan / Ker Lann        | Standing together with hands in the air
Thesard IRISA / CAPS         |           -- Manowar,
dol...@cl...    |                     'Brothers of Metal'

My old email addresses at thematrix.com:

    br...@th...
    sh...@th...

Have been changed.  The new email address is:

    br...@ir...

This change is more painful that when I moved (physically) last November.

-Bruce

Romain Dolbeau wrote:


> But I think assuming all Tower are
> starting points is easier for the moment.


Okay.  So we need to put a set of tower hex labels in MasterBoard, 
initialize it just after we read in the board from the map file 
(populating it as we parse the file would be slightly more efficient, 
but I think separating this code from the parsing is cleaner), add a 
public getTowers() method that returns 
Collections.unmodifiableSet(towers), modify the tower teleport method to 
iterate through this set, and modify Game.assignTowers() to use the set. 
  (Either with N-sided dice, or by ditching the dice entirely and just 
using a shuffling algorithm.)

I will do this over the weekend, unless you do it first.

 
> I hope the GUIBattleHex split didn't cause you trouble,
> as most of the code moved from GUIBattleHex to
> BasicGUIBattleHex... 


I haven't had a chance to look at this code yet.  Probably late tonight.


I need to fix the known bugs in my new carry / strike penalty code, test 
it a lot, check it in, check out your latest changes, merge if 
necessary, test some more, and make a public release.  Then I'll be 
ready to make more changes.  :->


-- 
David Ripton   dr...@wi...

David Ripton wrote:

> Are you assuming that all towers are starting towers?  I'm not sure how
> Extended Titan works -- can players start in the outer towers, or only
> in the 6 inner ones?

I didn't read the rules carefully, but I don't remember any
restriction. ATM, in Colossus, they can't start in 800
or 900 ; if we change the code, the will be able to.
We might add a flag in the map, if need be. Or even
make it universal, and have a 'Tower List' (for t-port),
and a 'Start List'. But I think assuming all Tower are
starting points is easier for the moment.

> Agreed.  Keeping the game at 2-6 players is a good idea for the
> forseeable future.  10-player Titan sounds neat on the surface, but it
> would take forever to play, and the board would have to be absolutely
> huge to avoid horrible crowding.

Colossus is about 10 times faster than regular paper-and-dice
Titan :-) But mostly because of the fast-playing AI...
10-players Colossus would be slow, yes.



I hope the GUIBattleHex split didn't cause you trouble,
as most of the code moved from GUIBattleHex to
BasicGUIBattleHex...

-- 
DOLBEAU Romain               | For a hill, men would kill,              
ENS Cachan / Ker Lann        |   Why ? They do not know.                
Thesard IRISA / CAPS         |      -- Metallica,                       
dol...@cl...    |       'For Whom The Bell Tolls'

Romain Dolbeau wrote:


>>I think the tower set would only be used for tower teleports and
>>possibly starting tower assignments.

> Is there any other place where a set of Tower is needed ?


I can't think of any.  In most places a tower is just another terrain type.


Towers only have one entry side, and a funny recruiting tree, but 
neither matters until you already have a reference to the hex.

I guess an advanced AI might have a "go looking for a tower with my 
stripped Titan stack" mode, but the same list that would work for 
teleports would work for that.


> There's no reason why tower should be kept in 100/900 ;-)
> If we have a List of Tower Label, we can use any value.
> (not that keeping 100/900 would be bad, but someday, someone
> is going to want ten or twelve towers...)


I agree; there should be no maximum number of towers.

Are you assuming that all towers are starting towers?  I'm not sure how 
Extended Titan works -- can players start in the outer towers, or only 
in the 6 inner ones?


> Allowing less that 6 towers is going to cause a chicken-and-egg
> problem : the GetPlayers dialog needs to know the number of
> possible Players, and we need the GetPlayers dialog to choose
> the map... ATM, we're probably better off saying "6 players,
> and at least 6 towers".

Agreed.  Keeping the game at 2-6 players is a good idea for the 
forseeable future.  10-player Titan sounds neat on the surface, but it 
would take forever to play, and the board would have to be absolutely 
huge to avoid horrible crowding.

-- 
David Ripton   dr...@wi...

Romain Dolbeau wrote:

> An easier way would be to keep Creature in BattleHex,
> but I'm unsure of the consequences: Creature import
> GetPlayers, which import Game, which import almost
> everything. We might end up executing static code
> that won't work properly.

Fortunately, it seems we don't :-)

I've commited to HEAD the GUIBattleHex split ;
the only thing left in it is the ability to
repaint on the HexMap used in the constructor.

Everything else is moved in BasicGUIBattleHex,
to which I've added a single function (innerContains,
which check if a given point is in the inner polygon).
I've also removed caching of the name.

This change allowed to remove Hex, BuilderHex and
the BattlelandLoader from /datatools, who only
contains  BuilderHexMap,
ShowBuilderHexMap, and the main class. Everything
else is imported from /client, /parser and /util.
GUIBuilderHex is very similar to GUIBattleHex,
but with a BuilderHexMap instead of a HexMap.

It's a _lot_ cleaner IMHO :-)

I had to add a few 'public' in functions
and class, but only those I used in /datatools.

I hope theses changes aren't problematic to anyone.

-- 
DOLBEAU Romain               | Who'd believe we'd spend more            
ENS Cachan / Ker Lann        | Shippin' drugs and guns                  
Thesard IRISA / CAPS         | Than to educate our sons?                
dol...@cl...    |   -- Megadeth, 'Youthanasia'

David Ripton wrote:

> Ick.  That is a recipe for complete unmaintainablility. 
> Go ahead and check it in, but we're going to need to clean
> this up by making the map/hex classes more generally reusable.
> (A good exercise in any case -- I've wanted to split the GUI
> from the data better to allow pluggable hex/map graphics.)

Well, I got a look at it :

1) BattleHex only use Creature in getEntryCost() ; everything
   else is self-sufficient. Unfortunately, getEntryCost is
   applied to a BattleHex that comes from the HexMap static
   BattleHex array, through Critter.getCurrentHex() :-(

2) GUIBattleHex use HexMap, but only for repaint() ;
   my code passes the map as a parameter to repaint()
   (I should change the name of the function, it's dirty).
   That could be solved by subclassing GUIBattleHex to
   only add the map and redefine repaint().
   I also removed caching of the name, as it changes
   in the Builder.

3) HexMap uses a lot of static member access. It's probably
   the most difficult to rework.

The problem for (GUI)BattleHex is that, if we move 
getEntryCost() in an intermediate class between
BattleHex and GUIBattleHex, GUIBattleHex is tainted.
If it's below GUIBattleHex, we have to use this
new subclass everywhere, except if the use of
HexMap.getHexByLabel() is removed, so that the
regular BattleHex aren't used anymore.

An easier way would be to keep Creature in BattleHex,
but I'm unsure of the consequences: Creature import
GetPlayers, which import Game, which import almost
everything. We might end up executing static code
that won't work properly.

Also, Hex, BattleHex & GUIBAttleHex are package private,
so we'll need to make them public to use them in /datatools.

-- 
DOLBEAU Romain               | Who'd believe we'd spend more            
ENS Cachan / Ker Lann        | Shippin' drugs and guns                  
Thesard IRISA / CAPS         | Than to educate our sons?                
dol...@cl...    |   -- Megadeth, 'Youthanasia'

> BTW, the game is saying
>=20
> Error: Could not find hex 700
> Error: Could not find hex 800
> Error: Could not find hex 900
>=20
> rather freqently during SimpleAI players' masterboard moves.  I haven't
> tracked down the exact bug yet.  (MasterBoard.getHexFromLabel() is=20
> called from many places.)  Have you by any chance changed any code to
> support more than 6 towers?

Oups, yes, I plead guilty ; this one is a merge from the variable size
masterboard. It comes fom the tower t-port code ; the list of tower is
hard-wired [for(i=3D0;i<=3D600;i+=3D100)], I updated it to 900 to test
Extended Titan. That fix is enough to use the new towers for t-port
purpose, but it's not nice, as those error message are annoying (but
should'nt cause problems). Feel free to ask me to back-out this patch.

The "right way" IHMO, whould be to add a List that would hold the
various Tower MasterHex, and all the code that need to find Towers would
iterate through that.

--=20
Romain DOLBEAU               | Ce que l'on con=E7oit bien s'=E9nonce
ENS Cachan / Ker Lann        | clairement, et les mots pour le dire
Thesard IRISA / CAPS         | arrivent ais=E9ment.
dol...@cl...    |       -- Nicolas Boileau

Romain Dolbeau wrote:


> It's done. I only changed the Makefile (added target "datatools" in the
> end, and related stuff), but not "build.xml", as I know zero xml/Ant.
> I also put subdirectory "datatools" in "docs/" and "META-INF/".


I'll update build.xml when I get a chance.

First I need to debug and check in my current changes.  I made choosing 
strike penalties network-friendly, but it's not working yet.

BTW, the game is saying

Error: Could not find hex 700
Error: Could not find hex 800
Error: Could not find hex 900

rather freqently during SimpleAI players' masterboard moves.  I haven't 
tracked down the exact bug yet.  (MasterBoard.getHexFromLabel() is 
called from many places.)  Have you by any chance changed any code to 
support more than 6 towers?

-- 
David Ripton   dr...@wi...

> I'll put it in /datatools (unless you prefer something else), and you'll
> see by yourself if you have the time what I needed to remove to get
> something "clean" (I added unclean stuff afterward :-)

It's done. I only changed the Makefile (added target "datatools" in the
end, and related stuff), but not "build.xml", as I know zero xml/Ant.
I also put subdirectory "datatools" in "docs/" and "META-INF/".

-- 
DOLBEAU Romain               | You won't break me
ENS Cachan / Ker Lann        | You won't make me
Thesard IRISA / CAPS         | You won't take me
dol...@cl...    | -- Judas Priest, 'Blood Red Skies'

> If the various tools you envision have code in common that could benefit
> from being shared between package members, then I agree that datatools
> makes sense.

> If the map editor, creature editor, savegame editor, etc. basically share
> no code, then giving each its own package might be cleaner.

Well, I don't really know yet... but I suspect code reuse will be only
with the main Colossus code. Problem: most of it is package private,
which in itself is good, but prevent reuse from /client in /editors
(that's a good name, isn't it ? :-)

> Ick.  That is a recipe for complete unmaintainablility.  Go ahead and
> check it in, but we're going to need to clean this up by making the
> map/hex classes more generally reusable.  (A good exercise in any case --
> I've wanted to split the GUI from the data better to allow pluggable
> hex/map graphics.)

Yes, it's ugly as hell :-) But the code I reuse is mostly display, that
shouldn't need much change.

Few changes would be needed for reuse ; only take out the code that
use/generate static member (in-class or from an outside class), and put
it in a subclass. I think :-)


I'll put it in /datatools (unless you prefer something else), and you'll
see by yourself if you have the time what I needed to remove to get
something "clean" (I added unclean stuff afterward :-)

> I'm slowly learning that non-final static variables should very rarely be
> used.  They always seem to get in the way of class reuse and are a pain to
> refactor because of all the callers who use them without an instance
> reference.

Yes, static variable are bad, even final, unless they are intilialized
statically (i.e., constant). HexMap contains a static array of BattleHex
that are loaded at startup time, and exclusively used to getHexByLabel()
by outsider. It's not clean, IMHO :-)

-- 
DOLBEAU Romain               | I tell you to enjoy life,
ENS Cachan / Ker Lann        |  I wish I could
Thesard IRISA / CAPS         |        but it's too late.
dol...@cl...    |  -- Black Sabbath, 'Paranoid'

Romain Dolbeau wrote:

>>I like option 3.  helper and tools are a bit generic; maybe maptools?
>> 
> If somedays a Creature editor went in, it might be a bit restrictive :-)
> What about datatools ? (datafilestools is too long :-)


If the various tools you envision have code in common that could benefit from being shared between package members, then I agree that datatools makes sense.


If the map editor, creature editor, savegame editor, etc. basically 
share no code, then giving each its own package might be cleaner.


It's your call since you know the code you're adding.


>>If you had to duplicate a lot of existing code, then we should probably
>>refactor the existing map classes to allow cleaner reuse and eliminate
>>double maintenance.
>> 
> Basically, I copy/pasted Hex (IIRC, because of package private stuff),
> BattleHex and GUIBattleHex (used Creature + HexMap), and HexMap (used
> MasterBoard static stuff and more) and the BattlelandLoader (because
> BattleHex weren't BattleHex anymore)
> 
> Then, I only added some popup-menu to change the content of the
> BuilderHex array, and that was it (input is done once on the command
> line, output goes to stdout... ugly, and should be improved).
> 
> But still, it works better than "vi" :-)

Ick.  That is a recipe for complete unmaintainablility.  Go ahead and check it in, but we're going to need to clean this up by making the map/hex classes more generally reusable.  (A good exercise in any case -- I've wanted to split the GUI from the data better to allow pluggable hex/map graphics.)


I'm slowly learning that non-final static variables should very rarely 
be used.  They always seem to get in the way of class reuse and are a 
pain to refactor because of all the callers who use them without an 
instance reference.

-- 
David Ripton   dr...@wi...

> I like option 3.  helper and tools are a bit generic; maybe maptools?

If somedays a Creature editor went in, it might be a bit restrictive :-)
What about datatools ? (datafilestools is too long :-)

> If you had to duplicate a lot of existing code, then we should probably
> refactor the existing map classes to allow cleaner reuse and eliminate
> double maintenance.

Basically, I copy/pasted Hex (IIRC, because of package private stuff),
BattleHex and GUIBattleHex (used Creature + HexMap), and HexMap (used
MasterBoard static stuff and more) and the BattlelandLoader (because
BattleHex weren't BattleHex anymore)

Then, I only added some popup-menu to change the content of the
BuilderHex array, and that was it (input is done once on the command
line, output goes to stdout... ugly, and should be improved).

But still, it works better than "vi" :-)

-- 
DOLBEAU Romain               | The Gods made Heavy Metal
ENS Cachan / Ker Lann        |     and it's never gonna die
Thesard IRISA / CAPS         |           -- Manowar,
dol...@cl...    |    'The Gods made Heavy Metal'

Romain Dolbeau wrote:


> I've written a graphical tool (quick and ugly) to
> create new Battlelands. It's mostly an extension/
> rewrite of (GUI)BattleHex / HexMap (I couldn't
> use them directly, due to the static loading of
> the default Battlelands and requirement of a Game...)
> 
> Where can/should I put that thing ?
> 
> 1) new module ?
> 2) subdirectory of Colossus ?
> 3) integrated in net/sf/colossus, say as /helper or /tools ?
> 4) elsewhere/nowhere :-) ?

I like option 3.  helper and tools are a bit generic; maybe maptools?

If you had to duplicate a lot of existing code, then we should probably 
refactor the existing map classes to allow cleaner reuse and eliminate 
double maintenance.

-- 
David Ripton   dr...@wi...

hello,

I've written a graphical tool (quick and ugly) to
create new Battlelands. It's mostly an extension/
rewrite of (GUI)BattleHex / HexMap (I couldn't
use them directly, due to the static loading of
the default Battlelands and requirement of a Game...)

Where can/should I put that thing ?

1) new module ?
2) subdirectory of Colossus ?
3) integrated in net/sf/colossus, say as /helper or /tools ?
4) elsewhere/nowhere :-) ?

-- 
DOLBEAU Romain               | The Gods made Heavy Metal                
ENS Cachan / Ker Lann        |     and it's never gonna die             
Thesard IRISA / CAPS         |           -- Manowar,                    
dol...@cl...    |    'The Gods made Heavy Metal'

David Ripton wrote:

> I have no problem with merging in this change.

The same branch has now a sliglty modified
BattleHex::getTerrainName(), more generic :
a non-zero elevation is added after all
terrain name (except 'Tree', where it doesn't
make sens). I've also added 'default:' case
for the color vs. elevation (tower & plain).

If there's no objection, I'll merge the branch
over the next week-end.

-- 
DOLBEAU Romain               |    You won't break me                    
ENS Cachan / Ker Lann        |    You won't make me                     
Thesard IRISA / CAPS         |    You won't take me                     
dol...@cl...    | -- Judas Priest, 'Blood Red Skies'

David Ripton wrote:

> I have no problem with merging in this change.  I suspect that at some
> point we will want to refactor the water dweller support into a
> subclass, but it's not worth the baggage yet since this change is so small.

Well, I think it would be pushing my luck to suggest to
add rivers[1] in 'more_native' ;-)

You shouldn't have linked 'Chee-Wai's titan page', there's
a lot of interesting stuff and links in it :-)

(thinking of it, the change for rivers would be bigger,
as we would need to add some drawing code in GUIBattleHex).

[1] see <http://gjerde.nvg.org/Titan/>

-- 
DOLBEAU Romain               |        Long live rock and roll           
ENS Cachan / Ker Lann        |        Long live rock 'n' roll           
Thesard IRISA / CAPS         |        Long live rock and roll           
dol...@cl...    | -- Rainbow, 'Long Live Rock 'N' Roll'

Romain Dolbeau wrote:

> I've created (yet) another branch, "more_native", that
> 
> 1) replaces the test "is a dragon" by a test isNativeVolcano() ;
> 2) replaces the test "is a warlock" by a test useMagicMissile() ;
> 3) add support for water dwelling creatures (that live only in Bog or
> Lake)
> 4) add the relevant flags in the CRE datafile and the CreatureLoader
> parser.
> 
> Changes are small and in very few files, so if everything test all right
> and no-one disagree (support for water dweller isn't regular Titan...),
> it should be easy to merge.

I have no problem with merging in this change.  I suspect that at some 
point we will want to refactor the water dweller support into a 
subclass, but it's not worth the baggage yet since this change is so small.

-- 
David Ripton   dr...@wi...

I've created (yet) another branch, "more_native", that

1) replaces the test "is a dragon" by a test isNativeVolcano() ;
2) replaces the test "is a warlock" by a test useMagicMissile() ;
3) add support for water dwelling creatures (that live only in Bog or
Lake)
4) add the relevant flags in the CRE datafile and the CreatureLoader
parser.

Changes are small and in very few files, so if everything test all right
and no-one disagree (support for water dweller isn't regular Titan...),
it should be easy to merge.

Any comments welcome,

-- 
DOLBEAU Romain               |
ENS Cachan / Ker Lann        | l'histoire est entierement vraie, puisque
Thesard IRISA / CAPS         |     je l'ai imaginee d'un bout a l'autre
dol...@cl...    |           -- Boris Vian

I've completed the merge og the branch
"packaged_variable_size_masterboard" in HEAD.

Changes are contained between tag "before_pvsm_merge" and
"after_pvsm_merge", so in case of problem this should be easy to
backout.

-- 
DOLBEAU Romain               | Brothers of Metal will always be there
ENS Cachan / Ker Lann        | Standing together with hands in the air
Thesard IRISA / CAPS         |           -- Manowar,
dol...@cl...    |                     'Brothers of Metal'

> i just sent a support request to get that corrected.

Fixed by the SourceForge team.

Thanks folks,

-- 
DOLBEAU Romain               |
ENS Cachan / Ker Lann        | l'histoire est entierement vraie, puisque
Thesard IRISA / CAPS         |     je l'ai imaginee d'un bout a l'autre
dol...@cl...    |           -- Boris Vian