HarvesteR

Lead Developer HarvesteR just posted on his dev blog this message, which is copied here:

Hi, Very good news today! After many months of preparation, KSP is now available on Steam! We're very fortunate also in that we're one of the very first games to be released as a Steam Early Access title. We've been working closely with Valve recently to make sure the release went as smoothly as possible, and their new Early Access category is just perfect for us. We're all very happy here! So, I think we should probably have a little Q&A here, to clear up what'll likely be the most frequent questions: Q: If I've already bought the game on the KSPStore, can I switch over to Steam? A: The answer to that is Yes, but not right now. We are going to set up a system on our store where you'll be able to get a Steam key for KSP provided you already have purchased the game. However, we are still working on the exact details of this feature, so it'll likely be a while until that's set up. We'll of course let you know when that becomes available. Q: What platforms are supported on the Steam version? A: KSP is available on Steam for all three platforms (Win, Mac and Linux), and the Demo is also available on all of them as well. Q: What is this Early Access thing you speak of? A: I think Valve can explain it better than we can. Q: Is this in any way related to the 0.19 update being smaller than usual? A: You've probably figured out already this is one of the main reasons we cut the 0.19 update short. We wanted KSP to look its best for the release, so we decided to get the reentry fx, animations and all the other features out in time for it. The shorter update cycle worked out nicely for us though, so we'll try to maintain that flow for future releases as much as possible. The patcher should also be ready by then. Q: Speaking of patcher then, how does that work with Steam? A: Steam has its own update system, so for the steam version of the game, we've turned off all version-tracking features in KSP. The Steam version will update automatically when we publish new builds, so it all happens without the need of any external tools. The patcher will only be used for the KSPStore-bought version of the game. That's all I can think of for now. If other relevant questions pop up in the comments, I'll update this post here to include an answer to it. Happy Launchings! Cheers

Hi again, We've just released the 0.19.1 revision for KSP. This update is just a small hotfix to address some issues with the 0.19.0 version. Here's the changelog for it: Bug Fixes and Tweaks: * Fixed re-entry shader failing on highly scaled parts * Corrected an issue that would prevent large rover wheels from applying brakes * Tweaked braking speed and power on rover wheels * Adjusted how rover wheels display resource usage * Changed Ladders on the launchpad ladders to make it easier to climb them. * Changed the names of launchpad and runway objects to be more descriptive when you crash into them. As always, you can download the new version from our Store. Happy Launchings! Cheers

Hi, I'm happy to announce we've just released the 0.19 Update for KSP. This update was a bit of a turning point in our usual way of doing things. We decided to not do a massive release with a huge amount of features, but release a smaller update sooner, with the features we had nearest completion. In any case, we did manage to include more features than even ourselves expected this time. Here are the highlights: * Linux Support: There is now a native Linux version of KSP! Official support for Ubuntu 12.04, but it should work on most distributions. * Atmospheric Effects: Watch your spacecraft flare up as they re-enter the atmosphere, and produce vapor trails during high-speed flight. * New Kerbal Animations: The Kerbals got a massive overhaul on their facial expressions! The new Expressions system uses the new Mecanim animation engine from Unity, giving Kerbals a lot more expressiveness. Watch their faces distort in total panic or gleeful joy, now also when you're out on EVA. * Rover Wheels: Drive across the surface of other worlds with the new rover wheel parts, which are steerable and self-powered. Construct anything from tiny unmanned rovers, to exploration buggies, to huge mobile contraptions. * Graphical and Scenery Improvements We've got a New Launchpad model at KSC, with 100% less launch tower, a new Runway, and much improved night-time lighting, making for greatly improved visuals, especially at night. * More New Parts We've added several new parts for general construction. Featuring panels, girders, and a lot more! Screenshots: And here's the complete changelog: New: * A Native Linux version! * Added visual (and sound) effects for re-entry and supersonic flight. * Overhauled the Kerbal Face Expression System with new animations, which are also visible on EVA. * Added wheel parts and modules for the construction of rovers. * Added several new general purpose structural parts. * New mesh for the launch pad area, now with 100% less launch tower. * New mesh for the Runway, with sloping edges to drive on and off it. Bug Fixes and Tweaks: * The sun no longer shines from below on ships and scenery objects at night, or while in orbit over the dark side of a planet. * Fixed the airspeed sound not looping properly, and adjusted the pitch range for it. * Various minor balance tweaks. * More texture variety added to probe cores, to better determine their positioning. * Fixed a few objects that were on the wrong layer. * Fixed an issue when comparing versions, which could result in false 'incompatible' warnings. * Fixed an issue with velocity changes when resuming 1x time while on a hyperbolic orbit inside a rotating reference frame. * Changed the debug toolbar key combo to ModifierKey+F12 (RShift+F12 by default) * Changed the quick scenario loader key combo to ModifierKey+F10 (was Ctrl+F10 before) * Removed an unused shader that caused the game to crash on Linux systems with AMD video drivers. * The Alt modifier key is now remappable, and defaults to RightShift on Linux. * Remapped all ocurrences of the Alt key to RightShift on Linux (as Alt is OS-reserved on most distros). * Fixed double-clicks not working properly. * Added a setting to tweak the mouse wheel axis scaling. * Input Axes now support linear scaling. * The Debug console can now also be toggled using the Grave and AltGr keys As always, you can get the 0.19 update as a full download on our Store. Happy Launchings! Cheers

