diomedea

As a RT user, I'm certainly interested. Hope the feature will include total distance of each couple of nodes along the path with time (kind of that graphical analysis Gaiiden showed), as RT makes links active only when distance is less than the maximum range, defined by both the antennae in the link. Actually the range could be based either on "standard" model (link range = Min (r1, r2)) or the "root range" model (link range = Min (r1, r2) + √(r1*r2), eventually corrected by RangeMultiplier). Would be great if that analysis tool showed the actual range against the maximum possible range for each single link (could be shown as a % of the max link range), and even output a warning in Mission Architect when no valid link is found (and particularly if this lack of a valid link happens while a burn is planned).

Done for you, as editing even your own thread (to change the label) would be impossible while in the Curious George group.

Ok, I had a look, using both your persistent and quicksave.sfs. Tested on a clean KSP 1.0.4 (build 861). In my tests, I could "fly" that Space Station (SS2), timewarp and return to normal time without adverse effects, but only when SS2 is the first object flown in game. Going back to it, even if only through the Space Center, makes the station to start a spontaneous disassembly if timewarping. That is certainly in relation with the NullReferenceException (shown in your output_log, but also in mine) "... at (wrapper managed-to-native) UnityEngine.Transform:INTERNAL_CALL_TransformDirection (UnityEngine.Transform,UnityEngine.Vector3&) ... at Vessel.GoOnRails () [0x00000] in <filename unknown>:0 ..." which means when that station is being packed for timewarp, the parts coordinates have to be frozen but something is missing that is needed to get the correct orientation on one or more of those parts. What I see is the station begins to disassemble with parts freely floating away, as if they lost the attachment relation with their parent part. Now, checking the output_log, can see before a disassembly, there is another specific NullReferenceException when going from the SS2 to the Space Center: "at (wrapper managed-to-native) UnityEngine.Transform:INTERNAL_CALL_InverseTransfo rmDirection (UnityEngine.Transform,UnityEngine.Vector3&) ... at Part.OnDestroy () [0x00000] in <filename unknown>:0" Ok, that tells nothing of what part is it about, but sure a part was destroyed and its joints terminated when the SS2 was left. Why that happens is not clear, however I have one observation here: if I wait long enough to let everything to settle (so that accelerations among parts due to the physics with off-rails vessels are very small) I can successfully get back to the SS2, timewarp and back without problems. The issue arises when I don't wait and the physics still fight to position those parts. Believe that may suggest you what to do (wait longer, let the station physics settle before making it on-rails again). The cause may be from the very thin connections (just a docking port in most cases) and the size of that station, that means even minimal errors in alignment of the parts may bring to forces greater then required to break the joints.

My main KSP gaming install (1.0.4, build 861) with 89 add-ons loads in 152 s. My barebone KSP test install (same as a build 861) loads in 19 s. Windows 8.0 64bit, 3.4 i7 CPU, KSP installed on a 1TB 840 EVO SSD.

Here are the reasons (IMHO) why your craft isn't behaving: 1. Your plane has the Center of Mass (CoM) exactly where the Center of Lift (CoL) is, that means it has no dynamic stability of its own (the effect of forces from the lifting/control surfaces is stabilizing if they act rear of the CoM): 2. Stabilizers (the horizontal control surfaces controlling pitch) are very close to the CoM, their effect to control pitch is minimum (torque = force * distance). It is effectively not enough to keep a desired pitch while aerodynamic forces make the plane change attitude. 3. Lift from the wings is high enough to make the plane climb even at low speed. The more it accelerates, the greater the lift: when the plane gains speed the effect is to increase the torque they exert. As the wings CoL is forward of the CoM, that effect is destabilizing and will soon be greater than the amount from those tiny stabilizers. So, to correct that: - move stabilizers to the tail; - if the above isn't enough to make the CoL enough to the rear of the CoM, move the wings towards the tail a bit too.

