I have a feeling that the way the Fleet Initiative mechanism is coded up is giving weird results at large time steps.
I had a fleet moving at 1 km/s near a survey point (it was picketing it) which detected an incoming fleet at ~6400 km/s, about an hour out for the fast fleet. I did a 1 hour update. The fast fleet ended up on the survey point as it should have. The slow fleet's move line indicated that it had moved towards the original position of the fast fleet. I think that what happened is that the slow fleet had worse initiative, so it moved first towards the original position of the fast fleet. The fast fleet then moved to a completely different location. I'm pretty sure I've seen other indications of this behavior - I've got an NPR fleet trailing one of my fleets, both moving at the same speed. I was surprised to come back to the system and see the NPR fleet had fallen out of range. I'm pretty sure it's because I recently upped the initiative of my fleet - the NPR probably overran my fleet on a big update and then got left behind.
If fleet initiative is supposed to indicate relative reaction times/control loop times, this behavior makes sense for updates shorter than e.g. 1 minute (or even 5 minutes). But at longer time scales it doesn't - basically the reaction time is being set to whatever the update time is. Putting the 4.1 increments in will help this some, but for very long sub-pulses I think it will still be a problem. My suggestion would be that for long sub-pulses (longer than the maximum reaction time) a trailer always moves after a trailee (you'll have to check for circular cycles of trailers, e.g. A trails B trails C trails A - those can be broken by having the lowest initiative move first).
I've noticed this effect show up in other places - especially how the speed of contacts is dealt with. It looks like Aurora trying to emulate Target Motion Analysis on passive (and possibly active) contacts by requiring two consecutive contacts with a target then taking deltaX/deltaT (as opposed to simply reading the target's speed from the data base and making it known). The same problem shows up as with initiative - this algorithm doesnt' take into account that deltaT can be anywhere from 5 seconds to 1 day. (In addition, there's a bug in the code which I logged early in this thread.) So you get the situation where a contact that's acquired at the end of a 1 day update, which is 10 hours inside the sensor envelope of the tracker is reported as having an unknown speed, while a contact that's only been held for 5 seconds (with a 5 second update after initial contact) has its speed precisely determined. I would vote that Aurora assume that the ship's staff will take care of the TMA, and simply display the course and speed (as obtained from the database) for each contact - this will allow you to rip out some complex code rather than trying to fix the reported bug. If you want to model the TMA process for passive contacts, you could have a time delay between initial acquisition of a contact and the time the course/speed information becomes available - I think you're already tracking how long a target's been held for the purposes of the tracking bonus - you could even use the same tracking tech track to reduce the TMA time.
While you're at it, I would recommend assuming the ship's staff can do a good job of re-recognizing passive contacts that have been momentarily lost. Right now, if I ping a thermal target with my active sensors to get an ID, the moment I turn off the actives the thermal contact goes back to "unknown". I understand the goal of this behavior was to put in fog-of-war effects on passive contacts without forcing players to micromanage target classifications, but I find the current behavior mildly frustrating in that Aurora refuses to mark contacts that I know are the same ship as the same ship. I know you did some work along these lines already in terms of which contacts cause interrupts etc., but I'm not sure how far it went.
In summary, I think what I'm advocating on the sensor side is that passives behave almost the same as actives, except that there's an initial delay to get course/speed information and (possibly) you can't lock up a passive contact.
John
