In my last post I showed how most Battlemechs couldn’t actually walk as fast as described in the game – if you missed that then you can read it at How fast can a Battlemech walk?. In this post I will present some optional Advanced Rules to implement the more realistic mech movement described there.
This is what I’m setting out to achieve here:
– Mechs now walk, run, and sprint at realistic speeds.
– Where possible, movement rates should be as consistent as possible with their current stats. That said, the fastest mechs must be slower here because it’s now impossible for them to be as fast as they were – this means they will have smaller engines and more space for equipment.
– It must be possible to design mechs so that their engine ratings (and gyros) are comparable with published designs.
– MASC, Superchargers and TSM will have a similar effect on speed as in the existing rules. Continue reading →
Or: “Can a Locust Battlemech really walk 240m in only 10 seconds?”
The answer, perhaps surprisingly, is “no, it can’t” – a Locust (or indeed any battlemech) could run that far in that time… but it is actually physically impossible for it to walk 240m in 10 seconds (at least in gravity similar to Earth’s). To discover why, we must take a rather fascinating scientific journey that sheds some light on something that perhaps many of us take for granted – the mechanics of how we move on two legs! Read on to learn more… Continue reading →
You hear the distant boom of an Autocannon echoing across the landscape and your mech shudders at the shell impacts against its left torso, blasting off some of the armour plating. It’s not enough to significantly damage your mech, but certainly enough to get your attention as you scan for your attacker and raise your arm-mounted PPC to respond…
And so the player peers at their Mech Record Sheet, and marks off five points of damage on the Left Torso:
But something’s funny here, to me at least. The way I see it, the side marked “Left Torso” is actually shown on the right side of the mech (it’s the player’s left side, but not the mech’s left side)! This has bugged me since I first started playing Battletech back in the 80s, and now I’ve started playing again I was reminded of it once again so I thought I’d dig into this a little further. Continue reading →
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… Continue reading →
While I was looking at the side branches of the French Arm (I’m still working on it!), I found a group of systems that were 7.769ly from the nearest star on one of the side branches. Which got me to wonder – what happens if a system in the 2300AD setting is slightly over 7.7 ly away – between 7.7 to 7.8ly? Can people still reach it without tugs or multiple drives/tuning? Do they have to “push the drive” even for such a small increment?
Let’s have a look at how “pushing the drive” really works (using the MGT rules). The rules say: “Pushing a stutterwarp drive past its discharge limit: 1–6 hours, Very Difficult, range increased by Effect x10%.” So when do you start “pushing the drive”? I’d guess no later than 6 hours before it gets to 7.7 ly (otherwise you wouldn’t be able to finish before hitting the limit).
Getting into the nitty-gritty of the game engine, I guess theoretically an engineer could spend a lot of time on it (reduce by two timesteps to 10-60 hours – so break out the coffee and stims!) to knock the DM penalty from DM-4 to DM-2. I’d imagine most engineers would have skill level 2-3 (DM +2 or +3), and Int or Edu of at least 9-11 (DM+1) – let’s just say that a competent engineer should be able to get a DM+4 between their skill and characteristic. So if they spend 10-60 hrs on it they’d be rolling 2d6 against difficulty 8 with a net DM of +2, which would give them a 72% chance of success. Though granted, it’s unlikely they’d be able to do the task for 10-60 hours (on their own at least) – at worst I think they’d just do it at Very Difficult with 1-6 hours and have all the DMs cancel out for a 42% chance of success. It seems to me that a competent engineer could reasonably be willing to spend at least 6-24 hours to push the drive to get a 58% chance of success with no possibility of destroying the ship (though there’s still a 42% chance that he’ll destroy the drive, so it’s probably not something that would be tried regularly).
Exceptional Failure only occurs if the Effect is -6 or less (I think that’s what the rules mean – not less than -6, since -6 isn’t on the table otherwise), so they’d only have a 2.8% chance of exploding the ship if they didn’t take more time to do it (Very difficult, no DMs, 8+ required) – otherwise Exceptional Failures can’t happen if there are net positive DMs. Though Average or Marginal Failures still at least disable the drive (I’d imagine the drive would just explode but not necessarily destroy the ship with it, and the the ship would suddenly drop out of stutterwarp).
If the roll succeeds, then there’s a decent chance that the range is increased by 10-30% (the chance is lower for the 40-60% increase, since that would require bigger effect – though spending longer on the roll would make those more likely) – so theoretically a drive has a reasonable chance of being pushed to 10.01 lightyears (maybe up to 12.32 ly if the engineer is very good and very lucky)!
So the question really is whether all this is even necessary to go slightly over 7.700 ly. If it is, then I guess it’s not going to be very likely that anyone would want to be regularly heading out to systems that are even 7.71 – 7.80 lightyears away since there’s a significant chance the drive would be destroyed/rendered inoperative (even though it’s at most about 1-2% further in range). Maybe risk-taking explorers would do it, but it wouldn’t be a regular route. Or maybe a 1-2% range increase is OK, but the drive MUST be checked over/recalibrated/retuned at the destination (after discharging) before it can be reused? I’d be more inclined to go with the latter option – it adds possibilities and doesn’t seem unreasonable.
Extending the drive range
There are at least three options (possibly more) to increase the range of the drive: Continue reading →
Now that my website is settled in its new home, I can finally start a new 2300AD project here. This time I’ll be moving on from the 2300AD Realistic Star Maps and going back to the original Near Star List!
The first thing to do is to make the data available. I’ve transferred the original NSL (oNSL) table from 2300AD into digital form and incorporated the extra data for Kafer Space from the GDW Kafer Sourcebook – and as an added bonus I’ve also thrown in the Backdoor system from Operation Backdoor that allowed the humans to contact the Ylii (Operation Backdoor may or may not be official canon, but I’m throwing it in anyway) :). This represents all the xyz data for the stars that was originally provided by GDW.
The xyz data is presented here as they were in the Near Star Lists – I haven’t rotated or recalculated anything, I’ve just transcribed them (though I have reordered some of the stars in the list to be consecutive to their companions for clarity). The list itself is in a CSV format that can be imported into Astrosynthesis, and the canonical arms are also provided in that format – the Backdoor route is also there. Keep in mind that this is not consistent with the Realistic Near Star Map that I’ve produced on this website (IIRC the coordinates may be flipped on the realistic map too) – but it’s all internally consistent at least.
The oNSL stars are listed with a Catalogue Number (Cat_no) between #230001 and #230749, the Kafer Sourcebook stars are #230750 to #230787, and the Backdoor brown dwarf system is #230788. So if you only want to use the oNSL stars you can ignore or remove the stars from 230750 and up (or just use the 2300AD_original_oNSL.csv in the zipfile below).
While there are some real stars in Kafer space in the oNSL (e.g. Gamma and Lambda Serpentis), the Kafer stars and the Backdoor system listed between #230750-#230788 are entirely fictional. Almost all of these fictional stars are within 7.7 ly of other stars (as shown in the screencap above), which means that there are no “dead ends” in Kafer Space – this is quite unlike the distribution of real stars in the oNSL (I would imagine that this was a design oversight when the new stars were being added – realistically I think the stars should be more spread out, with more being inaccessible).
You can download the CSV data from the link below. As usual, please don’t redistribute these files yourself – just link back to this page if you want to spread the word! The zipfile contains the following:
– 2300AD_original_Kafer+oNSL.csv (the full oNSL+Kafer Sourcebook xyz, cat_no, name and startype data table),
– 2300AD_original_oNSL.csv (just the oNSL data),
– The French, American, and Chinese Arms in a csv format that can be imported into Astrosynthesis,
– the original_2300AD_NSL+Kafer.AstroDB file that can be opened in Astrosynthesis.
Next time, we’ll start exploring some of the lesser known side branches of the original 2300AD near star map!
Copyright stuff: The 2300 AD game in all forms is owned by Far Future Enterprises. Copyright 1986 – 2016 Far Future Enterprises. 2300 AD is a registered trademark of Far Future Enterprises. Far Future permits web sites and fanzines for this game, provided it contains this notice, that Far Future is notified, and subject to a withdrawal of permission on 90 days notice. The contents of this site are for personal, non-commercial use only. Any use of Far Future Enterprises’s copyrighted material or trademarks anywhere on this web site and its files should not be viewed as a challenge to those copyrights or trademarks. In addition, any program/articles/file on this site cannot be republished or distributed without the consent of the author who contributed it.