Hi, I want to let everyone know about a decision we've made here, that changes the plans for the 0.19 update a bit, and what you should expect from that. What we want to do is this: Instead of doing a massive update every couple of months or so, we want to try releasing a smaller update on a quicker timeframe this time. There were many reasons behind this decision, not least among which were these: We've been noticing that the time between updates has been growing ever longer. This is not just because on each update we seem to set ourselves an even more ambitious goal than before, but also because of the ever higher standard for quality we have to live up to, as the game nears completion. Also, the sheer magnitude of the last updates we've done has made release periods incredibly stressful on us, because we are releasing these huge updates, with tons of room for bugs and problems. A smaller update means less things that can go wrong, and a lot less stress on all of us. So, what does this mean for 0.19 then? Basically, it means two things: One, 0.19 will have less features than originally planned, and two, it will come sooner as well. The features we want to get out early are the ones we have nearest to completion at the moment: The Reentry Effects, the new Patcher, and the new Kerbal Expression animations. About all the other features we had planned, this doesn't change them much. They're still being actively developed, and in all likelihood they'll be done in the same amount of time as before. The only difference is that we're getting the features we have ready out before the others that are still pending, instead of waiting for all of them to be ready before releasing it all in one go. We have not changed our internal deadlines for any of the features currently being developed, we've essentially split the one big update into two smaller ones. This was made possible after our switch to Git, in place of SVN. Before, we had to make sure all the features were ready to go before releasing the update, because there was no way to exclude an unfinished feature from the game without doing destructive changes. So everything we started absolutely had to be 100% complete before release. There was just no way around it. Now, each feature is developed on its own separate branch, and it only gets integrated into the actual game when it's ready to go. That means we can very easily select a few features that are nearer completion to have them tested and released, while work on the other features continues. So, to put this in as clear a way as I can, we are not postponing anything, we are going to release a few features out early. This isn't a definitive change though. We want to try it out, to see how we feel with this new way of doing things. If it works out, it could mean faster-paced updates, which is always a good thing. If it doesn't, we'll just go back to our old ways. We'll see how it goes. Please also keep in mind, this does not mean 0.19 is coming now. It's coming sooner than initially planned, but as always, there are no release dates. That's about it for now. Cheers Small update: I've answered this on a comment, but it got buried somewhere down in there. A lot of people have voiced concerns about more frequent saves implying more frequent compatiblity breaks. Here's an answer: You don't have to worry about that. On most updates, there are only one or two features among the lot that require us to break backward-compatibility. With smaller, more frequent updates, we'd always make sure to group together potentially save-breaking features, to minimize the frequency of save wipes as much as possible. The features we're implementing for 0.19 are all backwards-compatible with 0.18 saves. Cheers

