RKunze

Exactly. I'm not really sure if "left to right" is just cultural bias on my side, though (because I'm used to reading from left to right). If you do real math, it's moot anyway, because you would either display that equation with a fraction bar and get either 6 — ⋅ (1+2) = 9 2 or 6 ——————— = 1 2⋅(1+2) And if the system you are using can't render math properly (like this forum ) and you have to resort to plain text, just use enough parentheses to make it unambiguous: Either (6/2) * (1+2) = 9 or 6/(2*(1+3)) = 1

The problem with "strict priority" is that multiplication and division (as well as addition and subtraction) actually have the same priority, so you need an evaluation order to disambiguate And I just had a look at https://pemdas.info/ to check if they actually teach it differently (would have been a surprise, actually, because that would actually be wrong from a mathematical point of view), but they don't:

Make that "three math related guys" (and I actually have a university degree in mathematics, for whatever that may be worth). And yes, division is just multiplication with the inverse element, and therefore has the same priority.

Well you would have to scale based on total vehicle mass. Starship+Superheavy is about 40% heavier than Superheavy alone, so it's not a fair comparison. But that's kind of the point I'm making - a Superheavy SSTO gets way less paylod to orbit than a Superheavy/Starship TSTO, despite the fact that the Superheavy booster has to lift not only the payload, but the entire wet mass of the Starship second stage... And I've been just to plain lazy to do the math for an SSTO scaled up to full TSTO mass. Besides, it's silly anyway. If SSTO could get even near TSTO performance, everybody would build them, because two (or more) stages are way more complex than a single stage, and complexity is the enemy....

Correct me if I got the basic math wrong, but how can even an expendable Superheavy SSTO (with a payload capacity of around 50t, as mentioned before in this thread) exceed the 150t of the fully reusable Superheavy/Starship TSTO? I won't even mention the 250 to 300 t of the expendable TSTO here...

That will happily fly your probe right along a straight coast line until it runs out of fuel and crashes not 10 meteres away from shore "Program input only" actually makes sense. My current career is something like that - probes are either kOs controlled and autonomous, or the use the automation features of Kerbalism (mainly for running experiments), and all that's allowed from the ground is the same stuff that a real-world control center can do: Send signals to the in-flight software (I mostly use action groups for that), or update the in-flight software (and if that update breaks the probe past anything that can be repaired with an action group, too bad - we just transformed a million funds deep space probe into just another heap of deep space junk, with the click of a button). "Signal delay" doesn't add anything to gameplay. All it does is force you to timewarp another four years until the signal of your first interstellar probe finally gets back from Alpha Kentauri.... If you want to get somewhat realistic with signals and actually get some interesting gameplay out of it, go for a bandwidth limit, and make experiments take time both to gather and transmit data (and if you want to see how that feels in KSP1, install Kerbalism).

Back in my day, a "card reader" was a device that you could plug into a computer in order to read stuff from memory cards - just like nowadays. But the memory cards were made from actual cardboard, with holes punched through...

SR-2 Mission Report Gene Kerman, KSA launch center, 1/9 08:10 T-17:34 rollout complete T-17:04 ground based telemetry report completed, transmission in progress T-10:00 launch rail configuration complete, launch angle set to 2° off vertical east T-07:42 ground based telemetry report transmission complete (scrawled in the margin: Look at that transmission time. That fancy builtin antenna is worse than useless on a sounding rocket. Suggest to the manufacturer to at least make it an optional module so we can rip it out - Bill) T-06:00 pre-launch engineering checks completed, go for launch from engineering T-04:00 pre-launch science checks completetd, go for launch from payload control T-01:00 drop external connection, vessel on internal energy and control T-00:00 ignition and liftoff T+00:01 in flight telemetry report 1 and SRP experiment 1 activation confirmed T+00:24 in flight telemetry report 1 finished T+00:44 SRP experiment 1 suspended at 76.5% completion T+00:44 SRP experiment 2 start at 18000 m ASL T+00:44 telemetry report 2 activation at 18000 m ASL T+00:48 engine cutoff at 22412 m ASL 1247 m/s 73° heading 90 T+00:48 payload separation activated by remote command T+00:49 payload separation from booster confirmed by telemetry and visual observation T+01:01 telemetry data indicates increasing payload rotation T+01:10 in flight telemetry report 2 finished T+01:46 SRP experiment 2 completed T+01:57 in flight telemetry report 3 activated at 80000 m ASL T+01:57 SRP experiment 3 activated at 80000 m ASL T+02:21 in flight telemetry report 3 finished T+02:56 telemetry data indicates stable payload rotation in flight plane at 2.2 rpm T+02:58 SRP experiment 3 completed T+03:03 apoapsis reached at 100535 m ASL T+05:16 lost contact with probe, probably due to ionisation T+05:21 reestablished telemetry contact, 16553 m ASL, 770 m/s, Heading 283 T+00:23 telemetry data indicates retrograde orientation and heavy tumbling T+05:36 SRP experiment 1 confirmed resumed T+05:32 Osiris Parachute Recovery System activated by remote command T+05:44 parachute deployment confirmed 8354 m ASL 202 m/s, probe tumbling heavily T+05:54 SRP experiment 1 completion confirmed T+06:03 probe still tumbling, 4000 m ASL 154 m/s T+06:37 full parachute deployment confirmed, 547 m ASL 86.1 m/s, probe stabilising and slowing down T+06:54 probe confirmed stabilised at 200 m ASL 13.5 m/s T+07:18 splashdown confirmed T+07:18 telemetry report 4 activation confirmed T+07:43 telemetry report 4 finished T+07:50 initiating recovery operation Appendix A SR-2 technical data Launch Vessel: F3S0 "Shrimp" SRB, launched from MLS-1 "Milkstool" with attached launch rail Payload: "Eaglet" SRAC, configured for Telemetry Report (storage space for 5 reports) and three sample slots for the SRP experiment Recovery Subsystem: "Osiris" Recovery Chute attached to the SRAC below the detachable nose cone.

Yes, I did pull directly from git. I'll just leave my changes in place for now (just to have MM write out a cache file - it won't do this if there are errors) and wait for your fixes (I don't think my changes hurt anything in the save, it will take quite a bit still to unlock the greenhouse).

@CessnaSkyhawk: Short technical update from testing: I had one MM error and one MM warning from SkyhawkKerbalism. Reason for the warning is a simple typo in Support/Bluedog_DB.cfg, there is a duplicated ":" in the MM patch for bluedog_RTG_SNAP19_Quad. The error is a bit more complicated: [LOG 22:20:35.454] Applying update SkyhawkKerbalism/System/ScienceRework/ScienceDefs/LabExperiments/@PART[*]:HAS[@MODULE:HAS[#name[Greenhouse]]]:NEEDS[FeatureScience]:AFTER[SkyhawkKerbalism] to SkyhawkKerbalism/Parts/Greenhouse/kerbalism-greenhouse.cfg/PART[kerbalism-greenhouse] [WRN 22:20:35.458] Cannot find key CrewCapacity in PART [ERR 22:20:35.458] Error - Cannot parse variable search when replacing (%) key crew_operate = #$/CrewCapacity$ I'm not quite sure what you intended for the greenhouse, but for now I fixed/worked around the problem by explicitly setting CrewCapacity = 0 in Parts/Greenhouse/kerbalism-greenhouse.cfg so that the patch in System/ScienceRework/ScienceDefs/LabExperiments.cfg finds the variable. Do you want PRs for either or both of the problems? In addition, I currently have a B9PartSwitch warning: Initialization errors on ModuleB9PartSwitch (moduleID='meshSwitchExtension') on part bluedog.Pioneer.SNAP19 subtype 'Extension' Could not find matching module But I am not sure what the cause for this is or even if it is actually triggered by SSS/SkyhawkKerbalism and not a bug in BDB itself. Any ideas?

Same opinion as @Friznit here - I like the concept as well. Especially the part of offloading the experiments. Fits in well with what you are already doing, and I think it is a great motivator to actually use all these nice BDB parts (for my test career, I'm already trying to decide which of the early satellites I'm going to launch first, even if I just got my second sounding rocket off the pad).

Breaking News - Dawn of the Space Age - KSA launches its first rocket with mixed success by Halwig Kerman It is literally the dawn of the space age: 6:00 am, with the sun just rising over the horizon on the wide plateau where the rocketry research and launch facility of the newly founded Kerbal Space Agency ist located. SR-1 —the first rocket to be launched by KSA — is sitting on a "milkstool" style launch pad at the launch site directly east from the assembly building, waiting for the countdown to finish. At 6:01 on the dot, the solid fuel booster ignites and the rocket lifts off the pad on a column of fire. Slowly at first, then faster and ever faster, tilting slightly to the east. In mere seconds it is gone, high in the sky, speeding toward the distant harbor facilities. Only a huge cloud of smoke remains, drifting slowly towards the mission control building and dispersing in the early morning breeze. According to Gene Kerman from mission control, the mission was a resounding success from an engineering standpoint. SR-1 proved to be aerodynamically stable, reached a peak altitude of 6408 m above sea level and a top speed of 591 m/s, and finally splashed down into the ocean as planned after traveling 38.5 km eastward from the launch facility in only one minute and 47 seconds. The scientific mission, however, was less successful. The plan was to gather detailed telemetry data in flight and send it back by radio, and to recover a mysterious experiment only referred to as the "sounding rocket payload" after splashdown in the ocean. But the first part of the plan was not only hampered by severe technical limitations (according to an anonymous engineer at KSC, "the puny internal antenna built into the ESRAC would need more than an hour to transmit it all, and slapping on a more powerful external antenna does no good because of them darned interferences"), but the telemetry report failed to transmit any useful data at all because there was no onboard means to store the gathered data and queue it up for transmission. And the second part of the ambitious scientific plan vanished in a huge plume of water as the SR-1 slammed into the ocean at well over 200m/s and was completely destroyed in the process ("told 'em to put a parachute on it if they want to recover anything, but there is nary a single one of those anywhere to be found around here", the same anonymous engineer was heard to mutter).

I'm aware of that, and I'll start a new career just for testing...

@CessnaSkyhawkare you interested in alpha test reports for this in career mode, or is it too early yet?

Since your log indicates that KSP crashes somewhere in the garbage collection process, it could be related to the problem described here: https://bugzilla.xamarin.com/62/6216/bug.html#c26 Basically, the Mono GC (or at least the old and obsolete version still used by Unity) sometimes needs to split an existing memory block when freeing up unused memory, and may run over the allowed maximum of allocated memory blocks in the process (which leads to the weird situation that you get an out of memory error when trying to free unused memory). I had similar crashes a while ago, and increasing the vm.max_map_count sysconfig parameter (to 5000000 in my case, but other values my work just as well) fixed the problem for me.

You might want to check which links to the actual libc++-abi files exists - they could disagree with the exact name that principia expects. Here is what Principia is linked against: $ ldd Linux64/principia.so linux-vdso.so.1 (0x00007ffc3734c000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f3c0e31c000) libc++.so.1 => /usr/lib/libc++.so.1 (0x00007f3c0e243000) libc++abi.so.1 => /usr/lib/libc++abi.so.1 (0x00007f3c0e1fe000) libm.so.6 => /usr/lib/libm.so.6 (0x00007f3c0e116000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f3c0e0fb000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f3c0def1000) /usr/lib64/ld-linux-x86-64.so.2 (0x00007f3c0f436000) This means Principa expects libc++abi.so at "/usr/lib/libc++abi.so.1". If I remember correctly, Debian usually has the actual library under a different name (including the minor versions), which might cause it to not be found. In this case, creating a symlink from /usr/lib/libc++abi.so.1 to the actual library file might help. I think this one is harmless. KSP tries to load anything that looks remotely like a DLL, which unsurprisingly will fail for both the MacOS and Windows versions of the native Principia DLLs on a Linux install. I noticed that kind of log spam a while ago in my install (also Linux, but Arch Linux, not Debian), and got into the habit to simply delete GameData/Principia/ MacOS64 (MacOS version of the native library) and GameData/Principia/x64 (Windows version of the native library) after each update to get rid of it.

To get the thread back on the SciFi track, but stay with @Craigcoutures theme of "bringing me to the stars", here are some of my favorites (in no particular order): The Fountains of Paradise by Arthur C Clarke (about building a space elevator) Tank Farm Dynamo by David Brin (short story, link goes directly to the story on Brins website so no spoilers here) The Martian by Andi Weir (although that one is more about getting back home from the stars - and I just realized that the whole plot of The Martian is extremely Kerbal. Guess I won't be able to read it again without imagining Mark WatneyKerman with green skin and big cylindrical head )

There is. Just copy the downgraded version to some other directory (preferably before installing any mods), and then upgrade again on steam to get the recent version.

If a majority would habe that opinion, we would not have MechJeb, kOS, KRPC, Atmosphere Autopilot, and a gazillion of other mods I'm sure I forgot... .And just for a different view, for me, KSP wouldn't be KSP without Principia, Kerbalism, JNSQ, kOS, Strategia and a whole bunch oft other mods.

I beg to differ. My current personal challenge is to get kOS (clearly a kind of autopilot) on a limited IPU budget to bruteforce its way fast enough through some fairly complicated math (a homegrown Runge-Kutta solver for rocket motion equations in atmosphere) to hopefully finally get something that can actively guide any rocket from launchpad to orbit (and in consequence back again - that's basically the same equation, only drag is your friend now) without having to touch the keyboard after the initial "go"...

I'd say give it a spin, it doesn't use much resources actually. I'm playing with Principia on a Core i5 laptop and from a CPU point of view, that's working fine (my bottleneck is the integrated graphics in that thing).

I'll probably do a pull request to that effect. In the mean time, for anyone else trying to build Kerbalism from source without an IDE and stumbling on a missing 0Harmony.dll: install NuGet (if you are on Linux, it may be packaged by your distribution - on Arch Linux, it definitely is) and run the command nuget restore to download the library

@R-T-BAh, there's a package manager involved. Thanks - I knew I've been missing something (still pretty new to C# and .NET, although I do software development for a living and have been doing that for almost 30 years now). Yes - I'm building on Linux (so no VS, only VS Code as an editor) and have just been calling msbuild directly as per the instructions. Might be worth mentioning the dependency on nuget for the next noob like me...

I'm not quite sure we are talking about the same thing here. My problem is not using Kerbalism (that works fine), but compiling it. That fails if I don't copy 0Harmony.dll out of my GameData folder to the path packages/Lib.Harmony.2.0.4/lib/net45/0Harmony.dll within the Kerbalism source folder. And I just wondered why the build system for Kerbalism is set up to expect 0Harmony.dll at that particular path instead of having that path configurable and pointing to GameData/000_Harmony by default....

Sure. But what influence do they have on a config setting in the build file of Kerbalism?