Intercept missile fleets is artificially hard.

Is the range of 118km only for targets with a surface area of +1000 m? Or is it for meter targets?

I think closest approach is the closest you will get to the target when maintaining an intercept and before homing/maneuvering. On a side note, what's the acceleration on your MPD? I noticed that the wider the shield on them the higher the thrust and more expensive they are.

Sure, but that is the 'zag' only, the main point is that the plotted intercept is only available when I get the closest approach below 2km, while I *will* intercept if passing within 120km. Why can't I *plan* for a 110km or better intercept?

Even with a late adjustment I will only see an intercept at <2km.

I have to plan intercepts early, as the acceleration is not exceptional, so course changes have to happen early, ideally plotted half to one orbit in advance.... but against most ships getting within 800-1500km is 'close enough', and I can harass and pursue all month if a more agile fleet evades, and have sufficient delta-v to catch most things, and a small re-fuel requirement. (2kt is a complete resupply).

Acceleration numbers: 2.5-9.05 mg₀, with 9 xenon MPD active (7D 2h burn time), I might be able to redesign that to obtain more performance, but it is a silly thing I take out for fun, rather than a terribly practical design. (Long range PD ftw).

90377 Sedna is being one of the farthest minor planets, so it is a fair metrestick for the size of the solar system, especially in context of CODAE --- which would likely be fine if we cut off somewhere beyond Pluto (Aphelion: 7.4* 10^9 km).

Aphelion 90377 Sedna: 1.4 * 10^11 km == 1.4 * 10^17 mm
64 bit = 1.8 * 10^19

That gives us ~0.01mm on distance[1] and similar on angle, so we can do in fact better than just millimetre accuracy.

[1] assuming a distance + 2 angles notation

Math happening close to the simulation origin will still be more precise thanks to how floating point numbers work. Also, numerically integrating the orbit will mean accumulating errors the further you go.

Are you even sure the orbit simulation doesn't already use 64-bit floats? It wouldn't be a major change to do it so I'd imagine it already runs on double precision.

Because fixed point math will be significantly slower than floating points, since there's no hardware implementation of them in the CPU. There also doesn't seem to be too many ready-made implementations (because what madman would want to use them?) so you'd have to implement a whole bunch of math algorithms yourself. Already the orbits can get quite laggy in gas giant systems, I don't want to suffer even worse just to get some more precision, when the worst issues can be worked around quite easily.