Aelfhe1m

What's missing is an after patching clean-up to remove the flag before part compilation (the warning in the logs is harmless) Add: @PART:HAS[#SSS_Tier[*]]:LAST[zzzSkyhawkScienceSystem] { !SSS_Tier = delete }

1. Adding fins to the rear of small rockets can improve aerodynamic stability during early parts of flight. This may not be needed if you have engines with a high degree of gimbling instead. Most but not all rocket engines in KSP have quite large amounts of gimbling (this is shown in the right hand side of the part menu in the VAB) 2. In the VAB turn on the Centre of Mass (CoM) and Centre of Lift (CoL) indicators (buttons near bottom left of screen) and check to see that the blue ball (CoL) is lower than the yellow ball (CoM). If you want to be extra thorough check to see if this changes if you empty the fuel tanks. Having the CoL above the CoM will cause the nose of the rocket to be more prone to moving off course if you deviate even slightly from prograde. Conversely, having the CoL far below the CoM may make turning slightly sluggish and the rocket more "determined" to stay pointing in the direction its currently travelling. 3. During early parts of flight, it is generally a good idea not to turn too far away from your prograde vector. A good rule of thumb is to keep your direction indicator inside the prograde vector circle on the navball. Tap controls when turning rather than holding them down and use fine control (caps lock on keyboard) if necessary. 4. Start turning early and smoothly rather than trying to make larger corrections later in flight. This will vary depending on the exact design of your rocket (mostly based on the TWR of your stages), but a general rule of thumb is to fly vertical until you reach about 80-100m/s speed then pitch over 5-10° and then keep pitching over gradually until you reach about 45° at around 25 km altitude and be pointing more or less horizontal by 50km. NOTE: these figures refer to stock Kerbin atmosphere if you have any mods that replace Kerbin or change the atmosphere, then you may need to adjust for those. 5. Don't worry too much about getting to a perfectly equatorial orbit for going to the Mun. An small orbital inclination can be corrected quite easily (and for little cost in fuel) during transfer.

Copy the patch text into a new empty text file and save it into GameData as a .cfg file with any filename you want, I suggest a new folder to hold all your patches and then a meaningful name (e.g. GameData/Z_MyPatches/RealFuels_EvaFuel.cfg)

I'm pretty sure Parallax update 2.0.5 from 17 Dec 2022 resolved this issue (for large scatter) as it included a fix to respect the don't spawn on mapdecals setting. For any sites that are still showing trees/rocks or other large scatter in the wrong areas, it should just be a case of toggling the setting on in the KK editor or adding a (flat) mapdecal to any sites that are missing one and activating the toggle. The smaller scatter (grass, flowers etc.) will still appear within the mapdecal area, but as mentioned in Caerfinon's "Getting started with Kerbal Konstructs" guide, raising each KK group 2-3 metres will eliminate most of this poke through .

Try giving the main wings a small angle of incidence (use the rotate tool to tilt the front edge of the wings up about 5°). You get lift in KSP based on the angle between your wing surface and direction of flight. By pre-tilting the wings you get a little extra lift while holding the main body more horizontal which decreases overall drag (unless your wings are huge). Note: after applying angle of incidence you may need to move the wings back or forward to maintain relative CoM and CoL. Most of the fuel looks like it's in tanks towards the rear of the plane which is why it gets nose heavy later in flight. Which wings are you using? Can they store fuel? That can help keep the CoM more stable as fuel drains. Deploying flaps acts as a brake, which is why you are stalling. Instead you can use advanced tweakables to increase the control authority on the elevons. Also make sure that each of your control surfaces is only responsible for one axis of rotation (usually). Pitch on the rear elevons, yaw on the tail rudder, and roll on the wing elevons. Also, despite looking a bit out of place on a passenger jet like this, canards at the front can also help if the plane needs extra pitch authority.

