colossus-developers Mailing List for Colossus (Page 8)

... except that the wiki pages will disappear soon / would need to be 
migrated somehow...

But I am happy if someone passes on good hints. I had more or less 
forgotten that myself,
and since he didn't find that page, others might face the same
(which says something about the navigationness of our documentations 
;-)


I've always been in favor of the "better too much info than too few" 
approach.
Those who know this already can easily skip it. Those who don't for 
them it probably helps.

(I personally can easily ignore the superfluous parts, and/or match 
them against
my view of the matter, but if the text is missing essential 
information, I will
easily not, or wrongly, understand the given info.)

BR,
Clemens


On 2012-11-26 07:27, Barrie Treloar wrote:
> On Mon, Nov 26, 2012 at 3:36 PM,  <pe...@pe...> wrote:
>> I don't want to spoil your sense of achievement, but:
>> 
>> http://sourceforge.net/apps/trac/colossus/wiki/EclipseSetup#Usingassertionsandlogging
>
> :)
>
> Another good reason Craig should be updating the wiki with his 
> learnings.
>
> 
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, 
> vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

On Mon, Nov 26, 2012 at 3:36 PM,  <pe...@pe...> wrote:
> I don't want to spoil your sense of achievement, but:
> http://sourceforge.net/apps/trac/colossus/wiki/EclipseSetup#Usingassertionsandlogging

:)

Another good reason Craig should be updating the wiki with his learnings.

I don't want to spoil your sense of achievement, but:  
http://sourceforge.net/apps/trac/colossus/wiki/EclipseSetup#Usingassertionsandlogging


Quoting Craig Lish <the...@gm...>:

> I just learned this about java.util.logging and eclipse (I'm used to log4j
> or slf4j) so figured I'd pass it on.
>
> Adding -Djava.util.logging.config.file=logging.properties to the vm
> arguments will cause the eclipse runner to actually use the logging
> properties. You can do this for each run configuration or just add it to
> the vm args on the jre (window->preferences->Installed JREs->(edit
> button)->Default VM arguments). You can point to any properties you want,
> so you could have a personal colossus.logging.properties that lives outside
> the source tree or is on svn ignore.
>
> The log is much nicer! I wondered how you could restrict width to 80
> columns yet have such a horribly verbose logging output ;o)
>
> I'd suggest adding '-ea' as well to activate the asserts.
>
> cl

I just learned this about java.util.logging and eclipse (I'm used to log4j
or slf4j) so figured I'd pass it on.

Adding -Djava.util.logging.config.file=logging.properties to the vm
arguments will cause the eclipse runner to actually use the logging
properties. You can do this for each run configuration or just add it to
the vm args on the jre (window->preferences->Installed JREs->(edit
button)->Default VM arguments). You can point to any properties you want,
so you could have a personal colossus.logging.properties that lives outside
the source tree or is on svn ignore.

The log is much nicer! I wondered how you could restrict width to 80
columns yet have such a horribly verbose logging output ;o)

I'd suggest adding '-ea' as well to activate the asserts.

cl

I have no objections for the additional recruit info, as long as it 
does not bloat up the data too much.

No objections from my side to the Junit change. In fact sounds like a 
good idea to me. I downloaded the 4.9, all the normal unit tests went 
fine. So I replaced the checkedin libs/junit.jar with the 4.9 one in 
your branch.

Some of the functional tests (/trunk1/core/src/functest/java) fail with 
both old and new junit. Seems I didn't run the tests too often during 
recent changes :-/
Have to look into it one day...

BR,
Clemens



On 2012-11-13 05:51, Craig Lish wrote:
> I just checked in a change on my branch to RecruitingSubTree that
> preserves the recruit ancestor information. We have it and drop it on
> the floor while building the tree. I created a RecruitingInfo object
> to store the count and isAncestor information and map
> RecruiterAndRecruit to that instead of an Integer. I didn't add this,
> but instead of just returning the count we could return a
> RecruitingInfo from getRecruiterCount type calls, or the caller could
> ask for non-ancestor recruits in getAllRecruits type calls. My code
> just asks IRecruiting.isRegularAncestorOf(recruiter, recruit) on the
> recruits I get back.
>
> This came up while working on my AI, but it's a common need during
> recruiting and I think is a good direction to go. If you don't like 
> it
> the reversion is easy, but the patch wasn't as nice to read as a diff
> on the branch so I checked it in for you. (aren't I kind? :o)
>
> I wan't to upgrade to JUnit 4.9. I'm building in JDK5 now and simply
> replacing /libs/junit.jar worked for me (no code or project changes).
> All the JUnit 3 tests that extend TestCase will continue to work as
> before, but we can now use the JUnit4 runner if we need (don't extend
> TestCase, add @Test to your public void no-param testMethod, select
> JUnit4 in your run configuration). I mainly want the @RunWith tag for
> Parameterized tests.
>
> thoughts? :o)
>
> cl

When I picked c_...@ya... as a brand new dev the underscore wasn't an
issue. 20 years of trying to explain wtf an underscore is enough, it's time
for a change.

the...@gm...

Not to be presumptuous, 'aclish' was taken and there's a 6 char minimum. My
other option this late in the game was ur...@gm..., but I can't give
that to muggles ;o)

cl

P.s. urn:guid is a Universal Resource Name Guaranteed Unique Identifier,
which *is* just what I was looking for...

I just checked in a change on my branch to RecruitingSubTree that preserves the recruit ancestor information. We have it and drop it on the floor while building the tree. I created a RecruitingInfo object to store the count and isAncestor information and map RecruiterAndRecruit to that instead of an Integer. I didn't add this, but instead of just returning the count we could return a RecruitingInfo from getRecruiterCount type calls, or the caller could ask for non-ancestor recruits in getAllRecruits type calls. My code just asks IRecruiting.isRegularAncestorOf(recruiter, recruit) on the recruits I get back.


This came up while working on my AI, but it's a common need during recruiting and I think is a good direction to go. If you don't like it the reversion is easy, but the patch wasn't as nice to read as a diff on the branch so I checked it in for you. (aren't I kind? :o)

I wan't to upgrade to JUnit 4.9. I'm building in JDK5 now and simply replacing /libs/junit.jar worked for me (no code or project changes). All the JUnit 3 tests that extend TestCase will continue to work as before, but we can now use the JUnit4 runner if we need (don't extend TestCase, add @Test to your public void no-param testMethod, select JUnit4 in your run configuration). I mainly want the @RunWith tag for Parameterized tests.

thoughts? :o)

cl

That's exactly my concern, and creating a new game seemed too heavy if I could avoid it.
 
I made a simple LegionBot to extend Legion. The player, client, and games are not aware of this legion's existence. Any creatures added to the legion are strictly local. The markerId is just a reference string that is never validated or consumed (I pass "Weights00" for example). The LegionBot lifespan is contained within a single call during client initialization. Moving away from LegionClientSide isolated him nicely :o)
 
cl


----- Original Message -----
> From: Peter Becker <pe...@pe...>
> To: col...@li...
> Cc: 
> Sent: Tuesday, November 6, 2012 12:22 AM
> Subject: Re: [Colossus-developers] bots
> 
> One extra little thought: even if you want to do this with a Legion 
> instance, it probably should be part of it's own little Game. Otherwise 
> you might clash with the state of the rest of the game. What you do 
> sounds like a special little game to explore the variant.
> 
>   Peter
> 
> 
> On 6/11/2012 3:07 PM, Craig Lish wrote:
>> hah! :o) Sometimes it just takes telling someone for the solution to come 
> to you. I can change my code to act on a Legion instead of a LegionClientSide. 
> The only thing I need from client side was the player, and I just test the class 
> before casting in my AI (it'll always be client side).
>> 
>> I still think LegionClientSide wants to use the Creatures list. I don't 
> know the full plans for Creature, but I think we should extend CreatureType not 
> contain it. That way we store a list of CreatureType, which nearly everyone 
> needs (that's not still on strings ;o). Or we could store CreatureType and 
> have a CreatureIterator that wraps them when someone needs them. I don't 
> know what else was planned for the Creature though.
>> 
>> Sorry about the lengthy false alarm. I think I'm ok :oP
>> 
>> cl
>> 
>> 
>> 
>> 
>> ----- Original Message -----
>>> From: Craig Lish <c_...@ya...>
>>> To: colossus-dev <col...@li...>
>>> Cc:
>>> Sent: Monday, November 5, 2012 8:27 PM
>>> Subject: [Colossus-developers] bots
>>> 
>>> 
>>> 
>>> Here's an interesting situation.
>>> 
>>> 
>>> My AI uses recruitment weights that try to reflect the relative 
> recruitment
>>> difficulty for the board layout (think about Griffon vs Serpent in 
> Default vs
>>> Abyssal6, for example). It calculates those weights during init() by 
> walking the
>>> board (it has no eyes ;o). AI.init is called in Client.initBoard, right 
> after
>>> the movement is created and before the gui initializes, so the server 
> hasn't
>>> updated everyone yet. Anyway, my problem is that I need a 
> LegionClientSide for
>>> movement and that legion needs to initialize PredictSplits in the 
> player. In my
>>> testing I have been using the client's current player, creating a 
> legion for
>>> him, initializing predict splits, walking the board, and then clearing 
> predict
>>> splits -- a merciless hack but it got me going (this is not in the 
> branch code).
>>> I'm looking at how it might be done correctly.
>>> 
>>> I just need a temporary legion that the player, client, and games 
> don't know
>>> about -- I don't think that's "wrong" as long as he
>>> doesn't effect client/player/game state. Maybe PredictSplits is the 
> problem.
>>> If LegionClientSide started using the Creatures list then the player
>>> wouldn't have to know about the temporary legion. Man-handling 
> PredictSplits
>>> can't be the right way to go. I could perform the calculations 
> offline and
>>> serialize the result for each variant, but I think that would be clumsy
>>> and brittle. The process is fast and happens once per 
> CalculatingAI.init. It
>>> could be shared across local clients through the variant but it's 
> AI
>>> specific so doesn't really belong there.
>>> 
>>> 
>>> I was going to create a PlayerClientSide and just not add him to the
>>> game, but there are comments that the constructor should fully
>>> initialize the PlayerClientSide and that would be bad for me. The
>>> constructor is protected so I can't access it from my AI package 
> anyway. So
>>> then I thought I'd extend it and make a PlayerClientSideBot that is
>>> appropriately limited, throws exceptions when it's called in 
> invalid
>>> ways, times how long it lives, etc, but PlayerClientSide is final. I 
> realize I
>>> could (try to ;o) change the signatures, but I don't think a ghost 
> player is
>>> the way to go. I don't need a player, just a legion, and not even 
> an
>>> official legion.
>>> 
>>> I think that a legion should be able to function independent of the 
> player, that
>>> the LegionClientSide code wants to use the Creatures list, and that 
> creating a
>>> temporary legion during init to look at the board doesn't break any 
> rules.
>>> What do you think? :o)
>>> 
>>> cl
>>> 
>>> 
>>> 
> ------------------------------------------------------------------------------
>>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>>> Stay in control, update software, and manage PCs from one command 
> center
>>> Diagnose problems and improve visibility into emerging IT issues
>>> Automate, monitor and manage. Do more in less time with Central
>>> http://p.sf.net/sfu/logmein12331_d2d
>>> _______________________________________________
>>> Colossus-developers mailing list
>>> Col...@li...
>>> https://lists.sourceforge.net/lists/listinfo/colossus-developers
>>> 
>> 
> ------------------------------------------------------------------------------
>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>> Stay in control, update software, and manage PCs from one command center
>> Diagnose problems and improve visibility into emerging IT issues
>> Automate, monitor and manage. Do more in less time with Central
>> http://p.sf.net/sfu/logmein12331_d2d
>> _______________________________________________
>> Colossus-developers mailing list
>> Col...@li...
>> https://lists.sourceforge.net/lists/listinfo/colossus-developers
> 
> 
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers
> 

Shrodinger didn't know the solution before explaining it to the cat. Now thats a good kitty ;o)

I'm glad that the visibility is tight in the code, it keeps me from going down the wrong path. My goal while writing the AI is not to touch any files outside my package.

I found the utility of creature on the server side last night. I'd retract most of what I said if I could :oP I'm happy with the LegionBot solution, it worked out really well :o)

cl

On Nov 5, 2012, at 11:38 PM, Clemens <cl...@cl...> wrote:

> 
>> As long as you are not Schrodinger, the cat is fine to talk to.
>> Otherwise it will not help you choose.
> 
> :o)
> 
> Well you might talk to the cat, but you shouldn't look at it at the
> same time, wasn't it so?
> 
> 
> Regarding the original question: do as you see fit. E.g. if you'd
> need a special Legion which is more than a Legion but less than a
> LegionClientSide, feel free to change inheritance and plug it in 
> between.
> 
>> ... but it's protected
> 
> Or, also, that a class or methods is final right now does not indicate
> somebody has decided it's a bad thing to further extend it; it merely
> signals "right now there's nobody extending it." .
> Somewhere in the Readme or other docs David has stated that.
> 
> Whether to use Creature or CreatureType - I couldn't follow your whole
> explanation but if it makes sense to change it, fine. It might be the
> "wrong one" merely for hysterical raisins (refactoring not progressed
> far enough to get it right).
> 
> The primary problem is, that server side legions have precise list of
> creatures whereas client side legions have a predict split tree 
> instead;
> (I think they are converted into real creatures only in a battle, since
> at that point all of them are certain.)
> 
> Don't know whether that additional info helped or just added to the
> confusion :)
> 
> BR,
> Clemens
> 
> 
> 
> On 2012-11-06 07:39, James Henning wrote:
>> As long as you are not Schrodinger, the cat is fine to talk to.
>> Otherwise it will not help you choose.
>> 
>>> -------------------------
>>> FROM: Barrie Treloar <bae...@gm...>
>>> TO: Craig Lish <c_...@ya...>
>>> CC: colossus-dev <col...@li...>
>>> SENT: Monday, November 5, 2012 11:16 PM
>>> SUBJECT: Re: [Colossus-developers] bots
>>> 
>>> On Tue, Nov 6, 2012 at 3:37 PM, Craig Lish <c_...@ya... [1]>
>>> wrote:
>>> 
>>>> hah! :o) Sometimes it just takes telling someone for the solution
>>>> to come to you. I
>>> 
>>> I think that's one of the things a decent programmer learns.
>>> Even if no one is listening, or its the cat!
>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>>> Stay in control, update software, and manage PCs from one command
>>> center
>>> Diagnose problems and improve visibility into emerging IT issues
>>> Automate, monitor and manage. Do more in less time with Central
>>> http://p.sf.net/sfu/logmein12331_d2d [2]
>>> _______________________________________________
>>> Colossus-developers mailing list
>>> Col...@li... [3]
>>> https://lists.sourceforge.net/lists/listinfo/colossus-developers [4]
>> 
>> 
>> Links:
>> ------
>> [1] mailto:c_...@ya...
>> [2] http://p.sf.net/sfu/logmein12331_d2d
>> [3] mailto:Col...@li...
>> [4] https://lists.sourceforge.net/lists/listinfo/colossus-developers
> 
> 
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

One extra little thought: even if you want to do this with a Legion 
instance, it probably should be part of it's own little Game. Otherwise 
you might clash with the state of the rest of the game. What you do 
sounds like a special little game to explore the variant.

   Peter


On 6/11/2012 3:07 PM, Craig Lish wrote:
> hah! :o) Sometimes it just takes telling someone for the solution to come to you. I can change my code to act on a Legion instead of a LegionClientSide. The only thing I need from client side was the player, and I just test the class before casting in my AI (it'll always be client side).
>
> I still think LegionClientSide wants to use the Creatures list. I don't know the full plans for Creature, but I think we should extend CreatureType not contain it. That way we store a list of CreatureType, which nearly everyone needs (that's not still on strings ;o). Or we could store CreatureType and have a CreatureIterator that wraps them when someone needs them. I don't know what else was planned for the Creature though.
>
> Sorry about the lengthy false alarm. I think I'm ok :oP
>
> cl
>
>
>
>
> ----- Original Message -----
>> From: Craig Lish <c_...@ya...>
>> To: colossus-dev <col...@li...>
>> Cc:
>> Sent: Monday, November 5, 2012 8:27 PM
>> Subject: [Colossus-developers] bots
>>
>>
>>
>> Here's an interesting situation.
>>
>>
>> My AI uses recruitment weights that try to reflect the relative recruitment
>> difficulty for the board layout (think about Griffon vs Serpent in Default vs
>> Abyssal6, for example). It calculates those weights during init() by walking the
>> board (it has no eyes ;o). AI.init is called in Client.initBoard, right after
>> the movement is created and before the gui initializes, so the server hasn't
>> updated everyone yet. Anyway, my problem is that I need a LegionClientSide for
>> movement and that legion needs to initialize PredictSplits in the player. In my
>> testing I have been using the client's current player, creating a legion for
>> him, initializing predict splits, walking the board, and then clearing predict
>> splits -- a merciless hack but it got me going (this is not in the branch code).
>> I'm looking at how it might be done correctly.
>>
>> I just need a temporary legion that the player, client, and games don't know
>> about -- I don't think that's "wrong" as long as he
>> doesn't effect client/player/game state. Maybe PredictSplits is the problem.
>> If LegionClientSide started using the Creatures list then the player
>> wouldn't have to know about the temporary legion. Man-handling PredictSplits
>> can't be the right way to go. I could perform the calculations offline and
>> serialize the result for each variant, but I think that would be clumsy
>> and brittle. The process is fast and happens once per CalculatingAI.init. It
>> could be shared across local clients through the variant but it's AI
>> specific so doesn't really belong there.
>>
>>
>> I was going to create a PlayerClientSide and just not add him to the
>> game, but there are comments that the constructor should fully
>> initialize the PlayerClientSide and that would be bad for me. The
>> constructor is protected so I can't access it from my AI package anyway. So
>> then I thought I'd extend it and make a PlayerClientSideBot that is
>> appropriately limited, throws exceptions when it's called in invalid
>> ways, times how long it lives, etc, but PlayerClientSide is final. I realize I
>> could (try to ;o) change the signatures, but I don't think a ghost player is
>> the way to go. I don't need a player, just a legion, and not even an
>> official legion.
>>
>> I think that a legion should be able to function independent of the player, that
>> the LegionClientSide code wants to use the Creatures list, and that creating a
>> temporary legion during init to look at the board doesn't break any rules.
>> What do you think? :o)
>>
>> cl
>>
>>
>> ------------------------------------------------------------------------------
>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>> Stay in control, update software, and manage PCs from one command center
>> Diagnose problems and improve visibility into emerging IT issues
>> Automate, monitor and manage. Do more in less time with Central
>> http://p.sf.net/sfu/logmein12331_d2d
>> _______________________________________________
>> Colossus-developers mailing list
>> Col...@li...
>> https://lists.sourceforge.net/lists/listinfo/colossus-developers
>>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

> As long as you are not Schrodinger, the cat is fine to talk to.
> Otherwise it will not help you choose.

:o)

Well you might talk to the cat, but you shouldn't look at it at the
same time, wasn't it so?


Regarding the original question: do as you see fit. E.g. if you'd
need a special Legion which is more than a Legion but less than a
LegionClientSide, feel free to change inheritance and plug it in 
between.

>... but it's protected

Or, also, that a class or methods is final right now does not indicate
somebody has decided it's a bad thing to further extend it; it merely
signals "right now there's nobody extending it." .
Somewhere in the Readme or other docs David has stated that.

Whether to use Creature or CreatureType - I couldn't follow your whole
explanation but if it makes sense to change it, fine. It might be the
"wrong one" merely for hysterical raisins (refactoring not progressed
far enough to get it right).

The primary problem is, that server side legions have precise list of
creatures whereas client side legions have a predict split tree 
instead;
(I think they are converted into real creatures only in a battle, since
at that point all of them are certain.)

Don't know whether that additional info helped or just added to the
confusion :)

BR,
Clemens



On 2012-11-06 07:39, James Henning wrote:
> As long as you are not Schrodinger, the cat is fine to talk to.
> Otherwise it will not help you choose.
>
>> -------------------------
>> FROM: Barrie Treloar <bae...@gm...>
>> TO: Craig Lish <c_...@ya...>
>> CC: colossus-dev <col...@li...>
>> SENT: Monday, November 5, 2012 11:16 PM
>> SUBJECT: Re: [Colossus-developers] bots
>>
>> On Tue, Nov 6, 2012 at 3:37 PM, Craig Lish <c_...@ya... [1]>
>> wrote:
>>
>>> hah! :o) Sometimes it just takes telling someone for the solution
>>> to come to you. I
>>
>> I think that's one of the things a decent programmer learns.
>> Even if no one is listening, or its the cat!
>>
>>> 
>>> ------------------------------------------------------------------------------
>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>> Stay in control, update software, and manage PCs from one command
>> center
>> Diagnose problems and improve visibility into emerging IT issues
>> Automate, monitor and manage. Do more in less time with Central
>> http://p.sf.net/sfu/logmein12331_d2d [2]
>> _______________________________________________
>> Colossus-developers mailing list
>> Col...@li... [3]
>> https://lists.sourceforge.net/lists/listinfo/colossus-developers [4]
>
>
> Links:
> ------
> [1] mailto:c_...@ya...
> [2] http://p.sf.net/sfu/logmein12331_d2d
> [3] mailto:Col...@li...
> [4] https://lists.sourceforge.net/lists/listinfo/colossus-developers

As long as you are not Schrodinger, the cat is fine to talk to.  Otherwise it will not help you choose.



>________________________________
> From: Barrie Treloar <bae...@gm...>
>To: Craig Lish <c_...@ya...> 
>Cc: colossus-dev <col...@li...> 
>Sent: Monday, November 5, 2012 11:16 PM
>Subject: Re: [Colossus-developers] bots
> 
>
>On Tue, Nov 6, 2012 at 3:37 PM, Craig Lish <c_...@ya...> wrote:
>
>hah! :o) Sometimes it just takes telling someone for the solution to come to you. I
>>
>I think that's one of the things a decent programmer learns.
>Even if no one is listening, or its the cat!
>
>
>------------------------------------------------------------------------------
>LogMeIn Central: Instant, anywhere, Remote PC access and management.
>Stay in control, update software, and manage PCs from one command center
>Diagnose problems and improve visibility into emerging IT issues
>Automate, monitor and manage. Do more in less time with Central
>http://p.sf.net/sfu/logmein12331_d2d
>_______________________________________________
>Colossus-developers mailing list
>Col...@li...
>https://lists.sourceforge.net/lists/listinfo/colossus-developers
>
>
>

On Tue, Nov 6, 2012 at 3:37 PM, Craig Lish <c_...@ya...> wrote:

> hah! :o) Sometimes it just takes telling someone for the solution to come
> to you. I
>

I think that's one of the things a decent programmer learns.
Even if no one is listening, or its the cat!

hah! :o) Sometimes it just takes telling someone for the solution to come to you. I can change my code to act on a Legion instead of a LegionClientSide. The only thing I need from client side was the player, and I just test the class before casting in my AI (it'll always be client side).

I still think LegionClientSide wants to use the Creatures list. I don't know the full plans for Creature, but I think we should extend CreatureType not contain it. That way we store a list of CreatureType, which nearly everyone needs (that's not still on strings ;o). Or we could store CreatureType and have a CreatureIterator that wraps them when someone needs them. I don't know what else was planned for the Creature though.

Sorry about the lengthy false alarm. I think I'm ok :oP

cl




----- Original Message -----
> From: Craig Lish <c_...@ya...>
> To: colossus-dev <col...@li...>
> Cc: 
> Sent: Monday, November 5, 2012 8:27 PM
> Subject: [Colossus-developers] bots
> 
> 
> 
> Here's an interesting situation.
> 
> 
> My AI uses recruitment weights that try to reflect the relative recruitment 
> difficulty for the board layout (think about Griffon vs Serpent in Default vs 
> Abyssal6, for example). It calculates those weights during init() by walking the 
> board (it has no eyes ;o). AI.init is called in Client.initBoard, right after 
> the movement is created and before the gui initializes, so the server hasn't 
> updated everyone yet. Anyway, my problem is that I need a LegionClientSide for 
> movement and that legion needs to initialize PredictSplits in the player. In my 
> testing I have been using the client's current player, creating a legion for 
> him, initializing predict splits, walking the board, and then clearing predict 
> splits -- a merciless hack but it got me going (this is not in the branch code). 
> I'm looking at how it might be done correctly.
> 
> I just need a temporary legion that the player, client, and games don't know 
> about -- I don't think that's "wrong" as long as he 
> doesn't effect client/player/game state. Maybe PredictSplits is the problem. 
> If LegionClientSide started using the Creatures list then the player 
> wouldn't have to know about the temporary legion. Man-handling PredictSplits 
> can't be the right way to go. I could perform the calculations offline and 
> serialize the result for each variant, but I think that would be clumsy 
> and brittle. The process is fast and happens once per CalculatingAI.init. It 
> could be shared across local clients through the variant but it's AI 
> specific so doesn't really belong there.
> 
> 
> I was going to create a PlayerClientSide and just not add him to the 
> game, but there are comments that the constructor should fully 
> initialize the PlayerClientSide and that would be bad for me. The 
> constructor is protected so I can't access it from my AI package anyway. So 
> then I thought I'd extend it and make a PlayerClientSideBot that is 
> appropriately limited, throws exceptions when it's called in invalid 
> ways, times how long it lives, etc, but PlayerClientSide is final. I realize I 
> could (try to ;o) change the signatures, but I don't think a ghost player is 
> the way to go. I don't need a player, just a legion, and not even an 
> official legion.
> 
> I think that a legion should be able to function independent of the player, that 
> the LegionClientSide code wants to use the Creatures list, and that creating a 
> temporary legion during init to look at the board doesn't break any rules. 
> What do you think? :o)
> 
> cl
> 
> 
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers
> 

Here's an interesting situation.


My AI uses recruitment weights that try to reflect the relative recruitment difficulty for the board layout (think about Griffon vs Serpent in Default vs Abyssal6, for example). It calculates those weights during init() by walking the board (it has no eyes ;o). AI.init is called in Client.initBoard, right after the movement is created and before the gui initializes, so the server hasn't updated everyone yet. Anyway, my problem is that I need a LegionClientSide for movement and that legion needs to initialize PredictSplits in the player. In my testing I have been using the client's current player, creating a legion for him, initializing predict splits, walking the board, and then clearing predict splits -- a merciless hack but it got me going (this is not in the branch code). I'm looking at how it might be done correctly.

I just need a temporary legion that the player, client, and games don't know about -- I don't think that's "wrong" as long as he doesn't effect client/player/game state. Maybe PredictSplits is the problem. If LegionClientSide started using the Creatures list then the player wouldn't have to know about the temporary legion. Man-handling PredictSplits can't be the right way to go. I could perform the calculations offline and serialize the result for each variant, but I think that would be clumsy and brittle. The process is fast and happens once per CalculatingAI.init. It could be shared across local clients through the variant but it's AI specific so doesn't really belong there.


I was going to create a PlayerClientSide and just not add him to the 
game, but there are comments that the constructor should fully 
initialize the PlayerClientSide and that would be bad for me. The 
constructor is protected so I can't access it from my AI package anyway. So then I thought I'd extend it and make a PlayerClientSideBot that is 
appropriately limited, throws exceptions when it's called in invalid 
ways, times how long it lives, etc, but PlayerClientSide is final. I realize I could (try to ;o) change the signatures, but I don't think a ghost player is the way to go. I don't need a player, just a legion, and not even an official legion.

I think that a legion should be able to function independent of the player, that the LegionClientSide code wants to use the Creatures list, and that creating a temporary legion during init to look at the board doesn't break any rules. What do you think? :o)

cl

As I said, I don't think you need to feel sorry. I know that the 
codebase is not exactly maintenance friendly. In fact I am rather amazed 
that you were able to de-static-ize the variant stuff. I've looked into 
it myself once or twice and gave up because it deemed impossible. Or 
well, there's no "impossible" in programming, it's all a matter of 
amount of work. So, cost/benefit ratio was not attractive :)
Especially since the public server stuff is more 
publicity-effective....

(I do things, because it makes me happy when I make somebody else 
happy. Doing a thing just to have it done does not give me that much 
satisfaction.)

So, your changes are welcome, even if it involved some pulldown to 
client etc.; they are a small price to pay for getting the variant 
loading into shape. So says I.

BR,
Clemens


On 2012-11-03 23:06, Craig Lish wrote:
> Believe me, I am more sorry than you that this change touched so many
> files. I didn't receive a branch until the code was done so
> progressive check-ins weren't an option. But I'd have done this as a
> branch anyway because it's really one massive unwieldy change. I
> thought I could load the variant data and just refer to it statically
> as I started passing the instance down, but I was seeing some
> weirdness on reloads. I couldn't see what was causing it so I just
> forged on and got rid of the static reference all together (which
> was my goal anyway) and the problems fell out (as they do). The
> variant was loaded (on-demand and cached) statically all over the
> place and custom recruitment was using all of the statics heavily and
> trying to keep its own references up to date. This is also my first
> time in the code so was still learning the 
> whole client/variant/game
> layout (not an excuse, just a reason, and not a good one, but
> still ;o). It was hard to find
>  the right places to hook to actually load the data and then make
> that instance available everywhere. That's why I sent that
> email describing what I was doing when I saw the scope 
> explode :oP
> lol, I was so sure I wasn't going to have to go into the GUI... and I
> was so wrong.
>
> I didn't have to rework custom recruitment so heavily. I saw the
> comments about synchronization issues and I already had to figure 
> out
> how to make it non-static. I think the change is at least in the 
> right
> direction and so extensible with the listener model. My intent was
> to keep balrog recruitment essentially the same if you change it to
> an instance operating on only one game and caretaker, I just did it
> with a flourish. Custom recruitment was the fun part of an arduous
> task :oP It really adds flexibility to the variant, which is already
> so powerful. Such a good idea. Does the other implementation support
> variants? I heard a comment that it's just a dumb board, so no AI?
> Maybe I should go look for it and not ask all these questions :oD lol
>
> Regarding the LegionClientSide changes, I didn't have to make those
> now. While chasing what each of the getCreature... kind of methods 
> do
> in the various classes I saw that we were creating like 3 lists when
> anyone asked for the creature types on the client side because the
> legion client side isn't using the creatures list yet. So, as long as
> that override is in place we should also have another override that
> prevents all of the extra creation. Documented heavily. The name
> changed because we want to move away from the string names and the
> getters are now similar to their counterparts in other classes. This
> change could totally have been separate, but I couldn't leave it that
> way.
>
> Sorry about so many touches and no segmenting. I tried to disrupt
> the code as little as possible but most of the static references to
> VariantSupport, TerrainRecruitLoader, and CustomRecruitBase were in
> the leaves of the code tree and all related. It was like pulling a
> loose thread on an intricate tapestry. (I so shouldn't be allowed 
> near
> tapestries ;o)
>
> cl
>
>>________________________________
>> From: Clemens <cl...@cl...>
>>To: col...@li...
>>Sent: Friday, November 2, 2012 5:11 AM
>>Subject: Re: [Colossus-developers] First feedback on static resources 
>> changes
>>  
>>
>>
>>I agree with the goal of having small, semantically well-defined
>>commits.
>>However since the work was already done, I didn't want to force Craig
>>to have to invent a lot of additional work to split it.
>>Good to point it out for future.
>>
>>Git: from the 3 possible improvements this one I am least thrilled 
>> of,
>>because I have no experience with Git. So this would step *me* out
>>of the comfort zone.
>>
>>And since I am myself still not back to full power, it might be 
>> better
>>to not start such a big step right now, look at it after, dunno,
>>1-2 years again ;-)
>>
>>But thanks for the offer!
>>
>>BR,
>>Clemens
>>
>>
>>
>>On 2012-11-02 13:50, Peter Becker wrote:
>>> Hi Craig,
>>>
>>>  I had some time to start browsing through a diff between trunk 
>>> and
>>> your branch. The first problem is already in the phrase "start
>>> browsing": the diff is big. My feeling is that it doesn't have to 
>>> be,
>>> e.g. the changes in the AI package look very useful and independent
>>> of
>>> the rest. There's also minor bits of formatting changes that add to
>>> the diff size when they shouldn't.
>>>
>>>  Another thing I noticed is that some code in Client drifted down
>>> from
>>> Legion to LegionClientSide. That is a bit against the spirit of
>>> generalizing the game code across server and client. The server and
>>> client specific code is the old stuff that was pretty much fully
>>> duplicated, the base classes were extracted with the idea of taking
>>> over as much as possible. Changing signatures to the client 
>>> specific
>>> classes seems counterproductive in that sense, although I wouldn't
>>> claim it might not be a useful stepping stone. It's just hard to
>>> judge
>>> in the context of that large diff.
>>>
>>>  Having said those negative bits: there's a lot to like. Having
>>> started in alphabetical package order I have gone through the AI
>>> package first and that all just makes sense. It's all pretty
>>> straightforward, simple changes but that is good.
>>>
>>>  Given my recent activity level I don't feel entitled to much 
>>> weight
>>> on my opinion, but I would prefer seing changes like that as 
>>> separate
>>> patches. Small change is easier to judge and to manage. If a branch
>>> consists out of a series of smaller changes I can go through the
>>> changesets, with the changes themselves being conceptual units
>>> ideally
>>> accompanied by a commit message that explains the intention behind
>>> them in a bit of detail. Having a single large change set with a 
>>> high
>>> level goal is much harder to process.
>>>
>>>  Clemens: how do you feel about moving to git? SF supports that 
>>> now,
>>> although the migration is not fully automated. But if there is
>>> interest I might be able to look into setting up some scripting for
>>> it. I can't promise it given that I seem to have new work coming 
>>> up,
>>> but that's all not sure at the moment, so I might still have spare
>>> cycles to burn. SVN is awfully slow, especially on SF (although the
>>> ssh version you get with the new infrastructure seems a bit faster,
>>> at
>>> least at the moment).
>>>
>>>  Peter
>>>
>
>
> 
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command 
> center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

Ah. I see what you were saying about the drifting down in Client. I agree with your gut. I saw circular casts to *ClientSide and went the wrong way with getting rid of them. I shouldn't have done it in the first place, must've been a reflex while I was working on my AI (that code is moved to a different project, not in the branch, or not supposed to be ;o). I see now the movement towards a unfied base class, we're just not all the way there yet.
 
I'll revert those changes since they're moving in the wrong direction. thanks :o)
 
cl


>________________________________
> From: Craig Lish <c_...@ya...>
>To: "col...@li..." <col...@li...> 
>Sent: Saturday, November 3, 2012 2:06 PM
>Subject: Re: [Colossus-developers] First feedback on static resources changes
>  
>Believe me, I am more sorry than you that this change touched so many files. I didn't receive a branch until the code was done so progressive check-ins weren't an option. But I'd have done this as a branch anyway because it's really one massive unwieldy change. I thought I could load the variant data and just refer to it statically as I started passing the instance down, but I was seeing some weirdness on reloads. I couldn't see what was causing it so I just forged on and got rid of the static reference all together (which was my goal anyway) and the problems fell out (as they do). The variant was loaded (on-demand and cached) statically all over the place and custom recruitment was using all of the statics heavily and trying to keep its own references up to date. This is also my first time in the code so was still learning the whole client/variant/game layout (not an excuse, just a reason, and not a good one, but still ;o). It was hard to find
>the right places to hook to actually load the data and then make that instance available everywhere. That's why I sent that email describing what I was doing when I saw the scope explode :oP lol, I was so sure I wasn't going to have to go into the GUI... and I was so wrong.
>
>I didn't have to rework custom recruitment so heavily. I saw the comments about synchronization issues and I already had to figure out how to make it non-static. I think the change is at least in the right direction and so extensible with the listener model. My intent was to keep balrog recruitment essentially the same if you change it to an instance operating on only one game and caretaker, I just did it with a flourish. Custom recruitment was the fun part of an arduous task :oP It really adds flexibility to the variant, which is already so powerful. Such a good idea. Does the other implementation support variants? I heard a comment that it's just a dumb board, so no AI? Maybe I should go look for it and not ask all these questions :oD lol
>
>Regarding the LegionClientSide changes, I didn't have to make those now. While chasing what each of the getCreature... kind of methods do in the various classes I saw that we were creating like 3 lists when anyone asked for the creature types on the client side because the legion client side isn't using the creatures list yet. So, as long as that override is in place we should also have another override that prevents all of the extra creation. Documented heavily. The name changed because we want to move away from the string names and the getters are now similar to their counterparts in other classes. This change could totally have been separate, but I couldn't leave it that way.
>
>Sorry about so many touches and no segmenting. I tried to disrupt the code as little as possible but most of the static references to VariantSupport, TerrainRecruitLoader, and CustomRecruitBase were in the leaves of the code tree and all related. It was like pulling a loose thread on an intricate tapestry. (I so shouldn't be allowed near tapestries ;o)
>
>cl
>
>>________________________________
>> From: Clemens <cl...@cl...>
>>To: col...@li... 
>>Sent: Friday, November 2, 2012 5:11 AM
>>Subject: Re: [Colossus-developers] First feedback on static resources changes
>>  
>>
>>
>>I agree with the goal of having small, semantically well-defined 
>>commits.
>>However since the work was already done, I didn't want to force Craig
>>to have to invent a lot of additional work to split it.
>>Good to point it out for future.
>>
>>Git: from the 3 possible improvements this one I am least thrilled of,
>>because I have no experience with Git. So this would step *me* out
>>of the comfort zone.
>>
>>And since I am myself still not back to full power, it might be better
>>to not start such a big step right now, look at it after, dunno,
>>1-2 years again ;-)
>>
>>But thanks for the offer!
>>
>>BR,
>>Clemens
>>
>>
>>
>>On 2012-11-02 13:50, Peter Becker wrote:
>>> Hi Craig,
>>>
>>>  I had some time to start browsing through a diff between trunk and
>>> your branch. The first problem is already in the phrase "start
>>> browsing": the diff is big. My feeling is that it doesn't have to be,
>>> e.g. the changes in the AI package look very useful and independent 
>>> of
>>> the rest. There's also minor bits of formatting changes that add to
>>> the diff size when they shouldn't.
>>>
>>>  Another thing I noticed is that some code in Client drifted down 
>>> from
>>> Legion to LegionClientSide. That is a bit against the spirit of
>>> generalizing the game code across server and client. The server and
>>> client specific code is the old stuff that was pretty much fully
>>> duplicated, the base classes were extracted with the idea of taking
>>> over as much as possible. Changing signatures to the client specific
>>> classes seems counterproductive in that sense, although I wouldn't
>>> claim it might not be a useful stepping stone. It's just hard to 
>>> judge
>>> in the context of that large diff.
>>>
>>>  Having said those negative bits: there's a lot to like. Having
>>> started in alphabetical package order I have gone through the AI
>>> package first and that all just makes sense. It's all pretty
>>> straightforward, simple changes but that is good.
>>>
>>>  Given my recent activity level I don't feel entitled to much weight
>>> on my opinion, but I would prefer seing changes like that as separate
>>> patches. Small change is easier to judge and to manage. If a branch
>>> consists out of a series of smaller changes I can go through the
>>> changesets, with the changes themselves being conceptual units 
>>> ideally
>>> accompanied by a commit message that explains the intention behind
>>> them in a bit of detail. Having a single large change set with a high
>>> level goal is much harder to process.
>>>
>>>  Clemens: how do you feel about moving to git? SF supports that now,
>>> although the migration is not fully automated. But if there is
>>> interest I might be able to look into setting up some scripting for
>>> it. I can't promise it given that I seem to have new work coming up,
>>> but that's all not sure at the moment, so I might still have spare
>>> cycles to burn. SVN is awfully slow, especially on SF (although the
>>> ssh version you get with the new infrastructure seems a bit faster, 
>>> at
>>> least at the moment).
>>>
>>>  Peter
>>>
>
>
>
>   

Believe me, I am more sorry than you that this change touched so many files. I didn't receive a branch until the code was done so progressive check-ins weren't an option. But I'd have done this as a branch anyway because it's really one massive unwieldy change. I thought I could load the variant data and just refer to it statically as I started passing the instance down, but I was seeing some weirdness on reloads. I couldn't see what was causing it so I just forged on and got rid of the static reference all together (which was my goal anyway) and the problems fell out (as they do). The variant was loaded (on-demand and cached) statically all over the place and custom recruitment was using all of the statics heavily and trying to keep its own references up to date. This is also my first time in the code so was still learning the whole client/variant/game layout (not an excuse, just a reason, and not a good one, but still ;o). It was hard to find
 the right places to hook to actually load the data and then make that instance available everywhere. That's why I sent that email describing what I was doing when I saw the scope explode :oP lol, I was so sure I wasn't going to have to go into the GUI... and I was so wrong.

I didn't have to rework custom recruitment so heavily. I saw the comments about synchronization issues and I already had to figure out how to make it non-static. I think the change is at least in the right direction and so extensible with the listener model. My intent was to keep balrog recruitment essentially the same if you change it to an instance operating on only one game and caretaker, I just did it with a flourish. Custom recruitment was the fun part of an arduous task :oP It really adds flexibility to the variant, which is already so powerful. Such a good idea. Does the other implementation support variants? I heard a comment that it's just a dumb board, so no AI? Maybe I should go look for it and not ask all these questions :oD lol

Regarding the LegionClientSide changes, I didn't have to make those now. While chasing what each of the getCreature... kind of methods do in the various classes I saw that we were creating like 3 lists when anyone asked for the creature types on the client side because the legion client side isn't using the creatures list yet. So, as long as that override is in place we should also have another override that prevents all of the extra creation. Documented heavily. The name changed because we want to move away from the string names and the getters are now similar to their counterparts in other classes. This change could totally have been separate, but I couldn't leave it that way.

Sorry about so many touches and no segmenting. I tried to disrupt the code as little as possible but most of the static references to VariantSupport, TerrainRecruitLoader, and CustomRecruitBase were in the leaves of the code tree and all related. It was like pulling a loose thread on an intricate tapestry. (I so shouldn't be allowed near tapestries ;o)

cl

>________________________________
> From: Clemens <cl...@cl...>
>To: col...@li... 
>Sent: Friday, November 2, 2012 5:11 AM
>Subject: Re: [Colossus-developers] First feedback on static resources changes
>  
>
>
>I agree with the goal of having small, semantically well-defined 
>commits.
>However since the work was already done, I didn't want to force Craig
>to have to invent a lot of additional work to split it.
>Good to point it out for future.
>
>Git: from the 3 possible improvements this one I am least thrilled of,
>because I have no experience with Git. So this would step *me* out
>of the comfort zone.
>
>And since I am myself still not back to full power, it might be better
>to not start such a big step right now, look at it after, dunno,
>1-2 years again ;-)
>
>But thanks for the offer!
>
>BR,
>Clemens
>
>
>
>On 2012-11-02 13:50, Peter Becker wrote:
>> Hi Craig,
>>
>>  I had some time to start browsing through a diff between trunk and
>> your branch. The first problem is already in the phrase "start
>> browsing": the diff is big. My feeling is that it doesn't have to be,
>> e.g. the changes in the AI package look very useful and independent 
>> of
>> the rest. There's also minor bits of formatting changes that add to
>> the diff size when they shouldn't.
>>
>>  Another thing I noticed is that some code in Client drifted down 
>> from
>> Legion to LegionClientSide. That is a bit against the spirit of
>> generalizing the game code across server and client. The server and
>> client specific code is the old stuff that was pretty much fully
>> duplicated, the base classes were extracted with the idea of taking
>> over as much as possible. Changing signatures to the client specific
>> classes seems counterproductive in that sense, although I wouldn't
>> claim it might not be a useful stepping stone. It's just hard to 
>> judge
>> in the context of that large diff.
>>
>>  Having said those negative bits: there's a lot to like. Having
>> started in alphabetical package order I have gone through the AI
>> package first and that all just makes sense. It's all pretty
>> straightforward, simple changes but that is good.
>>
>>  Given my recent activity level I don't feel entitled to much weight
>> on my opinion, but I would prefer seing changes like that as separate
>> patches. Small change is easier to judge and to manage. If a branch
>> consists out of a series of smaller changes I can go through the
>> changesets, with the changes themselves being conceptual units 
>> ideally
>> accompanied by a commit message that explains the intention behind
>> them in a bit of detail. Having a single large change set with a high
>> level goal is much harder to process.
>>
>>  Clemens: how do you feel about moving to git? SF supports that now,
>> although the migration is not fully automated. But if there is
>> interest I might be able to look into setting up some scripting for
>> it. I can't promise it given that I seem to have new work coming up,
>> but that's all not sure at the moment, so I might still have spare
>> cycles to burn. SVN is awfully slow, especially on SF (although the
>> ssh version you get with the new infrastructure seems a bit faster, 
>> at
>> least at the moment).
>>
>>  Peter
>>

On Fri, Nov 2, 2012 at 10:41 PM, Clemens <cl...@cl...> wrote:

>
>
> I agree with the goal of having small, semantically well-defined
> commits.
> However since the work was already done, I didn't want to force Craig
> to have to invent a lot of additional work to split it.
> Good to point it out for future.
>
> Git: from the 3 possible improvements this one I am least thrilled of,
> because I have no experience with Git. So this would step *me* out
> of the comfort zone.
>
> And since I am myself still not back to full power, it might be better
> to not start such a big step right now, look at it after, dunno,
> 1-2 years again ;-)
>

You gotta find the bandwidth to learn Git Clemens.
(Or mercurial, but that doesn't seem to have the same cool factor)

You wont want to go back after you learn just the basics.

I agree with the goal of having small, semantically well-defined 
commits.
However since the work was already done, I didn't want to force Craig
to have to invent a lot of additional work to split it.
Good to point it out for future.

Git: from the 3 possible improvements this one I am least thrilled of,
because I have no experience with Git. So this would step *me* out
of the comfort zone.

And since I am myself still not back to full power, it might be better
to not start such a big step right now, look at it after, dunno,
1-2 years again ;-)

But thanks for the offer!

BR,
Clemens



On 2012-11-02 13:50, Peter Becker wrote:
> Hi Craig,
>
>  I had some time to start browsing through a diff between trunk and
> your branch. The first problem is already in the phrase "start
> browsing": the diff is big. My feeling is that it doesn't have to be,
> e.g. the changes in the AI package look very useful and independent 
> of
> the rest. There's also minor bits of formatting changes that add to
> the diff size when they shouldn't.
>
>  Another thing I noticed is that some code in Client drifted down 
> from
> Legion to LegionClientSide. That is a bit against the spirit of
> generalizing the game code across server and client. The server and
> client specific code is the old stuff that was pretty much fully
> duplicated, the base classes were extracted with the idea of taking
> over as much as possible. Changing signatures to the client specific
> classes seems counterproductive in that sense, although I wouldn't
> claim it might not be a useful stepping stone. It's just hard to 
> judge
> in the context of that large diff.
>
>  Having said those negative bits: there's a lot to like. Having
> started in alphabetical package order I have gone through the AI
> package first and that all just makes sense. It's all pretty
> straightforward, simple changes but that is good.
>
>  Given my recent activity level I don't feel entitled to much weight
> on my opinion, but I would prefer seing changes like that as separate
> patches. Small change is easier to judge and to manage. If a branch
> consists out of a series of smaller changes I can go through the
> changesets, with the changes themselves being conceptual units 
> ideally
> accompanied by a commit message that explains the intention behind
> them in a bit of detail. Having a single large change set with a high
> level goal is much harder to process.
>
>  Clemens: how do you feel about moving to git? SF supports that now,
> although the migration is not fully automated. But if there is
> interest I might be able to look into setting up some scripting for
> it. I can't promise it given that I seem to have new work coming up,
> but that's all not sure at the moment, so I might still have spare
> cycles to burn. SVN is awfully slow, especially on SF (although the
> ssh version you get with the new infrastructure seems a bit faster, 
> at
> least at the moment).
>
>  Peter
>
>  On 31/10/2012 7:51 PM, Clemens wrote:
>
>> Hello Craig,
>>
>> I have taken a first look at the newest revision in your branch.
>> Just checked out, and both Eclipse and ant don't like it.
>> (So, nothing to say on specific code changes yet).
>>
>> Basics first:
>>
>> - Colossus is at the moment meant to be Java 5 compatible. I know,
>> Java 5 is dead, but as long as not all major platforms support 1.6,
>> we won't make 1.6 mandatory...
>>
>> - It should not depend on anything which is not part of offical
>> JRE, except jdom.jar and junit.jar (build time only), which are in
>> the libs/ directory. This is due to the fact that is part of Fedora,
>> and Fedora does not allow any non-source SW being shipped. So the
>> Fedora build of it relies on the jdom which ships with Fedora. If
>> there are no legal issues with org.apache.commons.lang.Validate, it
>> *might* be possible to include that somehow as well.
>>
>> We others use(d) Eclipse, and then the .project stuff tells Eclipse
>> to be 1.5 compatible.
>>
>> So, I can't build right now due to errors below and/or in attached
>> document.
>>
>> Primarily:
>>
>> 1) It seems it uses now org.apache.commons.lang[.Validate] - my
>> build does not find it for me, not even in a JRE 6, and JRE 7 API
>> it's not listed either.
>> We used assert statements for things like that, so far.
>>
>> 2) Looks like the code uses now some functionality which came new
>> with in Java 7, at least:
>>
>> Boolean.compare()
>> Integer.compare()
>> String.isEmpty()
>>
>> e.g. http://docs.oracle.com/javase/7/docs/api/ [4]
>>
>> Description Resource Path Location Type
>> The method compare(int, int) is undefined for the type Integer
>> RecruitingSubTree.java
>> /clish_static/core/src/main/java/net/sf/colossus/variant line 426
>> Java Problem
>>
>> The method isEmpty() is undefined for the type String
>> VariantKnower.java
>> /clish_static/core/src/main/java/net/sf/colossus/variant line 24
>> Java Problem
>>
>> So, please use a JRE 5 and do an ant build and fix everything it
>> spits out :)
>> You probably need an ant.jar for this. I use ant 1.7, but that
>> should not matter so much. (I can send it to you if you don't find
>> it anywhere).
>>
>> I will look into the actual code changes nevertheless, when I find
>> some time.
>>
>> BR,
>> Clemens
>>
>> katzer@home> clish_static $ ant clean jar
>> Buildfile: build.xml
>>
>> cleanjars:
>>
>> clean:
>>
>> init:
>> [mkdir] Created dir: C:Clemensworkspaceclish_staticbuildantclasses
>> [mkdir] Created dir:
>> C:Clemensworkspaceclish_staticbuildanttestresults
>>
>> compile:
>> [javac] Compiling 288 source files to
>> C:Clemensworkspaceclish_staticbuildantclasses
>> [javac]
>>
> 
> C:Clemensworkspaceclish_staticcoresrcmainjavanetsfcolossusvariantVariant.java:20:
>> package org.apache.commons.lang does not exist
>> [javac] import org.apache.commons.lang.Validate;
>> [javac] ^
>> [javac]
>>
> 
> C:Clemensworkspaceclish_staticcoresrcmainjavanetsfcolossusgameGame.java:23:
>> package org.apache.commons.lang does not exist
>> [javac] import org.apache.commons.lang.Validate;
>> [javac] ^
>> [javac]
>>
> 
> C:Clemensworkspaceclish_staticcoresrcmainjavanetsfcolossusvariantCustomRecruitManager.java:23:
>> package org.apache.commons.lang does not exist
>> [javac] import org.apache.commons.lang.Validate;
>> [javac] ^
>> [javac]
>>
> 
> C:Clemensworkspaceclish_staticcoresrcmainjavanetsfcolossusgameRecruitGraph.java:22:
>> package org.apache.commons.lang does not exist
>> [javac] import org.apache.commons.lang.Validate;
>> [javac] ^
>> [javac]
>>
> 
> C:Clemensworkspaceclish_staticcoresrcmainjavanetsfcolossusgameeventsGameEvent.java:6:
>> package org.apache.commons.lang does not exist
>> [javac] import org.apache.commons.lang.Validate;
>> [javac] ^
>> [javac]
>>
> 
> C:Clemensworkspaceclish_staticcoresrcmainjavanetsfcolossusgameeventsPlayerEvent.java:5:
>> package org.apache.commons.lang does not exist
>> [javac] import org.apache.commons.lang.Validate;
>> [javac] ^
>> [javac]
>>
> 
> C:Clemensworkspaceclish_staticcoresrcmainjavanetsfcolossusvariantCreatureType.java:51:
>> cannot find symbol
>> [javac] symbol : method compare(boolean,boolean)
>> [javac] location: class java.lang.Boolean
>> [javac] int compare = Boolean.compare(critter1.isTitan(),
>> critter2.isTitan());
>> [javac] ^
>> [javac]
>>
> 
> C:Clemensworkspaceclish_staticcoresrcmainjavanetsfcolossusvariantCreatureType.java:56:
>> cannot find symbol
>> [javac] symbol : method compare(int,int)
>> [javac] location: class java.lang.Integer
>> [javac] compare = Integer.compare(critter1.getPointValue(),
>> critter2.getPointValue());
>> [javac] ^
>> [javac]
>>
> 
> C:Clemensworkspaceclish_staticcoresrcmainjavanetsfcolossusvariantCreatureType.java:61:
>> cannot find symbol
>> [javac] symbol : method compare(boolean,boolean)
>> [javac] location: class java.lang.Boolean
>> [javac] compare = Boolean.compare(critter1.isRangestriker(),
>> critter2.isRangestriker());
>>
>> On 2012-10-29 06:30, Craig Lish wrote:
>>
>>> I've checked into this branch
>>>
>>>
>>
> 
> https://colossus.svn.sourceforge.net/svnroot/colossus/branches/dev/clish/static-resources/
>>> [3]
>>> [5] (more descriptive name). Below is a 20k foot view.
>>>
>>> cl
>>>
>>>> FROM: Craig Lish <c_...@ya...> [1]
>>>> TO: colossus-dev <col...@li...>
>>>> [2]
>>>> SENT: Friday, October 26, 2012 9:47 PM
>>>> SUBJECT: Re: [Colossus-developers] non-static resources
>>>>
>>>> Here are the broad strokes:
>>>>
>>>> A Colossus session has one variant and multiple games (server +
>>>>
>>>> clients). The resources and custom recruitment are now
>>>> instanced and
>>>> available from Variant so are shared across all game instances
>>>> in
>>>> the session. The caretaker is per-game. Custom recruitment is
>>>> per-variant. I think caretaker should be per-variant but didn't
>>>> want
>>>> to go there right now. I think it's simple and makes sense.
>>>> Could
>>>> just put it in the variant instead of the game. Everyone can
>>>> get the
>>>> variant. But I digress... :o)
>>>>
>>>> TerrainRecruitLoader extends TerrainRecruitInfo which is
>>>> available
>>>> from Variant. I moved some data from VariantSupport into
>>>> Variant and
>>>> some into TerrainRecruitLoader and made TerrainRecruitLoader
>>>> instance instead of static. TerrainRecruitInfo is now commonly
>>>> passed to the GUI components for their resource needs.
>>>>
>>>> public abstract class TerrainRecruitInfo
>>>> {
>>>> public abstract CreatureType getCreatureByName(String
>>>> creature);
>>>> public abstract CustomRecruitment getCustomRecruitment(String
>>>> name);
>>>> public abstract MasterBoardTerrain getTerrainById(String id);
>>>> public abstract List<AcquirableData> getAcquirablesList();
>>>> public abstract int getTitanImprovementValue();
>>>> public abstract int getTitanTeleportValue();
>>>> public abstract Collection<MasterBoardTerrain> getTerrains();
>>>> public abstract RecruitGraph getRecruitGraph();
>>>> public abstract CreatureType[] getStartingCreatures(MasterHex
>>>> hex);
>>>> public abstract List<String> getDirectoriesList();
>>>> // Wrappers for getDirectoriesList()
>>>> public List<String> getDirectoriesList(String suffixPath)
>>>> public List<String> getImagesDirectoriesList()
>>>> public List<String> getBattlelandsDirectoriesList()
>>>> }
>>>>
>>>> Variant is available from Game and contains this data:
>>>>
>>>> private final String name;
>>>> private final TerrainRecruitInfo terrainRecruitInfo;
>>>> private final AllCreatureType creatureTypes;
>>>> private final List<CreatureType> summonableCreatureTypes;
>>>> private final Properties markerNames;
>>>> private final MasterBoard masterBoard;
>>>> private final Document readme;
>>>> private final int maxPlayers;
>>>> private final String fileName;
>>>> private final String directory;
>>>> private CustomRecruitManager crm;
>>>> // created after variant
>>>> private IVariantHint hints;
>>>>
>>>> CustomRecruitment was a challenge. Game now has
>>>> GameEventListeners
>>>> and broadcasts GameEvents. Only PhaseChange and PlayerChange
>>>> right
>>>> now, but I want to add ScoreChange for BalrogRecruitment to
>>>> work
>>>> correctly. I could probably have used the history events, but
>>>> those
>>>> don't always fire and I didn't want to disturb that code. The
>>>> functionality can be merged easy enough, I just wanted to get
>>>> the
>>>> custom recruitment working ;o)
>>>>
>>>> CustomRecruitManager (crm) has a reference to the variant and
>>>> is
>>>> referenced by RecruitGraph. You can get it as
>>>> game.getVariant().getCustomRecruitManager(), but it goes
>>>> through
>>>> TerrainRecruitInfo to the RecruitGraph to get it. The
>>>> CreatureLoader
>>>> is passed a crm and calls through it to load a custom recruit.
>>>> When
>>>> the crm loads a custom recruit it loads the corresponding
>>>> custom
>>>> recruitment and adds the recruit to it. If the custom
>>>> recruitment
>>>> implements GameEventListener then it's added to the crm's list
>>>> of
>>>> listeners. The crm is a GameEventListener handling all of the
>>>> Game
>>>> instances in the session (listener is hooked up in Game
>>>> constructor).
>>>>
>>>> When a GameEvent arrives, the CustomRecruitment listener will
>>>> act on
>>>> the game included in the event (_his_ caretaker). CRM will get
>>>> 1
>>>> event per-game instance instead of trying to manage multiple
>>>> games/caretakers with 1 handler. Let the server worry about
>>>> keeping
>>>> the games synchronized. If there was only 1 caretaker then crm
>>>> would
>>>> only listen to the GameServerSide for events.
>>>>
>>>> The game seems to play the same. There are no static methods
>>>> for
>>>> resources anymore so I'm sure that all of the resource loading
>>>> works
>>>> with the new instanced data. I should profile the memory as it
>>>> loads
>>>> and unloads a variant and test it some more, but I'm pretty
>>>> confident because of the kinds of errors I would be seeing and
>>>> when
>>>> I would be seeing them. Still, so many touches... Sorry about
>>>> that
>>>> :oP I'll have a diff soon.
>>
>>
> 
> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>>
>> _______________________________________________
>> Colossus-developers mailing list
>> Col...@li...
>> https://lists.sourceforge.net/lists/listinfo/colossus-developers
>
>
>
> Links:
> ------
> [1] mailto:c_...@ya...
> [2] mailto:col...@li...
> [3]
> 
> https://colossus.svn.sourceforge.net/svnroot/colossus/branches/dev/clish/static-resources/
> [4] http://docs.oracle.com/javase/7/docs/api/

