Contract Pack - History of Spaceflight - V1.0

[Morphisor]

5 hours ago, wolffy_au said:

Let me start by saying this is one of my all time favourite KSP contract packs.

I have been obsessively playing the Soviet contracts in RSS (I had to make a bunch of modified engines and fuel tanks to get it to play nice) and I'm wondering if there is anything I can do to help create more Soviet contracts e.g. Lunokhod Ye-8? I noticed also that the Kosmos missions are bundled together but they overlap with other areas - I'd be happy to help sort them out into their respective streams.

I think I can get my head around making contracts - what's the best way to submit them back to you guys?

Sure if you're up to adding contracts that's definitely welcome by any means - I don't have time/energy to continue work on it myself for the foreseeable future, though I will provide support where needed of course.

The best way to contribute is by using GitHub and creating your own forked branch - then making pull requests whenever content is completed. I recommend using the desktop app to make it easy for yourself. I'd prefer if you contact me through messaging to talk through the details if you're going through with it. 

[wolffy_au]

On 2/27/2021 at 2:15 AM, Morphisor said:

Sure if you're up to adding contracts that's definitely welcome by any means - I don't have time/energy to continue work on it myself for the foreseeable future, though I will provide support where needed of course.

The best way to contribute is by using GitHub and creating your own forked branch - then making pull requests whenever content is completed. I recommend using the desktop app to make it easy for yourself. I'd prefer if you contact me through messaging to talk through the details if you're going through with it. 

Ok, so I'm all set up on GitHub Desktop and I've got a copy of the repo. I can't message you directly on here cause I still need to do 4 more posts! 

In the meantime I'll keep chatting with Friznit on Steam and see what we can sort out.

[DeadJohn]

@Morphisor or anyone else, what tech tree works well with this in the RSS version? The first contracts I'm getting are dependent on parts too high in the stock tree and CTT. Is the intent to advance up the tree using stock contracts before trying historic contracts?

Examples:

1. "5000m USA flight". Even though the contract doesn't call for it, the spirit of this needs a plane rather than vertical rocket. Wheels and plane engines are several branches up the tree.
2. "TinyTim" sounding rocket: Must be unmanned but all early control parts need crew. Total mass must be less than 0.6t; the early RT-5 SRB is too heavy and lighter SRBs are pretty high up the tree.

(if it matters, I'm using SMURFF not RO)
 

[CAPFlyer]

Tiny Tim is an uncontrolled rocket, so you don't need control parts.  Most sounding rockets, especially the early ones, are either spin stabilized or simply ballistically stabilized by the fins.  So it's more about getting the right angle at launch than anything else.

[Morphisor]

On 8/2/2021 at 1:00 AM, DeadJohn said:

@Morphisor or anyone else, what tech tree works well with this in the RSS version? The first contracts I'm getting are dependent on parts too high in the stock tree and CTT. Is the intent to advance up the tree using stock contracts before trying historic contracts?

Examples:

1. "5000m USA flight". Even though the contract doesn't call for it, the spirit of this needs a plane rather than vertical rocket. Wheels and plane engines are several branches up the tree.
2. "TinyTim" sounding rocket: Must be unmanned but all early control parts need crew. Total mass must be less than 0.6t; the early RT-5 SRB is too heavy and lighter SRBs are pretty high up the tree.

(if it matters, I'm using SMURFF not RO)
 

 

On 8/3/2021 at 2:45 AM, CAPFlyer said:

Tiny Tim is an uncontrolled rocket, so you don't need control parts.  Most sounding rockets, especially the early ones, are either spin stabilized or simply ballistically stabilized by the fins.  So it's more about getting the right angle at launch than anything else.

I assume by control part a command module such as a crewed part or a probe core is meant. My personal preference for a tech tree is Unkerballed start, but in almost all user cases I would suggest to add parts mods to your liking to your install. Almost all history based parts mods have some extra early probe cores for control, you'll find my recommendations in the OP. Those missions mentioned are working as intended otherwise.

[CAPFlyer]

Ahh, I thought Squad changed the default tree to have at least one of the unmanned probe cores at the start?  I run such a heavily modded KSP anymore, that I don't dare try to assume what is stock or not anymore.

I don't run Unkerballed or Unmanned Before Manned anymore because I run the US Rockets pack (which includes the Aerobee rockets and their cores) and that gives me appropriate pods anyway from the start to be able to do things like Tiny Tim since I also use TweakScale and Procedural Parts to let me build those early rockets like Tiny Tim that don't have bespoke parts.

[wolffy_au]

So I've been helping @Morphisor with the Soviet line of contracts and I also experience the same problem. I've tried using pure stock (and experimental parts in the contracts including probe cores). Hopefully that will solve the problem for stock.

In RSS pure stock parts only get you as far as R-7, and then the stock parts are way too heavy to get into orbit in RSS. 

For RSS these are the mods I've experimented with:

• For the weight problem I use SMURFF but on fuel tanks only
• Procedural Parts mod if you want realistic shapes especially for early rockets
• Sounding Rockets mod for early contracts but I find them still to big for GIRD rockets
• I've made my own custom Soviet engine configs

Edited August 23, 2021 by wolffy_au
Left out RSS detail

[Gordon Dry]

The KSP-AVC check claims there is a v1.0.0.0

https://github.com/Frylovespi/History-of-Spaceflight/blob/master/RSS/GameData/ContractPacks/HistoryofSpaceflight/HistoryofSpaceflight.version

which is not as it's 0.9.2

 

Edit:

Ah, I see, the releases are outdated - and all point to the same URL as above.

I downloaded the master branch. Files are newer,  .version files still all point to RSS.

 

 

Edited October 31, 2021 by Gordon Dry

[baldamundo]

Enjoying this contract pack, but I've just realised none of the Vostok missions are appearing in-game. Have just had a look at the files, and it seems like this is due to a typo - they all say "group= VostokMission " when it should be "group = VostokMission" with a space before the equals sign.

[Morphisor]

1 hour ago, baldamundo said:

Enjoying this contract pack, but I've just realised none of the Vostok missions are appearing in-game. Have just had a look at the files, and it seems like this is due to a typo - they all say "group= VostokMission " when it should be "group = VostokMission" with a space before the equals sign.

While that may not be aesthetically pleasing, the lack of a space does not have any functional effect. If the group assignment of a contract is parsed incorrectly, the entire contract would fail to load. It's doing so just fine on my end. Something else must be wrong for you - you can check what's going on by checking the CC debug menu (Alt-F10 once the game has loaded) and finding any errors associated with the contract. Any faulty contract will show in red text, mousing over it will allow you to scroll to the error report.

[akyyy]

Hi!

I tried Veronique contract, i have rocket, but  unchecked mass in the air.

 

[baldamundo]

On 12/23/2021 at 1:50 PM, Morphisor said:

While that may not be aesthetically pleasing, the lack of a space does not have any functional effect. If the group assignment of a contract is parsed incorrectly, the entire contract would fail to load. It's doing so just fine on my end. Something else must be wrong for you - you can check what's going on by checking the CC debug menu (Alt-F10 once the game has loaded) and finding any errors associated with the contract. Any faulty contract will show in red text, mousing over it will allow you to scroll to the error report.

ohhhhh. i think what it is is the compatibility patch for Tantares - some of the parts/names have changed, so it's breaking some of the contracts

[baldamundo]

For the Vostok missions and for Kosmos-110, andromeda_crew_1 should be andromeda_crew_s1_1 or andromeda_crew_s1_2

and then with the Salyut ones, vega_crew_1p5_1_1 should be...i'm guessing tucana_crew_s1p5_1 or tucana_crew_s1p5_2? or grus_crew_s1p5_1 for the Almaz version

A few errors as well for some science defs, but I'm not sure if that's Kerbalism or KiwiTechTree interfering for Kosmos 122, Kosmos 92, and with the CoatlProbesPlus science defs for Mariner-4, Surveyor 3, 5, and 6, Apollo 12, OGO 1 and 3.

[Morphisor]

1 hour ago, baldamundo said:

For the Vostok missions and for Kosmos-110, andromeda_crew_1 should be andromeda_crew_s1_1 or andromeda_crew_s1_2

and then with the Salyut ones, vega_crew_1p5_1_1 should be...i'm guessing tucana_crew_s1p5_1 or tucana_crew_s1p5_2? or grus_crew_s1p5_1 for the Almaz version

A few errors as well for some science defs, but I'm not sure if that's Kerbalism or KiwiTechTree interfering for Kosmos 122, Kosmos 92, and with the CoatlProbesPlus science defs for Mariner-4, Surveyor 3, 5, and 6, Apollo 12, OGO 1 and 3.

Thanks, I didn't realize tantares updated to a different part name. I'm aware of the dev version of BDB being affected as well for Apollo. I may see about completing the intended update and including the necessary fixes for both mods 

The science defs is most likely Kerbalism, but I'll check that too in a regular build.

[Morphisor]

On 12/24/2021 at 1:45 PM, akyyy said:

Hi!

I tried Veronique contract, i have rocket, but  unchecked mass in the air.

 

I found the RSS version forgot to stop the mass check after it's completed, fixed on the repo.

 

On 12/24/2021 at 6:56 PM, Morphisor said:

Thanks, I didn't realize tantares updated to a different part name. I'm aware of the dev version of BDB being affected as well for Apollo. I may see about completing the intended update and including the necessary fixes for both mods 

The science defs is most likely Kerbalism, but I'll check that too in a regular build.

I updated the BDB and Tantares parameters with the correct partnames, they should work now. Mind, for BDB this only works for the in-dev Saturn branch, for the release version please use the Apollo files from the current (hopefully soon to be old) release version of this pack. 

Also I checked against science errors with Coatl and DMagic installed alongside BDB and Tantares. I came up with some errors for the new Mariner contracts, but nothing else; the other definitions are fine, so I'm afraid that's a Kerbalism issue @baldamundo. Coatl also doesn't have any definitions for OGO, so I'm at a loss there.

[baldamundo]

3 hours ago, Morphisor said:

I found the RSS version forgot to stop the mass check after it's completed, fixed on the repo.

 

I updated the BDB and Tantares parameters with the correct partnames, they should work now. Mind, for BDB this only works for the in-dev Saturn branch, for the release version please use the Apollo files from the current (hopefully soon to be old) release version of this pack. 

Also I checked against science errors with Coatl and DMagic installed alongside BDB and Tantares. I came up with some errors for the new Mariner contracts, but nothing else; the other definitions are fine, so I'm afraid that's a Kerbalism issue @baldamundo. Coatl also doesn't have any definitions for OGO, so I'm at a loss there.

It's displaying an error for me on OGO-1 and OGO-3, Parameter CollectScienceA. but it's a very long error (is there a way to copy and paste from the Contract Configurator menu?)  that i can't pretend to understand. can't see anything obviously connecting it to a specific mod - but it looks like it's saying that it failed to parse "[InSpaceLow, InSpaceHigh]"?

I've got both Kerbalism and KiwiTechTree installed, which make significant changes to the science system, but i'm not sure why they should break that specifically.

Anyway, i'm not bothered personally since i was only planning on doing the Soviet missions, which we've now fixed, but posting anyway in case it's helpful for anyone else having the same issue i guess

[Morphisor]

29 minutes ago, baldamundo said:

It's displaying an error for me on OGO-1 and OGO-3, Parameter CollectScienceA. but it's a very long error (is there a way to copy and paste from the Contract Configurator menu?)  that i can't pretend to understand. can't see anything obviously connecting it to a specific mod - but it looks like it's saying that it failed to parse "[InSpaceLow, InSpaceHigh]"?

I've got both Kerbalism and KiwiTechTree installed, which make significant changes to the science system, but i'm not sure why they should break that specifically.

Anyway, i'm not bothered personally since i was only planning on doing the Soviet missions, which we've now fixed, but posting anyway in case it's helpful for anyone else having the same issue i guess

Yeah that's definitely another mod breaking it. I'm not entirely familiar how Kiwi handles it, but Kerbalism has been known to screw up regular science contracts for a while

[CAPFlyer]

I'm finally getting into some of the "deeper" and more complex missions of the pack, and I found one that I'm not sure how to reconcile.

Syncom 1

Per the pack, I have to launch into a Geostationary orbit, with an Inclination of 21 degrees and a LAN of 28 degrees.

Here's the problem I have though - on Stock/Kopernicus, there's no way to make those two items line up with the BDB Delta B or the real world flightplan.  I've tried multiple times using different profiles and guidance methods, but every time, even though I get the right inclination and GTO, when I fire the kick motor, the LAN is never close enough to 28 degrees to clear.  As such, I would like to propose that at least for these early launches where there's no real ability to "tweak" the orbit on the fly for those playing it more realistically, that maybe you remove the LAN requirement?  I ended up just using the debug console to complete the contract because I got tired of trying, but on future runs I think it'd be more fun to be able to clear it normally.

[CAPFlyer]

Also, here's a few pics of what my game save looks like right now on 3 April 1963 -

Low Kerbin Orbit

Quote

High Kerbin Orbit

Quote

Kerbol Orbit

Quote

 

Edited January 3, 2022 by CAPFlyer

[Morphisor]

2 hours ago, CAPFlyer said:

I'm finally getting into some of the "deeper" and more complex missions of the pack, and I found one that I'm not sure how to reconcile.

Syncom 1

Per the pack, I have to launch into a Geostationary orbit, with an Inclination of 21 degrees and a LAN of 28 degrees.

Here's the problem I have though - on Stock/Kopernicus, there's no way to make those two items line up with the BDB Delta B or the real world flightplan.  I've tried multiple times using different profiles and guidance methods, but every time, even though I get the right inclination and GTO, when I fire the kick motor, the LAN is never close enough to 28 degrees to clear.  As such, I would like to propose that at least for these early launches where there's no real ability to "tweak" the orbit on the fly for those playing it more realistically, that maybe you remove the LAN requirement?  I ended up just using the debug console to complete the contract because I got tired of trying, but on future runs I think it'd be more fun to be able to clear it normally.

Isn't more of a specific issue with the flying of the BDB rocket in question however? I know many others, myself included, have a lot of trouble flying the early Deltas to their spec. I'll have a look in any case - this the only troublesome contract? There's a few more GTO ones.

[CAPFlyer]

7 hours ago, Morphisor said:

Isn't more of a specific issue with the flying of the BDB rocket in question however? I know many others, myself included, have a lot of trouble flying the early Deltas to their spec. I'll have a look in any case - this the only troublesome contract? There's a few more GTO ones.

The main issue is the inability to do a true guided coast phase with multiple restarts.  Agena and Ablestar don't have this problem.  The issue isn't getting to GTO.  It's that making those very specific inclination and LAN specs with the launcher used is where the conflict comes in.  Had you done the orbit like you did the Corona contracts with minimum orbital altitude, a required eccentricity of <0.01 and the inclination of 21*; I think you would've been fine to achieve the contract without an issue.  I was easily able to get Syncom 1 into the proper orbit with ISP to spare (not much, but enough).  It was getting all 3 orbital parameters you required (altitude, inclination, and LAN) to all match up with what I'm able to do because of the inability to do multiple firings of the 2nd, 3rd, and kick stages to tweak the orbit and the way maneuver planning works in KSP and MechJeb not really lending itself to being able to pre-visualise the entire launch path to launch to a LAN and be able to hit it reliably.

Also, again, I'm making it harder on myself (and I know it) by using things like EngineIgnitor and BDB, but as I understood the goal of this pack, I think I should still have a reasonable chance to succeed with these contracts and that's where my concern is with the design being so stringent compared to the prior launches with the same launch vehicles.

9 hours ago, CAPFlyer said:

Also, here's a few pics of what my game save looks like right now on 3 April 1963 -

Low Kerbin Orbit

High Kerbin Orbit

Kerbol Orbit

 

Forgot to make a note on this - the satellites in orbit still (and a few selected rocket bodies) are all being "deorbited" (terminated) based on the date on the mission.  When I launch I check what the decay date was, so for a lot of these early satellites, they are decaying pretty quickly so what's in orbit is what should have been in orbit for the USA missions on that date in history.  I think it adds to the personal challenge.  I'm launching on the right date and around the right time of day, and I've already had a couple of close encounters, so it's definitely adding to the experience.

Edited January 4, 2022 by CAPFlyer

[Morphisor]

6 hours ago, CAPFlyer said:

The main issue is the inability to do a true guided coast phase with multiple restarts.  Agena and Ablestar don't have this problem.  The issue isn't getting to GTO.  It's that making those very specific inclination and LAN specs with the launcher used is where the conflict comes in.  Had you done the orbit like you did the Corona contracts with minimum orbital altitude, a required eccentricity of <0.01 and the inclination of 21*; I think you would've been fine to achieve the contract without an issue.  I was easily able to get Syncom 1 into the proper orbit with ISP to spare (not much, but enough).  It was getting all 3 orbital parameters you required (altitude, inclination, and LAN) to all match up with what I'm able to do because of the inability to do multiple firings of the 2nd, 3rd, and kick stages to tweak the orbit and the way maneuver planning works in KSP and MechJeb not really lending itself to being able to pre-visualise the entire launch path to launch to a LAN and be able to hit it reliably.

Also, again, I'm making it harder on myself (and I know it) by using things like EngineIgnitor and BDB, but as I understood the goal of this pack, I think I should still have a reasonable chance to succeed with these contracts and that's where my concern is with the design being so stringent compared to the prior launches with the same launch vehicles.

Forgot to make a note on this - the satellites in orbit still (and a few selected rocket bodies) are all being "deorbited" (terminated) based on the date on the mission.  When I launch I check what the decay date was, so for a lot of these early satellites, they are decaying pretty quickly so what's in orbit is what should have been in orbit for the USA missions on that date in history.  I think it adds to the personal challenge.  I'm launching on the right date and around the right time of day, and I've already had a couple of close encounters, so it's definitely adding to the experience.

So here's how the Syncom contracts are set up: because the historical orbit is geosynchronous with 30 degrees inclination, I made use of CC's OrbitGenerator behaviour instead of specifying an orbital range. Geosynchronous orbit is a very specific position which is different for each planet, so using the regular method used in the other contracts would mean that the satellite mostly wouldn't actually be in synchronous orbit after completion.

The contract then automatically generates a synchronous orbit with somewhere in between 0 and 30 degrees inclination. It includes a margin of error for reaching the orbit, it doesn't have to be 100% perfect. None of the other values are specified by the contract, so any resulting orbit defined is purely determined by what CC reads out is necessary for the homeplanet you're using. It should be asking exactly how it happened in actuality, unless CC is in error, which I'm not aware of.

I'm not inclined to change a mission's goals away from their historical objective to make up for parts not being perfect for the job, historical accuracy comes first. So unless I'm missing something, I'll leave things as they are. Sorry that it's troublesome for you.

[Gordon Dry]

Some of the orbital parameters came up to the protocol papers after the launch was done, written down by a protocolist - so it's easy to put those into contract configs, but nearly impossible in some cases to recreate them.

Only parameters that have already been set before the launch should be in contracts.

[CAPFlyer]

On 1/4/2022 at 6:08 AM, Morphisor said:

I'm not inclined to change a mission's goals away from their historical objective to make up for parts not being perfect for the job, historical accuracy comes first. So unless I'm missing something, I'll leave things as they are. Sorry that it's troublesome for you.

I'm not complaining that your objectives are historical.  I'm complaining that as implemented, the objectives are not historically accurate or achievable on a Kopernicus install.  I understand how you're generating the orbit.  However, when I input that orbit into MechJeb (with PVG) and other flight planners, I can't get those orbital elements to match with the limitations imposed by playing a BDB strict setup.  I can get one or the other, but not both.  I need either 1 more burn or a multi-orbit coast.  The first & second stages are needed to set the initial parking orbit, the third sets the GTO, but because I'm limited by the onboard Delta batteries for the coast phase, I have to fire at a point that my LAN doesn't end up at the right spot close enough to what the contract requires for it to be "good" (which I'm not sure what the bounds are on that because I've not gotten close enough and the contract doesn't specify what the margins are).  That's why I was suggesting relaxing the contract parameters so that it doesn't require the LAN parameter or some way to be somewhat more flexible so it was more reasonably attainable. 

Look, I'm not asking you to make it "easy" or less realistic.  I'm asking if you'd consider keeping the spirit (much as you have with the Corona missions) without making it so stringent that you restrict who can complete them.  Removing the LAN requirement for the orbit doesn't make it any less of a Geostationary orbit.  It also doesn't change the purpose of the mission.  Unless this is the RSS version flying on a full scale earth with every launch site in the right geo location, we're already making compromises on the orbits and inclinations because KSC in most of them is at the equator and even the "high latitude" launch sites on Kopernicus are under 30* inclination.  So there's only so much "realism" that can be obtained anyway.  I don't see how what I'm asking is outside that.

Edited January 5, 2022 by CAPFlyer

[Morphisor]

29 minutes ago, CAPFlyer said:

I'm not complaining that your objectives are historical.  I'm complaining that as implemented, the objectives are not historically accurate or achievable on a Kopernicus install.  I understand how you're generating the orbit.  However, when I input that orbit into MechJeb (with PVG) and other flight planners, I can't get those orbital elements to match with the limitations imposed by playing a BDB strict setup.  I can get one or the other, but not both.  I need either 1 more burn or a multi-orbit coast.  The first & second stages are needed to set the initial parking orbit, the third sets the GTO, but because I'm limited by the onboard Delta batteries for the coast phase, I have to fire at a point that my LAN doesn't end up at the right spot close enough to what the contract requires for it to be "good" (which I'm not sure what the bounds are on that because I've not gotten close enough and the contract doesn't specify what the margins are).  That's why I was suggesting relaxing the contract parameters so that it doesn't require the LAN parameter or some way to be somewhat more flexible so it was more reasonably attainable. 

Look, I'm not asking you to make it "easy" or less realistic.  I'm asking if you'd consider keeping the spirit (much as you have with the Corona missions) without making it so stringent that you restrict who can complete them.  Removing the LAN requirement for the orbit doesn't make it any less of a Geostationary orbit.  It also doesn't change the purpose of the mission.  Unless this is the RSS version flying on a full scale earth with every launch site in the right geo location, we're already making compromises on the orbits and inclinations because KSC in most of them is at the equator and even the "high latitude" launch sites on Kopernicus are under 30* inclination.  So there's only so much "realism" that can be obtained anyway.  I don't see how what I'm asking is outside that.

Perhaps my previous explanation was not clear enough on this: this LAN parameter is not something I specify in the contract, it's entirely generated by CC through the behaviour OrbitGenerator. This behaviour comes up with the values necessary entirely without my input. All I add to it is limit the maximum inclination and leave margin for error. I cannot change the way this works without doing away with a geosynchronous orbit altogether, or at least one that actually works in more than one system.