diomedea

@Rayder: indeed, something similar here. I use gravitational parameter, SMA of the orbit and solar day duration (for Kerbin) as reported on the wiki, I believe those are exactly the values as coded in KSP (same for radius of the body and a few atmospheric data, though those aren't required to compute geostationary orbits). All other values are derived from the first three and the equations provide exact values to the precision of the sheet. The wiki is accurate for most practical purposes, but doesn't really compare with that level of accuracy. E.g., sidereal orbital period comes from Sun gravitational parameter and SMA of the orbit, the sheet gives (for Kerbin) 9203544.59721733 (wiki rounds to the closest integer); sidereal orbital period and solar day duration give sidereal rotation period (21549.4251829786, while wiki has 21549.425); to note, that is valid for Kerbin, but other bodies have exact values (coded) for sidereal rotation, so I compute solar day instead. Of course gravitational parameter and sidereal rotation period are all to compute SMA of the stationary orbit. You may have observed already from the above, my sheet accuracy is to 15 digits. I'm actually less confident about the accuracy used by KSP, even when it uses double precision (like it should with orbital parameters). The way Kerbin was switched to show 21600 seconds duration from sidereal to solar day is probably a bit less accurate, but only looking within KSP code may provide evidence of the accuracy and method used. Still if the result you have from manual testing in KSP is so close to what I get with a purely math approach, the accuracy is clearly good enough for all gaming purposes.

Actually not, at least in theory. That difference would bring to 1 second difference every 757.7992420966 Kerbin years. But I use math to compute that, don't rely on KSP to give accurate results. Internal precision used by Unity is generally less than we have with our sheets. EDIT: found to have limited precision in one of the equations in my own sheet (computing sidereal rotation period). Updated, my SMA now is 3463334.05947685. That's probably as much as my sheet can give; difference against yours now rates for 1sec every 21061.79967... years.

ok, had to "kill" Jeb on purpose to check this info, but he agreed it's all for a good cause. When a kerbal is killed, the savegame registers these changes, so guess those are what you need to revert in your save: (all in the sfs section KERBAL by name = <yourKilledKerbal>): state = Missing (should be Available) ToD = <TimeOfDeath> (should be 0; ToD seems to register 7200 seconds = 2 hours more than UT) idx = 0 (should be -1, but have unclear if that filed holds other info so it may have different values than those).

My sheet tells me SMA needs to be 3463334.05915771. Will have to run KSP for same million years and see if your value is better .

I can notice the atmosphere fades with altitude, but there's a discontinuity when it suddenly turns totally transparent, should be at the atmosphere limit. Possible that's what you are seeing too, therefore is normal. But you may be seeing something else or more marked. Can you take one or more screenshots to show here and describe what you see in them? Also, could be important to know your graphics settings, GFX and drivers, the effect may show differently on your configuration (so, please upload and link output_log.txt or player.log and settings.cfg).

Please provide all info as described here. Better if you have verbose logging on (in settings) so the output_log.txt or player.log gives more info. Best if you can also upload and link your savegame. "NullReferenceException: Object reference not set to an instance of an object" is one of the most common exceptions being logged, most of them have no effect on the game as the exception is managed. While most of those with the stock game have already been catched (so the exception won't show anymore), still that logged message is rather common with add-ons (but again, there's no effect when it is managed). In case wasn't managed, game could malfunction and even crash; that's why, if you have encountered one while playing unmodded, this needs be reported with all possible info.

@Draakon: removed something in your post hinting too much at where to find the current FAR build. Unless the author wants that published, it has not to be.

Uh, my turn? @goldenpeach, now yours!

Good points VaPaL. That's one good reason why we have moderators from different cultures too, so we discuss things together and come to understand better what a poster may mean in his own culture. Because all public messages on the forum are visible to everybody, there is always the possibility an innocent thing (from the poster viewpoint) could be regarded as offensive in another culture. Basic mutual respect always helps, and that's a reason for the forum rules we have and how we act. We always try to make so offensive content is removed from public view, though not always easy. We may still be unaware of particular nuances (e.g., something could not raise concern to any of us but still have an undesirable meaning to others) so we find reports from users useful in this regard too.

Please provide output_log.txt (player.log if your OS isn't Windows) when the issue shows. That will let us know what was loaded when KSP is launched, and some info about your system relevant to the issue (e.g. graphics dll in use, GFX, VRAM).

As to functionality, I found no issues playing with both Kerbalism (1.1.8) and RemoteTech (1.8.4) so far. However Kerbalism polls RT API very frequently to know if a connection is active, in a way that wasn't anticipated by RT devs. The result is, if you have verbose logging on, while in flight your log will be spammed by messages linked to the RT API function "HasAnyConnection" showing in log as "RemoteTech: Flight: <vessel#ID> HasConnection: True or False", as that is how the API was conceived to work. RT developers have already addressed this issue, so I expect it will be fixed on their side with the next release. IN the meantime, you need to avoid using verbose logging or your log file will grow hugely.

Perhaps the profile is involved. Had a profile for TAC LS time ago, possible it was in use when the pod had to be filled with resources. Sure that pod has resources defined, but the amounts were at 0 as soon as I had the possibilty to switch to it for a look (this info is easy for me to get, that pod was left in orbit, here an abstract from the sfs and here a pic of the pod). Log wasn't saved. Will send in case the issue shows again.

Hi @Rolacume. That crash report tells about an Access Violation (Error code 0x0000005), its meaning KSP_x64.exe asked the CPU to access a position in memory it shouldn't/couldn't (some good info on that error here and here). There are a lot possible causes for that error code, to include defective RAM, unassigned memory page, memory page reserved to another application, reserved system memory. Below the report shows "Read from location 00000028 caused an access violation." and that tells exactly where in memory the CPU was instructed to look. Can't tell exactly, but a location that low in memory should be reserved for the OS (from 0x00000000 to 0x00010000, the lowest 65K, is all reserved space). An application code doesn't normally point to such locations, but a faulty byte may have been interpreted by the CPU to head there. This faulty byte could be originated by a corrupted KSP_x64.exe file or another file it used (quite possible that "internal/PodCockpit") or by a faulty RAM where KSP_x64.exe or one of its files were loaded. You wrote to have reinstalled 3 times. As you are on Steam, please verify the game cache integrity (from the Steam client, selecting KSP, options, local files), it will report if any file on your disk doesn't match and will re-download just those. Verify again until all files match. If you still have the fault, the most probable cause is a faulty RAM, I'd verify that with MemTest86.

Do we have to figure your problem and provide walls of text to cover each and every case with joysticks so to include the ones of your interest, or are you going to provide info about what your problem is first? Maker and model of the stick; other input devices you have connected KSP could recognize as sticks; Operating system; KSP version. KSP would normally allow setting a stick quite easily, but is limited to what Unity recognizes. It is important how the stick is named for KSP, no two identical sticks can be used without mismatchs. Other external programs can be used to supplement KSP and allow more functionality, different settings, or else. There could be really a lot to write about sticks and I would not even start with the basics without knowing more of this problem.

Output_log.txt or player.log file is almost mandatory to diagnose issues. If you play unmodded, please consider to provide info as suggested here; if modded, as here. This thread will have to be moved accordingly once known if you play modded or not. Beyond that, I always find KSP.log (that KSP creates in the root folder) very useful to provide insight with initial loading issues, so please upload and provide a link to that file too. It is true that a very large output_log.txt or player.log file may bring to problems, they have to stay open while being written by KSP (or being read by other programs). However players shouldn't normally be concerned with deleting it: KSP recreates that file from scratch each time it is launched (so, you'll have a lean log file just afterwards, then it will keep increasing size until KSP is closed), you may actually see this if you keep the subfolder with that file in view during launch or use any program to show the log concurrently with the KSP process. Just because of KSP recreating the file each time, one may need to rename or otherwise save that file somewhere if it holds useful info (like when hunting bugs); and then the need to delete those saved files after bug is catched.

Pls show your ship, it may have RCS thrusters misplaced. Firing 4 instead of 2 is normal when thrusters are in a X cross configuration (pic below should make this clear), but thrust of those 4 sums to give the same as 2 in a right cross. However, you may also have center of thrust from RCS misaligned with the vessel CoM, so each time you want to translate, you also thrust to make a rotation (and then, having both SAS and RCS on, thrusters are fired to cancel the unwanted rotation, so you're actually seeing that retroaction). If that's the case, you may find RCSBA useful to check thrusters position while building vessels. (Also, this fits in GamePlay Questions, rather than Technical Support, at least until confirmed you are having a bug. Moved for now)

I'm not sure why the solution in MJ2 code, it spells to me about computing the root values for time in an equation derived from newtonian mechanics. However there are a number of issues with such approach, mainly due to values for gravity being a function of altitude, and vessel acceleration a function of vessel mass. To achieve a better solution for the powered descent problem (suicide burn being the limit with a powered descent when no margin exists), it is possible to run a simulation in time of the descent (e.g. as done here). However, I believe a simpler solution exists based on orbital energy (though haven't yet found it applied to this problem anywhere). Let me consider just the vertical components for sake of simplicity. Given a specific initial altitude (zi) and initial vertical speed component (vi) of a craft with mass m, is possible to easily compute the total initial orbital energy Ei = m * (1/2 *vi^2 - Gk*M/(R+zi)), (Gk = universal gravitational constant = 6.67408E-11, M = mass of mainbody, R = radius of mainbody). Of course we also know the final energy at altitude = 0 and speed = 0 (apart from the horizontal speed component with a rotating body that we can dismiss for now), Ef = - Gk M m /R. Now the difference in energy Ef - Ei is exactly what we need to provide to have the craft stop at altitude 0. Such energy difference is also known as Work and is easily applied when a constant Force (Thrust in our case) is applied along the direction the vessel moves: W = F * (zb - zf) (zb being the altitude where 100% thrust must be applied, or burn to begin). That way is immediate to find zb from Work; having zb and using newtonian mechanic the speed at burn start vb = RADQ(2/m*(Ei - potential energy at zb)) = RADQ(2/m*(Ei +GkMm/(R+zb)). With vb is then easy to compute time of burn tb = vb / (Thrust/m - GkM/(R+zb)^2). Of course, if Time to Impact is already known (simple newtonian mechanic again while no thrust is applied), subtracting the time of burn tb gives the time left before the suicide burn. If solving for horizontal as well, there is need to consider thrust applied retrograde, craft pitch changes while horizontal speed is matched to the body surface speed and thrust is applied by sine and cosine of pitch to the vertical and horizontal portions of the problem. Again a simple solution goes with energy and work, the total work being the composition of horizontal work required to match horizontal speed and vertical work as above.

Can't be sure if this will help, but a few points. Your error.log shows you have a paging file 64GB large (4x your RAM). That is more than the maximum size suggested and will certainly have a negative effect with performance of your system, in particular long activity time with your HDDs. Even having that large a paging file, it is almost totally used, while 93% of RAM remains in use too. That mean to me paging isn't effective, can't provide enough free RAM to keep loading and executing stuff. However can't think KSP, even with 142 add-ons, is able alone to load your system so heavily; definitely can't think a memory leak could be responsible, as those take time to deplete memory but you report crash happens within seconds from loading KSP. My guess is you are running other very heavy stuff at the same time, or you may have some malware that uses all the memory it can find free. I'd normally suggest to uninstall a few of the heaviest add-ons to see if then KSP can run without memory issues, you may try that but would be better to check how your system performs BEFORE loading KSP (Task Manager provides some useful info, other tools may give even more detail).

Indeed the error.log says KSP is using 40% memory. Can't tell what in your system is using the remaining 60%, but 0 MB free physical, 0 MB free paged memory and very close to 0 user address space all point to the system having run out of memory. An access violation to a position in memory (as reported) is quite telling too, because it in generally tied to that position being already in use. You aren't telling anything about add-ons or your system, of course if you provided a output log file it could be revealing something more. But all the above makes me think you installed some memory hungry add-ons. It could take just one actually, if there's a memory leak with it, to bring a crash if let run for enough time.

@Nils277: your question is actually more about the policy with applying forum rules and add-on rules. So, let us consider the following scenario, where one add-on (or a third-party translation for one add-on) is found not compliant with the above rules (what would happen because either forum members report the issue, or because of our own "fantastic" abilities with foreign languages ). As normal policy in these cases, the moderation team will notify the author, and is expected that action is taken shortly to remove offending material from any package (be it the true add-on, or just translation files). We may actually de-link packages from forum posts if no action is taken, so to ensure compliance with the rules, what has occurred in a few cases over the years. Can't tell for sure yet, but if the issue is limited (at least with languages we can actively moderate) we may actually have the ability to suggest proper corrections to the author, so allowing the ability to implement them and bring the package back with minimal delay.

Please allow me to jump in, though I hope this won't digress any more from RemoteTech as a subject. L4 and L5 lagrangian points are stable (if the major/minor mass ratio is > 24.96; Kerbin-Mun mass ratio = 54.227 therefore the system should be considered stable). As such, a vessel already in a L4 or L5 position won't require any active correction to keep orbiting around that point. Trouble is KSP using only two body gravitation, so lagrangian points can only be "faked in" but won't occur naturally (takes three body gravitation to make those positions stable). It may be considered beyond RemoteTech's scope to automatically correct stock KSP orbital decays, but certainly I'd welcome if it did. At no expense, as it wouldn't require any in reality with those stable L points.

Sure enough I had no need to use IRC before joining the mod team. Coming from a job environment where IRC protocol was considered a utter failure at security, I had no previous experience using it - and would never have used it if wasn't mandatory for moderation. Helps I'm using it only on my own machine, would have never allowed it within the organization I belonged.

Sure KSP isn't close to real objects about density, and quite impossible to do while keeping true gravity values (1 g on Kerbin at ASL) and gravitational constant (6.67408E-11). Earth's density = 5510 kg/m^3, Kerbin's = 58484. Eve's density beats everything at 85197; Jool's density is lowest of planets at 4679 (quite impossible for a gas planet). If I'm correct plutonium is the densest natural element at 19816. While Squad tried to avoid bending physical laws (e.g. same gravitational constant), the reduced scale in kerbol universe brings to values impossible in nature.

Should you stumble again in contracts which can't be completed, please know you can use the debug console (Mod-F12). While in career mode, under "Contracts, Active" you can make any contract "complete" with it. Worth doing if, after having done all what's required to achieve the contract (as described in the OP), a bug is found with the contract system, so to not ruin a career game.

Nice suggestion. Never checked Contract Configurator up to now, thanks