I’ve got back into Battletech recently and I’ve been trying to reverse-engineer how the Proximity Limit is calculated (because I like to know how these things work). First, here’s a little background if you’re unaware of how jump works in Battletech. According to the fluff, Jumpships use a “Kearny-Fuchida drive” to travel over interstellar distances almost instantaneously. Traditionally they arrive at the Zenith/Nadir points – above the north and south poles of a star respectively – at the Proximity Limit, which is (supposedly) determined by the gravitational field of the star. These Jumpships usually carry Dropships, which then detach from the Jumpship with their cargo of mechs and head towards their target planet using normal fusion drives. Meanwhile, the Jumpship (which has little more than a few manoeuvering thrusters) generally sits at the arrival point and unfurls a large solar sail about a kilometre in diameter that it uses to recharge its drive in readiness for the next jump, which usually takes around a week (150-200 hrs).
After looking at the latest version of the stellar data table on pg. 100 of Campaign Ops, and I made an interesting observation: the Proximity Limit is not based on gravity. Given all the fluff says that this distance is determined by gravity (e.g. the notes on pg. 122 of Strategic Ops, summarised as “hyperspace fields don’t like gravity”) this is somewhat surprising. It turns out I’m not actually the first to notice this either – a thread on the battletech forums from over a decade ago discusses this too, but no solution to this is presented there. So I wondered – what would it look like if the Proximity Limit was calculated using gravity?
If you just want to skip to the point – here’s the gravity-based Safe Jump Distance table that you can use in your Battletech games instead of the published ones (this is just intended as a variant to use if you want more realistic values):
If you want to know the technical details behind how I calculated this then read on…
This turned out to be a rather deep dive, because a few related issues needed to be addressed as well:
1) How do we determine a gravity-based Promixity Limit for a star?
2) How long does it take to recharge the drive at that distance from the star?
3) How long would it take to travel to the habitable zone of the system from the (recalculated) Zenith/Nadir arrival points?
Canonically, the jump distances and travel times are presented on a table like the one on pg 100 of the (2021) Campaign Ops book, that shows all the star types and their associated values – no calculations are given for these values, they’re just presented as is. The distances in this table are very similar to the ones in the old FASA Dropships and Jumpships book (pg 17, Operations Manual), though they’re not quite the same, implying that they were recalculated at some point.
First, some definitions:
BT Values: These are the “Battletech Values” – the Stellar Data (radius, luminosity, mass) provided in the original Campaign Ops tables. These values aren’t fully accurate compared to our universe but they’re in the right ballpark, so I’m going to use those BT values in all the calculations here for consistency (though I did take the stated mass for the spectral number 0 and 5 stars and interpolated between those since many of the masses shown for consecutive spectral types were identical and therefore not useful). I also changed the luminosity for an M9 V star from 0.00415 to 0.00315 because it was higher than that of M8 V and M7 V stars (presumably this was a typo?).
Proximity Limit: The Proximity Limit is the distance at which a ship arrives at a star – canonically this should be defined by gravitational field strength, but it actually isn’t (hence this exercise). The “gravity-based Proximity Limit” is the distance we are calculating here using the actual gravitational field strength of the star.
Safe Jump Distance: The Safe Jump Distance (SJD) is the distance at which it is safe for a Jumpship to arrive (or depart) from a star. Ordinarily this is equal to the gravity-based Proximity Limit but for brighter stars this is further from the star due to high temperatures at the Proximity Limit.
1) Calculating a gravity-based Proximity Limit.
The first step for me was to enter the StratOps stellar data into a spreadsheet and then calculate the gravitational field strength of the star at that distance (g=GM/r²) using those BT values. If the Proximity Limit really is defined as the distance at which gravitational field strength drops below a certain value then one would expect the calculated gravitational field strength at that jump point distance to be the same (or similar) for all stars… and here’s where we hit a problem – it’s actually very different for each star at that distance. The gravitational field strength at the stated BT Safe Jump Distance for the stars ranges from about 0.0023 m/s² for an M9 V to 0.000059 m/s² for a G2 V (like the Sun) to 0.000000019 m/s² for a B0 V star. This is shown in the graph below:
Even if I calculate the differential of the gravitational field (the gravity gradient) or the escape velocity at that distance, there still a similar variation from one mass extreme to the other, so clearly the distance is not determined by gravity or even anything related to it. Going down the rows of the table, the ratio of a given row’s jump distance to the previous row’s jump distance increases slightly with each step, starting around x1.095 for the M9:M8 ratio and ending at x1.23 for the B1:B0 ratio – and it’s not quite a linear relationship. This ratio doesn’t seem to have anything to do with the physical parameters of the stars though – the ratio of the stellar masses, gravitational field strength, luminosity (it’s not an inverse square relationship), or even a constant number of stellar radii – in fact it doesn’t seem to be based anything physical at all, which I think is deeply unsatisfying for something that is supposed to be based on gravity. This will not do!
Ideally what we want is something gravity-based – where the gravitational field strength at the Proximity Limit is equal to a certain specific value – that gives similar results to canonical BT. A first attempt would be to assume that the gravity at the Proximity Limit must be equal to what it is at the canonical M9 jump distance (0.0023 m/s²) for all stars – in this case, Proximity Limit for a M9 V is the same as it is in the BT tables (75 million km, or about 0.5 AU), but the distance for a G2 V is now 1.6 AU (far less than the canonical 10.146 AU) and the distance for a B0 V is only 6.63 AU (far less than the canonical 2325 AU). This is a rather extreme adjustment, so let’s try something else.
If instead we assume that the gravity at the Proximity Limit must be be equal to its value at the canonical G2 jump distance (0.000059 m/s²), then the distance for an M9 V now becomes 3.177 AU, the distance for a G2 V remains at 10.146 AU, and the distance for a B0 V is 42.03 AU. The gravity-based Proximity Limit for the least massive stars is further than it was canonically but still within the realms of the system (roughly where the asteroid belt is in our solar system), for sun-like stars it’s near the orbit of Saturn, and for the brightest stars it’s more like Pluto’s distance from the star instead of in the depths of the Oort cloud. Using this kind of scaling would make more sense to me, so we’ll go with this.
However, this isn’t the end of the story…
2) Recharging the K-F Drive
The next issue is how long does the K-F Drive take to recharge? Canonically jump ships open up 1 km diameter (500 m radius) jump sails that collect energy from the star, and use that to recharge their drives in about a week. We can actually calculate the energy required for this at the gravity-based Proximity Limit if we know the luminosity of the star and the distance from the star of the jump point, which we’ve just recalculated. The star’s luminosity is measured in Watts (Joules per second – the luminosity of Sol is 3.846e26 W), and we can determine the insolation (in W/m²) at the gravity-based Proximity Limit by dividing the luminosity by the surface area of a sphere with radius equal to the gravity-based Proximity Limit. We know the area of the jump sail (the area of a 500m radius circle, which is 785398.1634 m²), so in every second the sail will collect energy equal to the insolation multiplied by the sail area. If we multiply that by 604800 seconds (the number of seconds in a 168 hr week) then we get the total amount of energy collected in a week! Note that this assumes that the sail is a perfect absorber of energy too.
If we once again assume that the correct baseline to start from are the values for the gravity-based Proximity Limit we calculated for G2 (Sol), then we see that over 168 hrs at 10.146 AU our 1 km diameter jump sail would collect 7.76e12 Joules, which is 7.761 terajoules. The insolation at this distance is 16.34 W/m², compared to 1367 W/m² at earth’s orbit. So let’s assume that this is actually how much energy all K-F drives require to fully recharge (this is a handy bonus that came out from our calculations – it doesn’t sound like an unreasonable number for this technology at least, one would expect it to require a lot of energy).
Even canonically, it is physically impossible for a 1km diameter sail to recharge at every star in a week, because the Proximity Limit distances do not scale with the luminosity of the star. In some cases, there’s not enough energy per square metre to charge it in that time so it would take longer to charge, and in other cases much more energy is falling on the same area so it’d charge much faster. Using the BT values for luminosity and Proximity Limit, the graph below shows how much faster/slower the charging should actually be (canonically):
With our recalculated gravity-based Proximity Limit distances, the graph looks quite different now (note the difference in vertical scale) and actually presents us with some interesting new issues to address.
An M9 V star (0.00315 solar luminosity) is much dimmer than a G2 V (1 solar luminosity), and its gravity-based Proximity Limit is relatively much further away (3.177 AU around an M9 V is roughly equivalent to 50 AU from Sol) so it now actually takes 38 weeks to collect 7.761 TJ using a 1 km diameter sail there – at the other extreme a B0 V star would theoretically collect 7.761 TJ in only 352 seconds (less than six minutes!). The way around this is to assume that the sail size is not actually fixed at 1 km diameter – the Jumpship needs a larger sail to collect more energy at the dimmer stars, and a smaller sail to collect less energy (to avoid overloading the drive) at brighter stars. We can calculate the required sail radius for each star at the gravity-based Proximity Limit so that it’s exactly the size it should be to collect the 7.761 TJ in seven days, and we find that the diameter would range from about 7 km at most (the sail size actually peaks at M7 V) to only 24 metres for a B0 V star!
Jumpships would therefore carry larger sails (up to 3500 m in radius) that they could partially unfurl to suit the star in their arrival system, so that the drive still charges in exactly a week. Canonically the earliest jump sails were 50 km in diameter, so a 7 km diameter sail would not be technically unfeasible or unrealistic. There are even rules for charging the drive more quickly in Strategic Ops that could be used here with some risk – just unfurl the sail to a larger size than necessary, and hope the increased charge rate doesn’t blow the drive!
2b) Temperature effects
There is a complication here for brighter stars – even though the Jumpship would be at 42 AU from a B0 V star, in terms of insolation this is actually the equivalent of about 0.22 AU from Sol (nearly half the distance of Mercury from Sol – these stars are that bright). As such, the local temperature would most likely present a problem at this distance since it’d be about 593 K there, which is probably high enough to quickly destroy the fragile jump sail materials (and cause considerably discomfort on the Jumpship itself too). So it seems likely that for hotter, more massive stars the actual Safe Jump Distance would be further than the gravity-calculated Proximity Limit distance in order for the ship to remain at a safe temperature and function normally – this would actually help us since moving the arrival distance outwards would reduce the super-fast charge times around these stars too. We don’t know what temperature that would be “safe” for this purpose so we’d have to pick one arbitrarily, but we do know that the temperature at Sol’s recalculated Proximity Limit (10.146 AU) is about 87 K – so we’ll set a higher temperature that is still cold, which would be suitable for the superconducting materials that are probably involved in the sail’s material. So let’s assume that the local blackbody temperature has to be less than 150K (-73°C) at the Proximity Limit to avoid damaging the ship’s sail. An A6 V star (luminosity of 15.1 sols, Proximity Limit of 13.628 AU) has a temperature of 149 K at its Proximity Limit, which is just below this threshold. For more massive/brighter stars (A5 to B0), the actual Safe Jump Distance (SJD) would be beyond the gravity-based Proximity Limit.
This has an interesting side effect – because we’re now looking for a distance where the blackbody temperature is a fixed value, that means the isolation (W/m²) must also be a fixed value there, which means that the size of the sail becomes fixed as well. So although the arrival distance is now further from the star than before, the minimum sail diameter now plateaus at 237.234 m (radius 118.617 m) rather than 24 m.
3) Recalculated Travel Times
Now that we’ve recalculated the proximity limit and sail diameters, the final step is to determine the travel times between the Zenith/Nadir points and the habitable zone of the system (where presumably the “main world” of the system is located). In-system travel in Battletech uses Fusion Drives and a standard accelerate (to 1g)-turnover-decelerate trajectory to get to their destination. Again, calculations for this are not provided in Campaign Ops, but it’s actually relatively straightforward to determine if you know the total distance to travel. This calculation can be used for any situation (such as when the Jumpship arrives at a non-standard jump point) for which the total distance travelled is known.
TOTAL Travel time in days = 2.835 * SQRT(s/a) where s is TOTAL distance in AU and a is in earth gravities (1 g, in this case).
One thing I discovered is that the Habitable Zone distances provided in Campaign Ops appear to be unrealistic. The usual method is to take the SQRT of the star’s luminosity to determine the distance at which a world exactly like the Earth would have the same temperature (this sounds strangely convenient, but it’s actually how the equations work!), so I’ve used that to calculate the habitable zone distance here. The inner and outer limits of the habitable zone vary greatly depending on the planet’s atmosphere and rotation rate, but the usual shorthand is to multiply this distance by 0.9 to find the inner limit and something like 1.3 or 1.5 to find the outer limit.
So all that is left is to put this together in a table that we can use!
Addendum: Giant stars and stellar remnants
There are a few other observations I can add here. Like many IPs from the 70s and 80s, the BT universe contains habitable worlds that orbit giant and supergiant stars or B V stars (Antares, Betelgeuse, Altair, etc). We know that these are unrealistic (the Campaign Ops system generation rules even point this out rather sheepishly) because the lifespan of the systems are barely a few million years and there’s barely even enough time for planets to form let alone survive in such unstable environments – and yet, there they are (sigh). Personally I’d just replace these all with O’Neill cylinders or something. The table only shows the stellar data only for Main Sequence stars (Size V), so don’t make the mistake of using the M2 values for Betelgeuse (actually an M2 Iab supergiant with mass of about 17 Sols, luminosity around 126,000 Sols, and radius of about 900 Sols), or the M1 value for Antares (actually an M1.5ab supergiant with a mass around 12 Sols, luminosity of 75900 Sols, and radius of 680 Sols), or the K5 value for Aldebaran (actually a K5 III giant with mass of 1.16 Sols, luminosity of 518 Sols, and radius of 45.1 Sols). Fortunately these stars are so bright that the Safe Jump Distance would be determined solely by the 150K temperature limit anyway – for Betelgeuse it’d be 1225 AU, for Antares it would be 950.804 AU, and Aldebaran would be at 78.548 AU). For other giant stars, you can just use the corresponding luminosity values from the table rather than the spectral type. If you want to learn more about how stellar evolution works, do check out my Stellar Evolution Primer available elsewhere on this site!
For white dwarf stars, just use the row corresponding to the WD’s mass value from the table (e.g. a 0.7 solar mass WD star would have the same Proximity Limit as a 0.7 solar mass G2 V star). Neutron stars and black holes would actually retain their gravity-based Proximity Limits (the temperatures there wouldn’t be higher than 150K, unless they had luminous accretion discs). Neutron stars range in mass between 1.1 and 2.14 solar masses, so would just use the equivalent row on the table (a 2.14 Solar Mass NS would have a gravity-based Proximity Limit of about 14.6 AU). Stellar mass black holes generally range from 3 to 10 solar masses, which would correspond to a gravity-based Proximity Limit ranging between 17.5 AU to 32 AU). If they have an accretion disc then the luminosity is likely to be very high and you’d probably be using the B0 temperature-based Safe Jump Distance.
If you’ve stuck with me to the end, thanks for reading and please let me know if you have any questions or comments! 🙂
Is this the right approach?
My inclination would be to start with the narratively desired travel times (mostly to planets in the life zone) and calculate backwards to get a desired position, then find a formula that’ll give it. The problem is that there’s so much prior art (games, books) in which the writers simply assumed that you put the JumpShip out somewhere and trog back and forth without any particular difficulties that changing this stuff enough to matter will give you quite a different universe.
Are variable-size sails worth the increased mechanical complexity, compared with radiators on the spaceward side of the ship? In the art they’re always shown as single solar-sail-style discs, not any sort of modular vane system.
I think it’s the right approach :P. If you look at the 2300AD stuff I’ve written elsewhere on this blog you’ll see I prefer the physical approach over anything narrative.
I don’t think anything I’ve suggested here would radically change the setting. The idea of packing a larger sail doesn’t break anything, and the travel times to/from the recalculated jump points are generally fairly comparable to the canonical ones – they’re just based on more realistic parameters now.
But if you prefer to stick to the canonical values then by all means continue to do so. I’m just presenting this as a more realistic alternative variant.
There’s a bit of a cheat for a variable sail. You don’t need to vary the size of the sail, just it’s angle relative to the sun. If I recall, isn’t there some fluff about myomer threads tensioning the sail? So if you relax those, then the solar wind would “blow” the sail into a more teardrop shape, thus reducing the area of sail that is orthogonal to the sun.
Absolutely wonderful! Brilliant breakdown even if I don’t understand half of it 😀 Re there being habitable worlds around super massive stars like Canopus and all that I think it was more a case of
*Arrives in Canopus system*
“Okay..this is a radiation blasted hell that’s got a bare handful of accreting matter and thats it”
“So..no world to settle on?”
“No Ma’am.”
“Okay what about THAT system here?”
“Spectographics indicate its far more amicable.”
“That’s now Canopus.”
“Uhh..we’re IN the Canopus system.”
“Yes.”
“And the other system is now Canopus?”
“Yes.”
“…you’re paying the wages, whatever works!”
lol. Yeah, it’s been an issue in plenty of other scifi games too. In Traveller I had to fudge things by putting convenient brown dwarfs or previously unknown main sequence companion stars for a habitable world to orbit (there’s only so many times you can use the “oh, a captured rocky planet in a conveniently habitable orbit” approach. But I do kinda like your solution too ;).
Hey, this stuff looks great! Would you be open to sharing your spreadsheet? I’m interested in what the numbers would look like if you didn’t mandate the temperature limits, allowing class A and class B stars to serve as risky shortcuts.
I went ahead and built my own sheet based on the figures (thanks again for them!) but I am confused about one point. Why did you use:
TOTAL Travel time in days = 2.835 * SQRT(s/a)
to calculate travel time instead of:
TOTAL Travel time in days = 2 * SQRT(s/a)
Which seems correct for a brachistochrone trajectory to me?