colossus-developers Mailing List for Colossus (Page 9)

On 11/01/2012 07:30 AM, 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.

Apple had their own port of Oracle's JDK for years, which usually lagged 
behind, but they recently stopped maintaining it.  Now Oracle directly 
controls the JDK on Mac OS, like they do on Linux, Solaris, and Windows. 
  All are at the same version, jdk7u9.  So the old problem we had with 
Macs at an older JDK version than the rest is no longer an issue.

But the remaining problem is that new versions of the JDK might not run 
on old computers or OS versions.  I can test on Windows XP and Mac OS 
Tiger if needed.

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

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.

Hi Clemens,

I actually started playing with Java 8 earlier this week :-)

In my experience (which is mostly server side) Java 6 is still very much 
alive and kicking, not many projects I've worked on actually moved to 
Java 7 yet. That is partly due to a lack of compelling reasons, but also 
since Java 6 is still better supported on some operating systems. Java 7 
adds some little things, but it is not a big gain in terms of writing 
code. The automated resource management is quite nice, if you deal with 
file systems the new New IO is very handy. But nothing that gets me too 
excited. As a Linux user I do appreciate the XRender pipeline, but 
that's not affecting any code.

OTOH: Java 6 is heading towards it's end of public support fast, only 
four months to go.

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.

Just my 2c,

    Peter


On 1/11/2012 8:30 PM, Clemens wrote:
> Hello all,
>
> how is the general opinion about going forward to at least Java 6 ?
>
> We did the change from 1.4.2 to 1.5 when "all major OSes" (Win 95? Win
> 98?) did provide support to run 1.5 jars. I personally would propose to
> drop Win95+98, considering WinXP (which is also already dead ;-) as the
> minimum.
>
> Anyone knowing the situation in Mac world? Which is the oldest release
> which makes still sense to support, and are 1.6/1.7 JRE available there?
>
>
> Generally speaking, my plan would be to go with trunk eventually/soon
> to >= Java 6, jumping to 2.x versioning; and send the 1.5 compatible
> code (0.x versions) into a maintenance mode, where only minimum changes
> would be done to preserve compatibility with the Public Game Server - so
> that one could at least log in and do the basics. But any advanced stuff
> would work only with newer clients. For example, the new BeelzeGods12
> reworked variant might then perhaps NOT be runnable in 0.x maintenance
> branch. And this maintenance branch I would aim for maximum ½ or 1 year
> (let's see;-) - announcing it early that this 0.x version will become
> obsolete in a foreseeable future.
>
>
> Or is even Java 7 nowadays "state of the art"?
>
> If we can provide 1.5 compatibility in the maintenance branch, I think
> 2.x could even go for Java 7 right away.
>
>
> Opinions?
>
> BR,
> Clemens
>
>
>
> ------------------------------------------------------------------------------
> 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

Hello all,

how is the general opinion about going forward to at least Java 6 ?

We did the change from 1.4.2 to 1.5 when "all major OSes" (Win 95? Win 
98?) did provide support to run 1.5 jars. I personally would propose to 
drop Win95+98, considering WinXP (which is also already dead ;-) as the 
minimum.

Anyone knowing the situation in Mac world? Which is the oldest release 
which makes still sense to support, and are 1.6/1.7 JRE available there?


Generally speaking, my plan would be to go with trunk eventually/soon 
to >= Java 6, jumping to 2.x versioning; and send the 1.5 compatible 
code (0.x versions) into a maintenance mode, where only minimum changes 
would be done to preserve compatibility with the Public Game Server - so 
that one could at least log in and do the basics. But any advanced stuff 
would work only with newer clients. For example, the new BeelzeGods12 
reworked variant might then perhaps NOT be runnable in 0.x maintenance 
branch. And this maintenance branch I would aim for maximum ½ or 1 year 
(let's see;-) - announcing it early that this 0.x version will become 
obsolete in a foreseeable future.


Or is even Java 7 nowadays "state of the art"?

If we can provide 1.5 compatibility in the maintenance branch, I think 
2.x could even go for Java 7 right away.


Opinions?

BR,
Clemens

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

> It might be a fairly involved
> change, but it might just mostly work if the loader builds those 
> creatures,
> we have to change the way we ask the question... I'm getting all 
> excited ;o)

And it might be an excellent opportunity do introduce this new way by 
backing it
up with unit test cases. In case youa are accustomed to that approach.
I regret I never took enough time to add more tests for the changes I 
did.

-Clemens


On 2012-10-29 02:55, Craig Lish wrote:
>  
> ----- Original Message -----
>> From: Bruno Wolff III <br...@wo...>
>> To: Craig Lish <c_...@ya...>
>> Cc: colossus-dev <col...@li...>
>> Sent: Sunday, October 28, 2012 4:19 PM
>> Subject: Re: [Colossus-developers] Colossus development
>>
>> On Sun, Oct 28, 2012 at 13:36:07 -0700,
>>   Craig Lish <c_...@ya...> wrote:
>>>   
>>>  I want to make a CreatureTypeAny, CreatureTypeAnyNonLord, etc 
>>> next. I think
>> recruiting would simplify if there weren't those other lists to 
>> handle as
>> special cases. Then there would just be an entry for "Any recruits 
>> Guardian
>> for 3" in the tower. You'd still have to look for it specifically 
>> when
>> you go to recruit with your Ogre recruiter, but it would be natural, 
>> more of a
>> synonym than another list of recruiting options. Not now, but like 
>> after I get
>> this resource stuff in ;o)
>>
>> It's probably way to late to do anything about this for Colossus, 
>> but the
>> rulebook terminology is that all units are characters, not 
>> creatures. Creatures
>> are the characters that are not lords or demi-lords.
>>
>> For guardians, it's probably not worth special casing them. You can 
>> just
>> write a rule for each creature type plus guardians. The tricky 
>> special case is
>> when you can recruit a tower creature with any character in the 
>> tower without
>> having to reveal what the character is.
>>
>
> The anonymous recruit is what made me think of this. When you ask for
> all recruiters
> you'll get a collection back that contains a CreatureType named
> "Any" (or a AnyCreatureType
> or something). Then the recruit tree doesn't have to have different 
> lists and
> special handling and the caller can check for whatever suits his 
> situation.
> Might figure out somet clever subclassing for Any vs AnyNonLord, etc.
> It just moves the logic into the recruit tree instead of maintaining
> separate lists.
> The loader will load them and isConcreteCreature(String) will move 
> into
> CreatureType and you just ask it isConcrete(). It might be a fairly 
> involved
> change, but it might just mostly work if the loader builds those 
> creatures,
> we have to change the way we ask the question... I'm getting all 
> excited ;o)
>
> cl
>
> 
> ------------------------------------------------------------------------------
> The Windows 8 Center - In partnership with Sourceforge
> Your idea - your app - 30 days.
> Get started!
> http://windows8center.sourceforge.net/
> 
> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