Excerpt from Pathé News Monday 24th March 1958 “Kit Carson of Puck Aerospace was in an uncharacteristically sombre mood today as he addressed members of the press at their operations centre in Kourou, French Guiana. Today was the first attempted launch of their new larger rocket that had been shown to select members of the press over the weekend. Unfortunately, as Mr Carson reported, a number of technical problems with the engines resulted in the rocket not quite having enough performance to place its one-ton satellite into Earth orbit. “While everything looked nominal immediately following launch with all six of the powerful new rocket engines on the first stage of the massive 130 ton rocket lighting successfully and carrying the vehicle skyward, problems were first noticed a mere two minutes later, when telemetry from one of the side booster engines began indicating a reduction in performance. While concerning, Mr Carson stated that engineers had been confident that the rocket still had enough thrust to still reach some sort of orbit. “However, the rocket’s fate was sealed a mere three and a half minutes later when one of the second stage engines began reporting lower than expected thrust. The combination of failures resulted in the rocket failing to reach orbital velocity and the satellite was only able to transmit a tiny fraction of the planned scientific observations before falling back into the atmosphere and burning up less than 24 minutes after launch. “Despite the setback, Mr Carson remained cautiously optimistic, emphasising that such issues were only to be expected when dealing with such complex and experimental systems (a common refrain from previous Puck Aerospace launch failures). He pointed out that their engineers were already pouring over the data that had been returned by the flight monitoring systems and that this new information would be put to use in modifying the engines where necessary before the next launch attempt. “With a certain degree of wry humour, Mr Carson invoked the legendary tale of Robert the Bruce and the spider. ‘You only truly fail,’ he said ‘when you stop trying. Just as the spider fell many times while trying to spin its web but never gave up. We too will try, try, try again and eventually we will succeed. I have confidence in the abilities of our engineers and scientists to resolve these problems and deliver the full potential of our Xanthos rocket. I believe that this rocket holds a lot of promise for the future and we must not let our initial teething issues from taking a deep bite of the fruit of success.’” Excerpt from Pathé News Friday 22nd August 1958 “It has been a troubling couple of months at Puck Aerospace’s headquarters in Kourou, French Guiana. Reports of budgetary problems that led to the laying off of a large number of their researchers and technicians in favour of hiring additional engineers have been downplayed by company spokesperson Mrs McKenzie-Poitier. She stated that claims of the company facing bankruptcy were highly exaggerated and instead emphasized that this was expected to only be a temporary hiatus in their research and development endeavours and that most of the dismissed staff are likely to be rehired within a year or two as the company's finances improve. “Mrs McKenzie-Poitier was speaking to the press alongside Chief Administrator Mr Vincent Glasgow and Flight Operations Manager Mt Kit Carson, in a conference following the launch today of their second Xanthos rocket. While emphasising that the rocket had successfully delivered its satellite payload into orbit of the Earth, Mr Carson admitted that an early performance loss on one of the boosters had prevented it from reaching its full target altitude. He was careful to stress that only the one engine had shown any problems this time and that while the satellite was in a lower orbit than had been desired, it would still be able to return a significant portion of the expected scientific data planned for the mission. “He further pointed out that the fact that the satellite had reached a stable orbit despite the early partial loss of one engine, only went to demonstrate the potential capability of the Xanthos rocket once it is performing to its full capability.” Excerpt from Pathé News report Thursday 1st January 1959 “Addressing staff and guests at the Puck Aerospace Hogmanay party in Kourou, French Guiana yesterday, owner Peadar Kincaid joked about how it was only fitting that they end the horrors of their past year with a bang, as he pressed the button to start the evening’s fireworks display. He spoke candidly of mistakes made by himself and other senior management in their attempts to rush the Xanthos rockets into production and admitted that several corners had been cut in the testing of the rockets and their new engines that were rather glaring blunders in hindsight. “While admitting to their problems and the lack of any fully successful launches during the prior year, he was keen to stress that it hadn’t all been bad news and that they had learned a lot even from the worst of the failures. Mr Kincaid spoke of the next Xanthos rocket, even now being prepped for launch and of a fourth rocket just beginning construction. He highlighted his continuing belief in the capabilities and proficiency of their staff and contractors and his firm belief that they would overcome their current woes and forge forward together into a brighter future.” ==== Gameplay notes and screenshots:

It's a "grabbing claw" using the same mechanism as the stock "Advanced Grabbing Unit".