This article is in no way affiliated with the TV show Mythbusters. Over the past few months, I've noticed there is a large amount of misinformation and generally incorrect statements being passed off as fact around the KSP community, so I thought I'd take this opportunity to set some of those things straight, and have these 'myths' about KSP properly explained. I don't mean to point any fingers about how these things got started... These tales have a way of growing in the telling, so it's likely no one's fault actually... Just things that never got properly explained, and grew more and more inaccurate over time. So, let's get started here. Time to debunk some myths about KSP: Myth #1: Unity and Multiple Cores. The Myth: People have been tossing around the 'fact' that Unity (and KSP) is stuck on a single CPU core. I've heard several variations of this, with varying degrees of inaccuracy. I've also heard claims that the performance improvements from the port to Unity 4 are because it's added multi-threading, or something like that. The Truth: Unity has always used multiple threads (and therefore multiple cores) as far as we've been developing KSP. However, what Unity doesn't allow us to do, is write game code outside the main game thread. That is, we can spawn threads by code if we want, but Unity won't let you call any of its own methods or use its classes on those other threads. This means game scripts are all running on one thread (and a single core, yes), but it does not mean Unity is using a single core. Unity, as of version 3.5, has all of the CPU-side of the rendering work (the processes that happen before the frame is sent to be drawn on the GPU) happening on another thread. Other systems, such as particle FX, mesh skinning, sounds and some other stuff, are also handled on other threads. As for Unity 4, it didn't implement any new features regarding multi-threading. It did bring a number of performance optimizations to the engine itself, which in turn make KSP run faster and smoother. More specifically, on Windows, it implemented SSE2 instructions for some Physics operations (OSX already had that). Conclusion: Busted. Sources: http://unity3d.com/unity/whats-new/unity-4.0 (unity 4 changelog) Myth #2: N-Body Physics The Myth: Legend goes that the reason KSP has no multiple-body gravity simulation is because of some technical limitation on our or Unity's end. That limitation prevents us from being able to simulate perturbations from other gravity sources and Lagrangian points. The Truth: This is false. KSP only supporting a single gravity source at any time is a decision we made deliberately here. Yep, it's not a bug, it's not an incomplete feature, it's meant to be like this by design. This "limitation" is what makes many of the things you see in the game possible, or at least usable... Let me try and explain it: The usual way games simulate physics is by a process called Integration. This process works basically like this: To know the position and velocity of an object, you take the position and velocity that object had on the previous frame, add in all the forces currently acting on it (using the object's mass to calculate the acceleration from those forces), add that to the current velocity, and move the object by however much it would move going at that speed in the time that elapses between each frame. That means the state of an object at any point in time is only known if you know its state at the previous point in time, and the same goes for that point in time, and for the one before it, and so on.... So, to figure out the state of the solar system at any point in time, you need to start at a known starting point, and run the simulation forward until you get to that point. Sounds ok, until you have to warp time. If you start making time run faster, you can do one of two things: One, start simulating faster, so we keep up with the clock, or assume each frame spans a longer amount of time, and just move objects forward by the new amount of time. With the first method, it obviously becomes apparent that the computer will have to start working overtime if you want to catch up. If you warp time to 5x, that's 5 times more calculations it would have to do in the same amount of time... not good. Now, imagine warping time at a hundred thousand times the normal rate. Quite impractical. The second method won't melt your CPU down as much, but it's also problematic. Imagine you're orbiting Kerbin. At 1x, integration is perfectly ok. But what happens when time is running so fast, you cover half your orbit in a split-second? What happens then is that you never really calculated all that way you went around the planet, and now all of a sudden you're meant to be moving completely the other way around... That's not doable if all you know is that one frame earlier, you were at a particular position with a particular velocity, and a gravity was pulling towards some general direction.... You just don't have enough precision to simulate the physics at that rate, and then weird things start happening, like orbits shooting out of the solar system, of things mysteriously smashing into other things... It's not pretty. So, what we do here is something completely different. If your physics system consists of a single gravity source and objects orbiting it, then there are equations you can use that will tell you your position, at any given time. This is called the 2-body problem, and it basically means we can just ask the game "where will I be on Year 1, Day 42, at 2:42pm", and it will tell us the answer with absolute precision. This is what's known as a 'deterministic system'. At any point, the state of the system is known, or rather, can be calculated. We decided to use this method in KSP, because it adds more things than the restrictions it imposes take away. Sure, we lose the ability to simulate Lagrange points, or orbital decay due to perturbations from a moon or something, but we gain a lot. We gain being able to save the game and advance time without having to run the simulation. We gain being able to predict (and get it right) where your current trajectory will take you, and we also get to do fun stuff like turn off normal physics entirely, and let ships coast "on-rails", indefinitely, and with total stability. Long story short, this system is what makes things like Patched Conics, Time Warp, Flight Planning and multiple vessels possible. And to be perfectly honest, orbital perturbations really aren't a lot of fun... most of the time they just push you away from the predicted path, and just make things generally more frustrating. Conclusion: Busted.

