Update on Rewrite and Musings on Sub-pulses

[Steve Walmsley (OP)]

Back from Italy and straight back into the rewrite. If I had realised before I started just how huge this would turn out to be, I might have never started

The easiest way to describe my progress is through a description of the performance tests I have been running in my own Trans-Newtonian campaign. I decided to use that rather than start a new one because I wanted to test the changes in a reasonably well-developed campaign. I have only been testing short timescales so far because I am almost at the point of firing at alien invaders in the Salt Lake system but a 5 second turn and a 1 hour turn aren't very different in terms of the code that is executed.

A basic 5-second increment for the  Trans-Newtonian campaign now runs in about 3.5 seconds, including loading all of the fleets, ships, sensors, contacts, orders, missiles, pops, into memory, saving any changes after movement and combat, setting up all the NPR movement and combat, checking default and conditional orders, etc.. Where it gets interesting is that a 30 second increment with 6 sub-pulses only requires 4 seconds and a 2 minute increment with 24 sub-pulses is 5.8 seconds. In other words, once the basic requirements of the code are achieved, additional sub-pulses require approximately 0.1 seconds each.

This has considerable implications for running the game. Rather than being reserved for occasional use, sub-pulses can become the standard, enabling many detection cycles to take place during a increment and reducing the chances of NPRs or missiles appearing on top of one of your task groups. Other types of interrupt events will shorten the increment as they will be checked during each sub-pulses, which will enable much more efficient use of your fleets. The question that I am now pondering is whether to leave sub-pulses up to the player or just remove the sub-pulse buttons (which is my preference) and instead add an intelligent number of sub-pulses automatically. For example, if the turn is less than say 30 seconds, there would be no sub-pulses. For a one hour turn, perhaps 30x2 minute sub-pulses and for a one-day increment, perhaps 48 or 72 sub-pulses for 30 or 20 minute pulses. Maybe for a 5-day increment the sub-pulses could be an hour (120 sub-pulses). This means that players wouldn't have to worry about setting sub-pulses or using the wrong number and new players wouldn't even have to know they exist. I am interested to hear opinions on this idea.

I still have a check for inbound missiles that may shorten the turn, although I won't be checking detection by the target. Instead, each missile salvo is checked against its target (or any onboard sensors are checked to find a target) and the maximum turn length is based on how long the missile will take to arrive, assuming the target is on a reciprocal heading. If the increment size is reduced due to the projected missile flight time, it will be divided in many small increments allowing a lot of detection chances (by the target and any other forces nearby) as the missiles approach.

Steve

[sloanjh]

Back from Italy

Welcome Back!!!

First, I want to say thanks for all the work you've been putting into this stuff - it's greatly appreciated!!  And the performance numbers sound great!

This has considerable implications for running the game. Rather than being reserved for occasional use, sub-pulses can become the standard, enabling many detection cycles to take place during a increment and reducing the chances of NPRs or missiles appearing on top of one of your task groups. Other types of interrupt events will shorten the increment as they will be checked during each sub-pulses, which will enable much more efficient use of your fleets. The question that I am now pondering is whether to leave sub-pulses up to the player or just remove the sub-pulse buttons (which is my preference) and instead add an intelligent number of sub-pulses automatically. For example, if the turn is less than say 30 seconds, there would be no sub-pulses. For a one hour turn, perhaps 30x2 minute sub-pulses and for a one-day increment, perhaps 48 or 72 sub-pulses for 30 or 20 minute pulses. Maybe for a 5-day increment the sub-pulses could be an hour (120 sub-pulses). This means that players wouldn't have to worry about setting sub-pulses or using the wrong number and new players wouldn't even have to know they exist. I am interested to hear opinions on this idea.

My gut reaction when I read this was "I'd like to continue to be able to override the sub-pulse length that Aurora has chosen".  In other words, I'd prefer that the "no sub-pulses" setting actually be a "Aurora chooses sub-pulses".  The reason for this gut reaction is that the sub-pulse size is another knob one can turn in order to work around unforseen problems.  The most obvious example is if I really do want to run the next 5 minutes with 5-second sub-pulses because I know something's going to happen and that's more efficient than doing 5 1-minute updates.  Reading the next paragraph confirmed this gut reaction for me.

