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.

Thank you for this mod I'm having a blast with it right now. I wanted to suggest two mods for the realish list which I think fit in very well - and seem to play nicely with SMURFF as well. For your consideration: CareerEvolution - this is a very, very nice career-mode contract pack with realish progression, requires some kind of unmanned first tech-tree - but works well with stock parts. Since using SMURFF on RSS instead of RO means RP0 is not an option - I think this is a great alternative. The developer, PAP is actually an RP0 dev as well. I use SETI-unmanned-before-manned with it, but you can use others (suggestions listed on the mod page). Personally I like it much better than the SETI-ContractsPack though. SurfaceExperimentPack - you want realish experience mods, and you list some good ones (I've installed the whole list) but they don't include much in terms of science packs. There are a few realish science mods out there, based on actual scientific experiments done in space, but this one is one of my favorites. It's a set of experiments that have to be set up by Kerbals on EVA (uses KIS/KAS) and are some of the same experiments the actual Apollo astronauts did on the moon - such as placing big reflective plates which can be hit by lasers from earth to measure the exact distance of it's orbit. It's a lot more interactive than most science experiments, which is cool for the realish factor, and certainly hits the "real" part of realish as it's experiments that we've actually done in the real world space programs. I don't know if you'll like them as much as I do (maybe check out Kotabo's video reviews if you're not familiar with them) but I thought I would make the suggestion.

I have found the bug in pyKAN, and just pushed a fix. The latest commit in git contains it. I will release a new official version with the fix once @minecraft2048 finishes his current work so it can all go into one release. In the meantime you can get the (small) fix by using the master-branch git code directly.

Possibly, but I suspect not -since I wouldn't be writing any new functionality into the GUI at all - the GUI would just do the exact same thing the CLI does, call out to the underlying libPyKAN to do the work, while presenting it all in a nice a frontend. There is a stub pykanqt file in the repo, but I haven't had time to actually work on the GUI due to work-load getting insane this year, was planning to do so on my last holiday but ended up spending it all househunting. Hopefully sometime soon.

Version 0.1.2 is now available. A new version of PyKAN with multiple bug features and some new features including a revamped commandline interface with support for multiple modules in a single command. My thanks to Feanor for his wonderful contributions to this release. https://github.com/ajventer/pyKAN/releases/tag/0.1.2

Heh, well I was working on it mostly because it was ruining my playthrough so I'll be starting over now that it's fixed because I am in the final tier of CTT... and only NOW do I do manned missions again ? I'd end up with no use for the science from most of them. But I believe I have correct values for the missing ones now - I was able to do a test playthrough up to the end of the year-in-space mission. So I'm preparing a P.R. - and in case anybody was wondering, the KerbalAcademy pack works great with this.

I probably could, but I'm still experimenting a bit with the fix - looks like it needs a bit more tweaking to work for everything - GROUP_ALL worked for first crew but not for the next ones. Once I have it working properly I will do a P.R.

I believe I found the cause of the bug. Found this in the log file: NotSupportedException: The SelectUnique method can only be used in DATA nodes with the uniquenessCheck attribute set. So I added: uniquenessCheck = true To the DATA node in the SSFirstCrew mission - that did not help. So I instead I removed the SelectUnique() call from the targetVessel line. That made the contract not show up in the All listing even - suggesting it broke it entirely. Next thing I tried was to open my save file, get the hash for my station vessel - and replace that entire line with one that read targetVessel1 = <hash code> Hoping this would match what SelectUnique was meant to return. No luck. I googled the error message, it's actually defined in the ContractConfigurator code - so this may well be a version incompatibility with C.C. perhaps @nightingale has some insights ? Update: I found it, my very first hunch was right - it did need a uniquenessCheck line added, I just had to look up valid values for it. Based on my understanding of the documentation, and what I think the contracts want to do: adding uniquenessCheck = GROUP_ALL to every one of the targetVessel data nodes is the fix for the bug.

The only other contracts I have active is CactEye so I doubt it.

I seem to have encountered a bug. I launched a space station when I got the contract, completed it successfully. But the next contract never appeared. After a while I got concerned and looked. The first crew contract show "Get your space station" as unmet. I am playing with SSRSS and all other contracts seem to to work fine. Since I cannot get this contract, I also cannot progress with any other crewed missions. Is there a work-around, perhaps a save-file hack I could use for right now ? Or a fix suggestion to get it to appear ?

Those are all implemented - I've not had a mod fail to install correctly through it in a long time - I use PyKAN as my own client for day to day stuff -and my current playthrough is on SSRSS, with a whole slew of other mods, and working well. The main reason I didn't do it that way at the start was to avoid the risk that bugs in my then, still new, project could corrupt people's CKAN systems. Right now the CKAN registry is treated as a read-only access - so pyKAN knows what CKAN has installed, but not vice versa. But the code has been quite stable at the library level for some time now - so it's probably safe to add that feature now. The main place I want to evolve the code hence-forth is on the frontend side, it really could use a GUI.