Aelfhe1m

Out of control spins after some time in flight can often be caused by the COM shifting relative to the COL as fuel is drained from the tanks. In the SPH you want to check where your COM is with full fuel load, with the liquid only tanks empty (to represent transition to rocket power) and with all tanks empty (for landing - you might reserve some fuel for a powered landing approach, but checking the balance when empty is a good idea anyway). If the COM moves significantly and especially if it moves behind the COL, then you might want to try redistributing fuel tanks or changing flow priorities to try and keep it better balanced during different phases of flight.

Looking at your MM config cache, both the com-16 and com-16S have the same packet size and resource costs configured, but the 16S has only 1/4 the power of the extendable 16. The cause of this appears to be Probes Before Crew which changes some of the stock antenna settings. After Kerbalism applies its own antenna patches this results in the 16 having an antenna rating of 1.00M and the 16S having a rating of 250k. Without PBC both antennae have a rating of 500k. The shorter range of the 16S is intended behaviour with Probes Before Crew because it is available earlier in the tech tree.

A start might be to upload your GameData/ModuleManager.ConfigCache file and Logs/ModuleManager/ModuleManager.log file to a file sharing web site (optionally zipped first) and then posting links here, so that we could examine how the 16-S gets configured in your build and which mods are patching it in what order.

Yes, all the examples I know of use indexes. In principle, you could create a variable to hold the name of a specific kerbal if you were going to be referencing them frequently rather than indexing every time but I don't think I've ever seen that done in a contract. A simple example of changing kerbal types would be the Space Camp contract in the Tourism Plus pack. Starting on line 38 you'll see a DATA node that creates two lists of kerbals, assigns a number of random new Kerbals as tourists and 3 new kerbals as candidates who will join your space program after the contract is successfully completed. These lists are then used in SpawnPassenger BEHAVIOUR nodes at line 130 and 138. Then at line 158 there is the BEHAVIOUR that simply changes each of those candidate kerbals into a pilot, engineer and scientist respectively. They are also given some experience points in the next BEHAVIOUR node. Unfortunately, I don't think anyone has written a CC extension to interact with Kopernicus or the stock PQSCity system in this way.

That's what my CKAN is set to for that install, yes;

Alba Aerospace released a press release today, 3rd October 1955, stating that pilot Angela O'Quinn experienced a bit of a scary moment when going for a new X-Planes altitude record in the twin engine XP-03 "The Flying Scotsman". The flight started nominally with an air launch over the Atlantic Ocean 500km off the Florida coast and then an aggressive pitch up to reach for the sky. But as she reached the peak of her flight, just above 70km, the thinning atmosphere gave nothing for her flight control surfaces to work against and the plane entered an out-of-control tumble, spinning slowly on all three axes. Fortunately, after a couple of terrifying minutes, she recovered control as the plane dropped below 35km and she was able to glide back to Cape Canaveral for a gentle 60 m/s landing on the runway. Miss O'Quinn refused to answer any questions of whether or not a change of underwear was required. The XP-03 experimental rocket plane Miss O'Quinn flew today is an evolution of the earlier XP-02 "Nessie" and XP-01 "Haggis" rocket planes which have flown ten times over the last year, gaining repeated altitude and speed records for pilots Angela O'Quinn and Irena Novák. Miss O'Quinn is also notable for having set a new jet aircraft speed record of 705 m/s in a Phantom II jet earlier in the year, breaking Miss Novák's previously held record of 623 m/s. Miss Novák currently holds the speed record for a rocket plane having reached 1626 m/s at 66.9 km altitude on 20th September. ==== From a new RP 1 career I've recently started. I began by working through the Suborbital Research Program at breakneck speed, while also completing Early Rocket Development Program on fast speed before switching focus to X-Planes Research and Early Satellites (Heavy). I've been focussing on planes for the last few launches while I wait for various technologies to finish researching before building an orbital rocket. While I could build one with current technology, I feel that my funds would be better spent waiting for more mature technologies to become available. These last two flights represent the limits of what these aircraft can achieve, and future contracts will require alternative designs (or at least engine upgrades for the jet).