I still have a check for inbound missiles that may shorten the turn, although I won't be checking detection by the target. Instead, each missile salvo is checked against its target (or any onboard sensors are checked to find a target) and the maximum turn length is based on how long the missile will take to arrive, assuming the target is on a reciprocal heading. If the increment size is reduced due to the projected missile flight time, it will be divided in many small increments allowing a lot of detection chances (by the target and any other forces nearby) as the missiles approach.

I've been blowing up a lot of NPR survey ships lately, using missile salvos that are only ~2x faster than the targets.  One thing that's frustrating is that the target is running away from me, and I know it should take 2 minutes and 10 seconds for my missile to catch it, but Aurora stops my 2 minute (in 1 sub-pulse) update at e.g. 63 seconds because (I suspect) of the reciprical heading assumption.  Since sub-pulses are so fast, why not leave the total increment time alone and adjust the length of the sub-pulses?  E.g. the first sub-pulse might be 55 seconds, the next 25 seconds, the next 15, the next 10, then a bunch of 5 second sub-pulses until the missile catches the target (at which point an interrupt can go off and the update ends).

I recently found a work-around to avoid this issue in 4.0b - If I use 30 second sub-pulses for my 2 minute update, then the cut-off calculation doesn't seem to kick in and I can get much closer.

BTW, I had a similar problem with some beam-armed NPR ships chasing one of my non-combatants (a tug).  They started at ~300k km range, and the tug only had a slight (6000 vs 5773) speed advantage.  When I tried to do e.g. a 2 minute update, Aurora shortened the interval to e.g. 5.4 seconds (not sure if there was a decimal - I might be off by an order of magnitude on the times, but the principal's the same).  The next try was 5.8, then 6.3, etc.  I figured out that (I think) it was playing the reciprocal game for the chase that was going on - the way I got around it was to choose my sub-pulse to be shorter than the Aurora cut-off, and then I could do a long impulse.  So I did e.g. 2 minute impulses with 5 second sub-pulses until the cut-off was bigger (due to the tug getting further away) than 30 seconds, then went to 5 minutes with 30 second sub-pulses, and so on.  This is the sort of work-around I was talking about above when I said my gut says I still want the ability to control the sub-pulse time if I have to.

Another BTW, the cut-off code can result in time increments which aren't a multiple of 5 seconds, such as the 63 seconds I cited above.  You might want to round down to the nearest multiple of 5 seconds (that isn't 0 seconds ).

Best,
John

Thanks again,
John

[Brian Neumann]

Based on the numbers you gave, I would make the sub-pulses automatic.  No need for the player to have to set them manually.  The only exeption might be if they are expecting an attack but want to move forward in fairly large chunks,  ie defending near a wp.  In that case I might want to deal with the slowdown that having 5 second sub-pulses would inflict even if I was doing 5 day updates.  It would probably still be faster than doing smaller updates multiple times.  The easiest way to deal with this would be a check box that toggles for either 5 or maybe 30 second sub-pulses when doing a month at a time.

Brian

[Paul M]

I like the idea of automatic subpulses as well, just because I've accidently hit 5 day update when I ment to hit the review events button...it was late and I was a bit groggy.  Also frankly automatic selected sub pulses will be easier for you to do, check and debug since you won't need to deal with user selected stuff.  For the most part other people do things with programs I write that never fail to astound me (gob smacked look on my face followed by:  "Freak me green and call me Kermi but why did you even think to do that?") so I assume that I and others will do the same here.

Hope you enjoyed Italy.

[sloanjh]

In that case I might want to deal with the slowdown that having 5 second sub-pulses would inflict even if I was doing 5 day updates.  It would probably still be faster than doing smaller updates multiple times.

A couple of benchmarks people might find useful in the discussion:

At 0.1 seconds per sub-pulse, a 5 day update with 5 seconds sub-pulses would take ~2.4 hours.  

With a 3 second overhead for an update, i.e. update costs 3 + 0.1*N_sub_pulses, the break-even point (where it takes twice as long to do 5 second sub-pulses as to do 1 sub-pulse) is for a ~2.5 minute update.

