Post by: Steve Walmsley on May 27, 2009, 01:48:57 PM
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
Post by: sloanjh on May 27, 2009, 07:46:15 PM
Quote from: "Steve Walmsley"
Back from ItalyWelcome 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!
Quote
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.QuoteI 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.
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'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
Post by: Brian Neumann on May 27, 2009, 08:01:13 PM
Brian
Post by: Paul M on May 28, 2009, 03:25:30 AM
Hope you enjoyed Italy.
Post by: sloanjh on May 28, 2009, 08:55:05 AM
Quote from: "Brian"
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
Post by: Steve Walmsley on May 28, 2009, 11:09:43 AM
Quote from: "sloanjh"
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.
Quote
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.QuoteI 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).
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?
Quote
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
Post by: Steve Walmsley on May 28, 2009, 11:14:54 AM
Quote from: "Brian"
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
Post by: welchbloke on May 28, 2009, 12:34:38 PM
Post by: Steve Walmsley on May 28, 2009, 12:47:31 PM
Quote from: "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.Yes, I have seen a few of those situations :)
Quote
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
Post by: welchbloke on May 28, 2009, 01:31:32 PM
Quote from: "Steve Walmsley"
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
Quote from: "Steve Walmsley"
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.Sounds like the trip was worth all the trials and tribulations.
Steve
Post by: sloanjh on May 28, 2009, 06:21:20 PM
Quote from: "Steve Walmsley"
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.
Quote
QuoteI 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
Post by: ShadoCat on May 28, 2009, 06:35:07 PM
Post by: Steve Walmsley on May 29, 2009, 08:33:31 AM
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
LoopSteve
Post by: sloanjh on May 29, 2009, 07:28:00 PM
Quote from: "Steve Walmsley"
I have added the logic for the missile interceptions so I'll post it here for a logic checkCode: [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
Post by: Steve Walmsley on May 31, 2009, 05:25:13 AM
Quote from: "sloanjh"
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.
Quote
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.
Quote
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
Quote
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
Post by: sloanjh on May 31, 2009, 11:39:45 AM
Quote from: "Steve Walmsley"
I'm not 100% sure that it will (hence the "probably"Quote from: "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.
), 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.Quote
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.
Quote
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
Post by: Steve Walmsley on June 07, 2009, 09:34:00 PM
Quote from: "sloanjh"
I'm not 100% sure that it will (hence the "probably"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
Post by: Steve Walmsley on June 07, 2009, 10:55:48 PM
Quote
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: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.
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.
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
Post by: sloanjh on June 07, 2009, 11:22:35 PM
Quote from: "Steve Walmsley"
Quote from: "sloanjh"I'm not 100% sure that it will (hence the "probably"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
Post by: sloanjh on June 08, 2009, 12:02:51 AM
Quote from: "Steve Walmsley"
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.QuoteHmmmmmm - 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.
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.
Quote
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 thoughtCool!
Quote
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
Post by: Steve Walmsley on June 08, 2009, 12:03:39 AM
Quote from: "sloanjh"
I agree - just pointing out a possible "gotcha"And I do appreciate that :)
Steve
Post by: sloanjh on June 08, 2009, 12:08:34 AM
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
Post by: Steve Walmsley on June 08, 2009, 12:28:29 AM
Quote from: "sloanjh"
Something that occured to me while writing the bit about "realism" in the last post....I will be trying to make them more aggressive in the future. For my first attempt I was just trying to get them working
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?
. 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
Post by: Steve Walmsley on June 08, 2009, 12:33:53 AM
Quote from: "sloanjh"
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
Post by: sloanjh on June 08, 2009, 12:40:24 AM
Quote from: "Steve Walmsley"
Quote from: "sloanjh"Something that occured to me while writing the bit about "realism" in the last post....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.
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?
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
John
Post by: Steve Walmsley on June 08, 2009, 09:21:05 PM
Quote from: "sloanjh"
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.
Quote
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.
Quote
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.
Quote
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.
Quote
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
Post by: Steve Walmsley on June 12, 2009, 12:57:39 PM
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
Post by: Andrew on June 14, 2009, 06:06:21 AM
Quote from: "Steve Walmsley"
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.
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
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
Post by: Steve Walmsley on June 14, 2009, 10:22:52 AM
Quote from: "Andrew"
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 :)Quote from: "Steve Walmsley"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.
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
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
Post by: Steve Walmsley on June 14, 2009, 12:07:02 PM
Steve
Post by: Steve Walmsley on June 26, 2009, 04:57:33 PM
There is now an 'Automatic' option for sub-pulses instead of a 'None' option, although you can still select your own if required. The default sub-pulse lengths are shown below. If you use the player-specified increment length, it will use the closest default option for sub-pulse length.
Up to 60 seconds: 5 seconds
2 minutes: 10 seconds
5 minutes: 15 seconds
20 minutes: 60 seconds
1 hour: 2 minutes
3 hours: 5 minutes
8 hours: 15 minutes
1 Day: 30 minutes
5 days: 2 hours
30 days: 6 hours
There are some bugs but so far they are relatively straightforward and I am working through them as I play. I think it will probably be at least a month before v4.1 though as I am playing poker a lot at the moment and I am going to Vegas for 2 weeks for the WSOP.
Steve
Post by: sloanjh on June 26, 2009, 08:55:28 PM
John
PS - Have fun in Vegas!
Post by: sloanjh on August 16, 2009, 04:18:43 PM
1) Overall, it's GREAT!!! I've just gotten done running 3 1-day updates with a 2-minute sub-pulse size, i.e. 720 pulses per turn, and it only takes 20-30 seconds per turn.
2) Ok, now the bad news - the reason that I'm doing 2-minute pulses is that Aurora is still letting contacts get deep into the sensor envelope when doing large-scale (e.g. 1-day) updates. The first time I played the 1st contact scenario, Aurora chose a coarse (15-minute?) update, which put the gunboats that were intercepting me deep (about either 1/4 or 3/4 way - I don't remember which) into the range at which I should have detected them. So I still had to fall back to a saved DB and replay it with a finer-grain update The performance improvements mean I was able to do this, however.
3) While I was waiting for jump technology, I did a lot of updates (10-15 years) where nothing was happening except civie shipping shuttling back and forth between Earth and Mars. Once the civie orders issue was fixed, I still was doing 1.66 day or 2.5 day updates (depending on where Earth and Mars where in their relative orbits) rather than the 5 day updates I would have preferred. The reason for this is that the civie ships seem to pile up together at the planets when the updates are too long. I think this has to do with conditional orders not being checked during pulses; instead they're only checked at the end of the turn (at least it used to be this way). So a ship would drop off its load of goods at Mars and wait before deciding it should head for Earth for a new load. Note that I'm not 100% sure about the above - my prejudices were set while the civies were broken, and it might be that the order chaining is set up to not "pause" at the end of an update before going on to the next task. On the other hand, I think I'm still seeing them pile up at the planets when Earth and Mars are close together.
4) More good news - while I was doing e.g. the 2.5 day updates, Aurora was running faster than in previous versions. In previous versions, I'd time-share by reading while Aurora was thinking. In 4.2x, I don't quite have time to switch to the book before Aurora wants another click.
Overall - THANKS!!!!
John
Post by: sloanjh on August 18, 2009, 11:00:39 PM
John
Post by: sloanjh on August 18, 2009, 11:12:11 PM
Quote from: "sloanjh"
Oooh Cool!!! I just lost contact with some aliens, and Aurora left a location marker for where the contact was lost, along with a "tail" to show heading. Thanks Steve - that's exactly the sort of thing I was looking for with the lost contact stuff!!!
John
Oops. Looks like what was really going on what that I lost active contact (but still had thermal). The next timestep I lost all contact and they disappeared (i.e. no marker where they went away). OTOH, the message losing thermal contact remembered which ship the thermal corresponded to (a good thing).
John
Post by: SteveAlt on August 20, 2009, 09:19:20 AM
Quote from: "sloanjh"
I'm at year 18 of my conventional start, and in the midst of my 1st NPR encounter, so I thought I'd put out some observations on the rewrite.The default sub-pulses are 30 minutes for one day updates. If the general consensus is that the game is running well with 48 sub-pulses, I can up that to 15 or even 10 minutes per sub-pulse.
1) Overall, it's GREAT!!! I've just gotten done running 3 1-day updates with a 2-minute sub-pulse size, i.e. 720 pulses per turn, and it only takes 20-30 seconds per turn.
2) Ok, now the bad news - the reason that I'm doing 2-minute pulses is that Aurora is still letting contacts get deep into the sensor envelope when doing large-scale (e.g. 1-day) updates. The first time I played the 1st contact scenario, Aurora chose a coarse (15-minute?) update, which put the gunboats that were intercepting me deep (about either 1/4 or 3/4 way - I don't remember which) into the range at which I should have detected them. So I still had to fall back to a saved DB and replay it with a finer-grain update The performance improvements mean I was able to do this, however.
Quote
3) While I was waiting for jump technology, I did a lot of updates (10-15 years) where nothing was happening except civie shipping shuttling back and forth between Earth and Mars. Once the civie orders issue was fixed, I still was doing 1.66 day or 2.5 day updates (depending on where Earth and Mars where in their relative orbits) rather than the 5 day updates I would have preferred. The reason for this is that the civie ships seem to pile up together at the planets when the updates are too long. I think this has to do with conditional orders not being checked during pulses; instead they're only checked at the end of the turn (at least it used to be this way). So a ship would drop off its load of goods at Mars and wait before deciding it should head for Earth for a new load. Note that I'm not 100% sure about the above - my prejudices were set while the civies were broken, and it might be that the order chaining is set up to not "pause" at the end of an update before going on to the next task. On the other hand, I think I'm still seeing them pile up at the planets when Earth and Mars are close together.New trade runs are setup at the end of a turn after all movement is complete. I did this for performance reasons - mainly because the code carries out a search for all commodities between all planets for each fleet ready for a new trade run and I didn't want that happening every sub-pulse. Although I guess I could flag those fleets that had already been checked and failed to find a trade run and only check them again post-movement.
Quote
4) More good news - while I was doing e.g. the 2.5 day updates, Aurora was running faster than in previous versions. In previous versions, I'd time-share by reading while Aurora was thinking. In 4.2x, I don't quite have time to switch to the book before Aurora wants another click.That's good to hear. It sounds like the rewrite was worth it overall but I may need to revisit the default number of sub-pulses. I would be interested in feedback from other players as well on that point.
Steve