Colossus

On 2009.09.30 20:53:26 +0200, Clemens Katzer wrote:
> I think it would be a good time to make a new bugfix release (with the Balrog
> hangs and "each 50 a Balrog instead of each 300, for example).
> 
> But of course would be nice to get the Tower-rangestrike bug in?

I will attempt a fix for that bug tonight.

-- 
David Ripton    dripton@...

On 2009.09.30 12:41:40 -0700, David Ripton wrote:
> On 2009.09.30 20:53:26 +0200, Clemens Katzer wrote:
> > I think it would be a good time to make a new bugfix release (with the Balrog
> > hangs and "each 50 a Balrog instead of each 300, for example).
> > 
> > But of course would be nice to get the Tower-rangestrike bug in?
> 
> I will attempt a fix for that bug tonight.

Update: I have a failing unit test case.  I do not yet have a clean fix
for it.  It's not trivial but it's not super-hard either.  I expect to
have this fixed by Friday night.

-- 
David Ripton    dripton@...

> > > But of course would be nice to get the Tower-rangestrike bug in?
> > 
> > I will attempt a fix for that bug tonight.
> 
> Update: I have a failing unit test case.  I do not yet have a clean fix
> for it.  It's not trivial but it's not super-hard either.  I expect to
> have this fixed by Friday night.


All right. It's not a big deal is it 1 day or 3 days (but 1 week or 
3 weeks is slightly different story ;-)

BR,
-Cle.


-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

Hi EVERYONE,

WHEN this rangestrike bug is fixed, SHALL I then first make a public test build (contains also various other fixes).

There's only use to do so, if some persons who do NOT pull from SVN anyway
would be willing to do some testing with the public test build within, let's say,
5 days. 

Anyone ??


BR,

Clemens


-------- Original-Nachricht --------
> Datum: Thu, 01 Oct 2009 07:42:27 +0200
> Von: "Clemens Katzer" <lemenssi@...>
> An: David Ripton <dripton@...>, colossus-developers@...
> Betreff: Re: [Colossus-developers] Time for a new release?

> 
> > > > But of course would be nice to get the Tower-rangestrike bug in?
> > > 
> > > I will attempt a fix for that bug tonight.
> > 
> > Update: I have a failing unit test case.  I do not yet have a clean fix
> > for it.  It's not trivial but it's not super-hard either.  I expect to
> > have this fixed by Friday night.
> 
> 
> All right. It's not a big deal is it 1 day or 3 days (but 1 week or 
> 3 weeks is slightly different story ;-)
> 
> BR,
> -Cle.
> 
> 
> -- 
> Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5
> -
> sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9&#45;12, 2009. Register
> now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Colossus-developers mailing list
> Colossus-developers@...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

-- 
Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

Tell me what needs to be done...I'll do it.  Tho I'm busy most of this up coming weekend

 J. Derek Miller M.B.A., E.E.
 http://www.dream-tickets.com




________________________________
From: Clemens Katzer <lemenssi@...>
To: colossus-developers@...
Cc: dripton@...
Sent: Thursday, October 1, 2009 12:47:38 AM
Subject: Would anyone be able/willing to do some testing? Re: [Colossus-developers] Time for a new release?


Hi EVERYONE,

WHEN this rangestrike bug is fixed, SHALL I then first make a public test build (contains also various other fixes).

There's only use to do so, if some persons who do NOT pull from SVN anyway
would be willing to do some testing with the public test build within, let's say,
5 days. 

Anyone ??


BR,

Clemens


-------- Original-Nachricht --------
> Datum: Thu, 01 Oct 2009 07:42:27 +0200
> Von: "Clemens Katzer" <lemenssi@...>
> An: David Ripton <dripton@...>, colossus-developers@...
> Betreff: Re: [Colossus-developers] Time for a new release?

> 
> > > > But of course would be nice to get the Tower-rangestrike bug in?
> > > 
> > > I will attempt a fix for that bug tonight.
> > 
> > Update: I have a failing unit test case.  I do not yet have a clean fix
> > for it.  It's not trivial but it's not super-hard either.  I expect to
> > have this fixed by Friday night.
> 
> 
> All right. It's not a big deal is it 1 day or 3 days (but 1 week or 
> 3 weeks is slightly different story ;-)
> 
> BR,
> -Cle.
> 
> 
> -- 
> Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5
> -
> sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9-12, 2009. Register
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Colossus-developers mailing list
> Colossus-developers@...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