Note that I'm very much in favor of automated sub_pulses - it's just that I want to be able to control them myself if the AI that controls them gets into trouble.

John

[Steve Walmsley (OP)]

My gut reaction when I read this was "I'd like to continue to be able to override the sub-pulse length that Aurora has chosen".  In other words, I'd prefer that the "no sub-pulses" setting actually be a "Aurora chooses sub-pulses".  The reason for this gut reaction is that the sub-pulse size is another knob one can turn in order to work around unforseen problems.  The most obvious example is if I really do want to run the next 5 minutes with 5-second sub-pulses because I know something's going to happen and that's more efficient than doing 5 1-minute updates.  Reading the next paragraph confirmed this gut reaction for me.

That's a good idea. I could simply add an automated sub-pulses option and make that the default.

I still have a check for inbound missiles that may shorten the turn, although I won't be checking detection by the target. Instead, each missile salvo is checked against its target (or any onboard sensors are checked to find a target) and the maximum turn length is based on how long the missile will take to arrive, assuming the target is on a reciprocal heading. If the increment size is reduced due to the projected missile flight time, it will be divided in many small increments allowing a lot of detection chances (by the target and any other forces nearby) as the missiles approach.

I've been blowing up a lot of NPR survey ships lately, using missile salvos that are only ~2x faster than the targets.  One thing that's frustrating is that the target is running away from me, and I know it should take 2 minutes and 10 seconds for my missile to catch it, but Aurora stops my 2 minute (in 1 sub-pulse) update at e.g. 63 seconds because (I suspect) of the reciprical heading assumption.  Since sub-pulses are so fast, why not leave the total increment time alone and adjust the length of the sub-pulses?  E.g. the first sub-pulse might be 55 seconds, the next 25 seconds, the next 15, the next 10, then a bunch of 5 second sub-pulses until the missile catches the target (at which point an interrupt can go off and the update ends).

Although I hadn't considered the idea of diminishing rather than static sub-pulses, I did consider ignoring target speed and looking at just missile flight time. However, on the basis that many early anti-missile escorts have a detection and engagement range of less than one million km, a 20,000 km missile (for example) could cover that engagement envelope in 50 seconds. To ensure early detection I guess the sub-pulse would have to be around 10 seconds. For a missile with a two hour flight time that means 720 sub-pulses, or about 75 seconds for the increment (for my machine in debug mode anyway - other systems may be better or worse). The diminishing sub-pulses idea is a fascinating one, although it might be tricky to figure out the right rate of decrementation. How about a modified version of that idea? The total increment size is set to the max missile flight time (or the selected increment size - whichever is smaller). The sub-pulses proceed as normal without the missiles being a consideration, up to the point where they could conceivably intercept the target based on a reciprocal course. At that point they switch to a much smaller sub-pulse size until the end of the increment. As an alternative, the max length could be set to the max intercept time assuming a chase course but that could be different for a separate simultaneous missile attack that has a longer minimum time. Using max missile flight time is simpler and covers all bases and the increment will end anyway at the point of attack or detection of any salvo.

As an example, assume the player selects 1 day as the increment size and the normal sub-pulse time is 30 minutes (48 sub-pulses - 8 seconds). Aurora checks and finds a missile with a 20,000 km/s speed and a two-hour endurance 144m max range (which is definitely on the side of caution) en route to a target moving at 4000 km/s. The target is 80m kilometers away. The flight time to the target assuming a reciprocal course is 80m/24,000 km/s = 3333 seconds or almost 56 minutes. I could perhaps do a quick calculation at this point to work out the rounded up number of sub-pulses (2) and then divide the time to get two 28 minute sub-pulses. From that point on the increment would continue with 10 second increments. If the target was stationary, the missiles would be 13m kilometers away and the turn would last another 650 seconds - 65 sub-pulses. If the target was running, it would be at 26m and the missiles would require another 1625 seconds to overtake with a 16,000 km/s speed advantage, which is 163 increments. That is still almost 20 seconds for the increment. Not sure if that would be acceptable.

A third option may be to work out the minimum possible intercept time assuming a reciprocal course, leave sub-pulses at the standard size until that point and then run the missile interception check code again to determine if a new sub-pulse size is required. That adds a slight overhead but it's probably less than using too many small sub-pulses. If the new minimum intercept time is less than the standard increment, use one smaller increment and then go to 10 seconds. How does that sound?