I've checked into this branch https://colossus.svn.sourceforge.net/svnroot/colossus/branches/dev/clish/static-resources/ (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.
>
>thanx
>
>cl
>
>________________________________
>
>From: Peter Becker <pe...@pe...>
>To: col...@li... 
>Sent: Thursday, October 25, 2012 5:15 PM
>Subject: Re: [Colossus-developers] non-static resources
>
>
>
>Hi Craig,
>
>to commit to the repository one of the project admins will have to
      grant you access. In most OSS projects you start of submitting
      patches first (or pull requests in the case of GitHub and the
      like). I forgot how Colossus handled this, usually it should go
      either on this list or in a spot like this: https://sourceforge.net/tracker/?group_id=1939&atid=301939
>
>Clemens is probably the best person to tell you what is preferred.
>
>If you send me the patch via PM I'm happy to have a look at the
      diff and give it a spin. I got some time to spare at the moment.
>
>  Peter
>
>
>On 26/10/2012 9:19 AM, Craig Lish wrote:
> 
>Do I have branch/commit access? I wouldn't think you would want just anyone to go stomping around in the code, but I've never dealt with opensource before... What's the process here? Should I just be creating a patch? I've touched quite a few files in moving the resources from static to instance (~125 -- it's not that bad, most is just getting access to the TerrainRecruitInfo which is just an interface to the TerrainRecruitLoader instance data). The resouces themselves are still cached by the static loader, but as long as there is no name conflict then that should coninue to work as it always has. The game runs fine and my unittest concurrency issues are gone, but I expect there may be another tweak or two forthcoming as I/you/we look it over. 
>>
>>cl  
>> 
>>
>>------------------------------------------------------------------------------
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   
> 
>------------------------------------------------------------------------------
>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 10/28/2012 07:19 PM, Bruno Wolff III wrote:

> It's probably way to late to do anything about this for Colossus, but the
> rulebook terminology is that all units are characters, not creatures.
> Creatures are the characters that are not lords or demi-lords.

I considered using Character to be Titan-correct, but decided not to 
because Character is a fundamental Java class (the Object wrapper around 
characters like 'a') and it would get annoying to always have to 
disambiguate net.sf.colossus.Character versus java.lang.Character.

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

----- Original Message -----
> From: Craig Lish <c_...@ya...>
> To: Bruno Wolff III <br...@wo...>
> Cc: colossus-dev <col...@li...>
> Sent: Sunday, October 28, 2012 5:55 PM
> Subject: Re: [Colossus-developers] Colossus development
> 
>  
> ----- Original Message -----
>>  From: Bruno Wolff III <br...@wo...>
>>  To: Craig Lish <c_...@ya...>
>>  Cc: colossus-dev <col...@li...>
>>  Sent: Sunday, October 28, 2012 4:19 PM
>>  Subject: Re: [Colossus-developers] Colossus development
>> 
>>  On Sun, Oct 28, 2012 at 13:36:07 -0700,
>>    Craig Lish <c_...@ya...> wrote:
>>>    
>>>   I want to make a CreatureTypeAny, CreatureTypeAnyNonLord, etc next. I 
> think 
>>  recruiting would simplify if there weren't those other lists to handle 
> as 
>>  special cases. Then there would just be an entry for "Any recruits 
> Guardian 
>>  for 3" in the tower. You'd still have to look for it specifically 
> when 
>>  you go to recruit with your Ogre recruiter, but it would be natural, more 
> of a 
>>  synonym than another list of recruiting options. Not now, but like after I 
> get 
>>  this resource stuff in ;o)
>> 
>>  It's probably way to late to do anything about this for Colossus, but 
> the 
>>  rulebook terminology is that all units are characters, not creatures. 
> Creatures 
>>  are the characters that are not lords or demi-lords.
>> 
>>  For guardians, it's probably not worth special casing them. You can 
> just 
>>  write a rule for each creature type plus guardians. The tricky special case 
> is 
>>  when you can recruit a tower creature with any character in the tower 
> without 
>>  having to reveal what the character is.
>> 
> 
> The anonymous recruit is what made me think of this. When you ask for all 
> recruiters 
> you'll get a collection back that contains a CreatureType named 
> "Any" (or a AnyCreatureType
> or something). Then the recruit tree doesn't have to have different lists 
> and
> special handling and the caller can check for whatever suits his situation.
> Might figure out somet clever subclassing for Any vs AnyNonLord, etc.
> It just moves the logic into the recruit tree instead of maintaining separate 
> lists.
> The loader will load them and isConcreteCreature(String) will move into
> CreatureType and you just ask it isConcrete(). It might be a fairly involved
> change, but it might just mostly work if the loader builds those creatures,
> we have to change the way we ask the question... I'm getting all excited ;o)
> 
> cl  
> 

