diomedea

Being in career (as you said, early tech) makes for specific choices about what you have unlocked. In my most recent career game I had to wait a lot before the techs allowing to build a decent relay sat were unlocked (though I play at very hard level, so my progress is slower). Actually, you may wish to do specific choices based on what contracts/missions you have that could bring more advantages, and techs allowing unmanned flights aren't all available that early so you may have to go with more manned flights than you would like. At a very minimum, you need solar panels and decent batteries, and clearly some means to control the vessel (probably the small reaction wheel comes before RCS, unless you choose to go for that). If you need suggestions about building, probably best to open another thread in Gameplay Questions and show what you are doing and what isn't working as you expect, there is plenty of forum members willing to help if you ask.

Sure, I certainly know it can go to orbit. With MechJeb.

Would you mind first to confirm that what I suggested works, and the cause is indeed the lack of control with zmap launch? In the case of Comsat LX, the first stage has 3092 m/s DV (VAC), 2423 m/s DV at sea level. To make orbit from KSC at least 3200 m/s DV are needed. It takes a perfect ascent trajectory to bring it to orbital speed with the tiny engine of the last stage. Mechjeb can be set so to choose a proper ascent trajectory, but takes effort to set it, and some knowledge about what is involved. Again, it isn't Mechjeb the culprit. You keep blaming something wrongly, and now what is that other add-on (Unmanned before Manned) doing? Do your tests without other stuff that may change how things work, and could be the real cause of your troubles, instead of insisting against all evidence in blaming what isn't.

Indeed. Always best to provide version details. I tested with both the 2.6.0.0 version available as main download with MechJeb, and the latest (as of yesterday) devbuild 698.

Moved to Add-on development, where it belongs given the current status. When the mod is released (and the OP corrected to show that) will be moved back to Add-on releases.