Hi again! Now that the demo is out, it wouldn't do to have a demo that's actually a later version than the full game, would it? So we're now releasing the 0.18.4 patch. This patch is a small revision to the game, mainly focusing on porting KSP to the much more awesome Unity4 engine. It also has several bug fixes, and a new stock spaceplane, the Ravenspear Mk4. Here's the complete Changelog: ==================================== v0.18.4 RC3Bug Fixes and Tweaks:* Fixed the latest version checking.* Fixed some places that were using an old and inaccurate value for the vessel's G-force, preventing entering warp sometimes.* Fixed an issue which caused DAE model loading to fail.==================================== v0.18.4 RC2Bug Fixes and Tweaks:* Fixed an issue where controls could become locked when switching focus out of a dead uncontrollable vessel.* Fixed a collision issue with the large RCS Tank.* Fixed a transparency issue with smoke FX and explosions.* Boarding a vessel from EVA no longer toggles the SAS on the vessel.* The VAB and SPH now show decoupler ejection forces on the part stats.* Fixed a few typos on part descriptions and tutorials.* Increased Jool's rotating frame threshold altitude to prevent entering its atmosphere with the rotating frame disabled.* Fixed an issue with the UI background not scaling correctly on the SPH.* Fixed winglet colliders.* Fixed EVA light orientations.* Updated Copyright dates.* Fixed vab transparency issue.* Fixed Explosion Shader Transparency issues.* Fixed Part Actions being clickable if Time Warp was engaged while the Action UI was already up.==================================== v0.18.4 RC1New:* Ported the game over to Unity 4. Expect improved performance.* Added a new stock spaceplane: The Ravenspear Mk4.Bug Fixes and Tweaks:* Fixed some buttons not being locked out properly on the Tracking Station and possibly other scenes.* The Staging Stack now automatically scrolls back into view if a staging operation sends it off screen.* Stage groups and icons now accurately follow the mouse when dragging.* Fixed some UI controls and keys being responsive during pause.* Fixed some sounds (mainly voices) being affected by 3D effects when they shouldn't.* Fixed an issue when going in and out of Map View after crashing the ship.* Fixed the EVA map icons not showing.* Fixed the planetary terrain not starting up properly sometimes.* Fixed the error messages when exiting the game from the flight scene.* Added a bad name filter for the Kerbal name generator.* Fixed issues with the popup dialogs that allowed them to spawn a massive number of duplicates.* Parts on the parts list no longer show the author on their tooltips (that broke immersion).* Flight basics tutorial now requires player to set throttle to max before finishing the tutorial (and launching).* fixed the non-persistent StateName field on MunFlight Tutorial. Since our new patcher isn't ready yet, we're releasing this one as a full download from our Store. We're not using the old patcher anymore, so don't try to get this patch using it (not a challenge. you'd probably just get an error, or worse, break your install). This patch shouldn't break compatiblity. Saves and vessels from 0.18.2 should all be compatible with this build (No guarantee on saves from earlier versions than that though). Happy Launchings! Cheers