Anonymous recruits could totally be handled by custom recruitment (it _is_ custom recruitment).
Simple implementation, too. It's just asking recruiting counts and things.
No caretaker diddling or anything, just answers the recruitment count questions.

cl  

 
----- Original Message -----
> From: Bruno Wolff III <br...@wo...>
> To: Craig Lish <c_...@ya...>
> Cc: colossus-dev <col...@li...>
> Sent: Sunday, October 28, 2012 4:19 PM
> Subject: Re: [Colossus-developers] Colossus development
> 
> On Sun, Oct 28, 2012 at 13:36:07 -0700,
>   Craig Lish <c_...@ya...> wrote:
>>   
>>  I want to make a CreatureTypeAny, CreatureTypeAnyNonLord, etc next. I think 
> recruiting would simplify if there weren't those other lists to handle as 
> special cases. Then there would just be an entry for "Any recruits Guardian 
> for 3" in the tower. You'd still have to look for it specifically when 
> you go to recruit with your Ogre recruiter, but it would be natural, more of a 
> synonym than another list of recruiting options. Not now, but like after I get 
> this resource stuff in ;o)
> 
> It's probably way to late to do anything about this for Colossus, but the 
> rulebook terminology is that all units are characters, not creatures. Creatures 
> are the characters that are not lords or demi-lords.
> 
> For guardians, it's probably not worth special casing them. You can just 
> write a rule for each creature type plus guardians. The tricky special case is 
> when you can recruit a tower creature with any character in the tower without 
> having to reveal what the character is.
> 

The anonymous recruit is what made me think of this. When you ask for all recruiters 
you'll get a collection back that contains a CreatureType named "Any" (or a AnyCreatureType
or something). Then the recruit tree doesn't have to have different lists and
special handling and the caller can check for whatever suits his situation.
Might figure out somet clever subclassing for Any vs AnyNonLord, etc.
It just moves the logic into the recruit tree instead of maintaining separate lists.
The loader will load them and isConcreteCreature(String) will move into
CreatureType and you just ask it isConcrete(). It might be a fairly involved
change, but it might just mostly work if the loader builds those creatures,
we have to change the way we ask the question... I'm getting all excited ;o)

cl  

On Sun, Oct 28, 2012 at 13:36:07 -0700,
   Craig Lish <c_...@ya...> wrote:
> 
>I want to make a CreatureTypeAny, CreatureTypeAnyNonLord, etc next. I think recruiting would simplify if there weren't those other lists to handle as special cases. Then there would just be an entry for "Any recruits Guardian for 3" in the tower. You'd still have to look for it specifically when you go to recruit with your Ogre recruiter, but it would be natural, more of a synonym than another list of recruiting options. Not now, but like after I get this resource stuff in ;o)

It's probably way to late to do anything about this for Colossus, but the 
rulebook terminology is that all units are characters, not creatures. 
Creatures are the characters that are not lords or demi-lords.

For guardians, it's probably not worth special casing them. You can just 
write a rule for each creature type plus guardians. The tricky special 
case is when you can recruit a tower creature with any character in the 
tower without having to reveal what the character is.

On Sun, Oct 28, 2012 at 21:18:47 +0200,
   Clemens <cl...@cl...> wrote:
>
>> You can throw away
>> legions pretty much at will without giving up points because the AI
>> is
>> satisfied with a time victory and will not generally try to slay the
>
>Well, yes, as human player against the existing AIs you can do what you
>describe.
>
>But that is less easy against other humans, and certainly writing AI
>code
>relying on such an approach does not sound like a good idea to me.

I wasn't suggesting that the AIs get changed to try to take advantage of 
the poor fighting of the AIs. It was just one more thing to add to the 
list of battle fighting weak spots.

So, for my AI tests I built a ClientSideTestHarness. The test runner runs two clients with different variants simultaneously now. I'll  It's not the same as 2 server games in the same JVM, but it's close. I'd bet it would work now, depending on the startup code.
 
lol, it'd be nice if I'd get some code in the branch so you can look at it ;o) I'll get on that.
 
cl


