Multiple Ammo Types

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

What's with all the "increase max" for tokens that can't be purchased?

@guy, on 26 August 2012 - 10:23 PM, said in Multiple Ammo Types:

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

BurstCount=1, BurstReload=Reload.

The IncreaseMax is to prevent selling a launcher/bay that is still in use. In the case of the last method it's also needed to prevent selling deployed fighters.

BurstCount is multiplied by the number of launchers you have.

And this folks, is why I added the multiple-ammo feature to my EV4 Wishlist. Same goes for multiple-weapon.

Fighter Method 3 - Capture!

This is a highly complex method which allows for fighters to be captured, with a side bonus that you can have different maximums for different fighter types. The drawback is you can no longer mix and match fighters within a single bay - each bay you purchase is designated for a particular fighter type when you purchase the first fighter for it.
To see this method in action, check out rEV (follow the link in my sig) where I have just implemented this for Confed Fighters. It has some slight differences due to the way the main bay works with bay expansions but is otherwise much the same.

Base resources: 4 outfits, 1 cron, 1 ncb and 2 missions.
For each fighter type: 1 weapon, 2 outfits, 5 crons, 1 crb, 1 ncb and n+2 missions, where n is the max-per-bay for that fighter type.

In this example we will have FighterA with n=3, and FighterB with n=2.

Purchase outfits: UniversalBay, FighterA, FighterB.
Invisible outfits: Counter, LoadoutSlot, LoadoutToken, FighterBayA, FighterBayB.

Our fighter bays use MaxAmmo to prevent capturing fighters beyond what you're allowed. The bays aren't actually granted until you start purchasing fighters though, which gives us a problem because the MaxAmmo also prevents us from buying the fighters in the first place. To workaround this we use a little trick with a mission and a cron to temporarily grant the bays. We do this first because this cron must run before all the other crons...

Mission 1: Grant Temp Bays
Availability: !b0 (invisibly offered in the outfitter)
OnAccept: b0 g FighterBayA g FighterBayB
Auto-aborts

Cron: Remove Temp Bays
EnableOn: b0
OnEnd: !b0 d FighterBayA d FighterBayB
(remember: always use OnEnd with iterative exit to avoid bugs, even if the cron is only going to run once)

The missions for the fighters are used to create a mod-n counter which allows us to grant the fighter bay with every nth purchase of the fighter. You should read the explanation of this system in this topic but I'll go over the necessary details here...

Mission 2: Cycle A States (start to increment; start n-1 times to decrement)
OnAccept: a5 a4 a3 a6
Auto-aborts
Mission 3: A State 0 - b1 is clear if we're in State 0, otherwise it is set
Availability: !b1 (invisibly offered in the main spaceport)
OnAccept: !b1
OnAbort: s4 b1 d LoadoutSlot g LoadoutToken g FighterBayA
Mission 4: A State 1
OnAbort: s5
Mission 5: A State 2
OnAbort: s6
Mission 6: A State Wrap
OnAbort: s3

Mission 7: Cycle B States
OnAccept: a9 a8 a10
Auto-aborts
Mission 8: B State 0
Availability: !b2 (invisibly offered in the main spaceport)
OnAccept: !b2
OnAbort: s9 b2 d LoadoutSlot g LoadoutToken g FighterBayB
Mission 9: B State 1
OnAbort: s10
Mission 10: B State Wrap
OnAbort: s8

Mission 11: Reset All States
OnAccept: a4 a5 a6 a9 a10
Auto-aborts

The OnPurchase of any ship that can equip the fighters will need to include "s11 s1". This ensures the states get reset and grants the temporary bays, allowing the player to go directly to the outfitter without having to leave and land again.

Now we can set up the outfits...

