Update on Rewrite and Musings on Sub-pulses

[sloanjh]

 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.

I'm not 100% sure that it will (hence the "probably" ), but the thing I'm worried about is that this branch puts you into a situation where time_elapsed is not a multiple of the original sub pulse length.  Once you get into that situation, you have to have logic that checks to see if the last sub pulse will result in a time_elapsed which is greater than the increment length, and shortens it to increment_length - time_elapsed if this is the case.  For example, lets assume that an increment length of 55 seconds has been requested (I understand this isn't one of the options, but it's just for demo purposes), that you land in the "10 seconds per sub-pulse" branch, and that the true flight time of the missile is 80 seconds because the target's running.  In this case, I'm pretty sure you'll end up doing 6 sub pulses of 10 seconds each, for a total of 60 seconds.  To get an increment of 55 seconds, you'd need to have code to detect this and shorten the last sub pulse to 5 seconds.  I assume the same sort of thing can happen in the other code branch as well.

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.

Cool - didn't remember seeing it so I wanted to double-check.

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.

I was actually proposing a compromise.  At the beginning of the increment, you look at each target of a missile salvo and try and determine all members of that targets "task group".  For the purposes of language (since I'm not clear on the Aurora language)  I'm using (what I think is) Navy language: "unit" is a ship, "task group" is what used to be "Fleet" in Aurora, i.e. the thing that's kept track of on the F12 screen (and the "Fleet" table in the database), "task force" is a set of task groups which are working together to accomplish a mission (e.g. a core task group and its escort task groups), and a "fleet" is an administrative grouping which is managed by the screen in Aurora that allows commanding Admirals and their staffs to be defined (the thing you lose 1/2 your training points for if you change).  The idea is that you take the target task group and look for two things:

A)  All other task groups which are "co-located" (e.g. within either zero or e.g. 100 Kkm of the target) - put this in a list.
B)  All task groups which are escorting any task group in the co-located list (and escorts of the escorts, if any).

Now that I think of it, if the target is a picket (i.e. escorting another task group), you'll probably want to look "upstream" for the ship it's escorting before launching the "identify task force" procedure.

The idea is to scan over all the ships in the task force for "best" sensor, and then use that as the value when determining detection range for any unit in the task force that's targetted by a missile.  That way, if you've got a missile targetting a freighter with a frigate escorting it at zero range, the frigate's (presumably much better) detection range is used even though it's not the target, but you don't need to pay attention to the carrier task force 1,000 Mkm away.  Oops - just realized that the detection range of a picket (by which I mean a member of the same task force that isn't the target) should be the detection range of the picket plus the distance from the picket to the target - this takes into account the fact that the picket will probably be up-threat-axis and so able to detect the missile even earlier.

Hmmmmmm - I just had a thought - this "identify task force" stuff could probably be used to cut down on the N^2 sensor checks - basically divide all the ships in a system up into task forces before looking for "contact candidates" - basically the idea is to do a check between task forces to see if there's any hope of getting a contact before performing a more careful check between individual units in the task force.  The "divide into task forces" step should be very cheap, since if you're using zero range you can just use == on x and y and if you're using non-zero range you can sort TG in x and then compare neighbors in the sort (if there are too many things in an x bin you can then do the same thing in y, but this is unlikely), and the initial check between Task Forces should result in a much smaller "N" in the N^2.

John

[Steve Walmsley (OP)]

I'm not 100% sure that it will (hence the "probably" ), but the thing I'm worried about is that this branch puts you into a situation where time_elapsed is not a multiple of the original sub pulse length.  Once you get into that situation, you have to have logic that checks to see if the last sub pulse will result in a time_elapsed which is greater than the increment length, and shortens it to increment_length - time_elapsed if this is the case.  For example, lets assume that an increment length of 55 seconds has been requested (I understand this isn't one of the options, but it's just for demo purposes), that you land in the "10 seconds per sub-pulse" branch, and that the true flight time of the missile is 80 seconds because the target's running.  In this case, I'm pretty sure you'll end up doing 6 sub pulses of 10 seconds each, for a total of 60 seconds.  To get an increment of 55 seconds, you'd need to have code to detect this and shorten the last sub pulse to 5 seconds.  I assume the same sort of thing can happen in the other code branch as well.

I'll tackle this first as the rest of the email is on a separate, more complex subject. You could be right about the fact the total sub-pulses could add up to more than the specified increment length. However, I don't think that is an issue. The increment length is a total of the sub-pulses that actually happen and that is what is reported to the player. In most cases just being in this section of code means the increment length is probably less than that specified by the player anyway but even if it isn't, if the player specifies 1 hour and the final increment length ends up being one hour and two minutes, that shouldn't have any effect on gameplay.

Steve

[Steve Walmsley (OP)]

I was actually proposing a compromise.  At the beginning of the increment, you look at each target of a missile salvo and try and determine all members of that targets "task group".  For the purposes of language (since I'm not clear on the Aurora language)  I'm using (what I think is) Navy language: "unit" is a ship, "task group" is what used to be "Fleet" in Aurora, i.e. the thing that's kept track of on the F12 screen (and the "Fleet" table in the database), "task force" is a set of task groups which are working together to accomplish a mission (e.g. a core task group and its escort task groups), and a "fleet" is an administrative grouping which is managed by the screen in Aurora that allows commanding Admirals and their staffs to be defined (the thing you lose 1/2 your training points for if you change).  The idea is that you take the target task group and look for two things:

A)  All other task groups which are "co-located" (e.g. within either zero or e.g. 100 Kkm of the target) - put this in a list.
B)  All task groups which are escorting any task group in the co-located list (and escorts of the escorts, if any).

Now that I think of it, if the target is a picket (i.e. escorting another task group), you'll probably want to look "upstream" for the ship it's escorting before launching the "identify task force" procedure.

The idea is to scan over all the ships in the task force for "best" sensor, and then use that as the value when determining detection range for any unit in the task force that's targetted by a missile.  That way, if you've got a missile targetting a freighter with a frigate escorting it at zero range, the frigate's (presumably much better) detection range is used even though it's not the target, but you don't need to pay attention to the carrier task force 1,000 Mkm away.  Oops - just realized that the detection range of a picket (by which I mean a member of the same task force that isn't the target) should be the detection range of the picket plus the distance from the picket to the target - this takes into account the fact that the picket will probably be up-threat-axis and so able to detect the missile even earlier.

Hmmmmmm - I just had a thought - this "identify task force" stuff could probably be used to cut down on the N^2 sensor checks - basically divide all the ships in a system up into task forces before looking for "contact candidates" - basically the idea is to do a check between task forces to see if there's any hope of getting a contact before performing a more careful check between individual units in the task force.  The "divide into task forces" step should be very cheap, since if you're using zero range you can just use == on x and y and if you're using non-zero range you can sort TG in x and then compare neighbors in the sort (if there are too many things in an x bin you can then do the same thing in y, but this is unlikely), and the initial check between Task Forces should result in a much smaller "N" in the N^2.

This type of calculation is possible but it is complicated. I could run a comparison on other fleets within the system for the distance to the targeted fleet, find those within a set range and calculate their sensor chances against the missiles compared to those of the target fleet. Presumably I would base that on their distance to the missiles rather than the target fleet. This would also add some time to the real time required for the turn for each case. Finding those on the missile track is much harder. I am inclined to think that I could spend that real time running smaller increments instead. It's a lot easier and covers every fleet, population and friendly buoy/missile in the system without having to work out their proximity to the missiles. In any event, unless the fleets are on exact reciprocal courses, once the missiles get within a few game time minutes of the target, the sub-pulses will switch to ten seconds each, which will cover all possibilities on the approach. Rather than add extra calculations up front, which could turn out to be a LOT of extra calculations in a major battle, I could just increase the ten minute catch-all time to fifteen or twenty minutes.

I have recently added an extra calculation for those situations when an NPR fleet is closing on a PR fleet. Rather than carry out a lot of checks up front, which can get particularly complex if the pursuing fleet is slower and there are a lot of other units in the system, the game checks for a basic minimum intercept times. If that is less than 12 hours, the game runs a 12 hour increment with 10 minute sub-pulses (approx 10 seconds). if it is less than 24 hours, a 1-day increment with 15 minute sub-pulses is run (13 seconds). The 12 hour turn is to avoid those situations that occur at present with very small increments during pursuit situations. 10 or 15 minutes should be sufficient granularity for most ship to ship situations. I could change this if it proves not granular enough. One of the other changes I have made during the rewrite is that all NPR warship and scout movement is calculated pre-movement on every increment. Nothing is ever saved to the database. This takes about 0.7 seconds for the Trans-Newtonian campaign. Because of this, the interception check is carried out at the point the AI decides to carry out an interception. After all NPR movement is determined, the shortest interception is used as the basis for the above. Note this doesn't cover PR fleets closing on NPRs but the player will be aware that the closing is taking place and will no doubt chose smaller increments (which will have smaller auto-subpulses) in the case the NPRs turn out to be more dangerous or numerous that first thought

That still leaves one more tricky issue. What to do about transits into hostile systems? I could check for this at the start of each increment or the start of each sub-pulse. The former might take some time if several intervening jumps are also plotted so its probably better to check at the start of the sub-pulse for immediate transit orders. Even then, it's possible the fleet in question might have other orders first and the overhead of checking every fleet might have significant performance indications. Therefore I am considering a more radical approach which I thought I would run by you. It has virtually no performance cost. It does have a realism issue but probably not a gameplay issue. My idea is that I would stop the movement of any fleet that entered a system containing units of a hostile or unknown race and generate an interrupt so the increment would complete at the end of the current sub-pulse. The first possible downside is that if the game was running with 30 minute sub-pulses and the fleet entered the system after ten minutes of movement, it would lose twenty minutes of movement time. However, the other race(s) in the system in which it had arrived could not take advantage of that because they wouldn't know about it's existence during those twenty minutes because sensor checks only take place after all movement. In fact, I could refine it a little by checking for the detection of that newly arrived fleet and only stopping the fleet and generating an interrupt if it was detected or if it detected anything else, although that would have more of a performance implication. The second downside is that it might be obvious to the player that when one of his fleets enters a new system and time stops, he has entered a potentially hostile situation. Although there would probably be false alarms when another race triggers the interrupt at the same time as a transit.  I guess that is no different that the v4.0b SM events regarding alien presence in a system, although those no longer exist in v4.1. I think the benefits in terms of simplicity and performance probably outweigh the disadvantages. That is, unless I am missing something obvious, which is why I am posting the idea before implementing it

Steve

[sloanjh]

I'm not 100% sure that it will (hence the "probably" ), but the thing I'm worried about is that this branch puts you into a situation where time_elapsed is not a multiple of the original sub pulse length.  Once you get into that situation, you have to have logic that checks to see if the last sub pulse will result in a time_elapsed which is greater than the increment length, and shortens it to increment_length - time_elapsed if this is the case.  For example, lets assume that an increment length of 55 seconds has been requested (I understand this isn't one of the options, but it's just for demo purposes), that you land in the "10 seconds per sub-pulse" branch, and that the true flight time of the missile is 80 seconds because the target's running.  In this case, I'm pretty sure you'll end up doing 6 sub pulses of 10 seconds each, for a total of 60 seconds.  To get an increment of 55 seconds, you'd need to have code to detect this and shorten the last sub pulse to 5 seconds.  I assume the same sort of thing can happen in the other code branch as well.

I'll tackle this first as the rest of the email is on a separate, more complex subject. You could be right about the fact the total sub-pulses could add up to more than the specified increment length. However, I don't think that is an issue. The increment length is a total of the sub-pulses that actually happen and that is what is reported to the player. In most cases just being in this section of code means the increment length is probably less than that specified by the player anyway but even if it isn't, if the player specifies 1 hour and the final increment length ends up being one hour and two minutes, that shouldn't have any effect on gameplay.

Steve

I agree - just pointing out a possible "gotcha"

John

[sloanjh]

Hmmmmmm - I just had a thought - this "identify task force" stuff could probably be used to cut down on the N^2 sensor checks - basically divide all the ships in a system up into task forces before looking for "contact candidates" - basically the idea is to do a check between task forces to see if there's any hope of getting a contact before performing a more careful check between individual units in the task force.  The "divide into task forces" step should be very cheap, since if you're using zero range you can just use == on x and y and if you're using non-zero range you can sort TG in x and then compare neighbors in the sort (if there are too many things in an x bin you can then do the same thing in y, but this is unlikely), and the initial check between Task Forces should result in a much smaller "N" in the N^2.

This type of calculation is possible but it is complicated. I could run a comparison on other fleets within the system for the distance to the targeted fleet, find those within a set range and calculate their sensor chances against the missiles compared to those of the target fleet. Presumably I would base that on their distance to the missiles rather than the target fleet. This would also add some time to the real time required for the turn for each case. Finding those on the missile track is much harder. I am inclined to think that I could spend that real time running smaller increments instead. It's a lot easier and covers every fleet, population and friendly buoy/missile in the system without having to work out their proximity to the missiles. In any event, unless the fleets are on exact reciprocal courses, once the missiles get within a few game time minutes of the target, the sub-pulses will switch to ten seconds each, which will cover all possibilities on the approach. Rather than add extra calculations up front, which could turn out to be a LOT of extra calculations in a major battle, I could just increase the ten minute catch-all time to fifteen or twenty minutes.

I'm actually suggesting something that (I think) is a lot simpler, and would probably speed up performance, due to cutting the number of sensor checks.  The missile picket stuff is just a side-effect/bonus.

Let me describe what I'm thinking in wet-navy language (e.g. detection logic that might have been coded up for Harpoon).  Think of a 20-element CVBG, including AWACS.  Instead of modeling it as 20 point-like objects, each with its own sensor range, etc, model it as a "disk" of a certain radius, with sensor capabilities equal to the best of the 20 elements in each category and signature equal to the worst of the 20 elements in each category.  Let's say that there's a red force with 50 elements divided up into 3 groups, and a blue force with 60 elements divided up into 5 groups.  The detection phase then consists of checking between groups first using a range that's distance between disks (which is just the distance between centers minus the sum of the two radii); a "does not detect" between a pair of groups means that you don't have to check any further between elements of the groups, since there's no way they can see each other.  So in the case where the two groups are a long way away from each other, you only end up doing 30 checks (3*5 for red and 5*3 for blue), as opposed to 600 (50*30 for red and 30*50 for blue).

So the proposal is to break the ships up into groups at the start of the increment, and just leave them that way.  If you're worried about the performance of breaking them up (N^2 comparisons within a player's ships), then you could actually let the players specify which ships are operating together through a dialog - you've already got a lot of this information through the "escort" order.

I have recently added an extra calculation for those situations when an NPR fleet is closing on a PR fleet. Rather than carry out a lot of checks up front, which can get particularly complex if the pursuing fleet is slower and there are a lot of other units in the system, the game checks for a basic minimum intercept times. If that is less than 12 hours, the game runs a 12 hour increment with 10 minute sub-pulses (approx 10 seconds). if it is less than 24 hours, a 1-day increment with 15 minute sub-pulses is run (13 seconds). The 12 hour turn is to avoid those situations that occur at present with very small increments during pursuit situations. 10 or 15 minutes should be sufficient granularity for most ship to ship situations. I could change this if it proves not granular enough. One of the other changes I have made during the rewrite is that all NPR warship and scout movement is calculated pre-movement on every increment. Nothing is ever saved to the database. This takes about 0.7 seconds for the Trans-Newtonian campaign. Because of this, the interception check is carried out at the point the AI decides to carry out an interception. After all NPR movement is determined, the shortest interception is used as the basis for the above. Note this doesn't cover PR fleets closing on NPRs but the player will be aware that the closing is taking place and will no doubt chose smaller increments (which will have smaller auto-subpulses) in the case the NPRs turn out to be more dangerous or numerous that first thought

Cool!

That still leaves one more tricky issue. [SNIP]
  I guess that is no different that the v4.0b SM events regarding alien presence in a system, although those no longer exist in v4.1. I think the benefits in terms of simplicity and performance probably outweigh the disadvantages. That is, unless I am missing something obvious, which is why I am posting the idea before implementing it

Actually, this (detection of bad guys when they transit into a hostile system) is working really well in v4.0b.  As you say, (I think) an interrupt event gets generated, whether or not the WP is picketed.  In addition, Aurora seems to be calculating arrival time so that it stops at the time of transit (which shouldn't be expensive, since there's no N^2).  So I'm not sure how your idea is different/better than what's being done now in v4.0b.  I would keep things the same as v4.0b, with the following minor tweaks:

1)  Do a detection check (for that ship) when the ship transits, and only halt the increment if the ship is detected.

2)  Do a detection check on the pre-transit side too (for the transiting ship).  Right now, a bad guy who's glowing like the Sun can blow right by my pickets on the "friendly" side of a WP if a typical large increment is being used - when the increment stops, they're on the other side of the WP and undetectable.  If you knew a ship was going to make a transit, you could give the WP the ship's signature and see if anyone could detect it - if so, treat it like a missile engagement with the ship being the missile, i.e. take some smaller sub-pulses.

3)  This doesn't solve the "bouncing geo-survey" problem, where an NPR geo-survey ship keeps transiting back and forth between two fully surveyed systems, and one side of the WP is under observation.  I think that problem needs to be solved on the AI side, though.

As far as my personal preferences on the "realism" issue go, my v4.0b game has led me to the viewpoint that I'd rather err on the side of detecting things that should be detected over getting information that I'm entering a system with bad guys in it.  I also find it useful to get a "something's about to happen" indicator so that I can back up my DB in case a detection gets missed and I need to re-play with smaller increment.  I've found that I have a pretty good idea where the bad guys are if I know about the race, so the only situation where I think you'd be getting much additional info is when transiting an already explored system that the bad guys have snuck into, and even that wouldn't be a lot of info since I typically don't go looking through my fleets to see who just transited if I get an NPR interrupt.

How's that sound?

John

[Steve Walmsley (OP)]

I agree - just pointing out a possible "gotcha"

And I do appreciate that

Steve

[sloanjh]

Something that occured to me while writing the bit about "realism" in the last post....

In my next game, I think I'm probably going to turn off the computer-controlled NPR.  The reason for this is that they don't seem to be running their civilizations aggressively enough - I've been in contact with 2-3 (much higher tech) NPR for 5-10 years now and they've been ineffective at coming out after me.  What I'd REALLY like to do is have a mechanism to turn a "known" (shows up on the diplomacy screen) computer-controlled NPR into a player-controlled NPR, i.e. make it visible and taking orders in SM mode.  Would that be difficult to code up?

John

[Steve Walmsley (OP)]

Something that occured to me while writing the bit about "realism" in the last post....

In my next game, I think I'm probably going to turn off the computer-controlled NPR.  The reason for this is that they don't seem to be running their civilizations aggressively enough - I've been in contact with 2-3 (much higher tech) NPR for 5-10 years now and they've been ineffective at coming out after me.  What I'd REALLY like to do is have a mechanism to turn a "known" (shows up on the diplomacy screen) computer-controlled NPR into a player-controlled NPR, i.e. make it visible and taking orders in SM mode.  Would that be difficult to code up?

I will be trying to make them more aggressive in the future. For my first attempt I was just trying to get them working . After v4.1 is done, I intend to spend a lot more time with NPRs both in terms of their actions and in terms of adding more varied types of ships. I have already added NPR FACs for v4.1. In addition, they will be using diplomacy in v4.1 so you will have neutral or perhaps even allied NPRs. However, having said that, when I finally get around to working on my planned book using Aurora as the basis I will very likely run with NPRs turned off as well. Controlling all sides is more useful when you want to engineer certain scenarios or role-play a race in a certain way.

Turning an NPR into a player race is actually relatively straightforward. It may not make it into v4.1 but I will add it for v4.2. However, you can't have a part-controlled NPR as it would override any orders you gave. It would have to be an NPR or a human-controlled empire. What would be far, far more difficult would be turning a player race into an NPR

Steve

[Steve Walmsley (OP)]

I'm actually suggesting something that (I think) is a lot simpler, and would probably speed up performance, due to cutting the number of sensor checks.  The missile picket stuff is just a side-effect/bonus.

As it is 6.30am here I really need to get some sleep before answering this so I'll get back into it tomorrow

Steve

[sloanjh]

Something that occured to me while writing the bit about "realism" in the last post....

In my next game, I think I'm probably going to turn off the computer-controlled NPR.  The reason for this is that they don't seem to be running their civilizations aggressively enough - I've been in contact with 2-3 (much higher tech) NPR for 5-10 years now and they've been ineffective at coming out after me.  What I'd REALLY like to do is have a mechanism to turn a "known" (shows up on the diplomacy screen) computer-controlled NPR into a player-controlled NPR, i.e. make it visible and taking orders in SM mode.  Would that be difficult to code up?

I will be trying to make them more aggressive in the future. For my first attempt I was just trying to get them working :-)  I think they behave best when you are first making contact, though - the "what kind of contact is that and just how capable are they" effect is much more stimulating than role-playing both side.  Hence the "take over control" thought - to get the adrenaline spikes off the initial encounter, then to run them as a "smart" opponent.

Your diplomacy comment reminded me of something I've tried to do on my own in the past - decide on racial strategies to abide by when role playing.  For example, a paranoid race might picket all known WP with armed ships, and blow away anything making transit (which makes negotiation a little difficult ).  There's also a "how expansionistic are they" question - do they just want to sit in their home system, or are they rabid explorers?  It would be nice if part of NPR generation looked at the racial characteristics and picked such a set of strategies, similar to the commander characteristics that are generated.

John

[Steve Walmsley (OP)]

Actually, this (detection of bad guys when they transit into a hostile system) is working really well in v4.0b.  As you say, (I think) an interrupt event gets generated, whether or not the WP is picketed.  In addition, Aurora seems to be calculating arrival time so that it stops at the time of transit (which shouldn't be expensive, since there's no N^2).  So I'm not sure how your idea is different/better than what's being done now in v4.0b.  I would keep things the same as v4.0b, with the following minor tweaks:

I have to completely rewrite it anyway as it is all database-based at the moment and the new version only uses objects. What I am trying to do is remove the performance-intensive check at the start and replace it with something more reliable and that only interrupts if a detection takes place. There is also the concept of hostile/neutral/friendly/allied contacts in v4.1, so I don't want to interrupt for all detections.

1)  Do a detection check (for that ship) when the ship transits, and only halt the increment if the ship is detected.

While I was pondering how to tackle this part of the rewrite, I realised that a detection check is carried out anyway when a ship transits to see if anyone detects the jump point as a result of the transit. So I just added a little extra code that flags an interrupt if this detection is by a hostile or unknown race. This removes the need for any upfront checks. The only downside is that a ship may lose a few minutes of movement but as I noted above that has very little gameplay effect.

2)  Do a detection check on the pre-transit side too (for the transiting ship).  Right now, a bad guy who's glowing like the Sun can blow right by my pickets on the "friendly" side of a WP if a typical large increment is being used - when the increment stops, they're on the other side of the WP and undetectable.  If you knew a ship was going to make a transit, you could give the WP the ship's signature and see if anyone could detect it - if so, treat it like a missile engagement with the ship being the missile, i.e. take some smaller sub-pulses.

The detection code is already in v4.0 for the obervation of transit on the entry side. It just didn't stop time. The rewritten code should handle that. As far as the approach goes, the sub-pulses should take care of detecting ships on approach. Even using 1-day increments and 30 minute sub-pulses, a ship moving at 4000 km/s can only cover about seven million kilometers, which is not a huge distance compared to likely sensor ranges.

3)  This doesn't solve the "bouncing geo-survey" problem, where an NPR geo-survey ship keeps transiting back and forth between two fully surveyed systems, and one side of the WP is under observation.  I think that problem needs to be solved on the AI side, though.

I agree.

As far as my personal preferences on the "realism" issue go, my v4.0b game has led me to the viewpoint that I'd rather err on the side of detecting things that should be detected over getting information that I'm entering a system with bad guys in it.  I also find it useful to get a "something's about to happen" indicator so that I can back up my DB in case a detection gets missed and I need to re-play with smaller increment.  I've found that I have a pretty good idea where the bad guys are if I know about the race, so the only situation where I think you'd be getting much additional info is when transiting an already explored system that the bad guys have snuck into, and even that wouldn't be a lot of info since I typically don't go looking through my fleets to see who just transited if I get an NPR interrupt.

Steve

[Steve Walmsley (OP)]

Another update:

The rewrite is 95% done and I am starting the test phase. This will take a while though as so much has changed. After that I will go through the Bugs and Suggestions threads, although some of those may no longer be applicable because of the changes. As part of the testing, I came across a circumstance I hadn't fully considered before but which might explain the reports of NPRs not firing any anti-missiles. The potential problem occurs because while detection takes place after each sub-pulse, firing only takes place after all movement is complete. This has a couple of implications for NPRs that usually will not affect players.

The first is with regard to offensive fire. When you are firing weapons on your own ships, you very likely advance time enough to reach the next reload or recharge point. However, as you don't know when NPRs are firing, especially if they are launching missiles at long range, you could easily advance time too far. For example, an NPR could fire a salvo of missiles at you without you even knowing the NPR fleet was there and then you might select a 30 minute increment. The first wave of missiles would spend 30 minutes moving toward you and the second NPR launch would only take place at the end of that thirty minutes. The NPR missile waves could therefore arrive too far apart to trouble your defences.

Similarly for defensive fire, if you fire missiles at an NPR ship and then advance time by 30 mins or even 5 mins, it is possible those missiles will hit the target before the NPR can launch anti-missiles against them. Although this should be ameliorated a little by the code in v4.0 that tries to anticipate when a missile will enter sensor range of its target, NPR escorts are often in separate fleets and are therefore not checked for missile detection because they are not in the target fleet. This scenario could explain those reported situations where NPR escorts have not fired at incoming missiles but have then attacked player ships with their size 1 missiles.

The defensive fire should be improved anyway in v4.1 due to the small sub-pulses that should take place as a missile approaches its target. Even so, I have added some additional code to try and avoid both above situations in v4.1. At the start of an increment, Aurora will check for any existing fire orders for fire control systems. If it finds any, it will calculate the shortest reload or recharge time (if any) before weapons associated with that fire control are ready to fire and will reduce the increment to that length. This means that you don't have to worry about your own weapon reload times as Aurora will not advance time beyond the point at which they are due to fire. More importantly, it will allow NPRs to fire their weapons at the correct rate and should allow anti-missile launchers to fire as often as possible. This may cause a few short increments to occur for no apparent reasons but this will be for those situations where NPRs are fighting each other.

As fire control assignments are already unset if the target is out of range and NPRs review their firing decisions every increment, this should will not cause any unnecessary reductions in increment length. However, I hope it will increase the capability of NPRs considerably.

Steve

[Andrew]

Similarly for defensive fire, if you fire missiles at an NPR ship and then advance time by 30 mins or even 5 mins, it is possible those missiles will hit the target before the NPR can launch anti-missiles against them. Although this should be ameliorated a little by the code in v4.0 that tries to anticipate when a missile will enter sensor range of its target, NPR escorts are often in separate fleets and are therefore not checked for missile detection because they are not in the target fleet. This scenario could explain those reported situations where NPR escorts have not fired at incoming missiles but have then attacked player ships with their size 1 missiles.

Steve

I don't think that was the only cause as in at least one of these situations I was using 5 second increments because my own fleet was defending itself against long range missile fire. There was also a message visible in the SM View indicating that they where trying to fire at the incoming missiles but had no missiles for the launchers.
It looked to me that when they started firing size 1 missiles it was after they had fired off all of their larger long range missiles

[Steve Walmsley (OP)]

Similarly for defensive fire, if you fire missiles at an NPR ship and then advance time by 30 mins or even 5 mins, it is possible those missiles will hit the target before the NPR can launch anti-missiles against them. Although this should be ameliorated a little by the code in v4.0 that tries to anticipate when a missile will enter sensor range of its target, NPR escorts are often in separate fleets and are therefore not checked for missile detection because they are not in the target fleet. This scenario could explain those reported situations where NPR escorts have not fired at incoming missiles but have then attacked player ships with their size 1 missiles.

Steve

I don't think that was the only cause as in at least one of these situations I was using 5 second increments because my own fleet was defending itself against long range missile fire. There was also a message visible in the SM View indicating that they where trying to fire at the incoming missiles but had no missiles for the launchers.
It looked to me that when they started firing size 1 missiles it was after they had fired off all of their larger long range missiles

Thanks for letting me know. I'll see if I can figure out what is causing that. Although it may be academic anyway. I just started fighting an engagement to test the new object-oriented code and I appear to have broken missile defence

Steve

[Steve Walmsley (OP)]

I think I might have resolved the issue regarding the lack of NPR missile defence. Due to the screwup mentioned above I have been stepping through the code and spotted that the NPR allocation of missiles to launchers doesn't seem to happen unless the fire control has a specific target. If it is just setup for generic pont defence, then, as far as I can tell, the allocation code is never called. This is based just on reading the code though, rather than an actual test. I should know for sure once the current battle reaches a point where the NPR is defending against the Commonwealth missile strike. If that is the case, I cannot figure out how I didn't manage to spot before releasing v4.0b but at least NPRs will suddenly get a lot better in v4.1

Steve