As the name implies, the purpose of this project is to overhaul the game's progression. Essentially what I intend to create is a coherent modpack, with a sensible progression and a level of difficulty somewhere in between the stock game and Realism Overhaul. My target audience is players who are fairly experienced with the game and would like more of a challenge than the stock career game offers, but either don't like the extent to which RO changes things, or simply don't have the patience for RP-1.
Initially what inspired me to do this was the fact that, when playing with large collections of mods, the tech tree quickly ceases to make sense (and even with some good tech tree overhauls like CTT, unsupported mods can easily shift progression away from the realm of logic). This would've end up being just another tech tree rework (and the first stage of development will be just that), but I want to make a few more changes beyond the scope of yet another tech tree mod, and this number of planned changes has increased to include a few major overhauls. Additionally, there are often empty nodes in the tree when using any mod that expands its structure, and I'd like to avoid that issue while leaving my tech tree intact - the obvious way of doing this is by making some mods required, hence the need to make a modpack. I'd also like to balance this to be well-suited for use with the JNSQ planet pack.
Complete tech tree structure rework. Current Stage
Determine a preliminary list of mods. This has partly been done, and the initial tech tree rework will be based around mods which I already have decided to use, but the list is still mutable and will be finalised once the tech tree is completed. I'd prefer to fill logical gaps in progression without having too much overlap, and once the tech tree structure is completed I will be in a better position to figure out what's missing.
Fit all aforementioned mods' parts into the tech tree. At this stage I'll also move certain parts into an unresearchable node if I determine that they overlap too much with other parts and/or don't fit well into my desired progression (e.g. this will almost certainly happen to the Kerbalism centrifuge as it will be made obsolete by centrifuges from Station Parts Expansion).
Default config writing. For the sake of creating a coherent progression, I'll need to determine how to balance the mods I've chosen and do some playtesting to figure out what config settings all configurable mods need to have in order to suit the desired play style.
Science rewards and lab overhaul, as well as pricing for tech tree nodes. This stage is to make sure that science collection progresses at a rate which works well with the reworked tech tree, and also to make newer labs better than older ones while also ensuring that labs in general are not overpowered. Additionally, I'd like to make lab processing necessary (or at the very least, extremely desirable) for most science experiments, while also not making probes obsolete.
Compatibility patches. At this stage I'll take a look at game mechanics and the tech tree and write any necessary patches to make the progression smoother and to integrate all of the mods in the pack *properly*. For example, one of the things I'll do at this stage will be patching every crew capsule to adjust life support resources. Once this is done, things should be in an early playable state.
Major overhauls*. See below.
Tech node icons and descriptions. I don't have a specific place for these polish changes in the roadmap yet (aside from "somewhere before final release). I'll need to make quite a lot of custom icons (though I'll use stock ones where I think they fit), so this will be done whenever I feel like making icons. Likewise with custom descriptions. I'll probably try to do these in tandem, but until they're done the entire tech tree will use the default icon (the gear icon for everything except start) and no special descriptions.
Final balance passes and full release.
The general structure of the tech tree will largely be split between early space exploration and more modern space exploration; the former portion will largely be balanced around Tantares and/or BDB, while the latter will be balanced mainly around the Near Future series of mods. Additionally, I intend to ensure that, while either Tantares or BDB will be required for filling the entire tech tree, it will not be necessary to utilise both if not desired (this isn't going to be a "space race" pack, I just think that this is one case where overlap is a good thing).
My primary design philosophy for the tech tree is to keep similar technologies in similar places with logical prerequisites, and have more complex technologies require more science points. Additionally, individual tech nodes will generally include fewer parts, but cost less in general to unlock. This will mean that, rather than (for example) unlocking an assortment of station components, science experiments, utility parts, and several other things all together for a large investment of science, you will be able to choose to put a large amount of science points into advancing a specific technology while ignoring ones you don't yet need if so desired. However, certain advancements will require other developments if those developments logically should occur first (e.g. to research early space stations, you first need crewed spacecraft and docking techniques, and crewed spacecraft will need an understanding of life support). The tech tree will become significantly larger, but also more sensible.
Some of the major changes I have planned (see below) will be intended to encourage somewhat more realistic methods of approaching a space program, without the tediousness of something like Realism Overhaul (to clarify, I'm not trying to criticize RO - the devs do an amazing job and the pack is excellent for its target audience - I simply have a different target audience, namely people who want more of a challenge than stockalike gameplay but not quite to the same extent as RO is designed for). In particular, I'd like to encourage testing and reusing the same types of launch vehicles rather than building a new rocket for every payload (but without the hassle that is tooling), and to give more options for smaller missions that can be added on to larger launches to make the best use of payload capacity (the way that, for example, a single cubesat mission is too expensive to launch on its own, but you can fit several cubesats onto the same launch vehicle as a large geostationary commsat without exceeding the payload capacity of the rocket). Crewed space flight will similarly take more planning, but I think it's one of the most interesting aspects of KSP so I don't want to make it prohibitively challenging; something like a crewed Mun landing or a crewed orbit of Duna should feel like an excellent achievement, but also won't be out of reach for all but the most dedicated of players (at least, that is the hope).
Major changes from stock-style play
As previously mentioned, everything in this pack will be balanced to suit the JNSQ planet pack (and consequently should also be well-suited for use with the stock system at 2.7x scale). This will mean bigger rockets than in stock, and longer missions, but the basic concepts are by no means more difficult to apply than in stock KSP.
Mandatory RCS and Engine Ignitor Reignited are assumed to be included, and the modpack will be balanced around this assumption. This might mean that gyroscopes and certain engines may appear to be unbalanced for their positions in the tech tree if these two mods are ignored; with them, however, things will make more sense.
Kerbalism. I'll be providing my own set of configs for Kerbalism; I like exploring distant planets so it's not going to be the kind of hardcore life support that makes such expeditions impractical, but needless to say it will be more complicated than just shoving a few kerbals into a tiny lander can for decades and hoping for the best.
Kerbal Construction Time will be assumed to be present. Obviously I'll be providing my own default configuration for it, but I think it should make things somewhat more interesting
*One of the big changes I want to make in later stages of development is modifying most engines. This will include modified fuel mixtures, addition of methalox fuel (and related ISRU potential), limiting the minimum throttle (since most real engines cannot deep-throttle, and many launch engines cannot throttle at all), and (if I can figure out how to do this) adding upgrades for engines (the way I think I can confidently accomplish this last feature is by duplicating parts with MM and just changing the stats, but ideally I'd like to keep a single part and just allow part variants). This will be an optional change.
*Contracts. Assuming I can figure out how, I want to modify contracts to work better with the balance of the rest of the modpack. The larger scale of JNSQ means rockets will generally be more expensive, so contracts should be somewhat more rewarding by default; additionally, many stock contracts are either uninteresting or impractical (or both), so I'd like to change things up a bit. I do know of a few contract packs that I will almost certainly be using, but there are probably other contract ideas that I'd like to add in as well.
Custom science experiments (implemented for the Kerbalism system of adding experiments to probe cores and pods, assuming I can figure out how to do this) as well as custom science definitions for everything which is missing unique descriptions for every circumstance. This will be a big project (the descriptions in particular) so it'll likely be implemented gradually, though any custom Kerbalism experiment types will be done around the same time as the science rewards and lab rebalancing; I'd like to integrate this with contracts if possible too. The idea behind this is to encourage plenty of science probe missions that will all provide unique, interesting, and useful data.
Rocket avionics (the computers which control a launch vehicle) and probe cores are not the same things, and this pack will distinguish between them. Largely the distinction will be with MechJeb: ascent autopilot will for the most part be limited to avionics cores, while a probe core will be required for other features (including SAS). I will not be implementing anything like the RO avionics system based on mass (I realize my system could be exploited if desired, but the hope is that players playing honourably will stick to avionics suitably sized for their rockets). Landing autopilot and spaceplane autopilots will be similarly restricted to tech tree branches concerning landing and spaceplanes (respectively). The way this will work for cases where a single command part is desired for a wide variety of scenarios, as well as for crewed command pods, is that progress in the probe cores, avionics, and landing (and potentially spaceplane command) branches of the tech tree will gradually unlock these features for other command parts (e.g. lander can parts will have landing and ascent autopilots unlocked automatically, but if you want to use the Apollo command pod for a lander you'd need to unlock certain nodes in the avionics and landing branches, or include a capable control core, or fly manually).