**revisited**

@Guy: Your method is foolishly complicated. I propose some new ones.

Items in italics are outfits

A *UniversalLauncher* is the base launcher outfit that grants launcher outfits for all the other weapons when purchased

All crons are iterative

An invisible mission to automatically advance the date by 1 day whenever you land is required for any of these methods to work properly

crb = Contribute/Require Bit

**Methods for maintaining a maximum total ammo over multiple ammo types**

These methods keep track of how much ammo you have vs how much you're allowed and can recalculate to account for ammo spent or captured.

**Method 1 - Ship-dependent maximum**

See attachment for example plug and full explanation of how this method works.

Required resources: 3 outfits and 2 crons, plus 1 weapon, 2 outfits and 2 crons per ammo type.

Ships come with x number of both *TotalSlots* and *AmmoSlots*.

Ammo requires and removes 1 *AmmoSlot*.

Cron1: Transfer *TotalSlots* to *Counters* , removing *AmmoSlots*

Cron2: Transfer *Counters* back to *TotalSlots* , adding *AmmoSlots*

CronA1: Transfer *AmmoA* to *Counters*

CronA2: Transfer *Counters* back to *AmmoA* , removing *AmmoSlots*

etc...

**Method 2 - Launcher-dependent maximum**

I haven't actually tested this one but it's really just a variation of the previous one.

Required resources: 3 outfits and 2 crons, plus 1 weapon, 2 outfits and 2 crons per ammo type.

*UniversalLaunchers* grant x number of *AmmoSlots* and IncreaseMax for *AmmoToken*.

Ammo requires and removes 1 *AmmoSlot* and grants 1 *AmmoToken*.

Cron1: Transfer *UniversalLaunchers* to *Counters* , removing x number of *AmmoSlots* and *AmmoTokens* for each

Cron2: Transfer *Counters* back to *UniversalLaunchers* , adding x number of *AmmoSlots* for each

CronA1: Transfer *AmmoA* to *Counters*

CronA2: Transfer *Counters* back to *AmmoA* , removing *AmmoSlots* and adding *AmmoTokens*

etc...

**Methods for maintaining a maximum total fighters over multiple fighter types**

These methods keep track of how many fighters you have versus how many you're allowed. Fighters can be difficult when deployed but we take advantage of the fact that checking a crb gives a different result to Oxxx and can recalculate to account for lost fighters when all fighters are recalled. Since a maximum cannot be enforced properly when capturing additional fighters, these methods do not account for capture and should only be used with fighters that are not capturable.

**Method 1 - Simple**

The rEV beta first used this method for Confed fighters but it has since been updated to Method 3.

Required resources: 2 outfits and 1 cron, plus 1 weapon, 3 outfits, 2 crons, and 1 crb per fighter type.

*UniversalBays* grant x number of *FighterSlots* and IncreaseMax for *FighterTokens*.

Fighter types require and remove 1 *FighterSlot* , grant 1 *FighterToken* and set corresponding ContributeBits.

CronA1: Transfer *FighterAs* to *CounterAs* according to ContributeBitA, removing FighterTokens

CronB1: Transfer *FighterBs* to *CounterBs* according to ContributeBitB, removing FighterTokens

etc...

Cron: If no deployed fighters remain of any type then transfer remaining *FighterTokens* to *FighterSlots*

CronA2: Transfer *CounterAs* back to *FighterAs* , adding *FighterTokens*

CronB2: Transfer *CounterBs* back to *FighterBs* , adding *FighterTokens*

etc...

**Method 2 - Complex, fighters can take up mass/cargo space**

This method is used for Hawk fighters in the rEV beta. This was actually the first method I worked out.

Required resources: 3 outfits, plus 1 weapon, 4 outfits, 5 crons, and 1 crb per fighter type.

Purchase outfits: FighterBayA (UniversalBay), FighterUnitA, FighterUnitB.

Invisible outfits: Counter, FighterSlot, FighterToken, FighterBayB, FighterA, FighterB, DeployedFighterA, DeployedFighterB.

*UniversalBays* grant x number of *FighterSlots* and IncreaseMax for *FighterTokens*.

*FighterUnits* require and remove 1 *FighterSlot* , grant 1 *FighterToken* and corresponding *Fighter* , IncreaseMax for corresponding *DeployedFighters* , and set corresponding ContributeBits.

Start by assuming all fighters are deployed:

CronA1: Transfer *FighterUnitAs* to *Counters* , removing *DeployedFighterAs*

CronA2: Transfer *Counters* back to *FighterUnitAs* , adding *DeployedFighterAs*

Account for docked fighters:

CronA3: Transfer *FighterAs* to *Counters* according to ContributeBitA, removing *DeployedFighterAs*

If it turns out no fighters are deployed then we can account for lost fighters:

CronA4: If no deployed *FighterAs* remain then remove remaining *DeployedFighterAs* , removing *FighterUnitAs* and *FighterTokens* and adding *FighterSlots*

Clean up:

CronA5: Transfer *Counters* back to *FighterAs*

etc...

Challenge for the future:

Find a solution for capturing fighters. Desprez, who came up with way more complex stuff than this, allowed capture of fighters to replace lost ones by using a MaxAmmo of 1 and making every fighter purchased grant 1 launcher (see topic). The downside to this would be that the more fighters you purchase the faster they launch, but perhaps there would be a way around this...

**(UPDATE)**

After finally seeing the solution to my problem in Cron-less counting, capturing fighters was suddenly made possible (albeit very complicated). See **Method 3** further down...

This post has been edited by **Guy** : 10 May 2014 - 02:13 AM