metalpoetza

I seem to have found a bug in the contractpack. I have completed the First Kerbal in Orbit and Flyby the moon contracts. The next contract is meant to be "first EVA". Looking at it in the "All" section it shows three requirements: all three are shown as "Met". I also have upgraded the astronaut centre to enable EVAs - yet the contract isn't being offered. In fact, no more contracts are available. I currently have all stock contracts disabled, only the contracts from packs (KSRSS, ScanSat and CactEye) are enabled. I thought perhaps the issue was caused by the Better Early Trree mod - but removing that didn't make a difference. I honestly have no idea what else could be needed to make the next contract available ?

NVM - Seems it was user error in the install.

I'm trying it out at the moment, it starts of well enough - but I haven't gotten to the complicated contracts like the station or rover ones yet. I'll post some feedback when I have results.

I also have KIS/KAS installed. That could be where the incompatibility lies.

Some bug reports when using this with RealSolarSystem: 1) After performing a Venus flyby you get a contract to "Flyby" with no body specified. I suspect this contract would normally point to Gilly but it's being broken since Venus has no moons. 2) Orbit the moon of Mars. This contract is broken - most likely because Mars, unlike Duna, has 2 moons. It is impossible to finish the contract. If you use a single craft that orbits both sequentially, it only counts the one you are currently around. If you use two craft and orbit each, then the contract will show Deimos orbit when one craft is active, and Phobos orbit when the other is active - but never both. The "land on" and "fly by" contracts work fine however - so presumably this one just needs to be changed to match how they do their checking. In both the above cases one cannot progress unless you use the Alt-F12 cheat menu to finish these impossible contracts. And a balance issue: Fairly early you get a contract to flyby Mercury, as soon as this is done, you get a contract to land a Rover on Mercury. This has to be completed before you get any outer planets missions -but that is entirely unbalanced to the point of being virtually impossible. Mercury is much, much harder to land on than it is to fly by Jupiter or Saturn. In fact no real-life mission has done it, the only real life mission to even orbit it had to do 3 gravity assists in a row (Venus/Earth/Venus) in order to do so. Moho is tough, but Mercury is a whole other beast. If you don't kill of a massive amount of speed with gravity assists and encounter it from an almost directly parallel orbit it can easily take 20km/s just to get captured - to then still land something. This mission should be made non-required for progression, or moved much, much further in the line when people will have the skills and technology it requires, I would say around the same time as the first Uranus/Neptune missions. It is only marginally easier than Pluto.

I can confirm this. I just did a test. The H250-64 hydrogen tank weighs 700kg empty, over 2 tonnes full.

At the time I got it, I was in flight. I had two crewed vessels, both in Earth orbit. A space station and a command-module returning from the moon. Neither was consuming any snacks - and that error popped up sporadically in the logs. Presumably whenever eatsnacks was being called. I am on Linux, 64-bit in a very heavily modded game using RSS and SMURFF, almost everything Neartea has made and a few roverdude mods as well. I also had timecontrol installed, which I since realized was causing my EC to zero out in high-warp (the opposite of what it normally does) - so I got rid of that (pity, I liked that mod). It's at least conceivable that the two issues are related. I kept a copy of my install at the time I noticed this - before I started trying to fix things. So if you tell me what sort of tests could help I can do them for you. I did a case insensitive text search in the log but there is no reference to ConsumeAndGetDeficit at all.

Snacks are not getting consumed at all for me. KSP1.3.1 with Snacks 1.8.6. This is all I could find in the logs: [LOG 17:56:51.298] [SnackController] - EatSnacks called [LOG 17:56:51.300] Snacks - EatSnacks: Object reference not set to an instance of an object at Snacks.SnackConsumer.runConverters (.ProtoVessel vessel) [0x00000] in <filename unknown>:0 at Snacks.SnackConsumer.ConsumeAndGetDeficit (.Vessel vessel) [0x00000] in <filename unknown>:0 at Snacks.SnackController.EatSnacks () [0x00000] in <filename unknown>:0 [LOG 17:56:52.656] [SnackController] - EatSnacks called