I recently found a work-around to avoid this issue in 4.0b - If I use 30 second sub-pulses for my 2 minute update, then the cut-off calculation doesn't seem to kick in and I can get much closer.

The missile check is only run for increments greater than 30 seconds :-) ).[/quote]
Good suggestion.

Steve

[Steve Walmsley (OP)]

Based on the numbers you gave, I would make the sub-pulses automatic.  No need for the player to have to set them manually.  The only exeption might be if they are expecting an attack but want to move forward in fairly large chunks,  ie defending near a wp.  In that case I might want to deal with the slowdown that having 5 second sub-pulses would inflict even if I was doing 5 day updates.  It would probably still be faster than doing smaller updates multiple times.  The easiest way to deal with this would be a check box that toggles for either 5 or maybe 30 second sub-pulses when doing a month at a time.

Even with much faster sub-pulses, you wouldn't want to select 5 or 30 seconds for a month long turn. For 30 day increments, I would probably set the sub-pulse to several hours. Even with a 3 hour sub-pulse, it would still take almost 30 seconds to run an increment. To avoid the situation you describe, I will probably look at checking for transits into potentially hostile systems and set the maximum increment size accordingly.

Steve

[welchbloke]

I'm also in favour of automated sub-pulses.  I think I've already got enough to think about without fiddling with the sub-pulses.  I find it distracts from my enjoyment when I'm a bit tired and grumpy  

[Steve Walmsley (OP)]

I like the idea of automatic subpulses as well, just because I've accidently hit 5 day update when I ment to hit the review events button...it was late and I was a bit groggy.  Also frankly automatic selected sub pulses will be easier for you to do, check and debug since you won't need to deal with user selected stuff.  For the most part other people do things with programs I write that never fail to astound me (gob smacked look on my face followed by:  "Freak me green and call me Kermi but why did you even think to do that?") so I assume that I and others will do the same here.

Yes, I have seen a few of those situations

Hope you enjoyed Italy.

Well, two days before we left the holiday company told me I needed to show a credit card for the hire car. I don't have a credit card and the villa was 2.5 hours from the airport. After several hours of wrangling, during which I seriously doubted we would be going at all, the holiday company eventually agreed to put the car on their credit card - so we had to stay in the villa for the last two days. On arrival on Rome Airport we found the departure gate and settled in with plenty of time to spare. Ten minutes before boarding was due to start, they changed the gate but didn't announce it. Fortunately I happened to notice it on a screen and told some of the other passengers. The new gate was in an entirely different part of the airport. We had to catch a monorail back to the main part of the airport, go back through security because they told us we could have just got off a plane (even though we had boarding cards) and then run to the new gate. There was a plane for the right airline on the tarmac twenty yards from the gate across a small road but instead they loaded us on to a very hot airport bus parked between the gate and the plane. After twenty minutes of slowly getting people on to this bus they drove it around the plane and parked next to it, literally 15-20 yards from the starting point. Then everyone had to get off the bus and on the plane. I assume there must have been some health and safety rule about not crossing the small road !!

After taking off an hour late, we finally arrived back in England only to find our luggage didn't manage to get on the same plane as we did - double aaaaghhhhh! We filled in all the necessary forms and pointed out to a few officials that their airline had room for some improvement. Our luggage finally made it home yesterday.

Despite the above, we all did enjoy the rest of the holiday. The villa was huge and well-presented with a nice pool, a lot of forested grounds and a view of at least twenty-five miles across Lake Trasimeno and to the mountains beyond. The scenery throughout Tuscany and Umbria was superb, as was the food and the wine. We visited Assisi, Siena, Montefalco and the largest man-made waterfall in the world at Cascata delle Marmore, built by the Romans in 290 BC. It is 540 feet high and split into three cascades with the first being 270 feet. Myself and the girls climbed up a mountain path and went through a man-made tunnel that comes out on a small, rocky balcony extremely close to the base of the first cascade. When you emerge on the balcony, you are immediately drenched by the water and your vision is blurred but when you look up there is an amazing scene of white water filled with rainbows stretching upwards for what seems like forever into a sunny blue sky. A serious Wow factor and truly one of the best things I have ever seen. I would go back to Italy just for another minute on that small rocky balcony.