The orbital data with the asteroid in that savegame (SMA = -62370614.5606016, ECC = 1.00989215399152) allow to compute Pe = SMA*(1-ECC) = 616979.723778947, or (given Kerbin's radius = 600,000 m) a Pe altitude ASL = 16979.723778947. Which is totally consistent with KSPTOT and (rounded) with the Tracking station (unmodded) and VOID. The rotation period of Kerbin doesn't change the above (would only if Pe altitude was measured AGL instead of ASL, and terrain altitude changed at the Pe because of the different rotation). However, when a vessel goes off rails (loaded in the scene) its positional data is updated based on time and velocity vector. The process may easily bring to differences just because of the accuracy of the data. Can only guess at what may happen with add-ons, but should those affect any of the data required (positional vector, velocity vector, frame timing interval) the difference would come evident. Anyway, would be best to check with a saved game after having switched scene to the asteroid. SMA and ECC shouldn't change at all while off-rails when no external forces act on a vessel; but if they did then it would be a confirmation the orbit changed. The only thing that could actually bring to a difference of Pe altitude in reality would be to compute atmospheric drag (though believe none of the add-ons you mentioned do). And when atmospheric drag is considered, a difference could be due to the rotation of the asteroid itself because of the Magnus effect.

MechJeb works fine, but can't do miracles. One miracle would be being able to steer a zmap launch vehicle without any means of doing. Some of the stock vessels are of really poor design: zmap only has control surfaces and engine gimbals to change attitude, but the first don't work once out of the atmosphere; the second don't without thrusting. Indeed each and every zmap launch sees MechJeb stop completely any attempt at controlling attitude just as altitude goes beyond 70 Km (throttle being at 0% as the required Ap is already met). And while not pointing in the correct direction, MechJeb doesn't throttle (would only make things worse). You have any means of doing manually what MechJeb can't? I tried at least 10 times without any success, stock zmap simply can't be steered if not using the engine. Try what I did to verify what I'm telling: add a reaction wheel to the satellite and launch again: now MechJeb can complete the ascent and circularization without problems. Now, hoping you got how things work, would be honest if you corrected what you kept writing about this add-on, both here and on that other thread.

Very interesting. Just one question, as you know how RSS does orbital period, have you also checked how SMA is computed? Because while in stock KSP both Ap and Pe are measured from the mainbody center, with n-body gravitation those are to be taken from the center of mass of the system (which in a two-body system is always closer to a minor then the major body center). Of course SMA = (Ap+Pe)/2 therefore the orbit of the minor is smaller around the common center of mass then around the major body. If both major and minor positions were computed from the common center of mass all would fit; but if the major remains "on rails" around Sun instead of around the center of mass of the system (which is orbiting Sun) both minor and major positions would be wrong.

Unless all posters show to abide to forum rules from now on (in particular rule 2.2.d. " Insults and threats, stalking, bullying or any other behavior construed to be of a potentially rude, slanderous, accusatory, combative or otherwise harassing nature to/of another person "), this thread is going to be closed. Now, can everybody drop personal attacks and spicy replies? @Tau137, you have stated a number of times you intend this thread to collect data about users experience with lag-inducing add-ons. Please note you can't avoid other users to discuss the method and validity of the idea itself, as indeed ignoring what causes lag or why a system may slow down at times can only give useless readings. Knowledge of the possible factors with anything observed is the basis for building a valid theory, based on scientific grounds. Only once the method to take readings (and isolate possible concurrent factors) is properly defined, data collected following that method will be of value; data "taken in the wild" may only feed false beliefs about something being wrong. Of course spreading false ideas isn't welcome on this forum. If you don't like to have those factors discussed as happened above, then what will come from data collected? Will they be used to pressure modders to improve add-ons while isn't their fault?

Must say, never found this bug before. Really doesn't seem related to MechJeb, the trouble while undocking shows even while the plugin isn't loaded (MechJeb parts have to because vessels won't load without, but can't cause harm). It seems when the fuel pods docked, KSP got confused and didn't set correctly all relationships with parts of those fuel pods then belonging to the docked vessel. Sketched a graph showing these relationships for parts involved using data from your savegame. Numbers are the ID of each part (0 would be for the root part with the vessel). This chain starts from the size3 tank (ID = 191) where 4 attachment points are radially attached in symmetry, with large adapters and then docking ports over them. With the fuel pods docked, the chain continues from the coupled docking ports, large adapters and attachment points, to arrive at the size3 tanks with each pod (each one carrying a now unused attachment point). Somehow KSP got things wrong (probably due to how those pods were assembled) and didn't set the relationships shown by a red arrow, between attachment points and size3 tanks (in the savegame those show as nil, instead of pointing at the correct ID for the attached part). Though unclear how the above could bring to the issue, tried editing the savegame with the correct values. Unfortunately my try didn't work, with or without MechJeb still the issue shows; what follows is KML analyzing a savegame just after a unsuccessful undocking, showing the docking Port (with ID#501) having invalid data, plus the opposite attachment node on the same fuel pod being now wrongly attached. Interestingly, another vessel identical to the one with the 4 fuel pods (but still not detached) is also reported to have a problem with a docking port (probably caused by the double link with the mirrored ports, stock KSP isn't able to manage double links). I'm guessing something similar to the error with attachment points not correctly tied to those size3 tanks happens not only while docking, but undocking too. Indeed, undocking makes for all parts with the detached vessel to reverse parentship again, starting from the root part down; whatever caused KSP to not set ties correctly when docking seems to occur again. Therefore, even if I had the link for the attachment point corrected (parts 503-504) still this causes part 570 to go detached from the fuel pod and remain logically tied to the ship. Possibly the error that occurs at undocking (NullReferenceException: Object reference not set to an instance of an object) is due to this; certainly something prevents the new vessel to be generated (therefore the above exception) with consequences with all the concerned parts. KML shows the fuel pod still being a part of the ship (as confirmed by the docking ports not being reset to 'Docked(same vessel)' but having remained docked to the corresponding other port) and therefore that pod still uses engines at the same time of the ship. Parts 501 and 570 being now marked as having the root part as parent (though being not attached) brings to a situation that KSP is then unable to manage if the scene is reloaded. Normally similar issues could still be solved resetting by hand the docking ports; but this time KSP didn't even generate a vessel; may still try to solve manually deleting each single part of the detached fuel pod from the savegame, if not else to allow you to keep going with the game. Can't promise it will be successful; but before starting doing so, please let me know what is the situation you wish with that ship (seeing the pods are filled with fuel, they are probably not yet to be detached but intended to be used).

Files are good for me to check your issue. Indeed an abnormal undocking shows every time with one of those fuel pods, which raises exceptions. Please allow me some time, have to clean all unneeded vessels in your savegame before going deeper. A early analysis with KML (generally very useful to check docking issues) showed other vessels with troubles, but not that one: That means I'll have to go deeper hoping to find where the trouble is and how to fix it. Anyway, doesn't seem related to use of MechJeb.

Glad to have the possibility to help: I do keep past versions of add-ons I like stored and the BSD-2 license with this add-on allows redistribution if the copyright is retained (which is in the following file): Precise Node 1.2.3.

Please provide the following: link to the savegame that brings to this error; KSP version and build; MechJeb build you have installed. Best if you can also provide links to the crafts files for the ship and docked assemblies. Also, if you are able to read the output log (or, open the debug window and select Console), please observe if any error or exception is shown when you undock and report it. If not, please provide output_log,txt after having "unsuccessfully" undocked. I'm fairly sure checking the structure of your ship in the savegame (or craft file) will reveal something weird, as also can be guessed by one detail in your vid (that BZ-52 radial attachment point seemingly floating next to the ship but not moving, therefore actually still a part of the ship though seemingly belonging to the detached fuel pod).

To be honest, no idea at all; but I also doubt anybody may identify what caused the issue from only the information provided in the opening post. Let's start with one thing: sometimes we find what can be called "intermittent bugs", weirdnesses we are unable to identify the cause and, trying to reproduce in the same situation, don't show every time (or even never again). There is no chance to diagnose bugs unless reproducible, so these intermittent ones are very hard to squash. The above brings to consider one of the most important pillars with testing: reproducibility. Who has to examine the issue has to know the correct situation to make the bug appear. Among KSP testers, the consolidated procedure to report an issue is to provide a detailed explanation of the situation, possibly a savegame that leads to the appearance of the issue, KSP settings if appropriate to the issue, a detailed list of steps to perform to arrive at the bug, criteria to identify the bug occurrence (e.g. what is expected against what is produced by KSP). Another pillar with testing is appropriate documentation of the issue, e.g.: showing pictures (or even better, videos) while the bug is occurring; making tests of your own and providing results showing when the bug shows or not; if appropriate, external references providing evidence about the expected results. Plus of course the KSP logs as proper: often times logs provide information about KSP workings, showing if something went wrong (e.g. the various exceptions being logged with output_log.txt). Plus, mandatory information about the KSP version installed and the OS used (sometimes corroborated by further details, e.g. GPU brand, screen resolution, input devices used...). Final and very important pillar: no add-ons if trying to isolate a stock KSP bug. Actually, even better to run a virgin KSP install and try if the bug shows on a brand new game, rather than one you may have running (and could somehow have been corrupted). Most of the above is described in the guidelines for stock support & bug reporting. Should your bug be reproducible on your side, best you could do is to actually use the official bugtracker and fill all available information as suggested above. This forum section may give you help about fixing what may be wrong with your game or KSP install; but won't solve any real KSP bug: those have to be reported with the bugtracker.

KSP being a Unity based game, makes use of whatever libraries Unity includes. One such library is PhysX (now version 3.3) that devolves to a nVidia GPU most of the physics calculations. The more parts with a vessel, the more physics calculations per frame. A GPU is actually a very powerful parallel computing unit, using it to save CPU cycles is generally a good choice; however KSP is a lot heavier than other games when it comes to physics, having lots more interactions among parts (or with ground, water, atmosphere). The result is the GPU is often loaded way more than advisable and, concurrently with its true graphical tasks, can become the real bottleneck. I do use Process Explorer to keep track of resource usage while KSP is running (and even when not). One good feature of Process Explorer over other similar apps (e.g. Task Manager) is to show the % of GPU used in real time by any application, not only of CPU, RAM, or else. I have a nVidia GPU and guess what? when KSP is running with even a low partcount vessel, even without anything graphical to show (as when orbiting without looking at any object) the GPU% is at least double than the CPU%. Proof without doubt of the GPU being effectively charged with those PhysX calcs, not the CPU. On the other side, KSP doesn't use more than one CPU core unless it can make use of different threads (like when dealing with more vessels). With that same app is fairly easy to check each one of the threads started by KSP; there is always one that makes up the largest part (by far) of all CPU cycles (should it alone arrive to a CPU% = 100% / CPU cores, it would create lag); add-ons also add to that thread unless effectively using multithreading. Indeed, one could think there are some inherent Unity issues when CPU or GPU usage is not optimized. Maybe Squad could find new ways to improve over the basic multithreading Unity offers, or to reduce Physics computations when not really required, or else.

That is what happens anytime thrust is applied in a direction away from the correct maneuver (more than 90° from that). You certainly know that being the result when overburning a maneuver (applying more than the required DV), after having reached the minimum. The DV counter shows the amount required to fulfill the maneuver (that is, how much the current ship velocity vector is away from the required ship velocity vector) irrelevant of the direction. If that happens while correctly aiming at the maneuver marker, one of the following is the probable cause: burning at a orbital position very far from the node position; using engines thrusting in a direction different than the root part axis; or a bug with the marker placement. The latter could be verified by using an alternative way to place navigation nodes (e.g. if you experience the bug using MechJeb, check if the same happens executing any maneuver with a manually placed node).

Happy to know you found a workable solution . I believe to have got how you did, but should you wish, please provide more details for other users who may encounter this issue.

Being a registered customer of KSP with Steam means Steam itself will update KSP when a new version is released; no further payment is required. However, as you have now opted for a beta (like pre-release 1.2.9), you'll stay with that until it is removed from allowed downloads, or you choose another. To download the most current official release (now still 1.2.2 build 1622, will become 1.3.0 when released) you just need to opt out of any beta version.

Error.log alone doesn't provide enough info to diagnose the issue. Showing Mono.dll as having performed a wrong operation doesn't tell what brought there, only that the crash happened before KSP_x64.exe took control (as during initial load). Please provide output_log.txt (DO NOT merge that directly in a post; DO upload to an external file service e.g. Dropbox and show the link to it here). Quite probable the issue is with a missing class from one add-on, like a mandatory dependency required by another: you may be able to spot the issue yourself by reading the last valid lines of output_log.txt (before the crash report).

Your gif doesn't really tell about anything weird, apart that you made a node almost 2 years in the future. The synodic period of Eve from Kerbin is 679.9553 kerbin days, therefore is guaranteed that the first possible transfer window can't be beyond that; however Mechjeb placed the node at (1 year = 426.09 days) + 399 days + (5 h = 0.83 days) = 825.92 days in the future. The node "drifting" isn't anything weird. Given you were in a 1000x timewarp, SAS wasn't keeping the ship oriented, so the node would move away from the "nose" of the ship even if you actually tracked the node (which you hadn't). The direction of the burn at the node position remains fixed in space; you see that direction move because of the relative position on the orbit of your vessel changing, but the change is relative to the body you are orbiting, while remaining fixed in space (and that goes with the Eve antitarget marker too). Do the same with a stock (unmodded) KSP install, you'll find the effect just as well. Isn't clear what you state with "if one actually tries a transfer orbit (even to the mun), your destination mysteriously ends up at some other point in its orbit when you actually arrive.". If you set up a transfer manually so to show an encounter, executing it correctly will bring to the encounter (may require some mid-course adjustment for interplanetary transfers, certainly not for Mun). If the transfer is planned by MechJeb and doesn't fit, that is a MechJeb issue to be reported with that add-on thread (but is probably due to other add-ons interfering, MechJeb alone isn't known to make such evident errors). Bodies in the KSP universe don't move erratically, not even while using Principia: their position with time strictly follows keplerian laws, so if they "mysteriously" end somewhere else is because the time of your transfer isn't the same of what was planned. Which most often is caused by navigation errors.

Which is your OS? e.g. Alt is the Modifier key for Windows; but on Linux you need to press RightShift+F12. nVidia GeForce Experience is (by far) the most common software interfering with the functionality, as it by default uses Alt-F12 for the FPS on/off in Shadowplay, therefore intercepting any such command while remaining in background. Not having a nVidia GFX would not have required installation of GeForce Experience; however please check it really isn't around on your system. The above doesn't exclude other software could do the same (intercepting Alt-F12). However no other software doing so is currently known. You may have to stop background applications one-by-one and test each time to find when the functionality is restored (in Windows, Task Manager conveniently allows to terminate anything running), be careful however about not shutting system services unless you know what they do.

OK, let's be clear about what we don't allow then. Forum rule 2.2.j " Roleplay, e.g. acting as a Kerbal, creating fictional organizational hierarchy amongst users and/or interactions of fictitious entities of an oppositional nature " applies. I've differently coloured the three parts of the rule to make clear they aren't necessarily all happening in every instance of roleplaying. While creating a free cooperation with other users is allowed (I'd even say, could be encouraged), acting as if real users have hierarchical roles in anything resembling an organization is forbidden. Such arrangements have brought to rivalries in the past, sure, and that's a good reason for the rule to exist. However roleplaying doesn't require a rivalry to exist: it happens anytime some users act as if they were in a position of power over other users. Writing "I take full responsibility to the actions of this group" shows you want to be identified as leader in this group (which means a hierarchy is established), therefore goes contrary to the rule. Let this be the last time any of us needs to warn about this rule: avoid anything in your idea to resemble organizational (e.g. stop talking about "staff", do ask about "interested users").

Hi @Dragg0n, welcome to the KSP forum. Believe (from your 2nd post) you can read enough English; however please use only English in messages posted outside of the Russian subforum (as stated by forum rule 2.3.c). Reading through Google translate, I get you installed from Steam version 1.2.9, but then somehow installed a Russian language set on it. Don't know where you found a language set, but that is not how the install should work. Using Steam library, select KSP properties, on the properties window the 4th tab "language" allows to select the correct language; the 5th tab "betas" allows to select version 1.2.9. Having done both selections on Steam, KSP will be installed with the Russian localization. As explained by monstah, 1.2.9 is not yet complete, localization work is still ongoing and will be completed for KSP 1.3.0. But 1.2.9 should work and not crash as you reported. Should you still have crashes, please provide details in this thread, there are russian speakers around who also know how to bring such issues to the knowledge of developers.

Certainly. From the Steam browser, search the library for Kerbal Space Program. Right-click on KSP and, from the menu that now shows, select "Properties"; it will open a new window with 5 tabs, the last tab is "Beta" and has a pull-down menu for the beta you want to get. One of the entries you can select in there is "previous - 1.0.5. Kerbal Space Program". Being a public beta accessible to all who beought the game, you aren't required to fill a code and should be set: Steam will update your install to KSP 1.0.5

Done, done, and fully agree!