----- Original Message -----
> From: Clemens <cl...@cl...>
> To: Craig Lish <c_...@ya...>
> Cc: col...@li...
> Sent: Sunday, October 28, 2012 12:52 PM
> Subject: Re: [Colossus-developers] non-static resources
> 
> 
>>  Yeah, it's one of those tasks that has to grab you and make you do
>>  it.
> 
> It's one of the things I would have probably done eventually, once
> the Public server stuff, and doing goodies for users of the server
> hadn't eaten all my time...
> in my early days, it was just that, that I grabbed such things
> which bothered me. Now I have no time for such stuff any more,
> even if I had time for Colossus at all...
> 
> The staticness of the variant stuff (or anything else for that matter,
> but the variant is the biggest of them) is (or was) one of the core
> problems that prevented a number of other good improvements.
> 
> For example, right now on the public server, the game-pooling/chat 
> server
> is in it's own JVM, and each started game in it's own. The good side
> effect of that is: with each game completed, JVM ends, all memory
> released, etc., and the pooling/chat server in itself is significantly
> less complex than the game code, so not too much memory mgmt issues
> there.
> 
> I would like to eventually have them all run in the same JVM (or at
> least the possibility to do it optionally), but that is impossible
> as long as variant data is static.
> 
> (Not sure of whether running them all in same JVM would actually be
> such a good idea, but I might have liked to try.)
> 
> Likewise, on client side: the consequence of the static variant data 
> is,
> that you can be part of only one game within same JVM. So, if one game 
> is
> "my turn is only every 10 mins, I'd like to play another in parallel
> meanwhile", you need to start a new Colossus instance.
> 
> 
> BR,
> Clemens
> 
> 
> On 2012-10-28 21:32, Craig Lish wrote:
>>> ________________________________
>>>  From: Clemens <cl...@cl...>
>>> To: col...@li...
>>> Sent: Sunday, October 28, 2012 10:45 AM
>>> Subject: Re: [Colossus-developers] non-static resources
>>>   
>>> ... so I have given you (Craig) commit rights now, and would ask you 
>>>  to
>>> commit in a branch.
>>> (also because I should do a official build pretty soon, when the one
>>> big issue
>>> (game gets for some users stuck if they concede twice, or something,
>>> so I would like the release done before starting a major 
>>>  refactoring).
>>> 
>>> If the changes in the branch don't look nice I can still revoke the
>>> rights :)
>> 
>>  ah, and there it is ;o)
>>   
>>> 
>>> The static-to-instance refactoring is highly welcome -- I myself have
>>> more
>>> than once considered to go into this but ...
>>> 
>>   
>>  Yeah, it's one of those tasks that has to grab you and make you do
>>  it. Thinking back, I don't know why I couldn't let it go :oP
>   

> Yeah, it's one of those tasks that has to grab you and make you do
> it.

It's one of the things I would have probably done eventually, once
the Public server stuff, and doing goodies for users of the server
hadn't eaten all my time...
in my early days, it was just that, that I grabbed such things
which bothered me. Now I have no time for such stuff any more,
even if I had time for Colossus at all...

The staticness of the variant stuff (or anything else for that matter,
but the variant is the biggest of them) is (or was) one of the core
problems that prevented a number of other good improvements.

For example, right now on the public server, the game-pooling/chat 
server
is in it's own JVM, and each started game in it's own. The good side
effect of that is: with each game completed, JVM ends, all memory
released, etc., and the pooling/chat server in itself is significantly
less complex than the game code, so not too much memory mgmt issues
there.

I would like to eventually have them all run in the same JVM (or at
least the possibility to do it optionally), but that is impossible
as long as variant data is static.

(Not sure of whether running them all in same JVM would actually be
such a good idea, but I might have liked to try.)

Likewise, on client side: the consequence of the static variant data 
is,
that you can be part of only one game within same JVM. So, if one game 
is
"my turn is only every 10 mins, I'd like to play another in parallel
meanwhile", you need to start a new Colossus instance.


BR,
Clemens


On 2012-10-28 21:32, Craig Lish wrote:
>>________________________________
>> From: Clemens <cl...@cl...>
>>To: col...@li...
>>Sent: Sunday, October 28, 2012 10:45 AM
>>Subject: Re: [Colossus-developers] non-static resources
>>  
>>... so I have given you (Craig) commit rights now, and would ask you 
>> to
>>commit in a branch.
>>(also because I should do a official build pretty soon, when the one
>>big issue
>>(game gets for some users stuck if they concede twice, or something,
>>so I would like the release done before starting a major 
>> refactoring).
>>
>>If the changes in the branch don't look nice I can still revoke the
>>rights :)
>
> ah, and there it is ;o)
>  
>>
>>The static-to-instance refactoring is highly welcome -- I myself have
>>more
>>than once considered to go into this but ...
>>
>  
> Yeah, it's one of those tasks that has to grab you and make you do
> it. Thinking back, I don't know why I couldn't let it go :oP

>________________________________
> From: Clemens <cl...@cl...>
>To: col...@li... 
>Sent: Sunday, October 28, 2012 10:45 AM
>Subject: Re: [Colossus-developers] non-static resources
>  
>... so I have given you (Craig) commit rights now, and would ask you to 
>commit in a branch.
>(also because I should do a official build pretty soon, when the one 
>big issue
>(game gets for some users stuck if they concede twice, or something,
>so I would like the release done before starting a major refactoring).
>
>If the changes in the branch don't look nice I can still revoke the 
>rights :)

