OHara

Members
  • Content Count

    583
  • Joined

  • Last visited

Community Reputation

488 Excellent

2 Followers

About OHara

  • Rank
    Junior Rocket Scientist

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. There is a stock way to deflate the heat shield now, if we configure the capability explicitly in the VAB before launch. It uses the Axis Groups that appeared with KSP version 1.7. Probably we don't want to re-use an axis like 'Throttle' or 'Pitch' to also control the heat shield. So at Main Menu => Settings => Input => Vessel, we have to assign some keys (like PageUp/PageDown) to 'Custom01' Then in the VAB, open the Action Group panels, and select 'Custom01' under 'Axis Groups' in the list at the lower left. Now we can choose heat shield and link its 'Deploy Limit' to the Custom01 axis.
  2. The first thing to check is that you know about the throttle. (wiki link) You need to raise (open) the throttle for liquid engines to run. On PC the left-Shift and (left)-Alt keys raise and lower the throttle. The letter keys at the lower left, 'Z' and 'X' on English-style keyboards, set it quickly to 100% and 0%
  3. Your craft flies exactly the same for me (successfully) in my copies of KSP 1.7.3 and 1.8.1.2694. It looks like something went wrong with your KSP 1.8.1. My first guess is the contents of Physics.cfg are wrong. You can rename that file to Physics.txt, so that KSP re-generates the correct Physics.cfg on the next startup.
  4. This is a new bug with KSP version 1.8. It is reported on the bug-tracker (link) but so-far no-one has reported any way to work around the bug.
  5. The V-tail starts to try to lift up for me as well, as soon as I rotate the nose to take-off with your craft. That looks correct and normal to me, because the nose is high enough at take-off speeds that the air is coming from 5° below the craft. Only part of the tail-fin moves as a control surface, and the rest is lifting the tail up more than the moving part tries to push it down. That doesn't cause me any trouble in takeoff or climb. I climb well with the pitch control at the letter 'P' in the P-I-T-C-H labels. The big cargo bay is the root part of your craft, which causes an annoying bug on re-load and on revert-to-launch (link) that makes KSP count drag on the contents as if the bays were open. You can use the re-root tool (number 4) in the VAB/SPH to make some non-cargo part the root. Maybe you tested with more parts in the cargo bay and their drag was causing a pitch-down ? The only other thing I notice is that the main-wing flaps/ailerons are active for pitch, and they try hard to help with pitch, but mostly give drag because they are so close to the center of the ship they don't have a good lever arm for pitch.
  6. There are a couple bug reports https://bugs.kerbalspaceprogram.com/issues/13520 https://bugs.kerbalspaceprogram.com/issues/14181 and the first one explains why, even if it was the intention of the programmers, it is confusing behavior.
  7. It has been possible, but difficult, to dock multiple ports simultaneously since around version 1.3. The biggest problem, shown in @championofcyrodiil 's image three posts above, is that the first port to dock locks everything into place, preventing rotation to swing the other ports into alignment. Some people can orient the ports so well before first contact that both dock. KSP has internal options to require the ports to be aligned in the in-face rotation (clocking) before the ports join. We can use a ModuleManager patch in the link below to enable those options. Then no ports lock until the orientation is correct, within your chosen tolerance, so you might need to experiment to check if that is close enough that the second port to always join. A mod that should work even better for this (but I can't remember for sure if I've used it for multi-port docking) lets the docked joint rotate after docking, as if under motor power :
  8. @SuicidalInsanity, I don't know the history of this part, but experimentally I find that aero shielding works correctly, avoiding the problem with connected Mk3 cargo bays, if I patch your Mk3 service bay like this: @PART[M3X_serviceBay] { !MODULE[ModuleCargoBay],1 {} // remove the duplicate MODULE @MODULE[ModuleCargoBay] { @closedPosition = 1 @lookupRadius = 2 !lookupCenter = delete // the default 0,0,0 is already in center of part }} Edit: even with the patch above, opening/closing the M3X service bay does not trigger KSP to update the shielded status of parts in connected cargo bays. Maybe ModuleAnimateGeneric is the only door-opening module that works completely for cargo-bay doors.
  9. and I downloaded it and see the same problem as you do. There is an option in the alt-F12 menu under Physics: Aero: 'display aero data in menus' that lets us check if parts have zero drag, while still rolling on the runway. If I move the Mk3 drone core forward to go between the Mk3 service module (from the mod) and the stock long Mk3 cargo bay, then the contents of the long cargo bay are properly shielded and show zero drag. KSP seems to think that the Mk3 service module from the MK3 Expansion mod is open. When cargo bays are in a connected chain it requires that all of them are closed before it removes drag from the contents of any of the bays. (I don't know why they made this rule, but can guess the programmer had some good intentions, but in hindsight it seems overly complicated.) The Mk3 service module from the mod never shields its contents, so it looks like KSP thinks it is always open. I notice that the configuration file for that part has two entries of ModuleCargoBay, which seems strange. (I'm not familiar with that mod myself, so won't point it out to the mod author unless and until I look into it a bit more.)
  10. The aspect of the ScanSat mod that I would most like to see in KSP2 is the saving of scan data in maps that can be used for later missions. The way ScanSat gradually fills in the map, as different scanners pass over the surface, each scanner-type adding a different layer of information, addresses the OP suggestion nicely. ScanSat predates KSP vesion 1.2 that added the communications network and Kerbnet, so we can instantly use scans from one craft when flying others. In a future version, KSP could transfer mapping data over the communication network. (Kerbnet does similar, but there the information flow seems backwards; we need a connection to KSC in order to see the terrain below us, as if KerbNet were a SatNav and all the maps already stored at KSC.)
  11. Maybe your cargo bay is the root part? That causes the problem you describe (the bug report here https://bugs.kerbalspaceprogram.com/issues/13366) -- but not on initial spawn where you see the problem. If you have the craft posted on kerbalx or somewhere, one of us on the forum might be able to figure out what we're missing.
  12. The bubble left of the portraits toggles transparency for windows in crewed parts. Try it, but it might not help with your problem with the EAS-1. (For me, the button left of the portraits has no effect with the EAS-1, but I have no see-through problem in my install.) Other people have seen seated Kerbals when they should be inside the craft. Maybe you all can compare notes with each other and find the troublesome mod.
  13. You need to use fuel lines between the fuel tank and the wall of the Service Module. (Il faut utiliser des conduites de carburant entre le réservoir et le côté du 'module de service'.) Usually fuel flows through connected parts, but some there are exceptions in the Making History mod. It might be a bug; it was reported to Squad at https://bugs.kerbalspaceprogram.com/issues/21141
  14. Extremely high energy density. When hydrogen transitions from metallic to H2 it releases much more energy than any combustion reaction. So if we imagine Kerbals can contain the metallic form, and make nozzles to control the very hot H2 produced, it would serve as monopropellant with an Isp around 10 km/s or 1000s. (See http://www.projectrho.com/public_html/rocket/ for details, both proven and speculative, nicely clarified.) The corresponding engine has what I guess is a magnetic nozzle to handle the heat, and I suspect this engine might serve as a step in the in-game lore of Kerbals' development of magnetic nozzles for nuclear engines.
  15. No, Windows. I'll recheck if the behavior did actually change. -- it did : Version 1.8.1 gives us the single click re-rooting that I asked for above, but only in some situations, and part-highlighting is not giving us the right clues. Selecting the re-root tool gives me the message "Select a set of two or more parts to Re-root" with green mouse-over-highlighting as if in placement mode. If the next part I click is already root, or not valid to be the new root, KSP-1.8 says "Select a part as the new root" and switches to blue highlight when I pass over valid new root-parts, so that I can pick the new root part in the old manner with a second click. Otherwise I clicked a valid new root other than the old root, and KSP-1.8 re-roots with that single click and picks- p the whole craft with the mouse. I would suggest: upon selecting the re-root tool, say, says "Select a part as the new root of the craft, or new root of a detached set of parts", highlight valid new root-parts in blue on mouse-over, whether on the main craft of a detached subassembly, including the old root-part as a valid new root, and let one click re-root. No need to pick up the whole craft, simply switching highlighting back to green would confirm that re-rooting is finished. Also, sometime since 1.7.3, the rules have changed for what is a valid root for sub-assemblies. The old rules allowed a booster to be rooted to its decoupler, but the new rules seem to disallow surface-attach parts from being the new root. This means a subassembly of a boosters on a decoupler can no longer be rooted to the de-couplers. (The 1.8.0 changelog says "* Fix re-rooting of surface attach nodes.")