Steve

[welchbloke]

We phoned the bank in England and watched the charge on the phone as we went through the usual, incredibly frustrating series of automated questions before finally speaking to a spectactularly unhelpful person in a call centre. After speaking to a supervisor three times and getting disconnected twice, we finally sorted out the problem and were able to get some money out of the ATM. The mobile was virtually dead by this point and my wife wasn't far behind.

Sorry to hear this, my bank will stop cards once they have been used overseas if you don't notify them that you're overseas. I have to admit I like this.  On the flip side, they have an excellent overseas phone line that deals with any stopped cards.  I learnt a while ago to make sure that I ring them and let them know I'm travelling now; its really embarassing when both your cards get handed back as they've been stopped  

When you emerge on the balcony, you are immediately drenched by the water and your vision is blurred but when you look up there is an amazing scene of white water filled with rainbows stretching upwards for what seems like forever into a sunny blue sky. A serious Wow factor and truly one of the best things I have ever seen. I would go back to Italy just for another minute on that small rocky balcony.
Steve

Sounds like the trip was worth all the trials and tribulations.

[sloanjh]

As an example, assume the player selects 1 day as the increment size and the normal sub-pulse time is 30 minutes (48 sub-pulses - 8 seconds). Aurora checks and finds a missile with a 20,000 km/s speed and a two-hour endurance 144m max range (which is definitely on the side of caution) en route to a target moving at 4000 km/s. The target is 80m kilometers away. The flight time to the target assuming a reciprocal course is 80m/24,000 km/s = 3333 seconds or almost 56 minutes. I could perhaps do a quick calculation at this point to work out the rounded up number of sub-pulses (2) and then divide the time to get two 28 minute sub-pulses. From that point on the increment would continue with 10 second increments. If the target was stationary, the missiles would be 13m kilometers away and the turn would last another 650 seconds - 65 sub-pulses. If the target was running, it would be at 26m and the missiles would require another 1625 seconds to overtake with a 16,000 km/s speed advantage, which is 163 increments. That is still almost 20 seconds for the increment. Not sure if that would be acceptable.

A third option may be to work out the minimum possible intercept time assuming a reciprocal course, leave sub-pulses at the standard size until that point and then run the missile interception check code again to determine if a new sub-pulse size is required. That adds a slight overhead but it's probably less than using too many small sub-pulses. If the new minimum intercept time is less than the standard increment, use one smaller increment and then go to 10 seconds. How does that sound?

I think #3 is what I was thinking of, with the added bit of recalculating the reciprocal course limit at each reciprocal course break.  So in your example,the first increment would be 30 minutes, the next would be ~26 minutes (30+26 = 56, which is the reciprocal estimate).  Actually, it should be a little less, since the range to the target should have the biggest detection range in the target's stack subtracted off from it - let's say the subtracted distance is 80K.  The actual flight time was 80m/24k = 5k seconds, so there's still ~1667 seconds left (assuming the target's running - I think this was your 1625; I suspect we're rounding differently) and the range is (1/3)*80m ~26m.  A new reciprocal calculation is done, giving 1111 seconds (1/3 of the first one) or about 19 minutes.  You could either do two subpulses - one of 4 minutes to get back to the 30 minute sub-pulses (4+26=30) and one of 15 minutes (4+15=19) or simply do a single 19 minute subpulse and keep track of total elapsed time within the increment.  [INSERT BIG REALIZATION DESCRIBED BELOW HERE]  The next step would be 1111/3 ~370 seconds, then ~123 seconds, ~41 seconds, etc until 5 second increments kick in or the increment runs out of time or the missiles are detected and Aurora breaks.

Ok, the big realization was that I screwed up the example.  What I should have said was that 56 minutes is bigger than 30 minutes so the first sub-pulse is 30 minutes.  At that point, the range is 80m - 1800*16k = 51.2m, and Aurora redoes the reciprocal calculation.  51.2/24k = ~35.5 minutes, which is still less than 30 minutes, so we do another 30 minute increment, and the range is now 22.4m.  22.4m/24K = ~15.5 minutes, so that's the next sub-pulse length.  At that point, each sub-pulse is knocking the range down by a factor of 3 just like in the previous paragraph.

