Hi Steve,
Let me say upfront that I realize that this suggestion entails a lot of coding on your part, and (possibly) a major paradigm shift with the way Aurora handles movement. OTOH, I'm 20 Aurora years into my campaign that has 1 NPR, and I've hit two effects which are having a major impact on my gameplay - I'm worried about performance once there are several NPR empires and my empire is 3-4 times as big. The good news is that a LOT of the hang-ups from the early days are smooth as silk now - micromanaging which side of a JP a jump ship was on for ferry purposes, the "go tearing off across the system due to a 'survey next 5 bodies'" bug, intelligent NPR, etc. But you know users - we're never satisfied :-)[/list]
2a) If I want to do a 5-day update, it takes ~4 times as long for the computer to think if I use a 6 hour interval than if I used a 1 day interval, and ~24 times for a 1 hour interval. The reason this is a problem in 4.0b but wasn't in 2.x or 3.x is that I'm not controlling the NPRs any more. In the old days, I knew roughly when and where an encounter was going to take place, and could cut the timestep based on that knowledge. In 4.x, any system might have NPRs or Precursors in it, and so I have to guess when I need to cut the timestep. If I guess wrong, then I either zip right by the contact without ever seeing it or, as was the case with my first Precursor encounter, they end up 6 hours travel time inside my sensor envelope. Last night I went back to the Precursor system - what I ended up doing was saving my database more and more frequently as I got closer to them, so that I could replay it with a smaller timestep if I mis-guessed (which I ended up doing - I mis-guessed their missile range during a several-hour stern chase and was taking ~30 second timesteps)
2b) While exploring asteriods or moons, I "have to" cut the timestep and update times. Since (my recollection is) the ships only execute 1 order per timestep, and don't get another 5 bodies until the end of the update, I could have them spending 5 days for a survey or three that took 4 hours.
2c) Due to the interrupt frequency in #1 above, I frequently find myself using 6 hour intervals in 4.0b in places where I would have used a shorter interval in 3.x or 2.x. The reason for doing this is that way I know I can get 6 hours of Aurora clock to advance before being interrupted.
One thing I'm very curious about is if you're seeing similar issues in your campaign, and if not, what am I doing wrong :-) ) is a way to further make things more efficient. It's rather silly for my freighters running back and forth between Earth and Pluto to be taking 20 minute timesteps just because some survey ship is working a crowded asteroid belt 3 jumps away. The key observation is that it's impossible for movers in one system to affect movers in another system unless they either jump between them or send a message (generate an interrupt event). So you could set up a priority queue in each system that had movers in it, and do coarse grain updates in systems that don't have much going on. Basically, you could register each system's queue in a queue of queues, with the priority determined by the time of the next event in that system. The flow of control would be that the top system in the queue would advance its internal clock to its first event, then calculate and reset its priority in the queue. If an event that affected other systems (either a jump or an interrupt) occurred, then all systems would bring their internal clocks up to the time of the event. This would let the mining ship run small, tight timesteps without affecting the freighters in Sol; every time the accumulated time added up to a timestep in Sol (e.g. about once a day, which might correspond to 100 timesteps in the mining system) the Sol system would advance its clock in a single (rather than 100) timestep(s). If the mining ships found minerals on an asteroid (causing an interrupt), the Sol system (and any other systems) would advance its clock (again in a single timestep) up to the time of the event before displaying the interrupt to the player.
[/list]
Note that the only thing (I think) I'm advocating changing here is the mechanism for performing sub-steps within an e.g. 1-day update. The interrupts, updates (top row on F3 screen) and economic update mechanisms would stay the same. Another point: if you're worried about mis-estimating the time of a particular event (e.g. sensor contact) that's a long time off and important not to over-shoot, go ahead and cut the time-to-event by 10% for that particular event type. That should hone in VERY rapidly on the actual time that the event should occur, e.g. an undershoot of a day should go down to an undershoot of ~1 second after only four iterations/timesteps. As for sensor detection events, this method might be efficient enough that each mover can just brute-force them by calculating the closing velocity to every alien sensor platform in the system and predicting when it will move within range (then picking the shortest) - even with 10-20 fleets on a side you could easily win out over e.g. "calculate next 5 moves" in a system with 100s of asteroids, and you'd be doing a LOT fewer updates (I think). (Missile salvos might cause a problem with idea, if there are too many of them, however - they might need special optimizations.)
Hope you like the suggestion....
John