Aelfhe1m

It's not just inflating the outer shell but also equipping the interior space with furniture, shelves, containers, equipment, machinery etc. etc.

@jonrd463 I've seen similar behaviour in a variety of spaceplanes recently (not just ones with OPT parts) but mainly in roll oscillations that start out gently but quickly build up to wild tumbling. Some planes can be fixed by playing about with adjusting control authority on the reaction wheels (or just disabling them and relying on RCS) but others I've just had to fly manually instead. Another tactic I've been using to mitigate is turning on fine controls and setting the max velocity on the docking auto-pilot very low (0.2 or so) but at that point it's no longer saving me any time so that's often when I switch over to manual. The save this is happening in has a HUGE amount of mods so I'm not ready to point a finger at any suspects.

I thought that might be the case but just wanted to check. I can understand the tracking stations not working, they are quite new after all , but it's also not working for me with the regular monoliths. The same rover visited monolith00 and monolith02 on Gael but couldn't get a reading from either: PS: They are identified in SCANsat maps as monolith00 and monolith02

@DMagic There seems to be a minor inconsistency in the way the information text at the bottom of the main map and zoom map windows show anomalies. In the main map the text says "Anomaly: <name>" whereas in the zoom map it shows "?: <name>" These images were taken in Galileo Planet Pack if that makes a difference. PS: second image also shows a potential problem with orbital science's anomalous signal detector in my (VERY) heavily modded save - it always shows "No anomalous signal detected" even when I'm right next to an anomaly (log).

@DC Early game rockets will tend to produce highly eccentric orbits (just look at the real life Explorer, Vanguard etc.). To reliably get a more-or-less circular orbit I need the final stage to NOT be a SRB - some form of RCS or multi-ignition engine is needed for really fine control. However to try and minimise the eccentricity you can let your AJ-10 stage coast to apoapsis (provided its above the atmosphere) and then use its RCS to align pro-grade before staging the sergeants. Practice flying the first two stages consistently to get more or less the same burnout apoapsis on each launch. After that playing with the amount of fuel in the sergeant stages can help to target more closely having just enough dV in the final stages to circularise - doing a test flight and pausing the game just as you pass through circularisation can help gauge how much fuel to remove but reducing the weight of the final or penultimate stages will of course have knock on effects on the other stages. To be honest I wouldn't worry about it and wait until you've unlocked better tech before trying for precision orbits.

@ClLaw When you extract RP-0 to your GameData folder it should include the bin/yml2mm script. Open a command prompt (on Windows open the start menu then type cmd and press return), Change directory to the GameData/RP-0 folder (type cd "e:\Games\KSP\1.2.2 RP-0\Gamedata\RP-0" - changing the bit in red to match where you've installed your copy of KSP that you're installing RP-0 on - and press return) Then type the "perl bin/yml2mm". This should create a Tree.cfg file in the same folder. Edit: I typed the above from memory but I got the location of the folders a bit wrong. I've now actually checked and here is the corrected version. Download the master branch from GitHub (link) Extract the zipped RP-0-master folder to a temp location (e.g. e:\Games\Temp\RP-0-master) That folder will contain the tree.yml file, the bin folder with the script, the source files and output GameData folder. Open a command prompt (on Windows open the start menu then type cmd and press enter) In the command window change the folder to the unzipped temp folder (type cd "e:\Games\Temp\RP-0-master" and press enter - changing this to reflect the actual path you unzipped to - you may also need to switch to the correct drive first e.g. by entering e:) Type perl bin\yml2mm and press enter to compile and replace the Tree.cfg file inside the temp GameData folder (e.g. e:\Games\Temp\RP-0-master\GameData\RP-0\tree.cfg) You can now replace the RP-0 folder inside your KSP GameData folder with the version from the temp GameData folder to have an up-to-date version of the mod. Sorry for any confusion my mistake may have caused anyone.

Almost. Deleting a module requires empty braces after the filter so: @PART[Tundra_ASM]:NEEDS[!Karbonite]:FINAL { -MODULE[ModuleResourceConverter_USI]:HAS[@INPUT_RESOURCE[Karbonite]] {} }

I've only skimmed the article (interesting read) but it's about "pure" gravitational slingshots. You can get a much bigger boost by taking advantage of the Oberth effect during your sun-dive and doing a powered slingshot - burning fuel while whizzing past close to the Sun (or Ciro) gives you a lot more dV than burning it out at Earth's (Gael's) orbit.

@MaxL_1023 and @CatastrophicFailure. Most of the articles I could find about Jupiter -> low solar slingshot missions were in various science journals behind paywalls - however there were a couple of mentions in JPL studies including: https://interstellar.jpl.nasa.gov/interstellar/probe/requirements/concept.html and http://www.esa.int/gsp/ACT/doc/MAD/ACT-PRE-MAD-InnSys-McNutt.pdf (only brief mention). There's also a nice article about the science goals of the FOCAL mission to 550 AU on Centauri Dreams (http://www.centauri-dreams.org/?p=785) but not about how to get there efficiently.