Hi Craig,

I had some time to start browsing through a diff between trunk and your 
branch. The first problem is already in the phrase "start browsing": the 
diff is big. My feeling is that it doesn't have to be, e.g. the changes 
in the AI package look very useful and independent of the rest. There's 
also minor bits of formatting changes that add to the diff size when 
they shouldn't.

Another thing I noticed is that some code in Client drifted down from 
Legion to LegionClientSide. That is a bit against the spirit of 
generalizing the game code across server and client. The server and 
client specific code is the old stuff that was pretty much fully 
duplicated, the base classes were extracted with the idea of taking over 
as much as possible. Changing signatures to the client specific classes 
seems counterproductive in that sense, although I wouldn't claim it 
might not be a useful stepping stone. It's just hard to judge in the 
context of that large diff.

Having said those negative bits: there's a lot to like. Having started 
in alphabetical package order I have gone through the AI package first 
and that all just makes sense. It's all pretty straightforward, simple 
changes but that is good.

Given my recent activity level I don't feel entitled to much weight on 
my opinion, but I would prefer seing changes like that as separate 
patches. Small change is easier to judge and to manage. If a branch 
consists out of a series of smaller changes I can go through the 
changesets, with the changes themselves being conceptual units ideally 
accompanied by a commit message that explains the intention behind them 
in a bit of detail. Having a single large change set with a high level 
goal is much harder to process.

Clemens: how do you feel about moving to git? SF supports that now, 
although the migration is not fully automated. But if there is interest 
I might be able to look into setting up some scripting for it. I can't 
promise it given that I seem to have new work coming up, but that's all 
not sure at the moment, so I might still have spare cycles to burn. SVN 
is awfully slow, especially on SF (although the ssh version you get with 
the new infrastructure seems a bit faster, at least at the moment).

    Peter



On 31/10/2012 7:51 PM, Clemens wrote:
>
> Hello Craig,
>
> I have taken a first look at the newest revision in your branch. Just 
> checked out, and both Eclipse and ant don't like it.
> (So, nothing to say on specific code changes yet).
>
> Basics first:
>
> - Colossus is at the moment meant to be Java 5 compatible. I know, 
> Java 5 is dead, but as long as not all major platforms support 1.6, we 
> won't make 1.6 mandatory...
>
> - It should not depend on anything which is not part of offical JRE, 
> except jdom.jar and junit.jar (build time only), which are in the 
> libs/ directory. This is due to the fact that is part of Fedora, and 
> Fedora does not allow any non-source SW being shipped. So the Fedora 
> build of it relies on the jdom which ships with Fedora. If there are 
> no legal issues with org.apache.commons.lang.Validate, it *might* be 
> possible to include that somehow as well.
>
>
> We others use(d) Eclipse, and then the .project stuff tells Eclipse to 
> be 1.5 compatible.
>
> So, I can't build right now due to errors below and/or in attached 
> document.
>
> Primarily:
>
>
> 1) It seems it uses now org.apache.commons.lang[.Validate] - my build 
> does not find it for me, not even in a JRE 6, and JRE 7 API it's not 
> listed either.
>    We used assert statements for things like that, so far.
>
> 2) Looks like the code uses now some functionality which came new with 
> in Java 7, at least:
>
> Boolean.compare()
> Integer.compare()
> String.isEmpty()
>
> e.g. http://docs.oracle.com/javase/7/docs/api/
>
>
> Description    Resource    Path    Location    Type
> The method compare(int, int) is undefined for the type Integer 
> RecruitingSubTree.java 
> /clish_static/core/src/main/java/net/sf/colossus/variant    line 
> 426    Java Problem
>
>
> The method isEmpty() is undefined for the type String 
> VariantKnower.java 
> /clish_static/core/src/main/java/net/sf/colossus/variant    line 24    
> Java Problem
>
>
> So, please use a JRE 5 and do an ant build and fix everything it spits 
> out :)
> You probably need an ant.jar for this. I use ant 1.7, but that should 
> not matter so much. (I can send it to you if you don't find it anywhere).
>
>
> I will look into the actual code changes nevertheless, when I find 
> some time.
>
>
>
> BR,
> Clemens
>
>
>
>
> katzer@home> clish_static $ ant clean jar
> Buildfile: build.xml
>
> cleanjars:
>
> clean:
>
> init:
>     [mkdir] Created dir: 
> C:\Clemens\workspace\clish_static\build\ant\classes
>     [mkdir] Created dir: 
> C:\Clemens\workspace\clish_static\build\ant\testresults
>
> compile:
>     [javac] Compiling 288 source files to 
> C:\Clemens\workspace\clish_static\build\ant\classes
>     [javac] 
> C:\Clemens\workspace\clish_static\core\src\main\java\net\sf\colossus\variant\Variant.java:20: 
> package org.apache.commons.lang does not exist
>     [javac] import org.apache.commons.lang.Validate;
>     [javac]                                ^
>     [javac] 
> C:\Clemens\workspace\clish_static\core\src\main\java\net\sf\colossus\game\Game.java:23: 
> package org.apache.commons.lang does not exist
>     [javac] import org.apache.commons.lang.Validate;
>     [javac]                                ^
>     [javac] 
> C:\Clemens\workspace\clish_static\core\src\main\java\net\sf\colossus\variant\CustomRecruitManager.java:23: 
> package org.apache.commons.lang does not exist
>     [javac] import org.apache.commons.lang.Validate;
>     [javac]                                ^
>     [javac] 
> C:\Clemens\workspace\clish_static\core\src\main\java\net\sf\colossus\game\RecruitGraph.java:22: 
> package org.apache.commons.lang does not exist
>     [javac] import org.apache.commons.lang.Validate;
>     [javac]                                ^
>     [javac] 
> C:\Clemens\workspace\clish_static\core\src\main\java\net\sf\colossus\game\events\GameEvent.java:6: 
> package org.apache.commons.lang does not exist
>     [javac] import org.apache.commons.lang.Validate;
>     [javac]                                ^
>     [javac] 
> C:\Clemens\workspace\clish_static\core\src\main\java\net\sf\colossus\game\events\PlayerEvent.java:5: 
> package org.apache.commons.lang does not exist
>     [javac] import org.apache.commons.lang.Validate;
>     [javac]                                ^
>     [javac] 
> C:\Clemens\workspace\clish_static\core\src\main\java\net\sf\colossus\variant\CreatureType.java:51: 
> cannot find symbol
>     [javac] symbol  : method compare(boolean,boolean)
>     [javac] location: class java.lang.Boolean
>     [javac]             int compare = 
> Boolean.compare(critter1.isTitan(), critter2.isTitan());
>     [javac]                                  ^
>     [javac] 
> C:\Clemens\workspace\clish_static\core\src\main\java\net\sf\colossus\variant\CreatureType.java:56: 
> cannot find symbol
>     [javac] symbol  : method compare(int,int)
>     [javac] location: class java.lang.Integer
>     [javac]             compare = 
> Integer.compare(critter1.getPointValue(), critter2.getPointValue());
>     [javac]                              ^
>     [javac] 
> C:\Clemens\workspace\clish_static\core\src\main\java\net\sf\colossus\variant\CreatureType.java:61: 
> cannot find symbol
>     [javac] symbol  : method compare(boolean,boolean)
>     [javac] location: class java.lang.Boolean
>     [javac]             compare = 
> Boolean.compare(critter1.isRangestriker(), critter2.isRangestriker());
>
>
>
> On 2012-10-29 06:30, Craig Lish wrote:
>> I've checked into this branch
>>
>> https://colossus.svn.sourceforge.net/svnroot/colossus/branches/dev/clish/static-resources/ 
>>
>> [5] (more descriptive name). Below is a 20k foot view.
>>
>> cl
>>
>>> FROM: Craig Lish <c_...@ya...>
>>> TO: colossus-dev <col...@li...>
>>> SENT: Friday, October 26, 2012 9:47 PM
>>> SUBJECT: Re: [Colossus-developers] non-static resources
>>>
>>> Here are the broad strokes:
>>>
>>> A Colossus session has one variant and multiple games (server +
>>> clients). The resources and custom recruitment are now instanced and
>>> available from Variant so are shared across all game instances in
>>> the session. The caretaker is per-game. Custom recruitment is
>>> per-variant. I think caretaker should be per-variant but didn't want
>>> to go there right now. I think it's simple and makes sense. Could
>>> just put it in the variant instead of the game. Everyone can get the
>>> variant. But I digress... :o)
>>>
>>> TerrainRecruitLoader extends TerrainRecruitInfo which is available
>>> from Variant. I moved some data from VariantSupport into Variant and
>>> some into TerrainRecruitLoader and made TerrainRecruitLoader
>>> instance instead of static. TerrainRecruitInfo is now commonly
>>> passed to the GUI components for their resource needs.
>>>
>>> public abstract class TerrainRecruitInfo
>>> {
>>> public abstract CreatureType getCreatureByName(String creature);
>>> public abstract CustomRecruitment getCustomRecruitment(String
>>> name);
>>> public abstract MasterBoardTerrain getTerrainById(String id);
>>> public abstract List<AcquirableData> getAcquirablesList();
>>> public abstract int getTitanImprovementValue();
>>> public abstract int getTitanTeleportValue();
>>> public abstract Collection<MasterBoardTerrain> getTerrains();
>>> public abstract RecruitGraph getRecruitGraph();
>>> public abstract CreatureType[] getStartingCreatures(MasterHex hex);
>>> public abstract List<String> getDirectoriesList();
>>> // Wrappers for getDirectoriesList()
>>> public List<String> getDirectoriesList(String suffixPath)
>>> public List<String> getImagesDirectoriesList()
>>> public List<String> getBattlelandsDirectoriesList()
>>> }
>>>
>>> Variant is available from Game and contains this data:
>>>
>>> private final String name;
>>> private final TerrainRecruitInfo terrainRecruitInfo;
>>> private final AllCreatureType creatureTypes;
>>> private final List<CreatureType> summonableCreatureTypes;
>>> private final Properties markerNames;
>>> private final MasterBoard masterBoard;
>>> private final Document readme;
>>> private final int maxPlayers;
>>> private final String fileName;
>>> private final String directory;
>>> private CustomRecruitManager crm;
>>> // created after variant
>>> private IVariantHint hints;
>>>
>>> CustomRecruitment was a challenge. Game now has GameEventListeners
>>> and broadcasts GameEvents. Only PhaseChange and PlayerChange right
>>> now, but I want to add ScoreChange for BalrogRecruitment to work
>>> correctly. I could probably have used the history events, but those
>>> don't always fire and I didn't want to disturb that code. The
>>> functionality can be merged easy enough, I just wanted to get the
>>> custom recruitment working ;o)
>>>
>>> CustomRecruitManager (crm) has a reference to the variant and is
>>> referenced by RecruitGraph. You can get it as
>>> game.getVariant().getCustomRecruitManager(), but it goes through
>>> TerrainRecruitInfo to the RecruitGraph to get it. The CreatureLoader
>>> is passed a crm and calls through it to load a custom recruit. When
>>> the crm loads a custom recruit it loads the corresponding custom
>>> recruitment and adds the recruit to it. If the custom recruitment
>>> implements GameEventListener then it's added to the crm's list of
>>> listeners. The crm is a GameEventListener handling all of the Game
>>> instances in the session (listener is hooked up in Game
>>> constructor).
>>>
>>> When a GameEvent arrives, the CustomRecruitment listener will act on
>>> the game included in the event (_his_ caretaker). CRM will get 1
>>> event per-game instance instead of trying to manage multiple
>>> games/caretakers with 1 handler. Let the server worry about keeping
>>> the games synchronized. If there was only 1 caretaker then crm would
>>> only listen to the GameServerSide for events.
>>>
>>> The game seems to play the same. There are no static methods for
>>> resources anymore so I'm sure that all of the resource loading works
>>> with the new instanced data. I should profile the memory as it loads
>>> and unloads a variant and test it some more, but I'm pretty
>>> confident because of the kinds of errors I would be seeing and when
>>> I would be seeing them. Still, so many touches... Sorry about that
>>> :oP I'll have a diff soon.
>>>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
>
>
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

