Re: [Colossus-developers] non-static resources

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