Now, let me express my awe about the implications. ASET ALCOR has my favourite IVA in KSP, would certainly be a dream to see other parts with IVA so detailed and consistent. But that is exactly what I see coming with FusTek parts now, thanks to you all (sumghai, MOARdV, and Alexustas).

The CC BY-NC-ND license won't stop you from making derivatives for yourself, and that's one good case for sharing the code. Another important case is to allow independent checking, but that is of concern only to those who are security-minded (and will take too long to explain why open sourcecode and independent checking is important, especially for users who don't care about what they are installing on their 'puters). The license can't stop from making alternative add-ons, providing the same functionality in a different way (and here is a third good case for showing the sourcecode, it allows to verify any similar add-on isn't a derivative of this one). The license effectively stops everybody from pirating this add-on, and you can be absolutely sure we will use everything in our arsenal should piracy be detected. Now, hope this stops any further suggestion this add-on could be "taken care" in ways the author has not allowed, and bring back discussion on the add-on itself.

what's the reason for updating? if you are experiencing issues with the latest KSP and this add-on, then fine, but report those issues. I can't even see (unlike for other add-ons) a version mismatch being reported with Realchutes and latest KSP. If your reason is just to see the [1.0.4] label with this add-on title, then let modders take their time, there is no need to put unneeded pressure on them.

There's no use in posting about bugs in General Discussion. Have a look in Support (either the modded or unmodded sections, depending if you use add-ons or not) and you will find a number of reports already, some may fit with what you're experiencing. In case you have something to add, that may help diagnose your problem, you may do so in one of the threads already opened. If nothing fits, you can open a new one. But in any case, provide all the information as required in the guidelines for reporting bugs with those sections, Squad and any of the people providing support can't do much if those issues can't be replicated in a controlled situation. And sure nobody will try to fix something they can't see.

Yes, both threads develop from the same fact, but want to show different aspects. But even if both were on the same (and therefore could better be merged in one), it would be that other thread to be merged in this, as it was the second one opened.

Press F10 while in flight, you should see in the center view a green textline stating "Temperature Gauges: Disabled" (just press F10 again to re-enable).

Without a picture or something to describe your ship, guessing your problem is impossible. Upload the .craft file (best use a hosting file site) and link it here, so it could be tested.

Hi arien101, some of the points that help me with landing. 1. About dropping too quickly: does your plane have enough lift at low speed? it may not have wings large enough to provide lift at the final approach speed (please note, it is easier to take off with small wings than to land, because during T/O you use full thrust oriented by the angle of attack). 2. Find what the minimum safe speed is with your plane at very low altitude. Just fly straight, low and slow, and see when you can keep altitude from dropping further. Any slower will bring your plane to stall. That speed is the absolute minimum you must never go below during approach. Also, take note of the angle of attack when you can keep altitude at the minimum speed. 3. It is possible to fly with just a keyboard, but exercise with the throttle control (shift, ctrl). During approach the angle of attack is generally kept fixed, and rate of descent is a function of thrust, so you have to be able to change thrust fast enough to correct. 4. SAS may actually fight against a plane natural attitude, and induce oscillations or worse. With a plane built to be stable there is no need to use SAS (e.g., center of lift above the center of mass and positive dihedral angle help to keep roll neutral). Could be better to exercise flying without SAS. 5. Choose a correct glideslope for your craft. Most aircrafts do with 2.5 - 5°. It should allow your craft to descend without changing speed, while keeping vertical speed under control. 6. With all the above set (airspeed, angle of attack, glideslope, correct amount of thrust), you start aligned with the runway aiming for the gate. Correct thrust when lowering gear (due to increased drag). Just before the gate start a flare (increase angle of attack and cut thrust), it will increase lift so reducing the rate of descent, while also depleting airspeed. With proper timing and amount the flare will make for a gently touchdown, and that is needed to avoid bumping back in air. Immediately apply brakes and level (angle of attack down to 0). and sorry in case you already knew most of the above , but some points could turn useful for others too.

Nice to see some variant about propulsion systems. Just remember to show a license with the OP (beyond the download file).

Many thanks for this, sarbian. Sure enough I edit and make config files a lot, and really need such a tool .

While a small change in TAC-LS code (to recognize what DeepFreeze does) is certainly the most elegant long-term solution, there are other possibilities, you probably already considered them but I would ask what's your opinion about: - fork TAC-LS code and apply the proposed change; distribute the new DLL respecting TAC-LS original license with DeepFreeze (of course this will work only until a new TAC-LS version comes); - counter-do in DeepFreeze any of TAC-LS consumption of resources and creation of waste for frozen kerbals (re-adding the amounts TAC-LS subtracted for the time kerbals were frozen). Not really elegant, overly complex and possibly needs to sort recycling, but still better then a save-reload (from a user perspective at least).

Please look within KSP_Data subfolder (under the KSP root folder) for the output_log.txt. And yes, it is normal, KSP does not call any of the MS OS help routines when it crashes (I have yet to find once such help to be useful, but that's another story).

Your error.log shows you are running KSP.exe on Windows, therefore you are running the 32bit version (x64 executable was named KSP_x64.exe). However, can't desume what caused the crash. When KSP runs out of memory, in output_log.txt the crash message follows after a line that includes "System out of memory!", and often the operation that could not allocate memory. Have a look at the end of your output_log.txt (after the game crashed, as the log is renewed at each run), and if you find a similar line, you may have to begin thinking at measures to save RAM (less add-ons? use of -force-openGL?).

Well, don't despair, that ship just needs a little help to stay stable. With the new aerodynamic in KSP 1.0, stability is a real problem (like it is in the real world). To help ships stay stable while ascending in atmosphere, some wings or fins aft of the Center of Mass help greatly. I tried with original craft and then a slightly modified one (just with 3x AV-8R fins at the tail), the results are shown below (some comments with the pictures to help get the "picture"). Hope that helps, sure KSP is a game where testing different ship designs until a viable solution is found, makes for a great deal of the fun.

uhm, something like Launch CountDown perhaps? (Of course, if you like using add-ons)

That is generally the case when editing a post when you still are in a moderated usergroup (Curious George, i.e.) as the post needs to be approved again. Anyway, I took the liberty to edit it when was showing as needing approval again, so to make the spoiler actually working as intended.

Sure bugs have feelings too But I am for squashing bugs anyway. I should probably not download this add-on, I'm not qualified to use it.

In case you have some issue to report, do so. It will help fix things in case the issue is caused by this tool, or to provide you help on how to make it work. But what you wrote is false in general. This tool works perfectly for me and many others. Writing such things, in that way, shows your intent is actually to belittle this tool, without any evidence. This behaviour is unacceptable, and will be considered in view of community rule 2.2.h should it show again in the same unsubstantiated way.

Checked that savegame, but couldn't find any hint about what made those tourists to appear. That is actually better, rather then having still something in the save about them, and could create an issue not finding them any more. Could be something shows in the log (output_log.txt or Player.log), in case the process that created them also logged the event. But not knowing what that process could be, can't anticipate if that took care to keep events logged. Also, can't exclude it was actually KSP to generate those tourists, as if it called the process twice for the same contract; but then would be interesting to find out what really happened, it may show a bug escaped. Anyway, glad you could get rid of that annoyance.

Those are some good points. 1, sure not everything could be made stable. My considerations are worth for a correctly profiled craft, as the center of mass must lie below the center of curvature of the bottom. 2, I know you inherited those shields. And are nice shields also, but were working with a different aerodynamic model (both in stock, and with FAR). No surprise they can't work the same now, and sure is not your fault they can't. Sure they are a lot flatter than real ones, so the stabilizing effect has also to be much lower when correct aerodynamics are used. 3, good suggestions. Some of the alternate ones may work, have yet to try them. Or at least, I expect them to work with FAR and a correctly sized reentry vehicle, not anything. Without FAR, it may be the case to consider testing some offset, as KSP does, but that is not an action I would require you to take when you don't like it.