Added a waypoint for Mount Iodos.

Ah, missed that - now fixed in my pull request. If there are any other named landmarks that would be worth adding just let me know and I'll include them too.

I've created a pull request on GitHub with fixes for these issues. I've only did limited play testing but seems to work fine in my GPP career game.

I've created GPP compatibility patches for these two contract packs and put pull requests on @nightingale's GitHub project pages. Field Research (pull request) - fixed references to the Sun to be Sun() for compatibility with any planet pack. Added GPP specific conditional change to the Eve contracts to target Tarsiss and Hadrian instead. I felt these were the best fit since the contracts relate to bodies with non-water liquid surfaces (RSS changes these contracts to Titan). Tourism Plus (pull request) - Modified waypoints for sub-orbital flights when GPP present to be - North Pole, South Pole, the alternate KSC locations from KSC switcher and the highest point on Gael (I named it Mount Maximus just to call it something). - I also added some RSS specific waypoints while I was at it .

@akron All good points about TechTree. Another thing you might want to consider is how technology develops over time. A part with the same basic capability (e.g. range in the case of an antenna) may start off as bulky, heavy and consuming a fair amount of electric charge to operate but over time (subsequent tech nodes) other parts with the same capability (range) might be introduced but lighter, more compact and more efficient. Cost for more advanced versions could be argued either way depending on whether the part might be considered mass produced or custom specialised products.

I'm going to need more details. I just tested both a CKAN and manual install into a clean copy of KSP 1.2.2 with no problems. Can you post your logs as described in the following post? By the way the inherit, font and test layouts are not intended for actual game use but are included as syntax examples or for testing purposes.

I'm using the 11.4.0 tagged version which includes that file. Doh! I'm blind! Copying in the tree.cfg file fixed the issues with both the number of parts marked non-RP-0 and parts being marked unpurchased. Yes, I've got RealHeat installed (the 1.2.2 recompiled DLL). Nothing definitive to say yet but some light testing last night seemed to have very low ablator usage for reentry from LEO and LVO (Venus). On a similar note the parachutes (real chutes configured radials) showed the same strong heat warning bars when deployed I'd seen previously in 1.1.3 while no other parts on the lander showed any heat warnings - although this may be more a problem with my design rather than anything systematic. Didn't see any significant issues during several hours of play testing last night. I test launched several rockets that I had designed during my 1.1.3 play-through and they seemed to behave (very subjective) as expected. Docking a supply drone to my LEO space station worked flawlessly as did undocking the crew transfer vehicle for return to Earth. Jumping to each "in flight" vessel from the tracking station showed no noticeable problems with any missing parts or deviation from expected orbit. Even old landers on Mars, the Moon and Phobos loaded with no problems. Queued up manoeuvre nodes for probes en-route to the outer planets were also still showing the expected post node encounters. Performance felt similar to 1.1.3 although I think I'll need to add MemGraph to this build as well to reduce the time between GC - it was essential for me in 1.1.3. MechJeb was the only noticeable problem - and that minor - with a couple of times where it tried to fire the engine prematurely when asked to execute a manoeuvre (easily solved by manually waiting for the correct time before executing) and some back-and-forward oscillations when using Smart A.S.S. that weren't present when using the stock SAS. Possibly PID tuning?

I've just started doing some preliminary testing into porting over my long running (started in 1.0.5 and currently in 1.1.3) RP-0 career into 1.2.2 (I'm basing it off this spreadsheet @rsparkyc published on the RO discussion thread). Initial impressions are: The good: All in-flight vessels loaded safely and appeared to be in the right orbits - I need to do a careful comparison of resources/dV remaining and exact orbit parameters. KCT build queues, tech unlocks, techs being researched and build/research rates carried over without problem. Accepted contracts appear to have carried over successfully (will need to do a careful case by case examination of each wrt expiry dates, rewards, penalties and vessel tracking to be sure). Glitches/issues: Mk 2 Pod (4m) (the VSR replaced Mk1-2 command pod) has a visual issue with permanent RCS jet exhausts displayed from all ports. This is visual only and does not affect manoeuvring or resource usage as far as I can tell. No other part has shown the same issue yet that I've tried. Image In one load of the save a large number of unlocked parts became unpurchased again - easily fixed by re-purchasing them and then "cheating" funds back to original level Many parts picking up the "non-RP-0" label that weren't labelled as such in 1.1.3 Untested: FAR seems to work fine for rockets but I've read it's not yet ready for high speed jets or spaceplanes but since I don't generally build these I can't comment. Still need to check whether individual engine configurations that were unlocked have carried over correctly Re-entry tests - I've done some test launches and orbital manoeuvring without issue. I'll be doing at least one re-entry test tonight. Atmospheric friction/heating comparisons in general Science - the number of points I have to spend is correct but I haven't checked in detail that the science gathered per biome is still correctly listed Remote Tech - vessels in flight that are supposed to have connection still do but I haven't checked ranges or signal strengths etc. Or behaviour when signal is lost. KJR interaction with IR joints - to be tested tonight Not currently running with full suite of mods that I was using in 1.1.3 so will need to gradually add the others (that I still consider necessary/useful) and test again Lot's of other things I haven't thought of yet...

