Kerbas_ad_astra

Members
  • Content count

    1384
  • Joined

  • Last visited

Community Reputation

695 Excellent

2 Followers

About Kerbas_ad_astra

  • Rank
    bulkheadProfiler
  1. In the meantime, I've got an interim fix to suppress the issue from affecting my contracts. CNR v2.0.1: "Hiccup Suppression" Adjusted facility requirements to suppress random failures when entering the Tracking Station.
  2. Yeah, that's the same issue -- the contract failure is preceded by a notification: "ContractConfigurator.FacilityRequirement: Contract CommNetRelayInnerPlanet: requirement Facility was not met." I've got a quick fix on my end (basically telling CC to ignore that requirement after the contract has been accepted); I'll see about getting a release out shortly.
  3. Is it necessary to rename the nodes? Would it also work with e.g.: @PART[liquidEngine2-2]:AFTER[VenStockRevamp] { !MODULE[ModuleJettison],1 {} MODULE { name = ModuleB9PartSwitch moduleID = meshSwitch switcherDescription = Structure SUBTYPE { name = Size1 node = top } SUBTYPE { name = Size2 transform = Size2B node = top2 } } }
  4. BDB specifically excludes its parts from SMURFF's rebalancing, and has its own set of balance patches for larger solar systems. You'll have to discuss the balance of that patch with them.
  5. Stock is not broken (so far as I can tell briefly -- there's nothing to change to but 'Launchpad', but the dialog works) and it works with KK once again! Thanks!
  6. Thanks! Looking at that list, none of them look like they directly interfere with the functioning of Landertrons, but RealChutes jumped out at me as having some impact on landing. Adding that to my test install (I don't use it normally) caused the issue to occur. When I used my debug build, the predicted stopping distance is calculated to be some 500 meters when the parachute begins to fully deploy (at an altitude of 700 meters). During that series of tests, the stopping distance stayed below the distance to the ground (so the landertrons never fired prematurely) as the parachute opened, but only just, and the debug build is logging data at every frame, which slows the game; I suspect that when the game is running at full speed and high physical warp, the predicted stopping distance can dip into the ground and trigger the landing engines' ignition. 700 meters is pretty low, especially as terminal velocity is over 100 m/s; since the HGR RealChutes patch is living in 'my' mod, I can increase that to 1000 as it is for stock chutes in the next release. Additionally, I'm working on making Landertrons a little more intelligent and less conservative when landing on planets with atmospheres (the calculations presently assume that the spacecraft is descending under gravity without any drag), but all of my efforts so far have been underestimating the stopping distance for payloads landing without parachutes. In the meantime, you could be less of a daredevil when landing SoyJuice capsules.
  7. I'm not seeing that behavior in my test setup (HGR, Landertron, SafeChutes -- not using HyperEdit but boosting the pod up to 9800 m on an SRB, velocity ~210 m/s at ~2500 m altitude when I staged, ~170 m/s at opening) or in my heavily modded main setup, but I can believe that dropping out of high physical warp at high speed (or maybe it's more related to being in high warp, at high speed, at low altitudes) can trip Landertrons under the right circumstances (which seems to require more mod interactions?). The SoftLanding calculation is based in part on what the predicted altitude of the capsule will be in two frames, so being in high physical warp will push that prediction lower. It would help me to see even a screenshot of your GameData folder or a list of folders -- I use a lot of mods myself, so I can tell you what you've got that I don't, and help narrow down your search.
  8. I'm still not getting that behavior -- I made a new career save (plus some science and funds to get the necessary parts), launched a Soyjuice descent pod (the green one) by the Mun on a free-return trajectory, executed a skip-reentry with an initial periapsis of 40 km, separated the heat shield, deployed parachutes, armed the landertron at about 800 m (when the parachute had fully opened, terminal velocity ~3 m/s -- using the HGR LOM-7), and the engines fired at ~20 meters. There's nothing in Landertron code that depends on game mode, so this is very strange to me. Could you get me that save file and your list of mods?
  9. Are you sure you have both the latest versions of landertrons (v1.1.0, from here for KSP 1.3) and HGR (v1.5.2 for KSP 1.3, from here -- bear in mind that I've integrated all parts and patches into an HGR folder, so you shouldn't have HGR_Redux or HGRCommunityFixes folders)? I just made a quick test launch (up to 2000 m, deploy parachutes, arm landertron), and the motors fired at ~20 meters altitude (still not quite where I want it to be, but pretty low).
  10. Hey magico, using KCT beta 30 (1.3.9.0), I'm not able to access Kerbal Konstructs bases the way that I used to. When I click the "Select LaunchSite" button, I get the following in my log: [KCT] Site manager is good. (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) NullReferenceException at (wrapper managed-to-native) UnityEngine.Object:get_name () at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[],System.Exception&) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation. at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 at System.Reflection.MonoProperty.GetValue (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] index, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 at System.Reflection.MonoProperty.GetValue (System.Object obj, System.Object[] index) [0x00000] in <filename unknown>:0 at KerbalConstructionTime.KCT_Utilities.GetMemberInfoValue (System.Reflection.MemberInfo member, System.Object sourceObject) [0x00000] in <filename unknown>:0 at KerbalConstructionTime.KCT_Utilities.GetAllOpenKKLaunchSites (System.String type) [0x00000] in <filename unknown>:0 at KerbalConstructionTime.KCT_GUI.DrawBLPlusWindow (Int32 windowID) [0x00000] in <filename unknown>:0 at UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) [0x00000] in <filename unknown>:0 at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0 I thought the issue was just that Kerbal Constructs changed the launch site manager from KerbalKonstructs.LaunchSites.LaunchSiteManager to KerbalKonstructs.Core.LaunchSiteManager, but changing that in KCT_Utilities and recompiling didn't fix the issue. (KK's launch site manager API is now here: https://github.com/GER-Space/Kerbal-Konstructs/blob/master/src/Core/LaunchSites/LaunchSiteManager.cs)
  11. SMURFF doesn't change how much fuel a part has, it changes how much parts weigh. (In particular, it makes fuel tanks lighter.) You'll still have to make bigger rockets than you may be used to from playing stock, but without SMURFF, you'd have to make them even bigger.
  12. It was in the tracking station. First time in the game that I went there, as it happened, and after I noticed the contract failures some time later (and cheated myself some reputation and funds accordingly) and re-accepted the contracts at Mission Control, I was in and out of the tracking station several times without any problems.
  13. I was (am) on 1.23.1.
  14. I just caught the contracts failing on my own save (during the course of updating to 1.3). It shouldn't be possible for the contracts to fail (as I've added no failure condition), but the log said: ContractConfigurator.FacilityRequirement: Contract CommNetRelayInnerPlanet: requirement Facility was not met. I was working with the cheat menu at the time (using the orbit setter to 'poof' up some replacements for stations that would be deleted when I removed some part mods...), so I could believe that there was a stock bug or hiccup in the facility tracking system which in turn tripped the contract (if the facility level was spuriously set to 0, then the contract's requirement would no longer be satisfied, and the contract would fail). The next release will set 'checkOnActiveContract = false' for all of those requirements, so hiccups like this don't happen again. (You'll still have to have the minimum facility level to get those contracts, but afterwards it will assume you're good.)
  15. HGR Community Fixes v1.5.2 "20% Draggier" is out! Integrated HGR_Redux and HGRCommunityFixes parts and patches into the HGR folder (so delete your HGR, HGR_Redux, and HGRCommunityFixes folders when updating to this version). Many thanks to Orionkermin for relaxing the license of the parts, and to linuxgurugamer for integrating the patches! Increased the drag of the Spud pod to give it a subsonic terminal velocity. This release doesn't add support for localization (or the update to the Garlic texture that I promised...) as the integration of Orionkermin's parts and my patches was a pretty serious revision in itself. Something for you all to look forward to!