-- 
Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

On 2009.10.01 07:42:27 +0200, Clemens Katzer wrote:
> 
> > > > But of course would be nice to get the Tower-rangestrike bug in?
> > > 
> > > I will attempt a fix for that bug tonight.
> > 
> > Update: I have a failing unit test case.  I do not yet have a clean fix
> > for it.  It's not trivial but it's not super-hard either.  I expect to
> > have this fixed by Friday night.
> 
> All right. It's not a big deal is it 1 day or 3 days (but 1 week or 
> 3 weeks is slightly different story ;-)

The good: I think my fix works.

The bad: The core LOS function now takes even more arguments.  I was
hoping I could avoid this last night, but now I'm convinced I can't.

I'll probably be able to commit it tonight.  Needs another unit test
case and then some manual testing.

P.S. I'm thinking of splitting the big LOS function into four smaller
functions: one for obstacle hexes, one for obstacle characters, one for
cliffs and dunes and slopes, and one for walls.  This would be more
overall code and would probably be slower (but probably not enough
slower to really matter, so the fact that 3 of the 4 functions could be
memoized is probably not important), but each of the functions would be
simpler and would take a more reasonable number of parameters.  But I
don't want to attempt that big change yet.  Maybe after this release.

-- 
David Ripton    dripton@...

> > > Update: I have a failing unit test case.  I do not yet have a clean
> fix
> > > for it.  It's not trivial but it's not super-hard either.  I expect to
> > > have this fixed by Friday night.
> > 
> > All right. It's not a big deal is it 1 day or 3 days (but 1 week or 
> > 3 weeks is slightly different story ;-)
> 
> The good: I think my fix works.

Indeed, sounds good!

 
> The bad: The core LOS function now takes even more arguments.  I was
> hoping I could avoid this last night, but now I'm convinced I can't.

no pain no gain...

:-(

 
> I'll probably be able to commit it tonight.  Needs another unit test
> case and then some manual testing.

ok.

 
> P.S. I'm thinking of splitting the big LOS function into four smaller

Are you referring to this one:

    protected boolean isLOSBlockedDir(BattleHex initialHex,
        BattleHex currentHex, BattleHex finalHex, boolean left,
        int strikeElevation, boolean strikerAtop, boolean strikerAtopCliff,
        boolean midObstacle, boolean midCliff, boolean midChit,
        int totalObstacles)


Somehow I don't see how one could split this and have less arguments.

It's a recursion, and the inner instances need the state knowledge of the
outer - all of it, or not?

I mean, the result depends on combinations of "ok, midchit is ok if
striker is atop cliff" etc., i.e. of information collected in previous hexes.

(perhaps one could transform the whole thing into a loop ?)


So I can imagine one can factor out some parts into smaller methods, but the
overall recursive method would still need all those parameters. So thinks I.

But, I will let you surprise me :o)


> functions: one for obstacle hexes, one for obstacle characters, one for
> cliffs and dunes and slopes, and one for walls.  This would be more
> overall code and would probably be slower (but probably not enough
> slower to really matter, so the fact that 3 of the 4 functions could be
> memoized is probably not important), but each of the functions would be
> simpler and would take a more reasonable number of parameters.  But I
> don't want to attempt that big change yet.  

I agree fully on that.


> Maybe after this release.

ok let's see.

BR,

Clemens

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

On 2009.10.01 21:28:16 +0200, Clemens Katzer wrote:
> > P.S. I'm thinking of splitting the big LOS function into four smaller
> 
> Are you referring to this one:
> 
>     protected boolean isLOSBlockedDir(BattleHex initialHex,
>         BattleHex currentHex, BattleHex finalHex, boolean left,
>         int strikeElevation, boolean strikerAtop, boolean strikerAtopCliff,
>         boolean midObstacle, boolean midCliff, boolean midChit,
>         int totalObstacles)

Yes.

> Somehow I don't see how one could split this and have less arguments.
> 
> It's a recursion, and the inner instances need the state knowledge of the
> outer - all of it, or not?
> 
> I mean, the result depends on combinations of "ok, midchit is ok if
> striker is atop cliff" etc., i.e. of information collected in previous hexes.
> 
> (perhaps one could transform the whole thing into a loop ?)
> 
> 
> So I can imagine one can factor out some parts into smaller methods, but the
> overall recursive method would still need all those parameters. So thinks I.

