Cron-less counting

or state machine

In the original version of rEV, the Confed Fighter Bay system was supposed to let you hold either 3 Patrol Ships or 2 Gunboats per bay expansion. This didn't work. In the course of working out the multiple fighter types methods I decided to sit down and think about this problem too. It needs a mod-3 counter for the Patrol Ships and a mod-2 counter for the Gunboats. A mod-2 counter is trivial: 1 ncb which you toggle every time you buy or sell a gunboat. The mod-3 counter is the tricky bit - the counting system must be actively working within the outfitter, so while crons could probably do the job easily enough they would not be suitable because you would have to keep advancing the date every time you buy or sell a fighter just to make them fire. But I decided it ought to be possible using some system of aborting missions as conditionals. It took me a surprisingly long time to see this solution, which I have implemented in the latest rEV beta.

Mission 1: Cycle
OnAbort: A4 A3 A2 A5
(Self-aborting. This mission is just a shortcut to cycle the counter.)

Mission 2: State 0
OnAbort: S3

Mission 3: State 1
OnAbort: S4

Mission 4: State 2
OnAbort: S5

Mission 5: Wrap
OnAbort: S2

Mission 2 will be started when you start the game, so you begin in state 0. Whenever you want to increment the counter (buy a Patrol Ship) you start Mission 1, which will abort all the other missions (to decrement just cycle it twice). The aborting has to be done in a particular order to ensure that it only increments by 1 state.
When you're in State 0: Missions 4 and 3 aren't active so nothing happens with these. Mission 2 gets aborted next which starts Mission 3, putting you into State 1. Nothing happens with mission 5 either.
When you're in State 1: Similar thing happens and we end up in State 2.
When you're in State 2: Mission 4 gets aborted which starts Mission 5. Missions 3 and 2 aren't active so nothing happens with these. Finally mission 5 gets aborted, which was just started, and this now starts mission 2 which puts us back into State 0.

This is all well and good and I set a bit to indicate which state we're in and use this to control purchasing of fighters. If you start filling a bay with one type of fighter, you can't purchase any of the other type until you fill the first bay (more or less). But it could be better. What I'd like to do is grant an outfit with each complete cycle of the counter to keep track of how many bays are in use vs how many are empty. Easy enough to grant the outfit when moving from State 0 to State 1, but we also need to be able to remove it somehow. Make a distinction between cycling forwards and cycling backwards. Since my brain already hurts from thinking about all this too much I thought I best put it out to the Dev Corner to see if some other smart person can work out a solution

(This is completely unrelated but I also made a weird discovery: AI fighters with mass >=200 will not attack until the parent's shields drop below 2/3rds)

(UPDATE)
Not sure how I missed this, but it turns out the solution to keeping track of bays is actually trivial:
First grant the outfit (a bay token) whenever moving from State 0 to State 1 (State 0's OnAbort).
Then remove the outfit whenever you decrement the counter (sell a Patrol Ship).
That's it!
Because decrementing works by cycling the counter twice, whenever you decrement from State 0 to State 2, or from State 2 to State 1, the counter has to leave State 0 at some point along the way. The outfit will be added and subsequently removed, resulting in no change. Only when you decrement from State 1 to State 0 will the outfit actually be removed (the bay is now empty so we return the token).
This not only allows the purchasing/selling system to be smoother (see Qaanol's scenario below) but it also opens the door for allowing fighters to be captured. I've updated the Multiple Ammo Types topic with a new Method 3 which explains this.

This post has been edited by Guy : 06 May 2014 - 02:03 AM

Cool stuff! Nice for small counters.

Quote

(This is completely unrelated but I also made a weird discovery: AI fighters with mass >=200 will not attack until the parent's shields drop below 2/3rds)

Weeeeird. I feel like this fact should get archived somewhere. In the member-run FAQ? I don't know where, really. The counter should definitely get linked in "Cool Nova Hacks"

Agreed, the fighter mass problem is one for "Cool Nova Hacks."

Is this robust in the case where fighters die in combat (or are salvaged from a carrier)?

What if I want 2 bays, with exactly 1 Gunboat in one and exactly 2 Patrol Ships in the other?

Given the constraints of the Nova engine, it seems far simpler to just make 2 different expansion bay outfits for sale.

Losing fighters is not a problem, I just made sure the cron setup (method 1 in the other topic) resets the mission state as well. Salvaging is not permitted (Patrol Ships can't be disabled anyway but I had to give Gunboats zero crew).

As it stands, if you want 1 Gunboat and 2 Patrol Ships you would have to first buy 2 Gunboats, then 2 Patrol Ships, then sell 1 Gunboat. If the problem I mentioned at the end could be solved then you wouldn't have to do it that way but this is unlikely to be an issue anyway.

It would be simpler, yes, that's how I had it previously. But why settle for the simple? (it's only complex in the coding, to the player it still is simple)

@guy, on 30 August 2012 - 09:13 PM, said in Cron-less counting:

It would be simpler, yes, that's how I had it previously. But why settle for the simple? (it's only complex in the coding, to the player it still is simple)

Unless they hit the mission limit, then you get weird issues.

I've been trying to think about the problem further but I keep running up against the same two issues:
1. Missions can be started multiple times. I'm sure people could find a use for this if they really wanted to but I would say in most cases it's undesirable.
2. There's no other way to deactivate a missions besides Axxx. Fxxx is a useless operator because it neither removes a missions nor triggers OnFail. There's also no operator to make a mission succeed.

The BITEC is supposed to use some trick with visbits to force success of a mission but visbits don't change immediately and I couldn't actually get this to work anyway. Note his method also seems to imply that OnFail is triggered by Fxxx. Can anyone else verify these things or has Nova actually changed behaviour since then?