RKunze

Embedded kOS Kirkuits adds kOS processors to selected probe cores. Its primary use is career mode play with Skyhawk Science System (which is supported out of the box) but other mods can be supported as well (pull request on github welcome, or include the support patch with your mod). The mod contains a (deactivated by default) example patch which makes it act like the old kOS for All! mod. See the Github Repo for details. Installation: Recommended way to install is with CKAN. If you want to install manually, see the "Installation" section of the README on Github . License: CC-BY-NC-4.0 Source Code: https://github.com/rkunze/EmbeddedKOSKirkuits

Sure. Just pile up a big enough heap of fissible material. Can be done by hand (and has been done accidentally more than once, google "demon core" for details). Problem is (at least if you're working on bombs), that won't get you a nuclear explosion. Just a bit of heat (which will usually lead to some fires, and shove your fissioning stuff apart, thereby killing the reaction) and a lot of nasty, highly radioactive isotopes all over the place that are an absolute poodle to clean up afterwards (as can be seen in Czernobyl and Fukushima). Making the stuff go boom is a bit more complicated, mainly because you have to somehow keep it together until the chain reaction has used up a significant fraction of the fissionable (or fusionable) material.

First off, my heartfelt commiseration to Benjee10 for the data loss. Been there once myself, back in university, lost the final version of an assignment to a flaky floppy disk (yes, I am that old), had to cram 48 hours straight to recreate it from a heap of notes (because, of course, I lost it just before it was due) and went into the exam that went with it without having slept for two days. That's how I learned that backups are important That is exactly why the (fully automated as well) backup system I'm responsible for today is set up so that it sends a daily summary of what it did, even if everything went flawlessly. So that if I don't see an email about the daily incrementals when I start working in the morning, I can (and most definitely will) go investigate what exactly went wrong. And, of course, why I do regular checks that I can actually restore files from backup (not automated, because that doubles as training for the procedure when something actually is needed urgently).

I built some myself a couple of years ago when my kids where around that age. And yes, those things pack quite a punch at launch - I wouldn't let a five year old play with something like that unsupervised (besides, daddy wants to have fun with rockets as well ). It's actually pretty easy, basically just take an empty soda bottle and hot-glue some cardboard fins at the end for the rocket, and stick a small tube through a cork that fits snugly into the bottles' opening for the launcher. For launch, fill bottle with water (1/3 of the volume works pretty good), jam cork into bottle, connect open end of the tube to a pump (airtight), point to the sky (and more important, away from anything that could be damaged) and pump until liftoff. For a more elaborate, reusable, but still simple version, hot-glue half a tennis ball to the front of the rocket (protects the rocket a bit on impact, and gets the dry COM into the first third of the vehicle which gives quite a bit more stability in flight), use plastic for the fins (mainly because cardboard and water are not a durable combination), and use a garden hose quick connect system both as the nozzle and a launch clamp (which means you can pump to a predefined pressure and then launch at will by releasing the connection - preferably through some kind of remote release mechanism at a few meters distance, as that is a) much safer and b) will keep you mostly dry at launch). And if you really want to make a hobby out of it, build something like this (I never got that far, I didn't even build a single-stage one with a parachute for retrieval).

First I have to get KSP2 to run on my rig at all (or buy a new rig). And then I'll probably wait until I have at least a rough idea on how I have to structure the code so that the official modding system will load it, and what game interfaces are (or will be) supported by the official modding system. I think we should at least try to come up with a common host interface for both, so that the same WASM code that powers a e.g. "cheaty" ascent guidance can be run on the "gamey" version as well (provided the simulated computer in the "gamey" version is powerful enough). And I think we can even share a lot of the implementation - after all, if you're going to run WASM in a dotnet environment and want to have it portable across operating systems, you pretty much have to use wasmtime-dotnet (or do you know of any other portable dotnet embedded WASM runtime?). Which means the main difference between the "gamey" and the "cheaty" version is that the first ties WASM execution speed to in-game time and sets an artificial limit on WASM instructions per in-game second, while the second runs WASM asynchronously as fast as the real CPU allows. The rest (WASM memory, program size, in-game resource consumption, ...) are just artificial limits in the "gamey" version (well, apart from WASM memory - the "cheaty" version is limited to whatever leftovers of real RAM KSP2 doesn't gobble up). I'm actually very interested in that as well, ever since I read a paper on a closed-loop generic atmospheric ascent guidance algorithm based on optimal control that claimed to be "implementable on a simple embedded system". Tried to implement it in kOS, even, but gave up after I realized I would have to a) port all the math libraries from matrix multiplication on up and b) the kOS VM is at least and order of magnitude slower than a "simple embedded system" anyway. PS: Maybe we should take that discussion to a different thread as it isn't about MechJeb per se?