It's been a little over a year since we released the last of the free-version updates, and made that our demo. However, a lot has happened in that year, and I think everyone will agree that KSP isn't the same game as it was back then. And version 0.13.3 isn't a good sample anymore of what KSP is today. So, with that in mind, we decided it was about time we got out a new demo, so new players can get a better sense of what KSP is all about, and hopefully buy the full version afterwards. This new demo is based on KSP 0.18.2, so it has all the newer systems, with several restrictions, of course. Here are the main differences: * Saves are limited to a single demo profile, plus a few scenarios and tutorials. * Part Loading is limited to the 25 Stock ones included. * Plugin loading is disabled. * Kerbin, the Mun and the Sun are the only celestial bodies. * The Spaceplane Hangar and Runway facilities are inaccessible. * You can only launch three simultaneous missions before being required to end flights to launch another. We've revised the tutorials and scenarios so they work with the demo parts set. We've also included two demo-compatible stock rockets. The new demo is also compiled in Unity 4, so it should have much smoother performance. We will soon release the 18.4 patch (18.3 is the demo), which brings the full version over to unity 4 as well. You can get the new demo at our Download page. Happy Launchings! Cheers

Up until now, we've been using SVN for version control. SVN is ok, but 'ok' isn't quite good enough.... Git on the other hand, is awesome. If you're not a developer or version control enthusiast, here's the backstory: Git and SVN are version control systems. They allow multiple developers to work together over a single project, letting us manage revisions, commit changes, and generally work over the same files without making a huge mess of things. We've used SVN on KSP so far, and SVN, while simple to use, has some limitations that can turn into big issues as the project becomes larger and more people start working on it. For instance, in SVN, everyone commits changes to the same repository, which means if I change a piece of code that creates a gamebreaking bug and commit that, everyone's game will break as well. That led us to have to impose rules regarding who can commit and when, to prevent someone committing a gamebreaking bug as the game is under experimental testing, and other such stupidities that come from working with a limited system. We called that "Feature-Lock". While in Feature-Lock, no one was allowed to commit any changes unless they were bugfixes to the current experimental version. That worked to prevent gamebreaking commits during release times, but it also meant that people who didn't have bugs to fix were restricted from working properly until release time was over... And then their copies would have a huge amount of uncommitted changes to push, and merging all that would be a big problem. Now, Git is a much more elegant and sophisticated version control system. Unlike SVN, there is no single central repository that receives changes from all users. Git excels at something called 'branching'. Branching allows someone to work on something, and keep version control of it, without affecting the main version (the 'trunk') for everyone else. SVN has branches too, but in SVN, creating (and later merging) branches is a complicated and failure-prone task. Git on the other hand, can do this: This ease to create and merge branches allows us to create branches for each feature. The idea is that every feature we work on, be it a new set of parts, or a new feature to the VAB and SPH, wouldn't exist on the 'trunk' (or "master" in Git) until it is stable enough to be added to the project without creating game-breaking issues. Each feature would live on its own branch, and the master copy would always be kept at a stable state. This means features become very modular. They don't exist on the release version until they're ready to go, which means if a feature doesn't make it in time for a release, we don't need to do anything to remove or hide the incomplete implementation. We just don't merge the feature branch into the release branch. It also removes the need for Feature-Lock. When we go into experimentals, we can simply create a new experimental branch, which would only get bugfix commits. Any features that don't make it in won't affect that branch, and they in turn can get the bugfixes implemented for the experimental. Now that we have some room to breathe again, after the madness that was the 0.18 release timeframe, we set aside some time to do the transition. We had to re-upload the entire project to the new git repo we created on GitHub (it's a private one, we haven't gone open-source)... That took a while, since the KSP project is many GBs now, and we had to reconfigure our build pipeline to use the new Git repo instead of the old SVN one. Took some doing, but it's definitely worth it. So, what does all this mean for the average KSP player? Well, at first, not much, other than the knowledge that your favorite dev team now has a much better workflow and doesn't have to worry about one dev's work breaking the game for everyone else. In time though, this improved workflow might very well translate into faster development times for features, meaning more features on each update, and less trouble with half-implemented features, meaning less bugs as well. That's about it... Just wanted to share the news with everyone. Cheers

Hi, Continuing on the last article, where I explained how to set up a ScenarioModule to run your own logic on a scene, without requiring a part on your vessel, here's another short guide. This one about writing your own tutorials: Tutorials are nothing more than specialized ScenarioModules. To make writing tutorials as simple as possible, we created a TutorialScenario base class, which handles the basic systems for the tutorial, like managing the instructor dialog and the page flow, so you can focus on the content itself. So to get started, here is a simple tutorial implementation. I'll explain what each bit does as we go: using System.Collections; using UnityEngine; // Tutorials extend TutorialScenario (which in turn extends ScenarioModule). public class TutorialDemo : TutorialScenario { TutorialPage defaultPage1, defaultPage2, defaultPage3, specialPage1; KFSMEvent onSomethingUnplanned, onTutorialRestart; KFSMTimedEvent onStayTooLongOnPage1; protected override void OnAssetSetup() { instructorPrefabName = "Instructor_Gene"; } protected override void OnTutorialSetup() { // start up a default tutorial demo defaultPage1 = new TutorialPage("default page 1"); defaultPage1.windowTitle = "Tutorial Window"; defaultPage1.OnEnter = (KFSMState st) => { instructor.StopRepeatingEmote(); }; defaultPage1.OnDrawContent = () => { GUILayout.Label("This is a demo tutorial to test out the tutorial scenario features." + " Press Next to go to the next page, or wait " + (10 - Tutorial.TimeAtCurrentState).ToString("0") + " seconds." , GUILayout.ExpandHeight(true)); if (GUILayout.Button("Next")) Tutorial.GoToNextPage(); }; Tutorial.AddPage(defaultPage1); defaultPage2 = new TutorialPage("default page 2"); defaultPage2.windowTitle = "Tutorial Window (continued)"; defaultPage2.OnEnter = (KFSMState st) => { instructor.PlayEmoteRepeating(instructor.anim_idle_lookAround, 5f); }; defaultPage2.OnDrawContent = () => { GUILayout.Label("This second page is only here to test the state progression system." + " Tutorial pages can be stepped forward, and also stepped back.", GUILayout.ExpandHeight(true)); GUILayout.BeginHorizontal(); if (GUILayout.Button("Back")) Tutorial.GoToLastPage(); if (GUILayout.Button("Next")) Tutorial.GoToNextPage(); GUILayout.EndHorizontal(); }; Tutorial.AddPage(defaultPage2); defaultPage3 = new TutorialPage("default page 3"); defaultPage3.windowTitle = "Tutorial Window (last one)"; defaultPage3.OnEnter = (KFSMState st) => { instructor.PlayEmoteRepeating(instructor.anim_true_nodA, 5f); }; defaultPage3.OnDrawContent = () => { GUILayout.Label("This third page is also only here to test the state progression system." + " It's very much like the previous one, but it has a button to restart the tutorial.", GUILayout.ExpandHeight(true)); GUILayout.BeginHorizontal(); if (GUILayout.Button("Back")) Tutorial.GoToLastPage(); if (GUILayout.Button("Restart")) Tutorial.RunEvent(onTutorialRestart); GUILayout.EndHorizontal(); }; Tutorial.AddPage(defaultPage3); specialPage1 = new TutorialPage("special page 1"); specialPage1.OnEnter = (KFSMState lastSt) => { specialPage1.windowTitle = "Tutorial Window (from " + lastSt.name + ")"; specialPage1.onAdvanceConditionMet.GoToStateOnEvent = lastSt; instructor.PlayEmote(instructor.anim_true_thumbsUp); }; specialPage1.OnDrawContent = () => { GUILayout.Label("This Page shows that it's possible to use external events to send the tutorial to" + " any arbitrary state, even ones not in the default sequence. Use this to handle cases where the" + " player strays off the plan.\n\nNote that this page is added with AddState instead of AddPage," + " because we don't want this page to be part of the normal tutorial sequence.", GUILayout.ExpandHeight(true)); if (GUILayout.Button("Yep")) { Tutorial.RunEvent(specialPage1.onAdvanceConditionMet); } }; specialPage1.OnLeave = (KFSMState st) => { instructor.PlayEmote(instructor.anim_idle_sigh); }; Tutorial.AddState(specialPage1); onTutorialRestart = new KFSMEvent("Tutorial Restarted"); onTutorialRestart.updateMode = KFSMUpdateMode.MANUAL_TRIGGER; onTutorialRestart.GoToStateOnEvent = defaultPage1; Tutorial.AddEvent(onTutorialRestart, defaultPage3); onSomethingUnplanned = new KFSMEvent("Something Unplanned"); onSomethingUnplanned.updateMode = KFSMUpdateMode.MANUAL_TRIGGER; onSomethingUnplanned.GoToStateOnEvent = specialPage1; Tutorial.AddEventExcluding(onSomethingUnplanned, specialPage1); onStayTooLongOnPage1 = new KFSMTimedEvent("Too Long at Page 1", 10.0); onStayTooLongOnPage1.GoToStateOnEvent = specialPage1; Tutorial.AddEvent(onStayTooLongOnPage1, defaultPage1); Tutorial.StartTutorial(defaultPage1); } // this method would be called by some external component... public void SomethingUnplanned() { if (Tutorial.Started) { Tutorial.RunEvent(onSomethingUnplanned); } } } Yes, quite a bit of code I know, but we'll take in parts. The First thing you see on the class there are declarations of TutorialPage objects and some KFSMEvents. That is the basis of the tutorial system. The tutorial flow is managed by a state machine, which is based off the same one that the Kerbal EVA controller uses. It is based around the concept of States and Events. States hold the code that gets run when that state is active, and Events are used to move from one state to another. The TutorialScenario has a built-in tutorial FSM called Tutorial, as you can see above. In the OnTutorialSetup method, you create the tutorial pages and the events that will change them, add it all into the Tutorial solver, and start it. Before we get more in-depth about that, let's look at that OnAssetsSetup method. That method is called on Start, before anything else can run, to allow you to define your assets to use in the tutorial. The demo above only sets the intructor to be Gene instead of Wernher (who is the default), but as you will see on the other examples later, that method is also used to load or grab references to other assets that might be necessary. Back to the tutorial setup then, let's look at a page definition again: defaultPage2 = new TutorialPage("default page 2"); defaultPage2.windowTitle = "Tutorial Window (continued)"; defaultPage2.OnEnter = (KFSMState st) => { instructor.PlayEmoteRepeating(instructor.anim_idle_lookAround, 5f); }; defaultPage2.OnDrawContent = () => { GUILayout.Label("This second page is only here to test the state progression system." + " Tutorial pages can be stepped forward, and also stepped back.", GUILayout.ExpandHeight(true)); GUILayout.BeginHorizontal(); if (GUILayout.Button("Back")) Tutorial.GoToLastPage(); if (GUILayout.Button("Next")) Tutorial.GoToNextPage(); GUILayout.EndHorizontal(); }; Tutorial.AddPage(defaultPage2); TutorialPages are states in the tutorial state machine. They have a number of callback that get called as the tutorial progresses, in which you can add your own code. This demo uses a coding style known as lambda expressions to assign logic to each callback , without having to write methods somewhere else in the code. This is just to keep it all in one place, and you can do it the conventional way if you prefer. So, here's what each callback means. Note that you don't really need to assign a method to every one of them. They all default to an empty method, so it's safe to omit the ones you don't need. TutorialPage.OnEnter(KFSMState st) gets called once when the page becomes the active one. The 'st' parameter is a reference to the last state before this one. TutorialPage.OnUpdate() gets called repeatedly (from Update), to let you run your update logic for the state. TutorialPage.OnFixedUpdate() gets called repeatedly (from FixedUpdate), to let you run your fixed update logic for the state. TutorialPage.OnLateUpdate() gets called repeatedly (from LateUpdate), to let you run your late update logic for the state. TutorialPage.OnDrawContent() gets called repeatedly (from OnGUI) to let you draw your GUI content using Unity's GUI classes. TutorialPage.OnLeave(KFSMState st) gets called once when the tutorial is about to move to a new page. The 'st' parameter is a reference to that next state. TutorialPage.GoToNextPage() call this to make the tutorial go to the next state. Pages are sequenced by the order in which they get added. TutorialPage.GoToPrevPage() same as above, only goes back to the previous page. TutorialPage.SetAdvanceCondition(KFSMEventCondition c) Use this to set a condition which will be evaluated repeatedly to advance to the next step when the condition is met. This is just a convenience method to reduce repeated code. It's the same as checking for the same condition on one of the state update events and manually calling GoToNextPage. After your page is all set up, you add it to the tutorial sequence with Tutorial.AddPage(yourPage). Events can be used along with tutorial pages, to manage situations where the player strays from the plan. Events come in two forms: KFSMEvents and KFSMTimedEvents. KFSMEvents are similar to states (and pages) in some ways. They also have callbacks that get called at specific times. They also have a GoToStateOnEvent value, which holds a reference to the state you want to transition to after the event is triggered. Events are defined independently so when you add them, you can assign them to any combination of states. If you've ever seen an FSM diagram, the analogy becomes simple. States are the nodes, and Events are the arrows that connect each node. On the demo above, we have a TimedEvent assigned to run on page 1 of the tutorial. It's set to go off after ten seconds, and take you to a special page. You'll notice that this special page isn't a TutorialPage object, but a KFSMState. That's fine, since TutorialPage is just an extension of KFSMState. Adding a state that isn't a page to the tutorial is perfectly possible. Also notice that the special page is added by calling Tutorial.AddState instead of AddPage. This lets the tutorial know that this page isn't part of the standard sequence, so it doesn't get in the way of the normal flow when calling GoToNextPage, for instance. That's about it for how tutorials work. However, the demo above doesn't really show the more hands-on practices of writing a proper tutorial, so I'm also attaching here the source code for the Orbiting 101 tutorial, in full. That should hopefully be a good example of how a tutorial can be written using this system (I recommend turning word wrap on to read the Orbit101 code). Happy coding! Cheers PS: The attachment manager thingy decided to not let me upload a .cs file directly, so I changed the extension to .txt - Just change it back to .cs to open it as a normal code file.