I recently found a work-around to avoid this issue in 4.0b - If I use 30 second sub-pulses for my 2 minute update, then the cut-off calculation doesn't seem to kick in and I can get much closer.

The missile check is only run for increments greater than 30 seconds

That's funny - I could have sworn I saw a couple of 26 second advances on 30 second increments.

[EDIT] Drat - finger slipped onto "submit" button!

I wanted to say that the advantage of redoing the reciprocal check every pulse comes from targets that are running from a missile which doesn't have a big speed advantage - the reciprocal cutoff point will "run away" from its initial position as the missile moves within the sub-pulses, giving a longer time of full-size increments.

John

[ShadoCat]

That sounds really good.

[Steve Walmsley (OP)]

I have added the logic for the missile interceptions so I'll post it here for a logic check

Code: [Select]

// Before this function is run, the length of the increment and the length of each sub-pulse have been setup

If the length of the increment > 120 seconds Then

Run check on potential missile interceptions and get minimum and maximum flight time for earliest potential interception

If the minimum flight time is less than the increment length then
   
Set increment length to maximum flight time (unless it is already shorter than that)

If the max flight time is less than ten minutes then
Set the sub-pulse to 10 seconds and exit this function
Else
If Min Flight Time < Sub Pulse Length then
Sub Pulse Length = Min Flight Time rounded down to nearest 5 seconds
Set Check Sub Pulse Flag to recheck after 1 sub-pulse
Else
Set Check Sub Pulse Flag to recheck after (Min Flight Time / Sub Pulse Length) sub-pulses
End if
End if
End if
End if

// Skip now to the sub-pulse loop

// movement and sensor phase
Sub Pulse Count = 0
Do While Interrupt = False And Time Passed < Increment Length
   
  Game Time = Game Time + Sub Pulse Length
Time Passed = Time Passed + Sub Pulse Length
   
   Move Everything
Check All Sensors
Check Fire Control Locks
   
    Sub Pulse Count = Sub Pulse Count + 1
   
   // if a new missile interception check is scheduled for this sub-pulse, run the necessary code
If Check Sub Pulse Flag = Sub Pulse Count Then
       
  Run check on potential missile interceptions and get minimum and maximum flight time for earliest potential interception

  If Min Flight Time < Increment Length - Time Passed Then

If the max flight time is less than ten minutes then
Set the sub-pulse to 10 seconds and exit this section
Else
If Min Flight Time < Sub Pulse Length then
Sub Pulse Length = Min Flight Time rounded down to nearest 5 seconds
Set Check Sub Pulse Flag to recheck after 1 more sub-pulse
Else
Set Check Sub Pulse Flag to recheck after (Min Flight Time / Sub Pulse Length) more sub-pulses
End if
End if
       End if
End if
Loop
Steve

[sloanjh]

I have added the logic for the missile interceptions so I'll post it here for a logic check

Code: [Select]

// Before this function is run, the length of the increment and the length of each sub-pulse have been setup

If the length of the increment > 120 seconds Then

Run check on potential missile interceptions and get minimum and maximum flight time for earliest potential interception

If the minimum flight time is less than the increment length then
   
Set increment length to maximum flight time (unless it is already shorter than that)

If the max flight time is less than ten minutes then
Set the sub-pulse to 10 seconds and exit this function
Else
If Min Flight Time < Sub Pulse Length then
Sub Pulse Length = Min Flight Time rounded down to nearest 5 seconds
Set Check Sub Pulse Flag to recheck after 1 sub-pulse
Else
Set Check Sub Pulse Flag to recheck after (Min Flight Time / Sub Pulse Length) sub-pulses
End if
End if
End if
End if

// Skip now to the sub-pulse loop

// movement and sensor phase
Sub Pulse Count = 0
Do While Interrupt = False And Time Passed < Increment Length
   
  Game Time = Game Time + Sub Pulse Length
Time Passed = Time Passed + Sub Pulse Length
   
   Move Everything