That ties neatly into my mod idea - namely, using https://github.com/bytecodealliance/wasmtime-dotnet to simulate an embedded computer in-game (kind of like kOS, but without having to write my own VM). Would give a nice basis for in-game automation, make ist possible to use existing real world code (which is not possible with kOS), and provide a nice set of tweakables to provide different computing choices, because wasmtime-dotnet makes pretty easy to tie the simulated CPU speed to in-game time, i.e. we can have simulated processors with different CPU speeds as well as different RAM size (that's already inherent in any WASM runtime because the host always has to provide the "memory" and can choose its size).

I'm currently trying to figure out how to (in that order) get the thing to runcrawl on my (way underpowered, especially in the GPU department) Linux laptop from Steam with Proton figure out where in the launcher the feedback buttons are figure out how to give feedback on the official channels without the darn launcher from a copied install with Wine, and with neither the launcher nor the rest of the Steam spyware how to set up an IDE for modding it what APIs might actually be available to hook into After all of that, I'll either start modding (I actually have a fairly detailed idea for a mod), buy a more adequate rig (might do that anyway, but can't quite convince myself to shell out around 2.5 k€ for it yet), wait until the dev team gets around to giving us poor modders some hints on where to start, or give up in disgust Current status: Halfway into the very first step. Starting from Steam (with "Proton Experimental" as compatibility layer) works (including the launcher - that's something that never worked for me with KSP1) and actually gets me to the start screen and the settings page. Tried to actually start a game on default settings just for fun, ran out of RAM and crashed. Pretty surprised I got even this far. Will try again tomorrow with settings that maybe actually could get me to the KSP scene... Oh yes, the rig I tried this out on: CPU: i5-8265U RAM: 16 GB GPU: Intel UHD 620 (yes, really) OS: Linux (Arch Linux to be precise)

Well, looks like my current laptop is out. Not that I expected otherwise, I've been pretty surprised that KSP 1 was somewhat playable on its Intel 620 GPU. Whats actually surprising is that it meets the recommendations for CPU and RAM. So, KSP 2 gives me an excuse to upgrade the thing

I'm not familiar with those units - is this in that weird kimperial system they use on the other side of the big pond? Anyway, as every Kerbal knows, light (and comms signals, which are a kind of light) travels infinitely fast. And gravity stops at the SOI edge.

Unfortunately, it is. The mod explicitly checks for "KerbalTelemetryComputationalUnit" in the part name.

I could be tempted. But then, I'd probably cheat and simply look at the Principia sources, since they did all the hard work already

Actually, N-Body gravitational interaction per se is chaotic, and it is not easy to design a planetary system that's actually stable over longer periods. That said, you can at least avoid the additional chaos and instability introduced by the inevitable numerical errors in a simulation by choosing a "symplectic integrator" that preserves the system invariants even in the face of numerical errors (for a newtonian system, that would be the sum of potential and kinetic energy). You'll still get inaccurate results, of course, but instead if going completely out of control (as with a non-symplectic integrator such as Runge-Kutta), the orbits just wobble a bit around the "real" position.

If I'm not mistaken (could be, though, that stuff is far above my knowledge level), they created a quantum model that is equivalent to a wormhole in a 1+1 dimensional anti-DeSitter spacetime (a toy universe, to put it plainly). Using a mathematical model that nobody got to work yet in a 3+1 DeSitter spacetime (our universe) - and quite a number oft scientists suspect that this model actually can't work for the real world. Yep. Exactly.

Oh, come on, Common Lisp is ancient and boring (as I should know, having learned it at university at a time when Common Lisp wasn't even teenaged). Nobody wants to mod by writing ASTs. Let's stay properly kerbal here, and build a modding API in Kerboscript.

Actually, that depends strongly on the GPU vendor. AMD, for instance, contributes strongly to the open source drivers, and normally there is no reason to go to the hassle of installing the proprietary driver for an AMD GPU. Intel has middling to decent open source support as well (although Intel GPUs suck for anything other than basic office type stuff, as I can testify because I'm stuck with one for KSP gaming for now and therefore have to miss out on all the visual mod goodness). Nvidia, on the other hand, is a completely different story - they actively sabotage open source support for their GPUs. TL;DR: Don't buy nvidia GPUs for Linux boxes. That company actively works against you, don't reward them for it.

Current status: After deep diving into the Contract Configurator and ModuleManager docs, I am fairly certain that I can implement this as described above. Next up: Prototype implementation for a typical test scenario. Detailed progress can be tracked on Github.

Part Testing, With Purpose The stock "part testing" contract suite in KSP 1 regularly comes up with contracts that are inane even for Kerbal standards (Test LY-01 Fixed Landing Gear on a suborbital trajectory around Jool), extremely grindy (Haul $RANDOM_PART to the launch pad. Press 'test part' in the part menu. Rinse. Repeat.) or both. This contract pack mod tries to fix that. In addition, this contract pack tries to provide interesting game play together with part reliability/part failure mods, especially part failure mods based on TestFlight. First class support for Less Real Test Flight is built in from the start, and has a big influence on the overall design of the contract pack. Gameplay Overview Contract Types Contracts provided by this mod still follow the general schema of "Test $SOME_PART in $SOME_SCENARIO", and the bulk of the contracts is still generated procedurally. But each scenario tells a plausible story, and the parts are chosen to fit the scenario. For example: Test a new first stage based on the RE-M3 "Mainsail" Liquid Fuel Engine in flight: The contract requires launching a new vessel that has a "Mainsail" engine and a tank that can feed the engine. To complete the contract, the "Mainsail" engine has to be started while still on the launch pad and must be active while the vessel is flying in atmosphere. Test a new probe based on the Probodobodyne QBE probe core in orbit: The contract requires to launch a vessel that has a "QBE" probe core, and may optionally have RCS, reaction wheel, and antenna parts (including the optional parts gives a bonus reward). Contract completes when the vessel reaches a stable orbit. Test a modified probe based on the Probodobodyne QBE probe core in orbit: The contract unlocks when the contract above has been completed. It requires a vessel with the same probe core and the same categories of optional parts, but at least one of the optional parts has to be a different. Contract completes when the vessel reaches a stable orbit. Some contracts may provide special scenarios to support testing special parts, for example: Test the atmospheric launch abort procedure for the Mk1-3 Command Pod: The contract requires a vessel with the Mk1-3 command pod and the Launch Escape System. To complete the contract, the LES must be activated in flight in the atmosphere, and the command pod must be recovered. Contract Rewards Part testing contract rewards are moderate (this is part testing, after all, not exciting new science): Basic funds rewards are just a bit more than the cost of the tested part. Part costs are payed out in advance, anything over the pure part costs is payed on successful completion. Basic science rewards are on the order of one science point per tested part. Standard reputation reward is zero Standard contract prestige is "Trivial" Most contracts will give an extra bonus when the tested parts are recovered. That bonus reward is typically an increase of the science rewards by a small factor (greater than one, probably less than two), and one reputation point. Occasionally, contracts which have a bonus goal are offered with prestige level "Significant". These contracts require the bonus goal (usually part recovery) to be met for completion, and increase all rewards (including funds) so that they are a bit more than the corresponding contract at prestige "Trivial" including the bonus reward. No part testing contracts with prestige level "Exceptional" are offered. This is part testing, after all. Modified Reward System With TestFlight When TestFlight is installed, the real reward for taking part test contracts shifts to its natural target: Making parts more reliable. With TestFlight, parts accumulate "data units" while they are in active use (e.g. an engine is fired, a parachute is deployed, a tank is drained, ...). The amount of data units present on a part at launch determines how reliable that part is. So, with TestFlight installed, test contracts will pay out additional data units instead of science points (which are a poor substitute, really): Completing a test contract multiplies the data units acquired during the test for each tested part by a given factor > 1 That factor increases when the bonus goal is met The factor increases again when the contract has "Significant" prestige Penalties for failure Typically, part test contracts do not fail when the contract parameters are not met, meaning they can be repeated until success. Test contracts may expire (or can be declined) without any penalty besides having to repay the advance funds. The exception to this is killing crew members while testing. After all, an important purpose of testing parts is to avoid killing crew. Therefore, killing crew members while testing immediately fails the contract, and does carry a substantial penalty (mainly in reputation). Part selection Part selection generally considers only parts that have already been researched. Ocasionally, experimental parts from a node that is about to be researched may be offered, but this is rare. Part selection generally favors testing "new" parts: Parts that have been researched but not yet unlocked Parts that have not been tested before Parts that are not on any vessel ... Modified Part Selection With TestFlight With TestFlight installed, part selection is biased a bit differently: Unreliable parts in active use on a mission that is not covered by an active part testing contract are much more likely to be selected for testing than any other part (you really should have tested those parts before flying them on a mission, after all). Next up are unreliable parts that have been tested before (if you did test it, it stands to reason that you want to use it. And if you want to use it, it should be reliable). And last, there are all those untested new parts out there (to get you started on building your next generation reliable space craft)

Year 1, Day 132: WIMAS-I Not even one minth after the launch of Pathfinder IV (12 days, one hour and 56 minutes, to be overly exact), another Sandstone/Satevis launcher sits on the pad. Ready to launch the first weather imaging satellite — or WIMAS-I for short. Tension is high in mission control, because this launch again has a number of "firsts": Instead of launching into a highly elliptical equatorial orbit as in the previous missions, WIMAS-I will (hopefully) launch into a low, circular, polar orbit (so that it can eventually observe the weather all over Kerbin). WIMAS-I is much heavier and much more complicated than the previous satellites. It even has a computer built in, and this computer can even be reprogrammed in flight! In order to accommodate both the more massive satellite and the added Delta-V needs for a polar orbit, the Satevis stage will not have a dedicated controller aboard. Instead, the flight software for the launch phase will run on the WIMAS computer, and will be replaced remotely with the software for station keeping and scientific observations once in orbit (because — powerful as it is — the WIMAS computer nonetheless has not enough storage space to hold both the launch and the orbital software). Especially the last point makes the launch team nervous. But the alternative — haul both WIMAS-I and the tried-and-true Satevis control module into orbit, each with their own computers — simply exceeds the mass budget for the Sandstone/Satevis lifter. In order to maximize the illuminated area of Kerbin that WIMAS-I will observe on half of each orbit, the launch is scheduled for noon. At exactly 09:00:00, mission control gives the launch command. The Sandstone booster carrying WIMAS-I roars into the slightly overcast sky, and — for the first time — pitches north (and even a little bit west) instead of east. The adapted flight software automatically adjusts the azimuth direction so that the final orbit will have an inclination of 90° — at least, that is what everyone im mission control hopes. At the usual altitude of round about 60km, the fuel of the Sandstone booster is exhausted and the main engine cuts off. The new azimuth control software has worked perfectly so far. At an altitude of 65 km, fairings are separated to expose the Satevis upper stage, and the spent Sandstone booster is jettisoned. Almost routine. But this time, the big island that the mission just passed is not Welcome Back Island. WIMAS-I atop the Satevis stage coasts to an Apoapsis of 95 km. The extra batteries on the Satevis are needed to feed the power hungry computer during launch. Shortly before reaching apoapsis, the Satevis upper stage ignites as planned. In contrast to previous missions, this time — instead of just pointing prograde and hurling the payload as high as possible — the flight software makes sure that the apoapsis does not increase too much. And it cuts off the engine as soon as the orbit is circular (which is possible thanks to the ingenious engineers at Bluedog Design Bureau who came up with a system to stop a solid rocket before it runs out of fuel). After reaching an almost perfect orbit (94 by 97 km, with an inclination of almost exactly 90°) the flight program cuts of the Satevis engine, and triggers both the small explosive charge that separates WIMAS-I from the Satevis and a set of eight small, solid, retro rockets on the Satevis that will deorbit the Satevis upper stage. The launch team in mission control takes a collective, relieved, deep breath. Their job is done, and flawlessly. After handing control of WIMAS-I over to the payload team, the next to last item left on the agenda for the launch crew is to watch the — now uncontrolled — Satevis stage deorbit on the telemetry monitors. The spent Satevis stage may now be uncontrolled, but definitely not out of control. The push from the retro rockets has lowered the periapsis — exactly as planned — just enough that it will reenter the atmosphere shortly after passing the north pole, paint a fiery streak over the northern ocean and either burn up shortly before reaching the equator (probably) or fall into the ocean a bit south of the eastern tip of an arid equatorial coastal mountain range (not as probable, but possible). In any case, it will provide spectacular fireworks for a small crew of local radio (and space!) enthusiasts which are currently sitting high on a peak in said arid mountain range on behalf of the Kerbinian Society for Astronavigation, crewing the so called "off-site tracking station" (which consists of a portable — barely — antenna dish and radio, a portable — just as barely — generator, and a small cluster of tents) that provides the telemetry data currently scrolling over the monitors at KSC. Meanwhile, the payload team gets to work. The first item on their agenda is to replace the launch flight software with a program that will keep the satellite oriented so that its top — covered with solar panels — always points to the sun (the sides are also covered with solar panels, but that is mainly a precaution to make sure that WIMAS-I does not immediately run out of electricity if it is not pointing at the sun). The newly installed station keeping software boots up, detects that WIMAS-I is way out of alignment, and fires both RCS and reaction wheels to correct the error. As soon as the axis of WIMAS-I stabilizes pointing to the sun, the station keeping software proceeds to spin it up to exactly 5 rpm. Fast enough to stabilize its orientation, slow enough to not blur the camera images. From now on, the station keeping software will run in an endless loop, wake up every minute, check orientation and rotation speed, correct errors if necessary (using just the reaction wheels if the error is small enough, conserving the RCS fuel for unforeseen circumstances), and go back to sleep again. This will typically just take a few seconds, and leave most of the resources — especially the electricity produced by the solar cells — free for WIMAS-I's primary task: Observing the weather on Kerbin. From Space. And already the first image sent back to the science team proves out to be sensational: Not only a clear image of wispy clouds over the northern ocean off the polar ice shelf, but a an equally clear image of the northern aurora! As the launch team heads out of mission control to get to their last checklist item for the day (which is, of course, to repair to the cantina for a well earned celebratory snack), they hear in passing the preliminary discussions between the WIMAS-I and the Pathfinder science teams about a joint research program to further study the influence of the radiation fields around Kerbin on its atmosphere, focusing on the northern and southern aurorae.

No. Because there is absolutely nothing that incentivices this other player to spend that time in-game except that they want to spend the time. And how exactly should that work? How would you use an in-game currency that is absolutely worthless in real life to force another player to do things for you that they don't want to do anyway? Especially when they can always simply accept contracts from the system to get in game currency. Or - if those are also too boring and grindy - simply quit playing.

I can see that for a game where in-game currency can be easily converted to real money, or where there are (artificially) rare items that can either be purchased with in-game currency or have to be farmed (usually involving horrendous grind). Basically, the kind of game that is designed to get players to spend real money to purchase in-game stuff. But for KSP? Not really. The in-game currency only buys the same, standard in-game parts for everyone, it buys absolutely nothing in real life, and you can't easily buy it with real money. And you can always get enough in-game currency for your own in-game needs by simply accepting the contracts offered to by the system. So, the only incentive for any player to accept a contract from another player is that this contract is better (read: more fun) than a contract offered by the system. And I don't see any ethical problems with that...

The dropbear is here. How do I patch a conic?

No, that text goes into its own config file. Name and location does not really matter as long as the location is somewhere below GameData and the name ends with .cfg The usual recommendation for this kind of personal patch is to create a dedicated directory below GameData (e.g. GameData/LocalPatches) and name the file(s) in there to express their purpose in the file name (e.g GameData/LocalPatches/JNSQ-Color-Fix.cfg)

Don't know, haven't used Astrogator myself. No. Principia and Kerbalism work fine. Not that I know. JNSQ even has dedicated support for Principia (mostly changing some orbits which would not be stable otherwise - most visible of those is that Minmus is Kerbins inner moon with Principia). Depends on where your craft and stations are - stations in orbit around or bases on bodies that do not exist in the new system will probably be in trouble. And even orbits around bodies that are unchanged may be different with N-body physics instead of patched conics. I'd recommend to backup your save before you try.

Probably not. I did not play with Principia and OPM myself, but JNSQ and Principia work well. To install: Download the ZIP file from the link in the Principia thread (or in Github) and unpack it in your KSP directory. To uninstall: Delete the GameData/Principia subdirectory. I'm using CKAN for most mods myself, works pretty well with the occasional mod installed manually.

If it is only persistent rotation: You don't need the extra mod with Principia, persistent rotation is already built into it. Other than that, Principia allows for some interesting stuff that doesn't exist with patched conics. Like low-energy transits, or orbiting Lagrange points.