ah, and there it is ;o)
 
>
>The static-to-instance refactoring is highly welcome -- I myself have 
>more
>than once considered to go into this but ...
>
 
Yeah, it's one of those tasks that has to grab you and make you do it. Thinking back, I don't know why I couldn't let it go :oP

Hi Craig,

I have created a branch in which you can work:

https://colossus.svn.sourceforge.net/svnroot/colossus/branches/dev/clish/Colossus

You've skimmed over the "full docs"

     http://colossus.sourceforge.net/docs/index.html

and at least have read the coding standards page, right?

     http://colossus.sourceforge.net/docs/CodingStandards.html

If you run into problems, let me know. (I am much better in "re-active"
work than in starting to do something on my own.)

BR;
Clemens


On 2012-10-28 19:45, Clemens wrote:
>> When I was the maintainer, I preferred patches as unified diffs 
>> (from
>> 'diff -u' or 'svn diff'), sent to the mailing list.  When someone
>> sent
>> enough good patches that I thought the cost of having to review 
>> their
>> patches exceeded the benefit, I would give them commit rights.
>
> yes, and that's in principle the idea right now. However as I am
> somewhat
> not too available right now...
>
> ... so I have given you (Craig) commit rights now, and would ask you 
> to
> commit in a branch.
> (also because I should do a official build pretty soon, when the one
> big issue
> (game gets for some users stuck if they concede twice, or something,
> so I would like the release done before starting a major 
> refactoring).
>
> If the changes in the branch don't look nice I can still revoke the
> rights :)
>
> The static-to-instance refactoring is highly welcome -- I myself have
> more
> than once considered to go into this but ...
>
>
>> Clemens is the maintainer now, so it's up to him to approve new
>> committers.  But feel free to send patches to the mailing list
>> anytime.
>
> Thanks,
> Clemens
>
>
> 
> ------------------------------------------------------------------------------
> WINDOWS 8 is here.
> Millions of people.  Your app in 30 days.
> Visit The Windows 8 Center at Sourceforge for all your go to 
> resources.
> http://windows8center.sourceforge.net/
> join-generation-app-and-make-money-coding-fast/
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

I think Peter is right. Every player needs it's own instance of the 
caretaker
because it *might* be needed anyway by *some* client (remote clients),
and makeing the code distinct when sync is needed and when not would be
more error-prone than the "just do it for all the same way".

(for the same reason all server-client messaging is done via a socket,
even is the client runs locally in same JVM).

If there would be somewhat of a true RMI (or similar), having remote
clients using RMI to query numbers from one server instance could be
_considered_ (caching needed, anyway).

But we are far away from anything like RMI being usable.

BR,
Clemens



On 2012-10-27 11:56, Peter Becker wrote:
> I'm not sure I understand your idea, but my intuition says that 
> having
> local games behave differently to distributed ones is asking for more
> work, not less. The caretaker needs to be replicated in the
> client-server model, it is probably easier in the long run to do that
> no matter where the client sits.
>
>  Peter
>
>  On 27/10/2012 6:27 PM, Craig Lish wrote:
>
>> I agree about the variant and the caretaker, I just think that it
>> should be owned by the server game with all local games referring to
>> the same instance instead of having to keep multiple instances
>> synchronized.
>>
>> The diff is unwieldy, I was just seting the stage :oP
>>
>> cl
>>
>> FROM: Peter Becker <pe...@pe...> [4]
>> TO: col...@li... [5]
>> SENT: Friday, October 26, 2012 11:53 PM
>> SUBJECT: Re: [Colossus-developers] non-static resources
>>
>> Given that I haven't worked on the code for a while it's a bit much
>> to take in in this form. I usually find a diff easier to handle
>> since it provides the necessary context.
>>
>> One thing to clarify, though: the design philosophy behind the
>> variant/game distinction was to have the variant model everything
>> that describes the game rules, while the game class models the state
>> of a running game. That way the caretaker belongs to the game part,
>> not the variant -- it models the state of the still available
>> creatures in the running game. The variant and related objects
>> should be immutable during the course of a game.
>>
>> Peter
>>
>> On 27/10/2012 2:47 PM, Craig Lish wrote:
>>
>>> Yeah, lol, I don't even have access to the tracker link ;o) I'll
>>> go through the review first. I've seen a couple little differences
>>> in the way RecruitingSubTree and RecruitGraph answer similar
>>> questions. Happily, the only way to find them is to play, but that
>>> makes me want to go back into my AI code and educate him :oP
>>>
>>> Anyway, 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.
>>>
>>> thanx
>>>
>>> cl
>>>
>>> T
>>> FROM: Peter Becker mailto:pe...@pe... [1]
>>> TO: col...@li... [2]
>>> SENT: Thursday, October 25, 2012 5:15 PM
>>> SUBJECT: Re: [Colossus-developers] non-static resources
>>>
>>> Hi Craig,
>>>
>>> to commit to the repository one of the project admins will have
>>> to grant you access. In most OSS projects you start of submitting
>>> patches first (or pull requests in the case of GitHub and the
>>> like). I forgot how Colossus handled this, usually it should go
>>> either on this list or in a spot like this:
>>> https://sourceforge.net/tracker/?group_id=1939&atid=301939 [3]
>>>
>>> Clemens is probably the best person to tell you what is
>>> preferred.
>>>
>>> If you send me the patch via PM I'm happy to have a look at the
>>> diff and give it a spin. I got some time to spare at the moment.
>>>
>>> Peter
>>>
>>> On 26/10/2012 9:19 AM, Craig Lish wrote:
>>>
>>>> Do I have branch/commit access? I wouldn't think you would want
>>>> just anyone to go stomping around in the code, but I've never
>>>> dealt with opensource before... What's the process here? Should
>>>> I just be creating a patch? I've touched quite a few files in
>>>> moving the resources from static to instance (~125 -- it's not
>>>> that bad, most is just getting access to the TerrainRecruitInfo
>>>> which is just an interface to the TerrainRecruitLoader instance
>>>> data). The resouces themselves are still cached by the static
>>>> loader, but as long as there is no name conflict then that
>>>> should coninue to work as it always has. The game runs fine and
>>>> my unittest concurrency issues are gone, but I expect there may
>>>> be another tweak or two forthcoming as I/you/we look it over.
>>>>
>>>> cl
>
>
>
> Links:
> ------
> [1] mailto:pe...@pe...
> [2] mailto:col...@li...
> [3] https://sourceforge.net/tracker/?group_id=1939&amp;atid=301939
> [4] mailto:pe...@pe...
> [5] mailto:col...@li...

> When I was the maintainer, I preferred patches as unified diffs (from
> 'diff -u' or 'svn diff'), sent to the mailing list.  When someone 
> sent
> enough good patches that I thought the cost of having to review their
> patches exceeded the benefit, I would give them commit rights.

yes, and that's in principle the idea right now. However as I am 
somewhat
not too available right now...

... so I have given you (Craig) commit rights now, and would ask you to 
commit in a branch.
(also because I should do a official build pretty soon, when the one 
big issue
(game gets for some users stuck if they concede twice, or something,
so I would like the release done before starting a major refactoring).

If the changes in the branch don't look nice I can still revoke the 
rights :)

The static-to-instance refactoring is highly welcome -- I myself have 
more
than once considered to go into this but ...


> Clemens is the maintainer now, so it's up to him to approve new
> committers.  But feel free to send patches to the mailing list 
> anytime.

Thanks,
Clemens

Just thought I'd drop by and say Hi.
-Ed.


>

On 10/27/2012 12:47 AM, Craig Lish wrote:

> to commit to the repository one of the project admins will have to grant
> you access. In most OSS projects you start of submitting patches first
> (or pull requests in the case of GitHub and the like). I forgot how
> Colossus handled this, usually it should go either on this list or in a
> spot like this: https://sourceforge.net/tracker/?group_id=1939&atid=301939

When I was the maintainer, I preferred patches as unified diffs (from 
'diff -u' or 'svn diff'), sent to the mailing list.  When someone sent 
enough good patches that I thought the cost of having to review their 
patches exceeded the benefit, I would give them commit rights.

Clemens is the maintainer now, so it's up to him to approve new 
committers.  But feel free to send patches to the mailing list anytime.

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

I'm not sure I understand your idea, but my intuition says that having 
local games behave differently to distributed ones is asking for more 
work, not less. The caretaker needs to be replicated in the 
client-server model, it is probably easier in the long run to do that no 
matter where the client sits.

   Peter


On 27/10/2012 6:27 PM, Craig Lish wrote:
> I agree about the variant and the caretaker, I just think that it 
> should be owned by the server game with all local games referring to 
> the same instance instead of having to keep multiple instances 
> synchronized.
> The diff is unwieldy, I was just seting the stage :oP
> cl
> *From:* Peter Becker <pe...@pe...>
> *To:* col...@li...
> *Sent:* Friday, October 26, 2012 11:53 PM
> *Subject:* Re: [Colossus-developers] non-static resources
>
> Given that I haven't worked on the code for a while it's a bit much to 
> take in in this form. I usually find a diff easier to handle since it 
> provides the necessary context.
>
> One thing to clarify, though: the design philosophy behind the 
> variant/game distinction was to have the variant model everything that 
> describes the game rules, while the game class models the state of a 
> running game. That way the caretaker belongs to the game part, not the 
> variant -- it models the state of the still available creatures in the 
> running game. The variant and related objects should be immutable 
> during the course of a game.
>
>   Peter
>
>
> On 27/10/2012 2:47 PM, Craig Lish wrote:
>> Yeah, lol, I don't even have access to the tracker link ;o) I'll go 
>> through the review first. I've seen a couple little differences in 
>> the way RecruitingSubTree and RecruitGraph answer similar questions. 
>> Happily, the only way to find them is to play, but that makes me want 
>> to go back into my AI code and educate him :oP
>> Anyway, 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.
>> thanx
>> cl
>> T
>> *From:* Peter Becker mailto:pe...@pe...
>> *To:* col...@li... 
>> <mailto:col...@li...>
>> *Sent:* Thursday, October 25, 2012 5:15 PM
>> *Subject:* Re: [Colossus-developers] non-static resources
>>
>> Hi Craig,
>>
>> to commit to the repository one of the project admins will have to 
>> grant you access. In most OSS projects you start of submitting 
>> patches first (or pull requests in the case of GitHub and the like). 
>> I forgot how Colossus handled this, usually it should go either on 
>> this list or in a spot like this: 
>> https://sourceforge.net/tracker/?group_id=1939&atid=301939
>>
>> Clemens is probably the best person to tell you what is preferred.
>>
>> If you send me the patch via PM I'm happy to have a look at the diff 
>> and give it a spin. I got some time to spare at the moment.
>>
>>   Peter
>>
>>
>> On 26/10/2012 9:19 AM, Craig Lish wrote:
>>> Do I have branch/commit access? I wouldn't think you would want just 
>>> anyone to go stomping around in the code, but I've never dealt with 
>>> opensource before... What's the process here? Should I just be 
>>> creating a patch? I've touched quite a few files in moving 
>>> the resources from static to instance (~125 -- it's not that bad, 
>>> most is just getting access to the TerrainRecruitInfo which is just 
>>> an interface to the TerrainRecruitLoader instance data). The 
>>> resouces themselves are still cached by the static loader, but as 
>>> long as there is no name conflict then that should coninue to work 
>>> as it always has. The game runs fine and my unittest concurrency 
>>> issues are gone, but I expect there may be another tweak or two 
>>> forthcoming as I/you/we look it over.
>>> cl
>>>

On 27/10/2012 5:09 PM, Barrie Treloar wrote:
> On Sat, Oct 27, 2012 at 5:23 PM, Peter Becker <pe...@pe...> wrote:
>> Given that I haven't worked on the code for a while it's a bit much to take
>> in in this form. I usually find a diff easier to handle since it provides
>> the necessary context.
>>
>> One thing to clarify, though: the design philosophy behind the variant/game
>> distinction was to have the variant model everything that describes the game
>> rules, while the game class models the state of a running game. That way the
>> caretaker belongs to the game part, not the variant -- it models the state
>> of the still available creatures in the running game. The variant and
>> related objects should be immutable during the course of a game.
> This type of knowledge needs to get captured back into some html
> documents :) because I'm pretty sure that knowledge isn't shared/known
> now.
>
> Anything else that gets uncovered as someone new looks at the code
> base should also get captured.
>
> You are lucky in that David is still on the list, if not actively
> developing, and there are plenty of other people with stuff about how
> Colossus works in their heads here too.
>
Talking about this triggered some long lost memories: I actually did 
document some of the process and results: 
http://sourceforge.net/apps/trac/colossus/wiki/NewModel

I should probably have thought of that earlier when Craig came in, sorry 
about that. Consolidating the page would be good as well, at this point 
in time it is still a bit of a plan instead of a description of an as-is 
state. It seems pretty accurate, though.

Both relevant Java packages have a package.html file as well. Again it 
is in more in a "things to be" tone but it's a start.

The trac wiki actually contains this as well: 
http://sourceforge.net/apps/trac/colossus/wiki/ProvidingPatches -- it 
points solely to the feature tracker, though. For bug fixes and 
refactorings that might not be the best choice.

   Peter

I agree about the variant and the caretaker, I just think that it should be owned by the server game with all local games referring to the same instance instead of having to keep multiple instances synchronized.
 
The diff is unwieldy, I was just seting the stage :oP
 
cl
  

________________________________
 From: Peter Becker <pe...@pe...>
To: col...@li... 
Sent: Friday, October 26, 2012 11:53 PM
Subject: Re: [Colossus-developers] non-static resources
  

Given that I haven't worked on the code for a while it's a bit much to take in in this form. I usually find a diff easier to handle since it provides the necessary context.

One thing to clarify, though: the design philosophy behind the
      variant/game distinction was to have the variant model everything
      that describes the game rules, while the game class models the
      state of a running game. That way the caretaker belongs to the
      game part, not the variant -- it models the state of the still
      available creatures in the running game. The variant and related
      objects should be immutable during the course of a game.

  Peter


On 27/10/2012 2:47 PM, Craig Lish wrote:
 
Yeah, lol, I don't even have access to the tracker link ;o) I'll go through the review first. I've seen a couple little differences in the way RecruitingSubTree and RecruitGraph answer similar questions. Happily, the only way to find them is to play, but that makes me want to go back into my AI code and educate him :oP 
>  
>Anyway, 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. 
>
>thanx 
>
>cl
> 
>________________________________
>   
>From: Peter Becker mailto:pe...@pe...
>To: col...@li... 
>Sent: Thursday, October 25, 2012 5:15 PM
>Subject: Re: [Colossus-developers] non-static resources
> 
>
>
>Hi Craig,
>
>to commit to the repository one of the project admins
                  will have to grant you access. In most OSS projects
                  you start of submitting patches first (or pull
                  requests in the case of GitHub and the like). I forgot
                  how Colossus handled this, usually it should go either
                  on this list or in a spot like this: https://sourceforge.net/tracker/?group_id=1939&atid=301939
>
>Clemens is probably the best person to tell you what
                  is preferred.
>
>If you send me the patch via PM I'm happy to have a
                  look at the diff and give it a spin. I got some time
                  to spare at the moment.
>
>  Peter
>
>
>On 26/10/2012 9:19 AM, Craig Lish wrote:
> 
>Do I have branch/commit access? I wouldn't think you would want just anyone to go stomping around in the code, but I've never dealt with opensource before... What's the process here? Should I just be creating a patch? I've touched quite a few files in moving the resources from static to instance (~125 -- it's not that bad, most is just getting access to the TerrainRecruitInfo which is just an interface to the TerrainRecruitLoader instance data). The resouces themselves are still cached by the static loader, but as long as there is no name conflict then that should coninue to work as it always has. The game runs fine and my unittest concurrency issues are gone, but I expect there may be another tweak or two forthcoming as I/you/we look it over. 
>>
>>cl  
>> 
>>
>>------------------------------------------------------------------------------
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   
>  
>------------------------------------------------------------------------------
>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
>
>
>   
> 
>
>------------------------------------------------------------------------------
WINDOWS 8 is here. 
Millions of people.  Your app in 30 days.
Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/ 
> 
>
>_______________________________________________
Colossus-developers mailing list Col...@li... https://lists.sourceforge.net/lists/listinfo/colossus-developers   
 
------------------------------------------------------------------------------
WINDOWS 8 is here. 
Millions of people.  Your app in 30 days.
Visit The Windows 8 Center at Sourceforge for all your go to resources.
http://windows8center.sourceforge.net/
join-generation-app-and-make-money-coding-fast/
_______________________________________________
Colossus-developers mailing list
Col...@li...
https://lists.sourceforge.net/lists/listinfo/colossus-developers

On Sat, Oct 27, 2012 at 5:23 PM, Peter Becker <pe...@pe...> wrote:
> Given that I haven't worked on the code for a while it's a bit much to take
> in in this form. I usually find a diff easier to handle since it provides
> the necessary context.
>
> One thing to clarify, though: the design philosophy behind the variant/game
> distinction was to have the variant model everything that describes the game
> rules, while the game class models the state of a running game. That way the
> caretaker belongs to the game part, not the variant -- it models the state
> of the still available creatures in the running game. The variant and
> related objects should be immutable during the course of a game.

This type of knowledge needs to get captured back into some html
documents :) because I'm pretty sure that knowledge isn't shared/known
now.

Anything else that gets uncovered as someone new looks at the code
base should also get captured.

You are lucky in that David is still on the list, if not actively
developing, and there are plenty of other people with stuff about how
Colossus works in their heads here too.

Given that I haven't worked on the code for a while it's a bit much to 
take in in this form. I usually find a diff easier to handle since it 
provides the necessary context.

One thing to clarify, though: the design philosophy behind the 
variant/game distinction was to have the variant model everything that 
describes the game rules, while the game class models the state of a 
running game. That way the caretaker belongs to the game part, not the 
variant -- it models the state of the still available creatures in the 
running game. The variant and related objects should be immutable during 
the course of a game.

   Peter


On 27/10/2012 2:47 PM, Craig Lish wrote:
> Yeah, lol, I don't even have access to the tracker link ;o) I'll go 
> through the review first. I've seen a couple little differences in the 
> way RecruitingSubTree and RecruitGraph answer similar questions. 
> Happily, the only way to find them is to play, but that makes me want 
> to go back into my AI code and educate him :oP
> Anyway, 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.
> thanx
> cl
> T
> *From:* Peter Becker <pe...@pe...>
> *To:* col...@li...
> *Sent:* Thursday, October 25, 2012 5:15 PM
> *Subject:* Re: [Colossus-developers] non-static resources
>
> Hi Craig,
>
> to commit to the repository one of the project admins will have to 
> grant you access. In most OSS projects you start of submitting patches 
> first (or pull requests in the case of GitHub and the like). I forgot 
> how Colossus handled this, usually it should go either on this list or 
> in a spot like this: 
> https://sourceforge.net/tracker/?group_id=1939&atid=301939
>
> Clemens is probably the best person to tell you what is preferred.
>
> If you send me the patch via PM I'm happy to have a look at the diff 
> and give it a spin. I got some time to spare at the moment.
>
>   Peter
>
>
> On 26/10/2012 9:19 AM, Craig Lish wrote:
>> Do I have branch/commit access? I wouldn't think you would want just 
>> anyone to go stomping around in the code, but I've never dealt with 
>> opensource before... What's the process here? Should I just be 
>> creating a patch? I've touched quite a few files in moving 
>> the resources from static to instance (~125 -- it's not that bad, 
>> most is just getting access to the TerrainRecruitInfo which is just 
>> an interface to the TerrainRecruitLoader instance data). The resouces 
>> themselves are still cached by the static loader, but as long as 
>> there is no name conflict then that should coninue to work as it 
>> always has. The game runs fine and my unittest concurrency issues are 
>> gone, but I expect there may be another tweak or two forthcoming as 
>> I/you/we look it over.
>> cl
>>
>>
>> ------------------------------------------------------------------------------
>> 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...  <mailto:Col...@li...>
>> https://lists.sourceforge.net/lists/listinfo/colossus-developers
>
>
> ------------------------------------------------------------------------------
> 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... 
> <mailto:Col...@li...>
> https://lists.sourceforge.net/lists/listinfo/colossus-developers
>
>
>
>
> ------------------------------------------------------------------------------
> WINDOWS 8 is here.
> Millions of people.  Your app in 30 days.
> Visit The Windows 8 Center at Sourceforge for all your go to resources.
> http://windows8center.sourceforge.net/
> join-generation-app-and-make-money-coding-fast/
>
>
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers