Reddy

Yeah, I've considered doing that for all the antennas, as the Communotron 32 is not the only one I'm experiencing issues with. But before resorting to that solution, I wanted to find out if there's anything I can be doing clearly wrong. PS: I've just flown the exact same vehicle to orbit and back (burning prograde for a maximally hot entry) and it performed well. I know that if I quicksaved during reentry and then reloaded, the antenna would always be ripped - probably because RT makes its "isShielded" check before FAR comes into play, but I'm not sure. Sure I am though that this was never the case with my previous catastrophies. I feel lost... probably gonna make them all indestructible in the cfgs :|

Are you using FAR? I've encountered weird behavior with TweakScale arguing with FAR over wing mass, since the latter has a strength/weight slider which interferes with TS in an unpredictable way.

This is my reusable second stage rocket. http://i.imgur.com/WUcCM38.png You can only see the Kerbodyne S3-3600 tank and the Poodle engine - the intestines are nicely covered with some Procedural Fairings. Works pretty well with FAR, Deadly Reentry and a couple others flawlessly, but I can't get the Communotron to survive with DR + Remote Tech. As you can see in the pic, FAR tells me it's shielded (it should stay that way all the time, as I'm not jettisoning these fairings at any point). On the following screen I've clipped the camera inside the vehicle, so you could see the perpendicularly installed antenna. http://i.imgur.com/OutZsUR.png It may be worth noting that I can launch this vehicle with the antenna deployed (in fact, I'm not intending to toggle it at all), no problem. But reentry is, well, deadly. I remember to have survived one or two, but a couple of last times I got the "Communotron 32 was ripped by strong airflow" message, AFAIK coming from RT. Any ideas on what's the case here? Is it RT acting up, or FAR losing track of the fairings and "isShielded" status? How should I investigate this?

Only the value you will get will be completely unrelated to your actual velocity - unless you're going perfectly straight along one of the XYZ axes, which will never really occur in reality. You can obtain the velocity with SHIP:VELOCITY:SURFACE:MAG, which calculates the magnitude of your velocity vector (this is, square root of X^2+Y^2+Z^2).

Awesome!! Steven, are you or erendrake going to take a look into #389 anytime soon? For now my rockets are flying quite well with hidden torque wheels so I'm not trying to urge anyone, just thought it'd be nice to know if this is a fix that one could expect to see within a couple days, or rather something that requires a major rework.

EDIT: You were right, I had the two confused. The posts are corrected now, should be legible for everyone. I don't know how does the LOCK STEERING work, under the hood. I have no experience in Unity, no knowledge of KSP code, and an aversion to C# - looked into the source anyways and only found that comment line in Utilities/SteeringHelper.cs: // I take no credit for this, this is a stripped down, rearranged version of MechJeb's attitude control system Although, there is a good chance I wasn't even looking into the right file.

Turns out you're wrong Running the exact same script on the same rocket, but with 5 additional large reaction wheel modules between the tanks gives optimal performance. So I'm still going to say that LOCK STEERING is broken on anything that has no RW torque.

In relation to my previous post and a related issue 389. I have found the same strange response to steering attempt in a craft that could only use control surfaces and engine gimbal to maneuver - rapid wiggling of the control elements, also visible on the GUI indicator (see the video I attached to the post mentioned). Thus, the rocket fails to align with the given yaw angle. Reproduction steps on the 32-bit KSP v0.25.0.642 & kOS v0.15.1: build a 3.75m rocket with the KR-2L and two large tanks, some winglets at the bottom, but no reaction wheel modules (or get the said rocket from here). Launch it and run the following script (or download it): SET c_pitch TO 0. SET c_throttle TO 1. RCS OFF. SAS OFF. LOCK c_steering TO UP+R(0,0,180)+R(0,-c_pitch,0). LOCK STEERING TO c_steering. LOCK THROTTLE TO c_throttle. STAGE. UNTIL SHIP:ALTITUDE >= 2000 { WAIT 0.1. }. LOCK THROTTLE TO 0.8. UNTIL SHIP:APOAPSIS > 100000 { // should smoothly pitch the craft from 0 degrees on 2km altitude to 90 degrees on 36.5km SET c_pitch TO 0.002727*SHIP:ALTITUDE-8.18182. IF c_pitch < 0 SET c_pitch TO 0. IF c_pitch >90 SET c_pitch TO 90. CLEARSCREEN. PRINT "Rocket now pitched " + ROUND((UP+R(0,0,180)):YAW-SHIP:FACING:YAW,1). PRINT "Should instead be " + ROUND(c_pitch,1). WAIT 0.5. }. //The code uses the word "pitch" for the variable, though we'll actually observe yaw being changed. A similar effect to the one displayed on my should be observed. The script will also continuously notify on the difference between the given pitch and the observed.@Steven: I feel this is strongly related, and if I'm right it would prove that not only the RCS auto steering is broken, but all other means except for the reaction wheels as well.

Thank you. I'm willing to help in testing or whatever I could be of use in, as my space program relies on this feature Can't spare any kilogram on my reusable SSTO lifters, and with FAR and DR installed I'd have a hard time squeezing the SAS modules in the rocket while still maintaining its aerodynamic properties.

I've been getting a strange behavior upon trying to rotate my craft using a LOCK STEERING TO statement. The rocket can only use RCS to change its attitude, and what I get instead is a lot of wiggling its engine's gimbal, thrusters firing everywhere and a very, very slow rotation. Best explained with the video: (In case the HD version isn't available just yet: in 0:08 I'm calling a LOCK STEERING TO UP, then unlocking in 0:40, then locking to PROGRADE in 0:44.) Any ideas what's going on? EDIT: I have found the issue to be reprocudable on a clean 32-bit KSP 0.25.0.642 with only kOS v0.15.1 installed. You can grab the persistence file under this link, or the rocket itself here; to check it out, just open the terminal and try: LOCK STEERING TO PROGRADE. You could as well do RETROGRADE or UP or whatever instead. EDIT2: Just for the record, the issue was there in the previous version of the mod (0.14.2 IIRC).

How does FAR calculate drag for heat shields? I'm trying to balance my craft for atmosphere reentry. Everything nicely hidden within fairings, almost no parts sticking out. I'm checking it in the VAB under different orientations (tilting the craft a couple degrees both ways) and everything looks okay, CoL placed well behind the CoM in all situations. Then I add the heat shield on top of it and this happens: ALBUM During reentry, my craft quickly found itself turning upside down and broke in half due to aerodynamic stressess. What do I misunderstand about FAR and what am I doing wrong?

Yes I know TweakScale is not promised to work perfectly with Ferram Aerospace Research, but I'll report the annoyance I've found nevertheless. TLDR: weird things happen to rescaled wings when using them in subassemblies. To reproduce, run a clean 0.25 32-bit install with newest FAR (at this time v0.14.3.2) and TweakScale (v1.44), preferrably with some other mod able to display masses for individual parts (I'm using Kerbal Engineer v1.0.10). Go to VAB and pick an OKTO probe core as a root part for the new vehicle. Then place a RC-L01 core on top of it. Attach a AV-T1 Winglet to the size of the large core - note the displayed mass of the winglet: 88kg. Downscale it to 70% - KE overlay now should display a mass of 17kg. Now grab the large probe core with the winglet and create a subassembly out of them. [Warning]: [Part]: PartModule FARBasicDragModel at probeStackLarge, index 5: index exceeds module count as defined in cfg. Looking for FARBasicDragModel in other indices... [Error]: ...no FARBasicDragModel module found on part definition. Skipping... [Log]: Unnamed loaded! [Log]: deleting part winglet [Log]: deleting part probeStackLarge [Log]: deleting part winglet(Clone) [Log]: deleting part probeStackLarge(Clone) Now bring this subassembly back and attach it again on top of the OKTO. Check the mass of the winglet: it should say 88kg instead of the previously calculated 17, which we'd normally expect to get. The same warning/error messages appear upon loading of the subassembly. Should I report it to FAR thread instead, or is it a TweakScale issue? EDIT: Forgot to mention that this anomaly occurs with other wing-type objects, too (tested with Swept Wing, AV-R8 Winglet, Tail Fin, Delta-Deluxe Winglet and Wing Connector Type . Masses for all other parts are recalculated properly (as I believe they're calculated upon loading of the part - since there's no data field in a .craft file for mass).

Well, shame - that was one of the reasons I've installed the mod. Could I kindly request this feature in a future release, or is it something you're not willing to fiddle with? For now I've solved it with manually editing the craft file and setting the autocut speed to 0 (something the editor won't let me do, and will complain about if I load the craft and try to edit the chute settings).

Possibly I'm blind, but I can't find such setting. There is a deployment timer, but it doesn't sound like the one I'm looking for. The only other time settings are pre deployment speed and deployment speed, but I don't believe they have anything to do with autocut. Ones that look like related are autocut speed and autocut altitude, but neither let me disable or delay autocut. Fine. Could you at least point me to some further reading on this mod? I wish there was a wiki or some other explanation for it. Per chute, but if the only way to do that is a global setting - I'll live with it.

I've searched the thread for the issue that keeps irritating me in this otherwise awesome mod, but only found one or two posts on it, but they did not help me much. I'm talking about the autocut "feature". Is there any chance to let us disable it completely? I wanted to be able to land my vertical rocket on uneven terrain - turns out I cannot, because as soon as I touch the ground, the chutes cut and the craft falls to the side (and gets destroyed). Similar problem with splash landings: the rocket sinks to some depth, chutes cut, then it floats upwards and tilts to the side (this results in "vehicle splashed down hard and was destroyed"). I have tried setting the autocut speed to 0.01m/s but it never helps with the splash landing, rarely with ground landings. I'm 100% positive that if there was a way to have the chutes stay deployed no matter what, my craft would finally be able to land safely.

OK so I think I found and fixed a bug in the mod. I took a look into the sources you posted, and it seems like the following line in the config: CycleToMainCamera = false is mistyped, and should instead read: CycleMainCamera = false as this is what the config parser is looking for. After this change, the camera behaviour is as expected: once in Hullcam mode, '-' and '=' allow only switching between the vessel's cams and backspace returns to the original, third person view (if allowed). Also, I took a quick look at the part configs and found the KerbPro to have an unnaturally large zoom ability - its min FoV value is even lower than the telescope's. You might want to change that for realism And while I'm at it - if we could see camera parameters (min/max zoom, mainly) right there in the VAB, instead of having to check them on the launchpad or configs, it would be awesome, too!

Thanks for the awesome mod. A couple questions though. In the settings.cfg, there are 3 lines: AllowMainCamera = true CycleToMainCamera = false CycleOnlyActiveVessel = true As far as I understand, the first one disables/enables switching back from Hullcam view to the normal, 3rd person perspective (locking on cams when set to false). What does the second one do? I thought setting it to false prevented switching to the 3rd person view when I'm going through my vessel's cameras using "-" and "=", but nada, the TPV still pops up when I go through my cams. I wonder if it's my (moderately heavily modded) KSP's fault, or I simply misunderstand the config. CycleOnlyActiveVessel set to false means I can roll through all the cams on all the vessels in range, right?