Check All Sensors
Check Fire Control Locks
   
    Sub Pulse Count = Sub Pulse Count + 1
   
   // if a new missile interception check is scheduled for this sub-pulse, run the necessary code
If Check Sub Pulse Flag = Sub Pulse Count Then
       
  Run check on potential missile interceptions and get minimum and maximum flight time for earliest potential interception

  If Min Flight Time < Increment Length - Time Passed Then

If the max flight time is less than ten minutes then
Set the sub-pulse to 10 seconds and exit this section
Else
If Min Flight Time < Sub Pulse Length then
Sub Pulse Length = Min Flight Time rounded down to nearest 5 seconds
Set Check Sub Pulse Flag to recheck after 1 more sub-pulse
Else
Set Check Sub Pulse Flag to recheck after (Min Flight Time / Sub Pulse Length) more sub-pulses
End if
End if
       End if
End if
Loop
Steve

Hi Steve,

  Looks good.  Here are a few potential gotchas I noticed while reading through the code.

1)  Make sure to round (Min Flight Time / Sub Pulse Length) down.

2)  If the Min Flight Time < sub pulse length branch kicked in, then the total increment time will probably be greater than Increment Length unless you get an interrupt.

3)  I liked the "sub-pulse at 10 seconds if total time is < 10 minutes" - this should only take about 10 seconds total of wall clock, which is about what I'm running right now with my increments, and it saves a lot of complexity.

4)  Assuming the missile is undected, (I think) the minimum flight time needs to be flight time to detection, otherwise there's a good chance that the missile will magically pop up 4 seconds out from the target, even if the target (or another unit in the target's fleet) can detect it 30 seconds out.  I think you'll need to check both co-located ships and their escorts to take into the account of radar pickets along the threat axis - otherwise there's a good chance the missile will zip right by the pickets without being seen.  This means that there's actually two different branches in the "min/max flight time" calculation code - one for an undetected missile, and one for a detected one.  The good news is that a detected missile should generate an interrupt (which should then be followed by another increment if it's an NPR-on-NPR battle), so you'll only hit one branch in one increment.

John

[Steve Walmsley (OP)]

 Make sure to round (Min Flight Time / Sub Pulse Length) down.

I'd done that in the code but not included it in the logic.

2)  If the Min Flight Time < sub pulse length branch kicked in, then the total increment time will probably be greater than Increment Length unless you get an interrupt.

I'm not sure why. To be at this point in the code, the Min Flight TIme is already checked as being shorter than both the increment and the sub-pulse. The single sub-pulse added to match the min flight time should therefore be shorter than the increment.

3)  I liked the "sub-pulse at 10 seconds if total time is < 10 minutes" - this should only take about 10 seconds total of wall clock, which is about what I'm running right now with my increments, and it saves a lot of complexity.

Yes, I thought any complications were likely to occur if I tried to get clever with small time periods, so I sidestepped that potential pothole

4)  Assuming the missile is undected, (I think) the minimum flight time needs to be flight time to detection, otherwise there's a good chance that the missile will magically pop up 4 seconds out from the target, even if the target (or another unit in the target's fleet) can detect it 30 seconds out.  I think you'll need to check both co-located ships and their escorts to take into the account of radar pickets along the threat axis - otherwise there's a good chance the missile will zip right by the pickets without being seen.  This means that there's actually two different branches in the "min/max flight time" calculation code - one for an undetected missile, and one for a detected one.  The good news is that a detected missile should generate an interrupt (which should then be followed by another increment if it's an NPR-on-NPR battle), so you'll only hit one branch in one increment.

The min flight time calculation already includes the detection range of the target fleet or population vs the incoming salvo. Min Flight Time is from the missile's current position to the outer edge of detection range, assuming a reciprocal course. As you mention it would be ideal to check other units near the threat axis. However, this goes back to the pre-rewrite discussion on trig. In most cases Aurora works on a simple point to point system so its not straightforward to figure out what other sensors in the system would come into play and at what point. As a more brute force approach I have considered deducting a set distance from min flight time instead of using detection range, perhaps 3-5 million kilometers, or splitting the approach phase into perhaps 10 sub-pulses to allow for detection from other sources.

Steve