Yes, I am still banging on about my problems with plotting anywhere near the core...but I have progress
Firstly, this has convinced me to upgrade my PC. So my next run will be with a shiny new CPU
Secondly, within minutes of getting shipping confirmation of my new CPU and associated goodies, I discover a new set of magic numbers that work on my existing set-up
My thoughts so far (which are entirely built upon all the great work by everyone on this thread, especially Esvandiary), and could be a repeat of something I missed before...
As we all know, the last three jumps in a plot are generally shorter, and the length of that shortening seems to depend on location. Near to Sag A* it seems to be about 90% of full range (based upon video of my recent Asp and Hauler runs).
If you calculate the maximum distance based upon those 3 shorter jumps and the rest of the jumps at maximum range, you get a number that seems to be an instaplot number (and can vary by +/- 2 LY before it slows down). I have tested this by reducing the number of maximum jumps and seeing if I can still plot and the answer is YES! Generally, if I am within 2 LY of this number I do not have any plotting issues.
Now I haven't given lots of examples as I think I have an approximation that works just as well -
find the maximum number of full length jumps you need to get your distance and multiply that by your max jump distance rounded down to the nearest 0.5 (i.e. 35.9 = 35.5, 32.3 = 32.0). This seems to give a number within the same band as the 3 jump calc above and my initial tests seem to work well.
For example - my current Asp has a max range of 36.9. This is a maximum of 27 jumps to get to 996 LY. Take that 27 and multiply by the reduced 36.5 and this gives 985.5. I can instaplot in the range 984-988 LY...I have tried 20 and 10 jump variants and the resulting numbers instaplot just as well.
So on my main PC, although the 1.3.x updates have made the GalMap almost impossible for me to use normally in the core, plotting magic numbers does still work. Even if they are different numbers from my original calculations
EDIT: I will document this a little more coherently if it works for me across the bad plotting zone and add to Esvandiary's core-plotting thread