septemberWaves

Ah, I see. Even so, I don't think "colonization" is really within the range of technology I want my tech tree to cover. Extensive surface bases, yes; colony-scale, not so much.

If by "colonization" you mean Modular Kolonization Systems and the other USI mods, those will not be supported by this pack. There are simply other mods that I prefer for everything that the USI series does (besides the aspects of it that are beyond the technological range I intend to cover, such as FTT and the warp drive). Additionally, since they are designed specifically for use with USI Life Support, they would most likely be more difficult than most mods to properly integrate with Kerbalism.

Overview 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. Roadmap 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. Specific plans 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).

@Okhin Have you heard of a mod called Near Future Solar? It's by the same developer as the station parts mod you are using; it tends to be quite helpful for making spacecraft with fewer than a hundred parts used for solar power.

The other day I launched some relay satellites into stationary orbits of Kerbin.

I have a few from some recent missions I did after installing some visual mods.

I send probes first so that I never have to answer this question.

I optimise my rockets to fly with MechJeb's autopilot without manual input (at least as much as I can avoid it); I determine the maximum payload by first experimentally determining the required delta-v to launch the rocket into the desired parking orbit (which can vary somewhat depending both on the target orbit altitude and the design of the rocket, as well as the ascent trajectory used), and then using that as a basis to adjust the NRAP test weight (with smallest increments of 100kg) until the excess delta-v (whatever is left above the number I determined previously) is within 10 to 20m/s above the required minimum. I do de-orbit my upper stages, but they always have RCS which is partly for this purpose - and often there's a bit more delta-v left than what there is at maximum payload capacity anyway because I don't always launch payloads at the full capacity of the rocket. For anything besides low Kerbin orbit, the margins can vary a bit more than that, depending on how familiar I am with the specific intended mission profile and on how versatile the spacecraft needs to be. My crew spacecraft tend to be designed before I have a specific idea in mind of the mission profile, so I typically go with an estimate of about 30 to 50% extra compared to a specific baseline - for example, if I know a spacecraft is meant to return from Munar orbit after being put there by another stage, and that this is the largest single burn it will ever have to make (as well as the only significantly large burn it will make in that particular kind of mission), I use that as the baseline and then add a decent amount extra for the sake of covering most small orbital maneuvers. Other times, I typically design modular stages that can send a certain payload to a certain place, and I like to set the margins for those kind of stages pretty low in a similar way to with the launch vehicles - by designing the vehicle first and then determining its payload capacity. Ascent vehicles for atmospheric celestial bodies other than Kerbin are generally the hardest to design with precise margins, since the payload tends to consistently be "crew capsule + docking equipment + orbital propulsion + life support and basic functional stuff" and it makes less sense to design the lower stages of a lander first - although having broader margins is generally better in these situations for safety reasons, particularly since landing locations can also cause a lot of variability in delta-v requirements.

Ah, I didn't know about that; I wasn't sure if old configs would still work.

Is there a relatively easy way to make configs to support other planets, or would I have to write an entire mod for that? I've been using XPC and OPM (in 1.7.3, for reference) and I'd like to use EVE but I won't use it if the stock planets will look drastically better than the modded ones, since the difference would be far too obvious.

I launched a Munar flyby probe.

I constructed a small space station, and conducted the first spacewalk.

I completed a docking mission with my Drazana spacecraft. Next plan is a space station. Yes, I am aware that I made a mess of what I was saying during the landing at the end. As it turns out, recording videos is somewhat distracting.

I tried to record a video of what I'm doing now. I think I might make this into a series. This launch didn't go amazingly well, but I'll fix all the issues by next time.

Yesterday the wifi was out. I passed the time by using my Soyuz-building skills for evil. Gemini and Dragon 2 (albeit a scaled-down Dragon 2, because the Dragon-like Near Future pod only seats three and is roughly Apollo-sized) are probably the most unusual Soyuz payloads I have seen in a while. I would make an Apollo-Soyuz, but it would probably be too massive. Apollo-Proton on the other hand...