Split isLOSBlockedDir(11 args now, 14 args after my change)
into 4 simpler recursive methods.

isLOSBlockedDirHex(5 args)
isLOSBlockedDirCreature(6 args)
isLOSBlockedDirCliffDuneSlope(10 args)
isLOSBlockedDirWall(9 args)

Then extract the code that's basically the same in all four into helper
methods.

isLOSBlocked has to call all of them, but can shortcut if any of them
returns true.

-- 
David Ripton    dripton@...

Clemens Katzer wrote:

[...]
>  
>   
>> P.S. I'm thinking of splitting the big LOS function into four smaller
>>     
>
> Are you referring to this one:
>
>     protected boolean isLOSBlockedDir(BattleHex initialHex,
>         BattleHex currentHex, BattleHex finalHex, boolean left,
>         int strikeElevation, boolean strikerAtop, boolean strikerAtopCliff,
>         boolean midObstacle, boolean midCliff, boolean midChit,
>         int totalObstacles)
>
>
> Somehow I don't see how one could split this and have less arguments.
>
> It's a recursion, and the inner instances need the state knowledge of the
> outer - all of it, or not?
>
> I mean, the result depends on combinations of "ok, midchit is ok if
> striker is atop cliff" etc., i.e. of information collected in previous hexes.
>
> (perhaps one could transform the whole thing into a loop ?)
>
>
> So I can imagine one can factor out some parts into smaller methods, but the
> overall recursive method would still need all those parameters. So thinks I.
>   

Just thinking aloud without having looked at the code for a very long time:

The way I would approach the problem is to first generate all possible 
paths between A and B, then evaluate them.
If you have the path (as a List<BattleHex> or maybe a smarter 
collection), then most of those parameters should be easily inferred and 
thus would not need to be passed around.

It also seems a natural split of the full problem: first find the 
Set<List<BattleHex>> of all possible paths (one part of the of game 
rules), then figure out if any of those paths is clear (another related, 
but distinct part of the rules).

But as I said: I'm just grabbing this out of the blue, I might well miss 
some issues.

Peter

On 2009.10.02 07:09:59 +1000, Peter Becker wrote:
> Clemens Katzer wrote:
> 
> [...]
> > 
> >  
> >>P.S. I'm thinking of splitting the big LOS function into four smaller
> >>    
> >
> >Are you referring to this one:
> >
> >    protected boolean isLOSBlockedDir(BattleHex initialHex,
> >        BattleHex currentHex, BattleHex finalHex, boolean left,
> >        int strikeElevation, boolean strikerAtop, boolean strikerAtopCliff,
> >        boolean midObstacle, boolean midCliff, boolean midChit,
> >        int totalObstacles)
> >
> >
> >Somehow I don't see how one could split this and have less arguments.
> >
> >It's a recursion, and the inner instances need the state knowledge of the
> >outer - all of it, or not?
> >
> >I mean, the result depends on combinations of "ok, midchit is ok if
> >striker is atop cliff" etc., i.e. of information collected in previous 
> >hexes.
> >
> >(perhaps one could transform the whole thing into a loop ?)
> >
> >
> >So I can imagine one can factor out some parts into smaller methods, but 
> >the
> >overall recursive method would still need all those parameters. So thinks 
> >I.
> >  
> 
> Just thinking aloud without having looked at the code for a very long time:
> 
> The way I would approach the problem is to first generate all possible 
> paths between A and B, then evaluate them.

Right.  If we split the big method into 4 methods, an obvious next step
to reduce bloat would be to factor out what's common between all of
them, which is the code that iterates over all the hexes between the
striker and the target.

The slight complication is the hex spine case, which means that there
will sometimes be two lists of hexes instead of one.  That's what the
toLeft parameter does.  If the top method instead computes the lists of
lists of hexes first and then passes it in, we can dispense with toLeft.

-- 
David Ripton    dripton@...

On 2009.10.01 07:23:51 -0700, David Ripton wrote:
> The good: I think my fix works.
> 
> The bad: The core LOS function now takes even more arguments.  I was
> hoping I could avoid this last night, but now I'm convinced I can't.
> 
> I'll probably be able to commit it tonight.  Needs another unit test
> case and then some manual testing.

Hmm.  Failing the last assert in testLOS3.  The test says the LOS from
the top of the tower to just outside the tower is correctly blocked, but
the LOS in the other direction is incorrectly clear. 