That all sounds excellent. I look forward to playing with it. I agree that power consumption for avoiding boil-off should be steep. It makes a nice ballance then for the other changes - you still won't want to send LH2 on a deep-space mission due to all the power generation you would need (and full boil-off prevention requires enough power that no real space ship has even tried it yet - so it's definitely still gamey). Thanks dude.

It does seem to be more viable once cryotanks are unlocked - if you use the big balloon tanks. Though this does significantly lower the applicability. I would suggest looking at it in terms of where LH2 is used in the real world. I think right now SMURFF is a bit more limited than reality. The space shuttle used LH2 for it's external booster for example. It's not generally a good fuel for a small satelite - because it's so bulky. It does make a good upper stage fuel - though right now that only becomes possible in-game once you have balloon tanks - I think it's a bit too punishing there, either that or the balloon tanks need to unlock earlier (or the engines later). The other major thing it is useful for is as an engine for injection burns. You launch something into orbit, the stage that does your burn to where-ever you're going uses LH2 for a nice lightweight fuel with lots of delta-V, then you discard that stage. Boil-off isn't a big problem then because you aren't taking it with you. But at least now I know that what I'm seeing is actually intended. If I'm genuinely unhappy with it - make a custom hack for myself, it's the way you want it to play.

@Kerbas_ad_astra is it expected that liquid hydrogen engines from the CryoEngines packs have terrible performance (at least before unlocking cryotanks- haven't tried it with them yet) ? Sticking the small 1.25m cryo-engine on a 1.25m tank gives about 1/4 of the delta-V that you could get out of putting a terrier on the same tank. I know LH2 is low-density so wants large tanks but its as if the engine ISP is way, way lower than it ought to be (the reason LH2 is a good rocket fuel is it's incredible ISP). Or is this indicative of an issue with my install ? I've actually just unlocked the cryotanks in the high-performance-fuels node - and so far I've not yet used a cryoengine once, simply because at every stage they were - by far - the worst delta-V for mass option available. This makes me think there may be a bug (this is on 1.3.1). If there is a bug, let me know what information I should share that could help fix it.

Thanks for the response - I managed to get it working after I discovered a copy of the temp patch inside a post (the download appears to be gone), and edited the pqs_terain file in the RC4 release. I haven't got a working monodevelop setup right now, so can't actually recompile -though I may try to do so in the near future and see if I can offer any help. I wasn't judging on the timelines - I fully understand we're talking about support for a version on which your key dependency isn't even fully released, and I really understand the idea of "not really having everything you want in it yet". Heck I'd be the greatest hypocrite on earth if I complained about release times, I've been failing to find time to write the next version of pyKAN for over a year now ! I just found it curious that the stock ones were proceeding so much faster than the RSS ones I know about - and wondered if there was a technical reason behind it. For the moment it's working okayish for me. I did have one landing where apparently every longitude had become an narrow ocean (cutting right through continents) but it appears to have been a one-time glitch. Unfortunately I didn't think to take a screenshot and it seems a bit nasty to be reporting bugs on an unreleased hack

It took some digging but I found the post with your patch link... unfortunately when I hit the download link dropbox gave me a 404 error. I would be happy to try it out tonight - but I need to get my hands on it first lol

No build I could find. There is a branch - in the github repo - but I've not seen any build. I have no idea what would happen if I self-compile that branch as I can't easily tell from looking at the commit history how much work has actually happened in that branch yet. It seems RSS introduces some real difficulties for visual mods - considering how 1.3 stock has at least 3 great ones now (AVP, SVE and Spectra) while RSSVE is still in RC status for 1.2.2. I suspect something makes it more difficult ?

Has anybody tried this in Linux with openGL ? I have a pretty hefty gaming PC with 16Gb of RAM and an nvidia GTX1050. Second question - will this 1.2.2 build run on 1.3.0 ? RSSVE is basically unusable on 1.3 so this may be a nice(r) alternative if it works well.