Faster

Great mod! I really enjoy the choices I have to make based on igniters and missions to resupply igniters. After years of playing with it, I'm finding the ullage simulation doesn't really change anything for me, that is, I don't make any choices or face any challenges based on it--other than whether I remembered to quickly wiggle a vehicle's rear end before igniting in micro g and having to over-complicate stages for vehicles automated with things like Smart Parts. I see some older comments about disabling the ullage simulation by doing a global replace in /GameData of UseUllageSimulation=true to false (since the settings UI isn't wired up as of 1.3.6.2). Is that currently the best way to disable ullage or is there a better way now?

I've really enjoyed the choices this mod brings to strategising in career. It seems to work just fine in 10.1.1 with CKAN's versions of Scrap Yard, Stage Recovery, and KCT. Thanks! Some thoughts for whatever they're worth: I enjoy a rare, truly surprising failure that I have to figure out how to recover from and I enjoy choices like needing a ship launched now, damn the torpedoes, vs having the luxury of waiting for a more reliable cryo tank. After a few times of novelty, doing many tests of each part, clicking through Scrap Yard's click-intensive UI to ensure I'm upping the gen rather than just reusing a gen 1 over and over, I feel like I'm doing some serious busy/make work. Then later I find myself doing serious extra clicking (and forgetting to do so) with Scrap Yard to make sure I'm not reusing very old parts. So, I'd love to get rid of the beginning and ending of the curve and have parts be reliable, with failures still happening at a rare, "oh scrap! that was a surprise" rate. If there's a simple way I can do that now by editing files or whatever, I'd love to know. There are issues in GitHub already talking about this likely with better thinking behind them, so I'll just briefly note my ideas: I'd be happy to get rid of the beginning of the curve by deciding in settings which generation parts start at or even which generation they start at plus a first manufacture penalty per part. For example, I might select that parts start at generation 5 and the first time I order each part, that first part takes 500% longer to manufacture or 500% more to make. Just changing the start gen without a time or price (likely complex to code) would be a great, 99% solution*. And, ideally, getting rid of the end of the curve would happen in the integration with Scrap Yard with a feature that let's me select the reuse count at which parts are automatically discarded. Semi-related/unrelated: what think would be fun along the lines of "part testing" is seeing part gen jumping way ahead on failure ("lessons learned") and (out of scope and probably nigh impossible to mod) part performance increasing via usage counts, for example seeing ISP going up a tiny bit per launch with diminishing returns. * I've been playing KSP since .23 as often modded as stock and never have I seen anything remotely like a balanced, rational career economy, which makes the complexity (of coding) of cost penalties highly optional from my point of view and time penalties far more interesting, since the latter actually impacts Kerbal survival, contract success, etc. tldr; feeling of busy work eventually overruns added fun and so maybe add setting for initial gen X of parts, add setting for %Y time penalty for first part, add setting for auto-discard at uses count Z.

Noticed with a few different craft that when the power production is slightly higher than the drain, e.g., 2.337 drain and 2.500 production, and the stored power is increasing at 1X time warp, increasing the time warp by one or more steps will cause the stored power to begin to decrease while the drain and production readings remain the same and dropping back to 1X reverses the problem.

OK, I've not had much luck finding guaranteed reproduction steps; the problem of the game reverting to an earlier KCT launch immediately on switch to the Center seems to come and go. I uploaded the end of a log where the following occurred: 1. I launched a craft to orbit the Mun and did that. 2. After that craft exited the Mun's SOI I launched another craft to orbit Kerbin. 3. After getting the #2 craft circularized, I switched back to #1. 4. I brought #1 down in the ocean and recovered the vessel (the log begins at here at splashdown.) 5. The Center view loaded then immediately switched to the launchpad with craft #2 there un-launched and all other state and time reverted back to that of #2. https://gist.github.com/Famous-Shoes/e39f94ecf02e44e01b33 Let me know what I can check to help nail this down (or rule out KCT as the root cause.) Update 1: Note, I ran no simulations with the #2 craft. Update 2: Also, after launching craft #1, I switched to the Center and building views and other craft many times without issue. After launching craft #2, I did not switch to the Center again until clicking Recover on craft #1. Update 3: I'd been thinking KCT was the only mod I had that should have any "reverting" logic in it, but I just realized I'd installed Flight Manager for Reusable Stages based on a Manley video and then forgotten all about it. Looking at it's thread, it seems to be known to be a bit buggy and so I'll uninstall that and see if this ever recurs.

Is there a patch for this with Engine Ignitor? For example, to fix the LV-909 which shows in the VAB as supporting only Aerozine 50 + NTO or LH2 + LOX but then appears on the launch pad wanting generic hypergolic. Granted, it does burn the Aerozine 50 and maybe the current approach is the smoothest KSP itself makes feasible; just wondering if there's any patches already floating around that clean up these discrepancies so, for example, the automatic fuel selection options for fuel tanks work smoothly and the Delta-V readouts are correct? [update 1] Apparently getting the 909 to burn Aerozine 50 as hypergolic was a fluke, I can't seem to repeat that--so as it stands RF and Ignitor seem incompatible without a patch (though the chatter in this thread would seem to indicate otherwise.) [update 2] Now I can't get a 909 to not burn Aerozine 50; after all the convolutions of trying to figure the interplay of RF and EI I feel like I've been sniffing Aerozine. So, I'm back to the original hypothesis: the oddity of showing "Hypergolic" and then only Aerozine is just the best that can be done with the limitations of KSP. (Ignore the comment about incorrect delta-v above, that came after the Aerozine sniffing began.)

Noticed this causes some null reference exceptions with the toolbar, i.e., NullReferenceException: Object reference not set to an instance of an object at ApplicationLauncher.RemoveModApplication (.ApplicationLauncherButton button) [0x00000] in <filename unknown>:0 at WingProcedural.WingProcedural.OnDestroy () [0x00000] in <filename unknown>:0 Perhaps the member stockButton should be checked for null before being handed off to RemoveModApplication at: https://bitbucket.org/bac9/b9_aerospace_plugins/src/e8e08b27c372ed120ae440757cea7d000c1b1477/B9_Aerospace_WingStuff/WingProcedural.cs?at=master#cl-3256

Wow, Squad must have done something really nuts to change exception propagation that significantly, must make it impossible to stay sane as a mod developer. Anyway, plenty of exceptions in my log as well--always have been, presume there always will be, so there's just no cure then--too bad, great mod! Thanks for taking the time to respond.

Ditto, just observed with satellites that have a Stayputnik as the root and two small, inline reaction wheels (amongst other parts). The wheels were scaled to 0.625 in the VAB. On launch, they're back to 100%.

Sounds like you're using Active Texture Management and need an override to keep it from messing up KCT's icon. ATM's config files are perpetually out of date and so the first place I'd look. I don't have my KSP install handy, but I'm pretty sure I had to add an override file for KCT to ATM.

I'd run many simulations before the launches, edited the craft after starting construction, and duplicated it. To launch I go the space center view then click the KCT icon, then VAB, and finally the Launch button next to the craft in question. Since it sounds like it might be an issue, I'll have a go at some cleaner reproductions and a log file later on.

Seeing something odd that seems new to 1.1.5 and I'm not sure yet if I should report as a bug (could be coincidence with my installing 1.1.5 and is related to some other mod entirely.) Basic sequence is: 1. Use KCT on the space center view to launch an unmanned satellite lifter. 2. Do the normal launch things, you know, maneuver deftly, shout, panic, punch the air when it fails to explode horrifically. 3. Switch to other satellites in orbit to adjust their antennae settings to include the new satellite (which is out of atmo but still coasting to apoapsis) in they're (Remote Tech) network. 4. Once that's done, hit esc, click Space Center. Then I'm taken back to the space center as normal, but after it renders, maybe half a second later, I'm taken back to the launchpad at the time of #1, i.e., faster than I can reach for the mouse, the game reverts to the launch of step 1 above as if I'd been running a KCT simulation instead of a launch. Thoughts? (Does this sound likely enough to be KCT I should go through some more structured repro attempts and get a log file uploaded?)

On a career mode setup in 0.90 I'm noticing past events, e.g., successfully orbiting Kerbin, reaching Mun, are being forgotten and new "be the first to X contracts" are being generated. At first I thought this was a contracts bug, but then I noticed that if I sent different Kerbals, then Final Frontier would award them "first to X" ribbons making me think the problem is deeper in KSP than its contracts code. My question is: can I repair this, e.g., by editing persistence.sfs (now and as the symptom repeats throughout the play-through)? Here's the snippet of persistence that seems relevant (note: the game currently (again) thinks no Kerbal has reached Mun's SOI): SCENARIO { name = ProgressTracking scene = 7, 8, 5 Progress { FirstLaunch { completed = 120716.973798846 } FirstCrewToSurvive { completed = 121416.258603572 crew { crews = Jebediah Kerman } } AltitudeRecord { completed = 447870.213549721 record = 70000 } ReachedSpace { completed = 447870.213549721 vessel { name = Meatball 3 flag = Squad/Flags/retro } crew { crews = Jebediah Kerman } } Spacewalk { completed = 1269197.37314923 crew { crews = Jebediah Kerman } } Kerbin { reached = 120677.913798839 Orbit { completed = 599472.988429759 vessel { name = Meatball 4 flag = Squad/Flags/retro } crew { crews = Jebediah Kerman } } Escape { completed = 3535224.98060267 } Landing { completed = 120677.953798839 vessel { name = Jebediah Kerman flag = } crew { crews = Jebediah Kerman } } Splashdown { completed = 121384.218603565 } SurfaceEVA { completed = 120677.913798839 crew { crews = Jebediah Kerman } } FlagPlant { completed = 1409464.37108338 } ReturnFromOrbit { completed = 600525.815656174 vessel { name = Meatball 4 flag = Squad/Flags/retro } crew { crews = Jebediah Kerman } } } Mun { reached = 3535224.98060267 Flyby { completed = 3535224.98060267 } Escape { completed = 3537471.86158694 } } Minmus { reached = 5111324.97396296 Flyby { completed = 5111324.97396296 } Escape { completed = 5126889.85694749 } } } } [update] Corrected prefix.

I am, and I just pulled SETI and verified this symptom (missing fuel) presents with just RF and KCT and without SETI. Sorry for the confusion folks!

Another issue semi-related to Real Fuels I'm seeing is tanks reading full in the VAB sometimes show up on the pad with a portion of one fuel missing. For example, a "0 Procedural Tank" had 1,621 RP-1 and 1,729 of LOX in the VAB. It showed up on the pad with 1,621 and 1,785 respectively. Not consistent, but not infrequent either. - - - Updated - - - I'm sure it's a problem between Real Fuels and Procedural Parts. I only brought it up here because when the symptom presents, it makes the first few things in SETI fairly difficult at best and so while SETI, with a few Mod Manager patches, is compatible with both RF and PP separately, the bug those two have when together means the three all at once is not a great user experience right now.

The burn time can change on load seemingly at random. This usually only happens if you change a procedural parameter, so it's most noticeable when trying to make a SRB craft that won't exceed the limits of an early contract, e.g., test a chute at 2-5km at 200-500m/s. You may build in the VAB with a burn time of sixty seconds and a TRW of 2 only to find when the craft shows up on the pad the burn time has morphed to 1,200 seconds and so the TRW is essentially zero. So, depending on your mileage, which may vary, the first few contracts may be harder to do or nigh impossible.

Maybe just something to point out on the compatible mod list (since this isn't really a SETI issue): early contracts can be difficult or impossible to complete when using SETI with Procedural Parts and Real Fuels, since the "Procedural Real Fuels SRB" is broken when RF 8.4 is present and the PP SRB is all SETI makes available. [update] Forgot to mention that the "0 Procedural HRB" can't be used as a workaround if you make it to the second tech level in this scenario as it's non-functional, perhaps due to using "Oxidizer" rather than LOX. So might be better to say Real Fuels and SETI aren't currently compatible?

Love this mod and am just curious if folks have any tips and tricks to share for more reliability? For example, I find that: * If I make changes to a craft (even if unrelated to parts with smart parts attached), best bet is to recreate any smart parts to ensure they'll work. * Fuel sensors don't register kerosene (from Real Fuels 8.4,) so don't forget to switch fuel sensors to read LOX after attaching to Ker/LOX tanks. * Fuels sensors do register but sometimes don't fire on symmetric parts, e.g., radially-attached solid fuel boosters, so aim for timers instead where possible (with solid fuel, the burn time is constant!) What other sorts of tricks can one use to avoid catastrophes--I use the mod Engine Ignitor so even a second or two extra delay in staging can be the end of a mission if the fuel destabilizes before a one-shot engine is staged and tries to ignite?

Likely you typed that in a hurry and what was thought and typed turned out different, so no worries as the intent was obviously to be helpful; unfortunately what came across is neither factual nor logical. The closest I could some would be the (made up) "It has been noticed that Mac users usually buy Macs with small amounts of RAM (less than 4GB),and then there's not enough for KSP, causing some of KSP's memory to be swapped to disk, i.e., virtual memory is used, leading to awful performance, but no visual glitches or crashes or bugs like you just described." That's also not true (particularly in this case where 16GB was reported), nor related to symptoms in rendering, but it would make sense if it were. Anyway, one way for xerogravity to check if s/he is on to something is to observe memory consumption over time especially when returning to known states, e.g., back to the Space Center with the same number of craft/parts in flight or none. If memory is indeed leaking, then consumption will trend up over time even in these steady-state situations. But, I don't think it would be worth the headache: what would you do with that information, tell Squad the OS X build is broken? Memory leaks don't directly cause problems other than out-of-memory crashes (they can indirectly cause all sorts of other problems, e.g., poor performance with certain GC algorithms that tend to thrash when memory pressure is high.) The symptoms xerogravity saw presenting are indicative of programming errors, bugs in texture handling most likely, not poor reference management. Though, in theory they could be bugs whose symptoms are triggered by other bugs that are technically memory leaks. xerogravity: the forums seem to say 0.90 on OS X is a very mixed bag and far less stable for many of the folks reporting than previous versions, e.g., the thread I started related to this: http://forum.kerbalspaceprogram.com/threads/113514-Which-Operating-System-for-0-90-on-Apple-Hardware -- though I didn't call out all the symptoms you saw, I have seen them all and much more on OS X with 0.90; the last 0.24.x builds were the Rock of Gibraltar by comparison.

Thanks everyone. To be clear for the non-Apple users out there: Apple does tend to use subsystems that began life on PCs, e.g., GT 750M GPUs, Intel Core CPUs, but they often put a little twist in there that can make for incompatibility and/or instability with vendor (not Apple) drivers. The big pieces tend to be fairly compatible, i.e., unmodified, the glue that holds them all together, far less so. They've done a fair job smoothing that over with the low-level stuff that BootCamp throws in the mix for Windows, but they do nothing for Linux and as many of us who use Mac's at our day jobs for dev work are actually Linux escapees, the potential user base for Linux-on-Apple is smaller than it might otherwise be--I want to go back to that like I want to drill holes in my ankles with a rusty bit. A few folks asked what I'm using and that is OS X 10.10.2 on a MacBook Pro 11,3 Sounds like most folks are having OK times with 0.90 pre-10.10 OS X and maybe a few running OK with 0.90 on 10.10 with different hardware. I can't see what's going on when KSP freezes, but nearly every crash is coming from malloc and I'm seeing stock KSP exceed 2GB of RAM pretty much out the gate, therefore any mods would quickly push it to the limit of KSP-OS X, which is ironically lower than on Win. Again, up to and including 0.24.x the OS X builds were plenty stable for an alpha (the 32bit nonsense withstanding,) it's only with 0.90 that I'm seeing this severe instability (note I missed 0.25 so it could have begun there.) Anyway, I've already put a couple person days into failing to get 0.90 work on 10.10.2 on an MBP 11,3 and have no plans to continue that, especially since I see other folks in other threads saying KSP became unstable for them at 0.90. I'm finding Win 8 on BootCamp on this MBP to be quite stable and that it uses far less memory than the OS X build of KSP (not to mention having a higher threshold for OOM errors.) I'll keep an eye on Linux-on-Apple reports and if Squad hasn't fixed Win or OS X 64 bit by 1.0 then I'll roll up my sleeves some rainy Sunday and add Ubuntu as a boot option.

So I spent a few more hours working with the 0.90 on OS X 10.10.2 and it's just unusable; modded or not. Even got to wondering if aiming for 0.25 might be an option, perhaps a permanent one. Anyway, I installed 0.90 on Win 8 Pro/BootCamp on the same machine (a MacBook Pro 11,3) and dropped in the whole mod list I was hoping for, all 67 mods, which I never thought would work. And, it's playing just fine--NASA almost finished their Mars committee meetings while I was waiting for KSP to load, but once done, it worked without issue. Again, on OS X, even bare-bones 0.90 was about as stable as the cat lady on PCP and it couldn't even load, never mind play, this mod set. More annoying: I dug through the threads on this forum and it seems Squad ought to have enough data points to have pulled the 0.90 OS X version. It's not a very friendly thing to do, letting each player re-discover after hours of trial and error what you know--it doesn't bloody work. Still curious to hear from anyone running KSP under Linux on Apple hardware...

I can give you a rough idea on the first: I regularly fire up Unity3D apps and sometimes the IDE in VMWare Pro (day-job includes Unity dev) and performance is abysmal, far worse than apps on other engines; it doesn't seem to like virtualization, but perhaps Linux fares better. As for Linux, I believe Ubuntu is the officially supported version. If you're still partying like it's 1999 and have USB drives laying around, it's supposedly feasible to get a dual or triboot configuration with Ubuntu without pulling teeth. I'd have to hunt down a USB drive (do they still make those things? ) and am worried I'd then find the driver situation for Apple hardware (vis-à-vis KSP) is even worse than in BootCamp/Win. At least it sounds like Win 32bit 0.90 isn't nearly such a disaster; hope yet I suppose. - - - Updated - - - Thanks, it's good to know this unlikely some new 10.10 v. Unity issue. Sounds like KSP 0.90 v. OS X is just a (new) non-starter, too bad.

I've been away from KSP since 0.24 and just started trying to get an 0.90 installation going again under OS X 10.10.2. After a fair amount of time failing to find a stable modded configuration, I finally dropped down to bare-bones 0.24 and found it crashes and freezes quite a bit too (not nearly as much as with a dozen mods thrown in, but depressingly worse than 0.24.) Anyway, to avoid the letdown of thinking the only decent game of the last decade or so is circling the drain, I wanted to see how folks are faring with other operating systems on Apple hardware, i.e., drivers. I can easily get this going under Windows 8, and with a fair amount of work I could get it going under Ubuntu. Is KSP stable under either of those while still on Apple hardware, stable enough in your opinions to invest time in getting it setup under one or the other? Just looking for biased opinions and personal impressions, not a guarantee it will be perfect for me if I do spend the time. [update]: Fixed title to clarify we're talking Mac's here.

Thank you for this fantastic mod and for that hard work fighting it out with 0.24.x. Just in case this is helpful, I noticed the version file had a minor typo in it that seems to be confusing AVC (with no ill effects, just reporting that the version is 0.0.0 instead of 1.2.2.) Notice the quotes around the patch increment. { "NAME": "RealChute", "URL": "https://raw.githubusercontent.com/StupidChris/RealChute/master/Output/GameData/RealChute/RealChute.version", "VERSION": { "MAJOR": 1, "MINOR": 2, "PATCH": "2" }, "KSP_VERSION": { "MAJOR": 0, "MINOR": 24, "PATCH": 0 } } Here's one that seems to work, also has an additional 2 for the 1.2.2.2 { "NAME": "RealChute", "URL": "https://raw.githubusercontent.com/StupidChris/RealChute/master/Output/GameData/RealChute/RealChute.version", "VERSION": { "MAJOR": 1, "MINOR": 2, "PATCH": 2, "BUILD": 2 }, "KSP_VERSION": { "MAJOR": 0, "MINOR": 24, "PATCH": 0 } }

TLDR; KJR was a red herring, don't skip it on my account! Just an update on my earlier post about a problem with KSP 0.24.2 OS X, KJR 2.4.3 and an unknown mod. After several more hours of testing various mod combinations, it looks like: 1. KJR is merely altering or amplifying the symptoms, it's not part of a root cause. For example, with KJR, vessel parts drift apart without input. Without KJR, the parts don't drift but the vehicle is still broken and will fly apart as soon as acceleration is applied. 2. It now seems the problem is in incompatibilities between three other mod's various versions of KSPAPIExtensions and 0.24.2 and possibly each other; seems to be quite a mess around that (otherwise great) library right now. If I ever really nail it down, I'll continue this in the appropriate mods' threads. Sorry for the interruption; carry on.

I think I'm seeing an issue between KSP 0.24.2 OS X, KJR 2.4.3 and some other mod. After upgrading KSP and KJR this evening, I found all in flight vehicles tore themselves to pieces and new vehiclesâ€â€on the pad, prelaunchâ€â€have parts slowly drifting apart. Removing KJR fixes the problem in new vehicles, but switching to one already flying still causes that vehicle to explode. Loading stock KSP and KJR alone does not present the symptom. I did one binary search of all my mods to see which was fighting with KJR but had no luck finding a single mod that was the culprit; likely I just made mistake moving mod folders around. Or they're ganging up on me. Has anyone else seen this or know of another mod likely to start pulling hair when left alone with KJR? Info for the morbidly curious: 000_Toolbar ActiveTextureManagement AlignedCurrencyIndicator AviationLights B9_Aerospace BoulderCo Chatterer ConnectedLivingSpace DMagic Orbital Science DeadlyReentry DebRefund DistantObject EnhancedNavBall EnvironmentalVisualEnhancements ExsurgentEngineering FerramAerospaceResearch Firespitter FusTek Fusebox KAS KAX KSP-AVC KSPScienceLibrary KWRocketry Kethane KineTechAnimation MagicSmokeIndustries MechJeb2 ModStatistics ModsByTal ModularFuelTanks ModuleManager.2.2.0.dll NASAmission NavBallDockingAlignmentIndicator Nereid OpenResourceSystem PartCatalog RealChute RealRoster RemoteTech2 ResGen SCANsat ShipManifest TextureReplacer ThunderAerospace (LifeSupport) TreeLoader TriggerTech TweakScale US_Core UmbraSpaceIndustries WarpPlugin Here's a sample of some new log spam that I'm seeing (but have no idea if it's got nothin' to do with nothin') (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) getObtAtUT result is NaN! UT: NaN (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) nearestTT is NaN! t1: 0, t2: 0, FEVp: NaN, SEVp: NaN (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) problem! [NaN, NaN, NaN] - [NaN, NaN, NaN] - NaN - [NaN, NaN, NaN] - 0 (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) E is Infinity! tA: 3.14159263251637, e = 1 (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) dT is NaN! tA: 3.14159263251637, E: Infinity, M: NaN, T: NaN (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) problem! [NaN, NaN, NaN] - [NaN, NaN, NaN] - NaN - [NaN, NaN, NaN] - 0 (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) E is Infinity! tA: 3.14159263251637, e = 1 (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) dT is NaN! tA: 3.14159263251637, E: Infinity, M: NaN, T: NaN (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) getObtAtUT result is NaN! UT: NaN (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) getObtAtUT result is NaN! UT: NaN (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) getObtAtUT result is NaN! UT: NaN (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) getObtAtUT result is NaN! UT: NaN (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) problem! [NaN, NaN, NaN] - [NaN, NaN, NaN] - NaN - [NaN, NaN, NaN] - 0 (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) E is Infinity! tA: 3.14159263251637, e = 1 (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) dT is NaN! tA: 3.14159263251637, E: Infinity, M: NaN, T: NaN (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) E is Infinity! tA: 3.14159267466322, e = 1 (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) dT is NaN! tA: 3.14159267466322, E: Infinity, M: NaN, T: NaN (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) getObtAtUT result is NaN! UT: NaN (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) getObtAtUT result is NaN! UT: NaN (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) getObtAtUT result is NaN! UT: NaN (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) problem! [NaN, NaN, NaN] - [NaN, NaN, NaN] - NaN - [NaN, NaN, NaN] - NaN (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) getObtAtUT result is NaN! UT: NaN (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) problem! [NaN, NaN, NaN] - [NaN, NaN, NaN] - NaN - [NaN, NaN, NaN] - NaN And here's a screenshot of a pre-launch vehicle after having drifted apart for a while (notice the capsule is still in it's original position while the tanks and engine have floated, slowly, above it.)