Thanks for that quick update. I've tried it in my RP1 build and it works (mostly) great. Seems to be a slight problem with the setting not being reapplied on subsequent launches. Steps: In game, I bring up the WPM config panel and set a display opacity of about 60%. Grey background displays behind on-screen text correctly. Next flight without changing any settings, grey background is absent, but opening the WPM config panel shows it still set to about 60%. This is more of an annoyance than a breaking problem, as it's simply fixed by reopening the config and tweaking the opacity up or down slightly. Oh, and the green on grey is still a little bit hard to read. A darker grey or black would be better if it's not too much trouble. (Or an option to change all the text to white would also work)

Try setting Filters to All. Also what version of KSP is your install? This mod is listed in CKAN as 1.12.3 minimum version.

It's there for me. Just search for "Tweakscale". Also click the refresh button to make sure your CKAN mod catalog is up to date.

Simplest way might be to add a MM patch to update Configurable Containers to include them in its Soil tank type: @TANKTYPE[Soil]:NEEDS[GroundConstruction]:AFTER[ConfigurableContainers] { @PossibleResources ^= :$: MetallicOre 0.7; Metal 0.7;: } Not sure if the density numbers are properly balanced for the weight of these resources. I think the assumption is that some very specialised components need a high tech base to produce which may be beyond the scope of an off world colony and need supply from the home world (or some corporation might have a monopoly on their manufacture)

It's part of the Kerbalism patch on this line. DO NOT remove that line. It is supposed to remove the modules as part of the way it configures Kerbalism to work. Instead to get RR and Kerbalism to work together to make material kits for GC, RR would need to be updated to correctly insert the correct processor into the Kerbalism chemical plant controller patch; to add a new Process sub node into the Profile definition in 00_Kerbalism.cfg and add a new pseudo RESOURCE_DEFINITION node for that process. There may be other steps involved. I have little experience with configuring Kerbalism.

The bare bones of doing this is: clearscreen. print "Airspeed: " AT (0,2). print "Altitude: " AT (0,4). // loop forever printing updated airspeed and altitude UNTIL false { print ROUND(ship:Airspeed,2) + " " AT (10,2). print ROUND(ship:altitude,2) + " " AT (10,4). WAIT 0. } For a proper implementation you'd want to separate the printing into a function and then call it from inside your actual program control loop, but this is the code that shows airspeed and altitude at some specific location on the KOS terminal.

Except, that patch adds a ModuleResourceConvertor, but the Kerbalism patch removes all the ModuleResourceConvertors and adds Kerbalism's own processors. But none of the processors creates material kits.

@Ker Ball One Rational Resources, especially with the Kerbalism opt-in makes significant changes to the way ISRU works, including removing the module that this mod uses to create material kits. I can't see a recipe there for material kit production, but perhaps if you ask on the RR thread someone there will be able to help?