It ocurred to me that there is little to no documentation at this point about the new ScenarioModules and how to add them to your game. With that in mind, I've written this brief guide as to how they are used. I'm assuming you already have some experience writing PartModules, in which case it should be relatively straightforward to learn how ScenarioModules operate. If not, I strongly suggest reading through the available PartModule coding tutorials and (admittedly very incomplete) documentation first. Let's get started then: Scenario Modules, just like PartModules, are compiled into dlls that go in the Plugins folder. In fact, nothing stops you from having ScenarioModules sharing dlls with PartModules. The dlls in Plugins simply add their classes to the game assembly. Once added, a ScenarioModule is loaded into the game through SFS files. In very much the same way you set up a PartModule in a part.cfg, you set up a ScenarioModule in an .sfs file: GAME { version = 0.17.0 Title = Orbiting 101 Description = This training scenario covers the basics of flying a blablabla.... // mode 0: Sandbox - mode 1: Career (not available yet), mode 2: Scenario, mode 3: Non-Resumable Scenario Mode = 3 // scene to load when starting this save. scene = 7 PARAMETERS { // flight parameter stuff } FLIGHTSTATE { // flight state data (in 0.16 this was your entire sfs file) } SCENARIO { // the name of the ScenarioModule class to spawn name = TutorialOrbit101 // the scene in which the module gets spawned (7 = flight) scene = 7 } } The only limitation at the moment is that to add a scenario module to your ongoing sandbox game, you'll need to manually add the module config to your persistent.sfs. Once added, it gets loaded into the persistence data structure and will remain in your sfs file even as it gets resaved and rewritten. ScenarioModules have one main difference from PartModules though. Because they are made to run on any scene, you must specify a target scene in which your module will run. Currently, modules can only run on one scene at a time. When a scene starts, the scenario module runner attaches all ScenarioModules that target that scene as a MonoBehaviour on an empty game object in the scene. You can use all MonoBehaviour events (except Awake), and code it in very much the same way you code part modules... Of course, there is no reference to vessel or part, since the module isn't attached to one. Hope this helps. Cheers