JebIsDeadBaby

How do I enable it? By setting varianceAndResiduals to 1.0?

Question about creating directions by adding rotations to predefined directions, like this: LOCK STEERING TO SHIP:PROGRADE + R(90,0,0). where components of R are (pitch, yaw, roll). This should in effect point the ship to Radial Out. And it works like this while in Kerbin orbit. However, in Mun orbit, R seems to be build like this (yaw, pitch, roll). The same command will point the ship in the Normal direction. This was confusing me for quite some time but since I use rotations rarely, whenever this happened to me I thought I forgot something about coordinate systems again. But today I decided to check it out on two vessels (one orbiting Kerbin and one orbiting Mun in the same game session) and I'm positively 100% sure - the same command gives different results in different SOI's. Why is that?

Well, I have a similar problem. I see time being reduced but all parts are described as new. Time reduction is smaller than it used to be. For a vessel recovered from the launch pad, it used to be down to about 1 day. Now I have a vessel that takes about 4 days to build and this time gets reduced to about 3 days. I can see all used parts in the Inventory but they don't get applied automatically (I have this option checked). When I use Apply button to do it manually I can see a correct result in the part's right click menu (it's used, tested and has reliability of 9 or 10), but the number of used parts of this type in the Inventory stays the same. If I close and reopen the part's menu, the part is again described as new. I get some GraphFlow errors during this process as well. Also in case of some parts, if I open the part's menu, apply a used part manually and then right click another part without closing the previous menu, I get NRE spam and can't right click any other part. KSP 1.11.2.3077, ScrapYard 2.1.0.0.

@Dunbaratu - isn't it the case of this issue?

Dang, you're right on the money. Your trick does work.

I dunno if I'm again having trouble understanding frames of reference but can someone explain to me why do I get results like on this picture: I want to get a direction pointing along body's rotation axis with up direction set to the Solar Prime Vector. I use BODY:ANGULARVEL to get the direction of the axis. As you can see both Kerbin and Mun return some proper vector. However I get very different results when plugging both vectors to LOOKDIRUP, while they should be almost identical. The vessel is in Mun's SOI in this case and I use JSNQ.

Oh, OK. This is indeed explained on the Reference Frames page. It probably would be wise to repeat some of this info here, or at least put a link there.

Hi, why KERBIN:VELOCITY:ORBIT = V(0,0,0)? If thought it should return orbital velocity of Kerbin around it's parent body, which is the Sun.

Hello again. while docking two ships I get CTD with no error messages about one second after successful connection . These are the last entries in the log: [LOG 17:08:55.939] 2/4/2021 5:08:55 PM,kOS-IRWrapper,Attempting to Grab IR Types... [LOG 17:08:55.952] [FAR v0.16.0.1]: Updating vessel voxel for Space Station-2 [LOG 17:08:56.360] [FAR v0.16.0.1]: Voxel Element CrossSection Area: 0.00980822366822485 Std dev for smoothing: 3 voxel total vol: 167.724347110611 filled vol: 32.2048617377845 If I remove FAR the last entry is kOS, I just wanted to show that kOS is not the last mod trying to do something on this newly merged ship. I can't remove kOS for further testing as there are kOS cores on merging ships. So I just want to ask you if in your opinion, whatever kOS is trying to do here, may be a cause for CTD?

Pretty sure it's gone but it's understandable, since after patching RF does not act on the jet pack.

Your patch works like charm. The only tweak I had to do was to add :BEFORE[RealFules] to both patches. The reason for this is that I use Kerbalism, and it's Kerbalism that patches EVA Propellant into Monopropellant. Then Real Fuels comes, sees Monopropellant on the jet pack, and turns it into a service tank , which it can't further handle I guess. So the trick it is to "hijack" the jet pack and fill it with something that is not stock fuels after Kerbalism but before Real Fuels. I get this log input from part compiler: [LOG 22:27:39.212] PartLoader: Compiling Part 'Squad/Parts/Cargo/Jetpack/Jetpack/evaJetpack' [LOG 22:27:39.220] RealFuels.Tanks.TankWindow:HideGUI() RealFuels.Tanks.ModuleFuelTanks:OnDestroy() UnityEngine.Object:DestroyImmediate(Object, Boolean) UnityEngine.Object:DestroyImmediate(Object) PartLoader:StripComponent(GameObject) PartLoader:CreatePartIcon(GameObject, Single&) PartLoader:ParsePart(UrlConfig, ConfigNode) <CompileParts>d__56:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) This RealFuels.Tanks.TankWindow:HideGUI() looks like a reason why jet pack tank can't be accessed via GUI.

That's the thing - it's not me. From the moment I installed 1.11, jet packs were patched to 25l service tanks. I don't recall any patch regarding EVA propellant but I guess it is there somewhere and it does it's job on jet packs. Do you mean remove service tanks for jet packs? Anyway, I'll try your patch today. BTW, since 1.11 I don'y get rescue contracts. Can it be related to this change in EVA?

I don't mean refill, I mean how do you add any fuel at all? My jet packs come empty and there is no option to fill them, as with any other RF tanks. They are patched as service tanks though, I'm kinda not sure where this patch comes from. I don't recall any patch regarding EVA Propellant. How come no one complains about it? Am I the only one with this problem? Do your jet packs come filled with any fuel?

@garwel - you can use this for the time being set steeringmanager:pitchtorquefactor to 0.1. set steeringmanager:yawtorquefactor to 0.1. set steeringmanager:rolltorquefactor to 0.1. RCS will work flawlessly then. Engine gimballing will be a little too aggressive for a change but nothing game breaking.

Guys, how do I add fuel to jet packs? I have hydrazine on board, yet when I go to EVA I have a warning about lack of fuel in the jest pack. I can see that the jet pack has a defined fuel tank in VAB, but it has no right-click menu with a button to edit tank's contents.

Well, we can try. I've found an old webcam, so I have a mic, a bit crappy though. Still have to figure out how to stream. I think I know how start a stream but not how to see what is streaming.

Dunno, can I stream via website or do I have to install it (I'm on web Discord as JebIsDeadBaby#5004 right now)? Also I do not have a microphone attached to the PC, which may be a problem. Never streamed anything via Discord.

I'm u/Angel0a, since yesterday I use the patch you've just released. Can it be this patch introduced this (I don't recall having this problem before the patch frankly, although I finished only one flight in my campaign before I approached you with the bug on Reddit, so I might just missed it )? Anyway, my ship uses a few mods, I may test it on some simpler design tomorrow (it's close to midnight where I am). EDIT: OK, I checked it. Mk1 + FL-R25 tank + CX4181 + 4x RV-105 RCS on the waist, so I guess all stock parts but I use Restock models (shouldn't matter I guess). Important mods: Real Fuels with RealFuels-Stock engine configs. RCS set to Hydrazine. Mandatory RCS. I disable reaction wheels with this mod, but with reaction wheels enabled it's just as bad. With *torquefactors set to default 1 this ship spins like crazy. When I set them to 0.1 it quickly orients itself correctly.

The latest version seems to waaay overestimate available RCS torque. Steering manager keeps RCS firing until the desired angle is achieved, obviously overshoots, which results in an infinite loop of corrections. Reducing torque factors to 0.1 solves the problem for me.

Hi, now with Emergency Suppress feature implemented, would you be willing to reconsider this old request of mine? I think enabling suppression whenever comm signal is lost would work exactly as Automatic-Line-Of-Sight-Guidance.

@Nertea - sorry, might have been a false alarm. I use MandatoryRCS for so long that I forgot how far in the tech tree RCS' are supposed to be. Since you changed parts names (or is it Squad?), MandatoryRCS patches don't work now. So regardless of this exceptions all RCS parts may be where they are supposed to be in 1.10. However, I switched to 1.11 now and kinda too lazy to switch back just to check it. I do however have a problem with that linear RCS. Once you place it you can't select that damned thing. Multi nozzle RCS is OK.

I get this exception on every R+ newly added RCS [EXC 18:14:52.256] MissingFieldException: Field 'GameEvents.onPartRepaired' not found. UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Object:DestroyImmediate(Object) PartLoader:StripComponent(GameObject) PartLoader:CreatePartIcon(GameObject, Single&) PartLoader:ParsePart(UrlConfig, ConfigNode) <CompileParts>d__56:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) None of the RCS' appear in game. Anyone has this problem? KSP 1.10.

@BTAxis - yeah, can confirm, had the same problem too (I switched back to 1.10 since then though). Do you also have log spam in VAB after adding something to the scene (for me it was Mk1 pod)? Mine was so intense that my frame rate was dropping to 15 fps.

Hi, how does FAR deal with CoPOffset and CoLOffset? I've recently removed an ablator from Mk1 pod to make use of a heat shield necessary. And to my surprise a pod with a heat shield is very unstable. In the thin upper atmosphere it has tendency to fly sideways, which with Deadly Reentry ends really bad really fast. I expected it to be even more stable as the heat shield adds mass to the bottom while preserving shape. Now I realized that all stock heat shields have an offset to CoL and CoP, which probably are the cause of the problem. I'd like to correct them as now they obviously lead to unrealistic behavior. Should I just remove them or does FAR need them but with different values? EDIT: well, removing offsets from both the pod and the heat shield seems to improve stability a lot. So I guess they do affect things when FAR is installed. I wonder which behavior is more realistic - with or without the offsets.

@Starwaster - how does DR calculate if parts are in the heat shield's aeroshadow? I dunno if I accidentally changed something but Restock's Mk1 Pod with Restock's 1.25 m heat shield burns instantly unless perfectly aligned with surface retrograde. I had no such problem in my previous game. EDIT: damn, I think maxTemps are screwed again. In game I get skinMaxOperationalTemp at only 1147.50 K on the Mk1 pod. How the hell do you trace which mod changed what? EDIT 2: OK, so I'm testing a minimum configuration: Squad + Squad Expansion + Deadly Reentry. Some time ago I decided to delete the heat shield module that DR adds to Mk1 pod. So I turned this: @PART[mk1pod|mk1podNew|mk1pod_v2]:FOR[DeadlyReentry] { %maxTemp = 850 %skinMaxTemp = 2700 %skinInternalConductionMult = 0.0001 %emissiveConstant = 0.85 MODULE { name = ModuleHeatShield ablativeResource = AblativeShielding lossExp = -7500 lossConst = 1.6 pyrolysisLossFactor = 6000 reentryConductivity = 0.001 ablationTempThresh = 500 depletedMaxTemp = 1200 charMin = 1 charMax = 1 charAlpha = 1 useNode = true nodeName = bottom } RESOURCE { name = AblativeShielding amount = 100 maxAmount = 100 } } into this: @PART[mk1pod|mk1podNew|mk1pod_v2]:FOR[DeadlyReentry] { %maxTemp = 850 %skinMaxTemp = 2700 %skinInternalConductionMult = 0.0001 %emissiveConstant = 0.85 } Simple enough, right? Turns out this is the cause of my problem. With the heat shield module missing in game skinMaxOperationalTemp of the pod is 1147.50 K, if it's there, skinMaxOperationalTemp has a correct value of about 2300 K. What's more interesting %skinMaxTemp = 2700 is properly applied in both cases (checked via MM config cache), so it's like there is some multiplier that is applied differently (AFAIR it should be 85%). EDIT 3: OK, so I figured that mk1pod_v2 lacks leaveTemp = True so I added MODULE { name = ModuleAeroReentry leaveTemp = True } and now temps are OK. So for now I considered the problem solved. I have two questions though: 1. Sometimes leaveTemp = True is added to the root node and sometimes to ModuleAeroReentry. Is the former obsolete? Is there any difference between the two? 2. Why temps don't get halved when ModuleHeatShield is present even though there is no leaveTemp = True?