UniversalBay
OnPurchase: g LoadoutSlot
OnSell: d LoadoutSlot
IncreaseMax for LoadoutToken ( LoadoutToken has max=1)
FighterA
Availability: o LoadoutSlot | b1 (either we have a free LoadoutSlot or we have a partially-filled bay we can add to)
Contributes: crb1
OnPurchase: g FighterA s2 (increment the counter)
OnSell: d FighterA g LoadoutSlot s2 s2 d LoadoutToken d FighterBayA (decrement the counter - the adding/removing outfits negates the adding/removing of State 0's OnAbort)
FighterB
Availability: o LoadoutSlot | b2
Contributes: crb2
OnPurchase: g FighterB s7
OnSell: d FighterB g LoadoutSlot s7 d LoadoutToken d FighterBayB

Make sure any ships that come with these fighters include the appropriate outfits as well: One UniversalBay and one LoadoutToken for every fighter bay.

Finally the crons to do the usual recalculations...

CronA1: Start by always resetting the state
EnableOn: b1
OnEnd: a4 a5 a6
CronA2: Transfer undeployed fighters to counters
Requires: crb1
OnEnd: d FighterA g Counter
CronA3: If fighters are still deployed, transfer back
EnableOn: o FighterA & o Counter
OnEnd: g FighterA d Counter
CronA4: Otherwise, transfer bays and tokens back into slots
EnableOn: !o FighterA & o FighterBayA
OnEnd: d FighterBayA d LoadoutToken g LoadoutSlot
CronA5: Transfer counters back to fighters and cycle up the mod-counter
EnableOn: o Counter
OnEnd: d Counter g FighterA s2

So here's what happens:
1. The first time your pilot lands, the State 0 missions are started. Once a counter has been started there is no way to exit it, so this is the safest way to initialise the counters and make sure they never get started more than once (a mission will not be offered if it is already running).
2. When you enter the outfitter, a mission that grants you temporary fighter bays is started to make sure you can actually buy the fighters. This mission is also started if you buy a new ship, in case you previously entered the outfitter (it can only be started from the outfitter once per land).
3. Each UniversalBay you bay buy gives you a LoadoutSlot. This represents the number of bayfulls of fighters you're allowed.
4. When you purchase fighters the corresponding counter is cycled:

• The first FighterA you buy cycles Counter A, moving from State 0 to State 1 which swaps a LoadoutSlot for a LoadoutToken and a FighterBayA, and sets b1 to indicate that you have a partially-filled bay. You must either have a free LoadoutSlot or be in a partially-filled state in order to buy a fighter.

• The second FighterA you buy moves you from State 1 to State 2, but nothing else happens.

• The third FighterA you buy moves you from State 2 back to State 0, which clears b1 to indicate that this bay is now full. The process then repeats itself, and is similar for FighterB.

5. When you leave the planet, the first cron removes the temporary bays that were granted.
6. The recalculation crons then do their stuff with every passing day:

• If you have no fighters deployed, everything gets reset and it cycles you up from State 0 again according to the number of fighters you have. This makes sure you're in the correct state if you've lost (or captured) any fighters and that any empty bays are exchanged for slots.

• You can only capture fighters to replace lost ones or to fill a partially-filled bay. If you have any deployed fighters when the crons run, they can't be sure how many you actually have and so must assume that you have the maximum allowed - the counter will be reset to State 0 but nothing else will change.

7. When you land again, your invisible Advance Date mission runs to force the recalculations.

... And that's about it. Hope someone can make sense of it all, provided I haven't made any mistakes (it still causes me headaches). A few more thoughts to leave you with...

If you make the Advance Date mission available in the outfitter rather than the spaceport, you can set a bit that all your crons require (and end with one more cron to clear the bit) to make the recalculations run only when you enter the outfitter and not when jumping around. This gives you the (minor) advantage that when you lose fighters you'll have more opportunity to capture replacements before the crons remove your empty bays.

If this isn't complex enough for you, Method 2 could probably be combined with this one to allow fighters to take up mass/cargo space. If you did this you wouldn't need to bother with the temporary bays - you don't purchase the fighter ammo directly so you aren't restricted by the MaxAmmo.

For more crazy ideas with fighters, see Desprez's topic, Revamping the mechanics of EVO.

This post has been edited by Guy : 16 May 2014 - 12:34 AM

Maybe I missed it in the jargon, but what when the player captures a ship that can use the bays? Are the bays on it already set?

No, the temporary bays are granted when entering the outfitter and removed when you leave the planet. They must not be present in-space else you would be able to capture more fighters than you're allowed. Does that answer your question or was it something else you were thinking of?

There is one possible exploit that exists: If you have fighters deployed when you capture another ship, the deployed fighters remain in your control rather than staying with your old ship (now your escort). If your new ship has the appropriate bays then you can recall the fighters and keep them (if it doesn't it makes the fighters very confused when you try to recall them), and if the ship happened to still have some of its own fighters on-board when you captured it then it's possible to exceed the maximum allowed.
You could certainly add some logic to deal with this if you felt it was a problem but I'll leave that as an exercise for the reader.

This post has been edited by Guy : 14 May 2014 - 10:07 PM

The situation I'm thinking of is this: if one buys a ship that doesn't have bays, and then adds bays to it, the process triggers so players will only get what they're supposed to. But if a player captures a ship that already has bays on it, and uses that ship as their own, will they have to go through the process again next time they land, or will the bays already be set for a specific fighter?

Ships that come with bays should have all the necessary weapons, ammo, and outfits already equipped on them. E.g. a Carrier comes with 6 FighterAs and 4 FighterBs. Since there are 3 FighterAs or 2 FighterBs to one bay, the ship will come equipped with 2 of each type of bay (the weapons) plus 4 UniversalBays (the outfit you purchase) and 4 LoadoutTokens. So yes, the bays are set for the fighters it carries, which is the same whether you buy or capture. The temporary bays required while in the outfitter are granted OnPurchase if you buy the ship or otherwise simply by entering the outfitter.
Does this help or am I still missing your question?

No, I get it now. Well, the answer to my question, anyway. The actual coding seems a bit over my head right now, but that's fine. Thanks.