Try this instead: The @NODE[value] selector is shorthand for @NODE:HAS[#name[value]]. If the identity field is called anything except "name" then the longer version is needed. NOTE: I only fixed the syntax in the patch and have not tested it.

It's the big NODE button on the first row (KILL ROT is the equivalent of basic stability assist). The buttons on the OBT mode panel are pretty direct substitutes for the stock SAS modes (when orbit is selected on Navball). SURF gives similar functions for surface mode, but with more options for specifying offsets to the vector. And for horizontal or vertical alignment. TGT is for target mode. TGT+ and TGT- are the point at/away from target. RVEL+/RVEL- are stock target relative prograde/retrograde and PAR+/PAR- align your crafts axis parallel to your target's (very useful for docking) ADV is for various alignments relative to celestial bodies (useful for pointing solar panels at the sun for example or having a space station's cupola module always point down towards the body it is orbiting for cinematics/roleplay)

11-14 Nov '54 was when I finished the Suborbital Rocket Research Programme and started the Early Satellites (Heavy) Programme (it's at the end of this post). In RP-1, you need to spend confidence points in order to start any programme at anything other than Normal speed (i.e. Fast or Breakneck). The tighter the deadlines you choose, the more funding per year you get for the Programme.

Yes, I've made several abortive attempts at writing up 1958 and early 1959, but I'm struggling with it. There weren't many launches (a lot of waiting around for stuff to build/upgrade/accumulate funds) and the launches were mostly disastrous due to Test Flight not being kind during this period, and I made several stupid mistakes on top of that. Trying to wrangle that into a coherent story is proving difficult, but I should have the next update soon™. Peek at log:

Never tried this myself, but off the top of my head, the positioning of the perigee point (and hence timing of launch) will be dependent on the burn time of the initial boost phase. If you are recreating the Artemis SLS launcher then it might be worth looking at the real world launch date/time and trying to match that lunar phase angle as closely as possible since NASA will have done all the hard maths already. You might also be able to track down documentation of alternate launch windows they had planned. For a more practical approach you could start with a test satellite in the plane of the Moon in a circular orbit at the planned periapsis height then plot a manoeuvre to raise the apoapsis to 1800 followed by a TLI at perigee and then adjust them until you get a suitable Moon encounter. That should then let you plan your actual launch time to hit 1800 km apogee at the correct time for the perigee TLI.

Are you planning to do a direct launch or launch to orbit in correct plane followed by TLI burn? Stock physics or Principia? I much prefer to go to orbit first and usually delay my first Moon missions until I have the necessary tech. Then the correct time to launch is when the ascending/descending node of the Moon's orbit is close to the Cape (shown in MechJeb (if you have manoeuvre nodes unlocked) by the relative target inclination being at a minimum (~ 0.7° from memory). What time of day this occurs at will depend on the time of year, but since there are two launch windows spaced 12 hours apart (one at the AN and one at DN), most of the year there will be one of them during daylight hours. For direct ascent, you also need to factor in the journey time to the Moon based on the ΔV of your rocket. For advance planning you can also use the mod : https://github.com/KSP-RO/LunarTransferPlanner (it is a recommended mod when installing RP-1 express)

@Steigleder It's not that these mods are incompatible with RO, but rather that the compatibility patching is provided BY RO rather than being in the mods themselves. The RO suggested mods patch folder includes patches for many (most?) Raidernick parts including LN & LOK as well as N1 adapters, engines and tanks. While I'm not using them in my current RP-1 build, I have used them in past RO/RSS sandbox builds without issue and I would expect they still work (if correctly installed.) As cheesecake intimated, the large size of your log file suggests that something is throwing frequent error spam, which is often indicative of a mis-installed or incompatible mod. Double checking that all your mods have been correctly installed and that none of them are out of date or known to be incompatible with each other would be a good idea.

@Superawesome4141 MechJeb isn't doing this, Advanced SAS for all is choosing to disable itself if MechJeb is installed. Instead, I recommend using MechJeb's built in Smart ASS instead (from the MechJeb menu in flight) that becomes available on all command pods/control probes after you unlock flight control (45 science). It uses a separate UI and replacement SAS controller and once you get used to it, you'll find that Smart ASS is much more flexible than the stock SAS modes. If you would like Smart ASS to be unlocked from the start node, then that can be done using a ModuleManager patch:

This list suggests to me that you probably have installation issues in some/many of your mods. If you post your KSP.log file on a file sharing service (e.g. Dropbox, Google Drive, OneDrive etc.) and then link it here, then we might be able to diagnose issues for you. 1. I've never used BDA, but installation problems should be obvious from the log. 2. White square's replacing icons is a common symptom of an incorrectly installed mod. KSP relies on full file paths to find the textures it uses to display buttons/icons etc. in game. The part of the path before GameData is unimportant, but the part after GameData must be EXACTLY correct or many mods will break. 3. Sounds like an installation problem 4. Sido's Urania is an extremely old mod. I doubt it has been updated to work with modern versions of Kopernicus. 5.Installation again? The logs would tell us more 6. Ditto.

Think about the size of the radio dishes at the KSC, the HG-5 (and all the other antennae parts) are absolutely tiny in comparison. The KSC dishes are a lot more sensitive than anything that can be carried on a satellite, so they have much more range.

A couple of small typo in the patch I posted (KerbalEVA is case sensitive as a Module name and I should have included a ,* on the delete statement. Revised (and tested) patch: // patch to remove eva chutes from the list of default kerbal inventories // Author: canisin, slightly modified by Aelfhe1m @PART:HAS[@MODULE[KerbalEVA]]:FINAL { @MODULE[ModuleInventoryPart] { @DEFAULTPARTS { !name,* = deleteall name = evaJetpack } } } NOTE: if you have the persistent inventories option enabled in game settings then this will only apply to the initial inventory load out when a new kerbal is hired. Adding or removing items from each kerbal's inventory will be remembered in your save.

Didn't keep a link to the original post but: Edit: found original:

The original KerbinSide was All Rights Reserved but this mod KerbinSide Remastered is CC BY-NC-SA 4.0 (changed in v. 1.0) Edit: As soon as I posted, it struck me that the stated license might not represent the whole picture so I dug a little deeper and while the mod is CC BY-NA-SA, the "Disributed Static Assets, Artwork & Models" are All Rights Reserved. So anyone wanting to "fix" a given static would need to remodel and implement it from scratch as a new KK Static, then replace the instances in the configs with their replacement static unless they could get permission from the original author to modify their originals.

That's a KAS problem, not Pathfinder. The following (old) post and the one after it talk about some work arounds for when this happens - to my knowledge no complete fix was ever made (at least there's nothing in the releases changelog that looks like it addresses this issue):

Depends how cheaty your willing to play it. Easy but very cheaty way is to convert the specialist to a non-tourist type by editing your persistent save file (TAKE A BACKUP) then EVA them across to the "base". It shouldn't affect the contract's ability to remove the kerbal once all the requirements have been met. Not too hard but a bit cheesy - I see a Pathfinder icon, so you probably have KAS/KIS installed. You could send up a supply probe with some KAS parts in inventory (remember a wrench or screwdriver) and use your crew kerbal to link the lander to the base using a RTS-1/JS-1 connections - unfortunately the max pipe length is 30m, so you'll also need a couple of pylons and extra RTS-1's to bridge the 70m gap to the base. But once they're connected up and the links are changed to dock, the base and the ship become one vessel and that should satisfy the requirement for your specialist to be on the base. [minimum parts in inventory 2xground pylons, 3 x RTS-1, 1 x JS-1, screwdriver/wrench] If you don't have KAS or think transferring crew through tiny little pipes is too cheaty (some mods do supply larger pipes) then the stock method would be to send a crewed rover (with cabin not external command seats) with a three docking ports (1 for docking and two spares to attach to the lander and base [if it doesn't already have one]). Use stock construction to take one port off the rover and attach it to your lander. Dock rover to lander and transfer specialist to rover. Drive over to base. Attach other docking port and dock rover. Wait for specialist's mission timer to complete. Undock rover. Drive back to ship and dock again. [Warning: docking rovers to grounded vessels/bases can be very fiddly]

Perhaps you reconfigured the omni-storage to hold some other resource and didn't split the storage to include space for inventory? If so you can adjust the mix of storage through Omni -> Reconfigure Storage.

That's weird. That text (SuborbitalRocketplanes) does not appear anywhere in my ModuleManager.ConfigCache, nor was I able to find it searching RP-1's current GitHub source code. My version of the first hypersonic contract (hold 2000m/s for 2min below 40000m) and the follow up optional contracts ask for program: EarlyXPlanes . Perhaps a copy of your ModuleManager.ConfigCache and logs/modulemanager/modulemanager.log might help find what's causing the problem for you?

The video link: video