I don't see the problem yet, but I committed the fix anyway in case
someone else wants to help look at it.  I plan to resume working on this
tomorrow night.

-- 
David Ripton    dripton@...

> >
> > So I can imagine one can factor out some parts into smaller methods, but
> the
> > overall recursive method would still need all those parameters. So
> thinks I.
> >   
> 
> Just thinking aloud without having looked at the code for a very long
> time:
> 
> The way I would approach the problem is to first generate all possible 
> paths between A and B, then evaluate them.

That is done already: if it's a "along spine" case, the method is called
twice anyway:

        {
            // Hexspine; try both sides.
            return (isLOSBlockedDir(hex1, hex1, hex2, true, strikeElevation,
                false, false, false, false, false, 0) && isLOSBlockedDir(hex1,
                hex1, hex2, false, strikeElevation, false, false, false,
                false, false, 0));
        }


So it is really just a pure "one way" recursion, not even backtracking.

Thus transforming it into a loop should be doable and several of those parameters
could then be local variables.


BR,

Clemens


-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

I'll test it this weekend. Either  SVN or  public test build would work, just tell me when to get it. Else I just play the latest release via  jnlp.

cl




________________________________
From: Clemens Katzer <lemenssi@...>
To: colossus-developers@...
Cc: dripton@...
Sent: Wednesday, September 30, 2009 10:47:38 PM
Subject: Would anyone be able/willing to do some testing? Re: [Colossus-developers] Time for a new release?


Hi EVERYONE,

WHEN this rangestrike bug is fixed, SHALL I then first make a public test build (contains also various other fixes).

There's only use to do so, if some persons who do NOT pull from SVN anyway
would be willing to do some testing with the public test build within, let's say,
5 days. 

Anyone ??


BR,

Clemens


-------- Original-Nachricht --------
> Datum: Thu, 01 Oct 2009 07:42:27 +0200
> Von: "Clemens Katzer" <lemenssi@...>
> An: David Ripton <dripton@...>, colossus-developers@...
> Betreff: Re: [Colossus-developers] Time for a new release?

> 
> > > > But of course would be nice to get the Tower-rangestrike bug in?
> > > 
> > > I will attempt a fix for that bug tonight.
> > 
> > Update: I have a failing unit test case.  I do not yet have a clean fix
> > for it.  It's not trivial but it's not super-hard either.  I expect to
> > have this fixed by Friday night.
> 
> 
> All right. It's not a big deal is it 1 day or 3 days (but 1 week or 
> 3 weeks is slightly different story ;-)
> 
> BR,
> -Cle.
> 
> 
> -- 
> Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5
> -
> sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9-12, 2009. Register
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Colossus-developers mailing list
> Colossus-developers@...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

-- 
Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

Hi all,

I've made the new Public Testing Build (0.9.3beta).

Right on the top of project main page is now also a link to the
"Public Testing Build" Wiki page.

Thanks to David for fixing the wall rangestrike bug now so quickly (due to my nagging... ;-)

Thanks to the volunteers - that encouraged me to do this test build!

No hurry with the testing - I think I will let this be like that at least
a week or so before considering the real next release.


Enjoy & Best Regards,

Clemens

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

For clarification:

> Right on the top of project main page is now also a link to the

I meant that one here:

http://colossus.sourceforge.net/

Perhaps "Colossus home page" would have been better description... :-/

BR,

Clemens

-------- Original-Nachricht --------
> Datum: Fri, 02 Oct 2009 22:06:18 +0200
> Von: "Clemens Katzer" <lemenssi@...>
> An: colossus-developers@...
> Betreff: [Colossus-developers] Public Testing Build (0.9.3beta) available!

> 
> Hi all,
> 
> I've made the new Public Testing Build (0.9.3beta).
> 
> Right on the top of project main page is now also a link to the
> "Public Testing Build" Wiki page.
> 
> Thanks to David for fixing the wall rangestrike bug now so quickly (due to
> my nagging... ;-)
> 
> Thanks to the volunteers - that encouraged me to do this test build!
> 
> No hurry with the testing - I think I will let this be like that at least
> a week or so before considering the real next release.
> 
> 
> Enjoy & Best Regards,
> 
> Clemens
> 
> -- 
> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9&#45;12, 2009. Register
> now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Colossus-developers mailing list
> Colossus-developers@...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

-- 
Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

On 2009.10.01 22:06:38 -0700, David Ripton wrote:
> On 2009.10.01 07:23:51 -0700, David Ripton wrote:
> > The good: I think my fix works.
> > 
> > The bad: The core LOS function now takes even more arguments.  I was
> > hoping I could avoid this last night, but now I'm convinced I can't.
> > 
> > I'll probably be able to commit it tonight.  Needs another unit test
> > case and then some manual testing.
> 
> Hmm.  Failing the last assert in testLOS3.  The test says the LOS from
> the top of the tower to just outside the tower is correctly blocked, but
> the LOS in the other direction is incorrectly clear. 
> 
> I don't see the problem yet, but I committed the fix anyway in case
> someone else wants to help look at it.  I plan to resume working on this
> tomorrow night.

I checked in a fix.  The unit test passes now.

If anyone has time, please test some tower battles with rangestrikers
and pay close attention to line of sight.  If you're not a Titan rules
expert the following might help:

* Top of tower to just outside the tower should be blocked.  
* Top of tower to further outside the tower should be clear.  (Of course
you need skill 4 to be able to shoot that far.)
* Lower level of tower across another lower-tower hex then a wall to
outside the tower (either adjacent or not) should be blocked.
* Lower level of tower across its own hex's wall to outside the tower
should be clear.
* Warlocks ignore LOS as usual.

Of course our unit tests should handle all that but we've been burned
twice now so I don't have much confidence in them.

-- 
David Ripton    dripton@...

On Fri, Oct 02, 2009 at 22:06:18 +0200,
  Clemens Katzer <lemenssi@...> wrote:
> 
> I've made the new Public Testing Build (0.9.3beta).

I'll do some testing this weekend. I'll probably end up waiting for the
nonbeta to push a new Fedora release. Rawhide is currently frozen and
pushing a beta to a release needs to be done carefully.
I was upgrading the OS on my mail server this week and ended up having a
lot of email delayed. Otherwise I would have chimed in sooner.
Thanks for the fixing and nagging guys!

> > I've made the new Public Testing Build (0.9.3beta).
> 
> I'll do some testing this weekend. I'll probably end up waiting for the
> nonbeta to push a new Fedora release.

Yes, I think that would be better.

> Rawhide is currently frozen and pushing a beta 

earlier we didn't even call public testing builds beta...

- in fact whole Colossus was all it's lifetime "beta".

BTW it's now categorized "stable/productive", I hope noone minds.

> to a release needs to be done carefully.
> I was upgrading the OS on my mail server this week 

Ah, that's why it was so quiet... ? ;-)

> and ended up having a
> lot of email delayed. Otherwise I would have chimed in sooner.
> Thanks for the fixing and nagging guys!

-Cle.


-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

On Sat, Oct 03, 2009 at 02:44:39 -0500,
  Bruno Wolff III <bruno@...> wrote:
> On Fri, Oct 02, 2009 at 22:06:18 +0200,
>   Clemens Katzer <lemenssi@...> wrote:
> > 
> > I've made the new Public Testing Build (0.9.3beta).
> 
> I'll do some testing this weekend. I'll probably end up waiting for the

I tried out beta2 a bit. I played a few full games and did a bit with
Keith's tower test and didn't notice any regressions.

> I tried out beta2 a bit. I played a few full games and did a bit with
> Keith's tower test and didn't notice any regressions.

Good to know! Thanks!

BR,

Clemens

-------- Original-Nachricht --------
> Datum: Sat, 10 Oct 2009 14:31:17 -0500
> Von: Bruno Wolff III <bruno@...>
> An: Clemens Katzer <lemenssi@...>
> CC: colossus-developers@...
> Betreff: Re: [Colossus-developers] Public Testing Build (0.9.3beta) available!

> On Sat, Oct 03, 2009 at 02:44:39 -0500,
>   Bruno Wolff III <bruno@...> wrote:
> > On Fri, Oct 02, 2009 at 22:06:18 +0200,
> >   Clemens Katzer <lemenssi@...> wrote:
> > > 
> > > I've made the new Public Testing Build (0.9.3beta).
> > 
> > I'll do some testing this weekend. I'll probably end up waiting for the
> 
> I tried out beta2 a bit. I played a few full games and did a bit with
> Keith's tower test and didn't notice any regressions.

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser