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 →
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:
Just your normal everyday record sheet.
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): Table showing recalculated gravity-based Safe Jump Distance values.
If you want to know the technical details behind how I calculated this then read on… 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!
Kafer Space (from the Kafer Sourcebook).
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.