There's a mod called NavBallAdjuster that might help

Well I'm still playing RP-0 in 1.1.3 but I've also started a colonisation save in Galileo's Planet Pack in 1.2.2. I played RP-0 this afternoon (designing a fast transfer Neptune probe and getting my latest two Venus landers into parking orbits to wait until Earth is in a position I'll be able to maintain communication during a daylight landing) but will be switching to GPP after dinner (sending up the core of my Iota orbital station and expanding the Gael station). 1.2.2 seems a little more stable and performant with a stockish game. Hopefully this will translate into RP-0 once all the mods are updated and I can migrate my save (it stated in 1.0.5). That's the way I do my updates. Start with a clean unmodded install of the current version then download latest versions of each mod, install, test, next mod... until I've got all the essential mods needed for a particular save installed then I'll copy over the save folder and do another round of testing/tweaking and adding "optional" mods.

Version 1.2.7 Released Fix issue #10 where configuration dialog would not show correctly if Historian.cfg file had to be created during start-up (e.g. after first installing mod and add action to Visual Studio build sequence to automatically delete Historian.cfg so I don't overlook this breaking in the future (thanks @razark) Add configuration option to allow setting text to be shown for empty crew slots i.e. in pilot, scientist, engineer (and short or list variants) tags when no crew of that type are present in vessel per @razark Default = None (same as previous version) Add configuration option to allow setting text to be shown in Crew, CrewShort or CrewList tags for a vessel with no crew. Default = unmanned (same as previous version). Fix #13 Out by one error when displaying Kerbin formatted dates (thanks @tg626). Modify text parsing routines to remove many temporary strings and to use cached stringbuilder if available. Should reduce garbage collection footprint.

Umm, we're both wrong. It should be Diznam 31, 0001 (10/31/0001). The change in date handling in 1.2 has introduced an out by one error in my year calculation code (will be fixed in next release - probably this weekend). The month is correct however: Month 1 (days 1 - 35), Month 2 (36 - 71), Month 3 (72 - 106), Month 4 (107 - 142), Month 5 (143 - 177), Month 6 (178 - 213), Month 7 (214 - 248), Month 8 (249 - 284), Month 9 (285 - 319), Month 10 (320 - 355), <---- Month 11 (356 - 390), Month 12 (391 - 426) or programatically MonthNumber = Floor((DayNumber - 0.0001) / 35.5 + 1) See this spreadsheet for full year calendar (It's not prettily formatted. It was just intended for my use when deciding how to split months, days and days of week and writing the test cases for my code).

Ratio should have a capital R.

I've finally got around to trying out some of the Surveyor parts (in Galileo's Planet Pack) and I'm really liking them. The only thing I'd say is that the sampler scoop and camera seem a little on the heavy side. I couldn't find exact figures for the real world originals but did dig up some figures from the Apollo 12 retrieval of some parts from Surveyor 3 (I forgot to bookmark the page) that suggest they were considerably lighter. Here's a couple of shots of my frankenprobe's mission to Iota (other parts are from stock, SSTU, Bluedog DB and BoxSats) On another note I found an omission in the Bluedog DB patch that turns the IR spec. experiments into run once versions despite both yours and BDB's being multi-run originally. I've submitted a fix on GitHub.

Looking at the cache all the TechRequired fields seem to be mixed values but the names match the patch in your post so it should affect them. It might be ordering between your patch and other patches. Try adding :FINAL after :NEEDS and see if that helps.

You've got the :NEEDS[] in the wrong place. It should be after the part list not before it. Also use an @ to edit TechRequired since it should already exist in all parts. // Parts @PART[AdjustableRailScaleable|dockingwasher_stdScaleable|dockingwasher_freeScaleable|GantryLargeScaleable|GantryLargeScaleableVariant|IRHingeClosedScaleable2|IRHingeOpenScaleable|IRHingeTallScaleable|IRHingeTallNDScaleable|IRPistonScaleable|IR_RotatronScaleable|IR_Rotatronmk2Scaleable|IR_RotatronVTOLScaleable|TelescopeFullAScaleable]:NEEDS[MagicSmokeIndustries] { @TechRequired = IR }