On 11/1/12 13:30 , Peter Becker wrote:

> I wouldn't bother with Java 5 anymore at all. It's EOL was more than 4
> years ago. But I don't know the Mac story.

On my shiny latest and greatest OS X Mountain Lion (10.8) I do have Java 
1.6:

jani@mcbook:~$ sw_vers -productVersion
10.8.2
jani@mcbook:~$ java -version
java version "1.6.0_37"
Java(TM) SE Runtime Environment (build 1.6.0_37-b06-434-11M3909)
Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01-434, mixed mode)
jani@mcbook:~$

And it looks to be the same back to 10.6:

http://support.apple.com/kb/HT5494

OS X 10.5 might have 1.5/1.6:

http://support.apple.com/kb/DL1359

OS X 10.4 might have 1.4/1.5:

http://support.apple.com/downloads/Java_for_Mac_OS_X_10_4__Release_9

OS X versions for non-initiates:

http://en.wikipedia.org/wiki/Osx#Versions

On 11/01/2012 05:34 PM, Peter Becker wrote:
> On 2/11/2012 12:08 AM, David Ripton wrote:

>> I don't think Linux will be a big problem.  Though maybe the openjdk 6
>> default on Ubuntu means that it makes sense to go to 6 first rather than
>> skipping it and going straight to 7.
>>
> This does remind me of a potential issue, though. Oracle withdrew the
> distribution license, which means you can not get Oracle's JRE/JDK7 from
> the standard Linux repositories, you need to download it yourself. That
> adds a bit of a hurdle to using Oracle's JRE.
>
> Of course that's not much of an issue as long as we test with OpenJDK.
> Unfortunately they are not the same, in particular when it comes to
> Swing. IDEA used to warn you if you run it on OpenJDK due to known
> issues (I never researched what they are and I can't find anything
> conclusive right now). Colossus is not as complex, so we might well be fine.

I just ran a 6-player (me and 5 AIs) game on Ubuntu, OpenJDK 1.6, Java 
Web Start.  Didn't see any problems.

-- 
David Ripton    dr...@ri...

On 2/11/2012 12:08 AM, David Ripton wrote:
> On 11/01/2012 08:48 AM, Bruno Wolff III wrote:
>> On Thu, Nov 01, 2012 at 12:30:02 +0200,
>>      Clemens <cl...@cl...> wrote:
>>> Hello all,
>>>
>>> how is the general opinion about going forward to at least Java 6 ?
>> Fedora has 1.7 these days. I would expect that expect for some of the
>> long term support releases, that at least 1.6 would be available on
>> linux distros.
> RHEL 6 has 1.5.0, 1.6.0, and 1.7.0 versions of openjdk available.  Or
> you can download and install Oracle Java 7.
>
> Ubuntu 12.04 LTS box has openjdk 6 by default, but it's easy enough to
> install openjdk 7 or Oracle java 7.
>
> I don't think Linux will be a big problem.  Though maybe the openjdk 6
> default on Ubuntu means that it makes sense to go to 6 first rather than
> skipping it and going straight to 7.
>
This does remind me of a potential issue, though. Oracle withdrew the 
distribution license, which means you can not get Oracle's JRE/JDK7 from 
the standard Linux repositories, you need to download it yourself. That 
adds a bit of a hurdle to using Oracle's JRE.

Of course that's not much of an issue as long as we test with OpenJDK. 
Unfortunately they are not the same, in particular when it comes to 
Swing. IDEA used to warn you if you run it on OpenJDK due to known 
issues (I never researched what they are and I can't find anything 
conclusive right now). Colossus is not as complex, so we might well be fine.

   Peter

On 11/01/2012 08:48 AM, Bruno Wolff III wrote:
> On Thu, Nov 01, 2012 at 12:30:02 +0200,
>     Clemens <cl...@cl...> wrote:
>>
>> Hello all,
>>
>> how is the general opinion about going forward to at least Java 6 ?
>
> Fedora has 1.7 these days. I would expect that expect for some of the
> long term support releases, that at least 1.6 would be available on
> linux distros.

RHEL 6 has 1.5.0, 1.6.0, and 1.7.0 versions of openjdk available.  Or 
you can download and install Oracle Java 7.

Ubuntu 12.04 LTS box has openjdk 6 by default, but it's easy enough to 
install openjdk 7 or Oracle java 7.

I don't think Linux will be a big problem.  Though maybe the openjdk 6 
default on Ubuntu means that it makes sense to go to 6 first rather than 
skipping it and going straight to 7.

-- 
David Ripton    dr...@ri...