A bit late answering this, but the ModuleManager approach would be something like: @PART[*]:HAS[#TechRequired[highAltitudeFlight],#category[Aero]]:FINAL { @TechRequired = start @entryCost = 0 } // repeat the above patch for each of the different tech nodes you wish to affect // e.g. aviation, aerodynamicSystems, supersonicFlight, advAerodynamics // a full list of the tech node names can be found in // GameData/Squad/Resources/TechTree.cfg

Or there is a new mod in development that looks like it might be promising:

Have a look at: Everything is configurable on a part by part basis via MM patches. Quote: Features Engine Sound Replacements Jet Engine Sound Replacements RCS Sound Replacements RotorEngines Sound Effects Propeller Sound Effects Wheel Tire and Motor Sound Effects Decoupler Sound Replacements Collision Sound Effects Atmospheric Sound Effects (Featuring Sonic Booms if AirSim is enabled) Physics Based Hull Sound Effects (rattling, creaking in IVA)

How complicated this is will depend on what mods you have installed. Some mods store extra information about vessels or Kerbals in their own parts of the save files. Life support mods like Kerbalism or USI Life Support are prime examples. For a mostly stock (or stock + parts/visual mods) this is fairly straightforward. First - ALWAYS MAKE A BACKUP OF A SAVE FILE BEFORE EDITING IT You can do splicing using just a text editor, but KML makes it much easier, especially if you are on PC. Make sure you and your friend have all the same mods installed and that they are configured the same across the saves you want to share. The two main nodes you need to look at are FLIGHTSTATE and ROSTER for information about in flight vessels and Kerbals respectively. In the FLIGHTSTATE node, each sub node represents a vessel (or debris or an asteroid/comet). Carefully select the whole of the node representing the vessel you want to move, then copy it and paste it into the end of the FLIGHTSTATE node on the other save file. If the VESSEL is crewed then make sure to copy the kerbals from the ROSTER section as well, making sure not to create duplicate kerbals with the same name. (Changing the state and assignments of existing kerbals is a slightly more complicated procedure - in the roster node for the kerbal, their state should be either assigned (on a vessel) or available (at the astronaut complex). Where they are on a vessel is controlled by having their name in a crew parameter on a PART subnode of the vessel's node in FLIGHTSTATE) Take a look at how each of these nodes are structured before trying to edit and if anything is unclear I would be happy to provide further clarification

Oh, a whole lot of zeros!! Sorry, never seen that before. If this happens again, take a copy of your log file and zip it up and put it on a file sharing service (e.g. dropbox, google drive, one drive etc.) and link it here. There's not a lot anyone can do to diagnose your issue without it, since it seems rather unusual.

I've only experienced this sort of whole screen white-out effect when Windows freezes briefly for some reason. It usually fixes itself after a few seconds, but can sometimes deteriorate to a full crash. If you still have flight control while this effect is on screen then that's a new one on me.

@linuxgurugamer Just did a bit of testing and I can't get the settings menu to display. After I first encountered the problem, I tested on clean 1.12.5 install with just Waypoint Manager (and dependencies) installed. New sandbox save, enter VAB, add mk1 pod, launch, test WP. Log file here: https://1drv.ms/u/s!AoMBZCPKpMrQxTE0l_tCCJYEyjn7?e=R8QIlV Not sure how useful that log will be as it contains 0 errors or exceptions. Rolled test build back to WPM 2.8.3.5 to confirm menu worked fine in that version under same test.

CC has built in support for creating waypoints based on PQSCities, but the only behaviours associated with them that I'm aware of are through a Kerbal Konstructs extension with a very minimal (and undocumented) feature set. Looking at the code on the CC GitHub the KK extension seems to offer: Requirements: BaseClosed, BaseExists, BaseLocked, BaseOpened, BaseUnlocked Behaviours: CloseBase, LockBase, OpenBase, UnlockBase As far as I can see each requirement just takes a basename parameter and the behaviours take a basename and one or more Condition blocks.

Yes, CONTRACT_TYPE:NEEDS[ContractConfigurator] will mark the contract config node as only being added if Contract Configurator is present. If you are bundling your contracts inside an existing mod then this is all you should need do. If you intend to ship the contract pack separately from the Interstellar mod then I would suggest extending this to NEEDS[modname,ContractConfigurator] so that they are only parsed if both mods are present. The CC wiki is more or less up to date as far as I'm aware. Can you give some examples of the sort of features you are seeing that aren't documented?

That sounds very useful @linuxgurugamer, thanks. Any chance of adding an option to toggle a background shading (like the huds in KER)? It can be very difficult to read the display when flying around cloudy parts of Kerbin (pale text against a white background is hard on my old eyes).

Most contracts use :NEEDS[modname] where they have a mod dependency but AFTER would work if it's absolutely needed. If you're writing your own patch to modify an existing contract for use with a mod then using either NEEDS or AFTER in your MM patch should be fine.