Search the Community

Showing results for tags 'tutorial'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General
    • Announcements
    • The Daily Kerbal
  • Kerbal Space Program 2
    • KSP 2 Discussion
  • General KSP
    • KSP Discussion
    • Suggestions & Development Discussion
    • Challenges & Mission ideas
    • The Spacecraft Exchange
    • KSP Fan Works
  • Gameplay and Technical Support
    • Gameplay Questions and Tutorials
    • Technical Support (PC, unmodded installs)
    • Technical Support (PC, modded installs)
    • Technical Support (PlayStation 4, XBox One)
  • Add-ons
    • Add-on Discussions
    • Add-on Releases
    • Add-on Development
  • Community
    • Welcome Aboard
    • Science & Spaceflight
    • Kerbal Network
    • The Lounge
  • Making History Expansion
    • Making History Missions
    • Making History Discussion
    • Making History Support
  • Breaking Ground Expansion
    • Breaking Ground Discussion
    • Breaking Ground Support
  • International
    • International
  • KerbalEDU Forums
    • KerbalEDU
    • KerbalEDU Website

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Skype


Twitter


Location


Interests

Found 121 results

  1. A forum user, @Murdabenne requested that I share how to do an adoption of a mod. So, last week I showed an adoption while on Twitch Stream, and have finished writing up the steps here. The video is available at the end of the OP. These instructions and the files are available on Github: https://github.com/linuxgurugamer/KSP-Build-Scripts/ They are all licensed using the GPLv3 This process has evolved over time; the first mods I adopted didn't use these, and each one was a customized setup. As time went on I developed this process, with the following goals in mind: Consistency Repeatability Ease of setup Easy to follow While not perfect, they do the job for me. Occasionally I run into a mod which has an odd layout or setup, which can usually be dealt with by rearranging folders, or some other minor changes. This discussion will not be going into any issues about coding or bug fixing,etc. These scripts are based on the following directory layout: modmaindir |-> GameData |-> ModDir |-> Plugins |-> Sourcedir The GameData should contain all files needed for a release Abbreviations used VS - Visual Studio IDE - Integrated Development Environment Overview and Dependencies These scripts are based on the following directory layout: modmaindir |-> GameData |-> ModDir |-> Plugins |-> Sourcedir The GameData should contain all files needed for a release Overview and Dependencies Dependencies These instructions are based on using Microsoft Visual Studio 2017 Community version, available here: https://www.visualstudio.com/free-developer-offers/ The 7Zip packaging program is required for the final packaging, available here: http://www.7-zip.org/ The JQ program is required to parse the JSON version file, available here: https://stedolan.github.io/jq/download/ Overview Part of the process involves adding a file, AssemblyVersion.tt, to the codebase. This file is called a "Text Template", and is used to create the AssemblyVersion value which is then stored in the final DLL There are two batch files, deploy.bat and buildRelease.bat. The "deploy.bat" used to copy the DLL to the GameData directory, and then to copy the complete release to a test install. The "buildRelease.bat" is used to create the final zip file for release While the packaging program can be changed to an alternative (with appropriate changes to the "buildRelease.bat" file, the JQ program is required and not replacable. The assumption is also made that the mod is downloaded and ready to be worked on. Instructions 1. Create the GameData folder if it doesn't exist If it doesn't exist, then copy the latest release of the mod into the GameData folder 2. Find the .version file (if it exists) and copy it to the top level directory. If it doesn't have a .version file, create one in the top level directory 3. You can either copy the AssemblyVersion.tt to the main mod folder, or create a new TextTemplate in the project (using MS Studio) and do a copy/paste operation. If you copy it over, you will need to add the file to the project in the IDE 4. Edit the AssemblyVersion.tt file, update the following line: string versionfile = @"CompletePathTo.version"; Replace the "CompletePathTo.version" with the path to the .version file. 5. Remove or comment out the following line from the file AssemblyInfo.cs (usually located in the "Properties" folder inside your C# project): [assembly: AssemblyVersion("1.0.0.0")] 6. If there are any Pre-build steps in VS, copy them to a save place and delete them. 7. If there are an Post-build steps in VS, copy them as well 8. Add the following to the Pre-build event command line. This line is based on using Visual Studio 2017, installed on the X drive: set textTemplatingPath="%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Community\Common7\IDE\texttransform.exe" %textTemplatingPath% "$(ProjectDir)AssemblyVersion.tt" 0. Copy the two files, deploy.bat and buildRelease.bat to the main mod folder 10. You need to update the deploy.bat and the buildRelease.bat with the following values: H to point to your test KSP install: set H=R:\KSP_1.3.1_dev GAMEDIR to the name of the mod folder: set GAMEDIR=xxxxx GAMEDATA to point to the GameData folder: GAMEDATA="GameData" VERSIONFILE to the name of the .version file: VERSIONFILE=%GAMEDIR%.version In most cases, the VERSIONFILE is built from the GAMEDIR, but some mods use a different name 11. For the buildRelease.bat, you have to update the following as well: If existing, LICENSE to the license file: set LICENSE=License.txt If existing, README to the Readme file: README=ReadMe.md Set RELEASEDIR to where you want the zip file: RELEASEDIR=d:\Users\jbb\release 12. If you want to use a different program than 7z, change it in the next line. If you do, you will have to change the options to the zip program at the end of the file: set ZIP="c:\Program Files\7-zip\7z.exe" 13. In the IDE, right-click on the Solution in the Solution Explorer, and select "Add -> New Solution Folder", give the folder a name SolutionItems 14. Right-click on the SolutionItems folder, and select Add -> Existing item..., add the two files just copied and the .version file 15. Add the following to the Post-build event command line, replace the "xxxxx" with the complete path to the top level directory of the mod: start /D xxxxx /WAIT deploy.bat $(TargetDir) $(TargetFileName) if $(ConfigurationName) == Release ( start /D xxxxx /WAIT buildRelease.bat $(TargetDir) $(TargetFileName) ) 16. Make sure the .version file has the correct values. 17. Now, set the Visual Studio configuration to Debug, and do a test compile. 18. If all is correct, it will compile the code, copy the DLL to the destination folder, and then copy the complete release to your test KSP installation 19. Finally, change the VS config to "Release" and rebuild the mod. This time it will add the step to pack up the entire release and leave it in the RELEASEDIR I did an online stream when I used most of this to adopt a small mod, you can watch it here:
  2. I'm playing on ps4. When I do the 3rd tutorial, Intermediate Construction, the game gets stuck as soon as I enter the VAB. Wernher Von says enter VAB. So I enter the VAB. Then once inside he tells me about all the wonderful things we'll be building so, I hit the X button for the next screen. The screen blinks, it says "saving..." in the top right corner but nothing else. I can keep hitting X and it's just more of the same, blink, saving... nothing. I shut down the console, reinstalled the game, nothing works... please help.
  3. Newer versions of KSP support Unity’s updated UI system (technically available since KSP 1.0, but only really practical since 1.1), which is a major improvement over the old OnGUI system. Rather than rebuilding the UI every frame using the esoteric GUILayout and GUI system, the new Unity UI is built using standard Unity objects and hierarchies. This significantly improves performance, reduces the garbage created, and allows for some fancy effects that weren’t practical with OnGUI. The only problem is that building the new UI entirely through code is extremely tricky, to the point of being impractical in all but the simplest cases. So there are basically two options for using the new UI. One is built into KSP and is perfect for creating relatively simple windows that don’t require much customization. This is the PopupDialog system, it uses notations similar to the old GUILayout system, but generates a new Unity UI object. There is a thread with more details on PopupDialogs and some examples. The other option is to build your UI in the Unity editor, export it as an AssetBundle, and load it into KSP. There are also two options for how to handle this. You can create the UI in Unity without importing any assemblies into the Unity editor. When you load this UI into KSP you will need to manually hook up all of the elements through code. Things like the function called by a button, or the string of a text element will all have to be manually assigned. This is OK for simpler UIs, but can become prohibitively tedious for more complex UIs. Sarbian’s GC Monitor is an example of this type of UI. For a more complex UI it can be simpler to import an assembly directly into the Unity editor, allowing you to set button, or toggle listeners, and to store references to UI elements where needed. The only problem here is that you cannot import an assembly that refers to KSP’s Assembly-CSharp.dll, the primary KSP assembly. This means that any mod using a Unity UI will need two assemblies, one to handle the KSP side of things, and another that can be imported into Unity and will handle the UI side of things. The KSP assembly can keep a reference to the UI assembly, but the UI assembly can’t refer to the KSP assembly, since that will refer to Assembly-CSharp. This means that communication between the two assemblies will be difficult. But before we get to that we can go over some of the basics of Unity UI creation (generic UI creation is also broadly similar to KSPedia creation, which is covered in its own tutorial). I won’t go into too much detail, since there are a number of very thorough tutorials and examples available. Check out some of these; pay particular attention to the RectTransform as that is the core positioning component of all UI elements, and it can be quite tricky to get a handle on. Using Basic Orbit as an example project we’ll go over several different areas of UI creation, starting with making a simple, static window, one that can’t be re-sized and has a fixed amount of UI elements. I’ll be using the same formatting as in the KSPedia tutorial, with Unity Editor screen elements Bolded and UI objects and elements Bolded and Italicized. The code for Basic Orbit is available on GitHub. Much of the methods used here come from Kerbal Engineer Redux (which uses the Unity UI only for its toolbar button), its source and Unity project can be found on its GitHub page. This is the window we’ll be creating and hooking up to KSP today. It controls the visibility and some options for other screen objects. Section 1: Software and Tools: Required: Unity – Current KSP version (1.4.3) is using Unity 2017.1.3p1 KSP Part Tools – The current package includes what is needed for generating Asset Bundles and the legacy Part Tools files It should be noted that anyone familiar with Unity who can write their own asset bundle script doesn't need to worry about the Part Tools, just write the script for building an asset bundle and you can use the version of Unity that matches KSP If you do so make sure that any scripts you add to the project are placed in a folder called Editor somewhere within your Unity project's Assets folder To start with we need a new Unity project (I’m using Unity 5.2.4f1, since this is the version supported by the KSP Part Tools - KSP 1.4.x uses Unity 2017, but earlier versions should still work). I would suggest making a separate project folder for each UI, you can create a new project in the Unity startup window, you can then copy the KSP Part Tools files into that project’s Asset folder, or just import them into Unity in the normal way. We only need the Part Tools for the Asset Compiler function, which we’ll get to later. Unity Project Setup: The first step is to install Unity and add the Part Tools package. Once Unity is installed open it and create a project for KSP (there are probably other tutorials that cover setting up Unity in more detail; that isn’t really covered here). Go to the Assets Tab along the top -> Import Package -> Custom Package -> Select the PartTools_AssetBundles.unitypackage file This will load all of the bits necessary for KSPedia creation Now you want a new scene; the Hierarchy Window should only have the Camera, which we want because it allows us to view the UI as it will be in-game In the Main Window you’ll want to be in the #Scene Tab, in 2D mode, using regular Shaded mode Section 2: Creating the UI: All Unity UI windows must be the child of a Canvas element, so we’ll need to add one here. In general, we don’t need to export this Canvas, since our UI can be added directly to one of KSP’s Canvases, but we need it in the editor to actually see anything we create. Add a Canvas: GameObject Tab -> UI -> Canvas This adds the Canvas element and the EventSystem The default properties should be fine, you’ll want to set Pixel Perfect on, since most KSP canvas’ seem to use this, it simply makes sure that all UI elements are snapped to pixel edges Render Mode should be on Screen Space – Overlay, this is for basic UI styles, a simple window on the screen To this Canvas we then add a Panel: Right-click on the Canvas -> UI sub-folder -> Panel The Panel is the basic window object, this is where we add buttons, labels, images, and so on The Panel has a RectTransform, a Canvas Renderer, and an Image element The RectTransform controls the window size and position The Canvas Renderer is a required component for any UI element that will actually be drawn on-screen The Image is the window background image By default, the Panel is the same size as the Canvas and uses the Stretch Anchor, meaning it will always stretch to the size of the Canvas, we obviously don’t want this Click on the Anchor image (the blue arrows, or red lines) in the RectTransform element and select the Middle-Center Option, with red lines crossing in the center You may end up wanting the Anchor to be Top-Left and the Pivot to be 0, 1, but you can leave them as they are for now This will set the Anchor to the center of the Panel, and will change the available RectTransform Fields, we can now directly set the size of the Panel, and they will be fixed Once we set the Panel size it will look like this: The Pivot (blue circle) and Anchor (white arrows) are in the center and the borders are marked in the corners with the blue dots Adding Elements to the Window: We’ll go over the background images used for the window, and more complex anchoring and pivot functions later, but for now, we can start adding the UI elements to this simple window. Basic UI elements can be added by right-clicking on any object in the Hierarchy Window and selecting a UI object The Add Component button can be used to add those same elements, or any other Unity object or script To start with we’ll add a few Text labels and some Toggles that look like buttons For Text elements just right-click the Panel and select a Text object under the UI tab To position the element we can drag it to the desired location, it should snap to the center line The width and height can be changed by dragging the edges, or by changing their values in the RectTransform properties Dragging the edges will make the element un-centered, whereas editing the height and width in the RectTransform will adjust the element’s size based on its pivot position (centered by default) Since this window is fixed we don’t need to worry about the anchor position, but if you want to make sure that an element stays at the top of the window you can change the anchor to Top-Center, or Top-Right if you want it stay in that corner, this can help when making a UI if you are frequently adjusting the window size For fixed Text elements we can just type in the Text Field whatever we want, for dynamic elements (which are set by something in-game) we’ll cover them later The Text properties: size, style, alignment, color, etc… can all be adjusted in the Text element’s properties A quick note about hierarchy and draw order here: Elements lower in the hierarchy are always drawn above higher elements This means that child elements are drawn over their parents, and siblings are drawn in order from last to first, with last on top Now to add some Toggle Buttons, since this a group of three related Toggles we can put them all under one parent object Right-Click on the Panel and select Create Empty, this will add a simple RectTransform with no UI elements We can adjust its position, size and anchor so that it can hold the Toggles and be fixed relative to the top of the window Now add a Toggle element directly to the new empty object (all Unity objects can be renamed by double-clicking on the in the Hierarchy window) Unity doesn’t have native Toggle Buttons, so the element created here is a standard toggle with a label and checkbox We can adjust these elements to work as a Toggle Button just by changing their size and positions (and some code that we’ll get to later) We need to go from this: To this (yes it looks odd, but we’ll get to specifics in a bit): Creating a Toggle Button and Adjusting the RectTransform: To make what we need we basically only have to adjust the RectTransform component for each UI element in the Toggle element. The Toggle itself is made up of a Toggle Script, which controls actually activating and deactivating it, the Background Image, which by default is the empty checkbox, the Checkmark Image, which is only shown when the Toggle is put into the “on” state, and a Text Label. We want this Toggle to look like a standard KSP button, so the images should fill the entire object and the text should be centered The Background Image will be set to standard KSP button styles (the regular button, a brighter button for when the mouse is over the element, and a darker button for when the mouse is actually clicking on it) and the Checkmark Image will be set to the darker, pressed KSP button; since the Checkmark Image is drawn over the Background Image, it will hide the standard button images when the Toggle is on To do this we need to adjust the Background and Checkmark Image RectTransforms to fill the entire object We set the Anchor to Stretch-Stretch (four blue arrows), this will make the element stretch to fit the size of its parent, it also replaces the size and position fields with offsets, so if we want an element to stretch with its parent, but always have 10 pixel borders around the edge, we can set each field to 10, here we want them all set to 0, the same size as its parent We do the same with the Checkmark Image For the Label, we generally want some padding around the edges, and the text should be changed to centered alignment We’ll get into actually assigning images to these elements later on, for now these are all using the default Unity UI element sprites (which can be seen in KSP in the debug window and a few other places) We can also replace the Text label with an Image element, this will simply draw an icon over the Toggle Button rather that a label Images can be imported into Unity by simply copying them into a folder in the Unity Project’s Asset folder, or by dragging them directly into the Unity Editor’s Project Window Images should be imported as Sprite (2D and UI) and the Generate Mip Maps toggle should be off Filling in the other UI elements: I’m not going to go over how to add all of the different UI elements. There are numerous UI tutorials that thoroughly cover different element types; sliders, standard buttons, and text labels are all fairly straightforward to add. For static windows it isn’t too complicated, the RectTransform can get quite complicated, but the best way to understand it is to simply play around with it and change values to see what happens. More complicated UI layouts, and variable size windows will be covered later on. Exporting the Asset Bundle: To load anything into KSP we’ll need to actually export all of our prefabs as an AssetBundle using the Asset Compiler from the KSP Part Tools. The method for this is similar to that described in the KSPedia tutorial, just without the KSPedia Database steps. Drag any prefabs into the Assets folder in your Project Window (this would be the Panel that we added to the Canvas at the start for our window) Set the AssetBundle name in the Properties Panel in the lower right Then open or go to the Asset Compiler window -> Create (for your bundle) -> Update -> Build This will export a file into the AssetBundles folder in your Unity Project, it should have the .ksp file extension Section 3: Hooking up the UI: Now to get to the fun part. By making use of the Unity Editor we can assign methods to all of the toggles and buttons, store references to text elements so they can be updated later, spawn new windows, and much more. To do this we need to make a new assembly that can be imported into the Unity Editor. Any MonoBehaviours defined in this assembly can then be added as scripts to our UI objects. These can be scripts that control specific behaviors, like switching text colors when mousing-over an element, or that control the various window functions. I’ll be referring to the assembly that is imported into the Unity editor as the Unity Assembly, and the assembly that uses KSP code as the KSP Assembly. Unity Assembly: We create our Unity Assembly the same as any other, it should use .Net 3.5, but it should only add references to UnityEngine and UnityEngine.UI, it should not have any references to KSP assemblies. For our KSP Assembly we create that as always, and we add a reference to our new Unity Assembly. This means that the KSP Assembly can call any public methods from the Unity Assembly, modify any public fields, and implement interfaces. But the Unity Assembly can’t directly communicate with the upstream KSP Assembly, or directly use any KSP code. There are a few ways around this, we could use some sort of listener and events system to trigger methods in the KSP Assembly or use interfaces in the Unity Assembly. We’ll be using the interface method. To simplify importing your assembly into Unity you might want to add a post-build event to your VS project that copies the assembly into the Unity folder: copy /y "$(TargetPath)" "C:\YourUnityProjectFolder\Assets\Plugins\" Creating Scripts for Unity: Any class that inherits from a Unity MonoBehaviour can be imported into Unity and added as a component to any other Unity object. To import an assembly into the Unity Editor just drag the .dll into your Unity project’s Asset folder, there should be a separate Plugins folder Once it is imported you can add the script to any Unity object: Add Component -> Scripts -> Your.Assembly.NameSpace -> YourScript Now the script is added to that object and a new instance will be instantiated whenever that object, or its parent object is created These scripts can accomplish several things They can store references to elements of the UI that need to modified by the script They can add behaviors to elements, such as controlling text color, or for replacing standard Unity Text elements with KSP’s new vector font Text Mesh Pro elements They can be used to assign listeners to buttons, toggles, sliders, etc… For the simple window that we’ve already created we have a Text element that needs to be updated in-game (the little mod version label), and several toggles. Because we want to set the initial state of some of these toggles (one controls whether a separate window is open or closed, so if it’s already open that toggle should be set to the on state), and because we want some of the toggles to affect others, we need to store references to the Toggle elements. And we need to assign listeners to the Toggle scripts. Any field with Primitive Types, or Unity Object Types can be set in the script then assigned to in the Unity Editor Storing these fields allows for easy access in the script using UnityEngine; using UnityEngine.UI; namespace BasicOrbit.Unity.Unity { [RequireComponent(typeof(RectTransform))] public class BasicOrbit_Example : MonoBehaviour { [SerializeField] private Toggle m_OrbitToggle = null; [SerializeField] private Toggle m_OrbitDragToggle = null; [SerializeField] private Toggle m_OrbitSettingsToggle = null; [SerializeField] private Text m_VersionText = null; } } Note the RequireComponent attribute at the top, this simply means that the specified types must also be present on the same GameObject All UI elements that actually draw something on the screen (images, text, etc…) require a CanvasRenderer, for example If that component isn’t present on the object it will be added when you add the script Public fields will automatically be added to the script’s Inspector tab You can set attach the [NonSerialized] attribute to public fields to prevent them from being shown in the editor or serialized Private fields can be added by attaching the [SerializeField] attribute (unity chops off the m_ part of the field's name in the Inspector window) These fields can be filled in by simply dragging the desired elements into their respective fields, or by selecting the little circle to right of the field and selecting the element from a list of all valid elements in the project, or by filling in the desired value for primitive types Now we can access these fields from any instance of the script, though it is still a good idea to check if they are null, in case of errors made when setting up the UI, or exporting your prefabs To access or update these properties we just use these references public void updateVersionText(string newText) { if (m_VersionText != null) m_VersionText.text = newText; } public void setInitialToggle(bool isOn) { if (m_OrbitToggle != null) m_OrbitToggle.isOn = isOn; } One thing to note about setting Toggle states like this, whenever you change a Toggle’s isOn field, it will trigger that Toggle’s Listener Events, so anything you or anyone else has attached to this Toggle will be triggered. One way of getting around this is to have a Bool set to False while you are doing the initial setup. Then set your Toggle Listener to not do anything when the Loaded Flag is False, after the setup is complete you can set the Flag to True. Now to add listeners to Toggles and Buttons. The Unity UI attaches listeners to Unity Events triggered by a Button, Toggle, Slider, etc… Any public method that meets the requirement of that particular event can be added as a listener. public void OrbitPanelToggle(bool isOn) { if (!loaded) return; if (m_OrbitToggle == null) return; //Turn on Orbit Panel } public void OrbitDragToggle(bool isOn) { if (m_OrbitDragToggle == null) return; //Turn on Orbit Panel drag state } public void OrbitSettingsToggle(bool isOn) { if (m_OrbitSettingsToggle == null) return; //Spawn Orbit Panel settings window } public void myButtonListener() { //Methods with no arguments can be added to any button or to any other element if the argument does not need to be specified } public void mySliderAlpha(float alpha) { if (!loaded) return; if (m_AlphaText != null) m_AlphaText.text = alpha.ToString("P0"); //Change panel background alpha } Inside the Inspector tab for any Unity element with a Unity Event there is a section for adding listeners, you can add more by selecting the plus button on the bottom. Add a listener by first selecting an object for the little box below the “Runtime Only” box This will be the object that contains the script which has your listener You can either drag the object into the box, or select it from the list using the little circle In this case we select the parent Panel object, which has our example script The specific method is then selected in the box on the right This box has a list of all components attached to the selected object Select the Example script which will then show a list of all public methods that can be chosen Now we can just basically repeat these steps wherever needed. If you need access to an object somewhere, just add a reference to it in your script and assign it in the editor. If you need more listeners, just add them. More complicated behaviors will be explained later. One thing to note about Buttons, Toggles, etc, is the Transition and Navigation elements in their Inspector tabs. Transition refers to how the element behaves in its different states Sprite Swap transitions mean that different sprites are used for the normal state, when the mouse is over the object, or for when the mouse is clicking on the object Color Tint just adjusts the color tint for the attached Image element in those same states Animation uses Unity Animations to design more complex behaviors This is something that will be covered more later, but KSP generally uses Sprite Swap transitions, and for this example these states will all be setup in-game Navigation refers to keyboard navigation and is generally something that should be deactivated When you click on an object it will become the “active” object until you click somewhere else unless Navigation is disabled This means that the element will remain in the Highlighted state Section 4: Assembly Communication: Now that we have our UI hooked up to the Unity Assembly we need to get it communicating with the KSP assembly. There are probably several ways of handling this, but I’ve been using Interfaces in the Unity Assembly to handle it. The basic idea is to create one or more interfaces with the methods and fields needed to send information between the two assemblies, then we add those interfaces to objects in our KSP Assembly. This basically serves two purposes, the interface us used to set the initial state of the UI when it is created, using information from KSP, this could be persistent data, or just anything that can be altered at run time, like the name of a vessel. And it allows for the UI elements to make changes on the KSP side, by setting persistent data, or triggering a KSP-related function. In our last example we had a window with several Toggle elements, a Text field, and a method for the alpha Slider, so the interface contains what is needed to setup those elements, and to transfer data to the KSP Assembly for persistent storage. namespace BasicOrbit.Unity.Interface { public interface IExample { string Version { get; } bool ShowOrbit { get; set; } float Alpha { get; set; } } } The Version string is read-only, since the UI does nothing to alter it The Show Orbit bool is read to set the initial state, but can also be set by the UI when clicking on the Toggle The Alpha float is also used to set the initial state, and needs to be updated when changing the Slider value So now we can set the UI’s initial state by implementing our interface on an object in the KSP Assembly and calling the Setup method. private IExample exampleInterface; public void setInitialState(IExample example) { if (example == null) return; exampleInterface = example; if (m_VersionText != null) m_VersionText.text = example.Version; if (m_OrbitToggle != null) m_OrbitToggle.isOn = example.ShowOrbit; if (m_AlphaSlider != null) m_AlphaSlider.value = example.Alpha; if (m_AlphaText != null) m_AlphaText.text = example.Alpha.ToString("P0"); loaded = true; } public void OrbitPanelToggle(bool isOn) { if (!loaded) return; if (m_OrbitToggle == null) return; if (exampleInterface != null) exampleInterface.ShowOrbit = isOn; //Turn on Orbit Panel } public void mySliderAlpha(float alpha) { if (!loaded) return; if (exampleInterface != null) exampleInterface.Alpha = alpha; if (m_AlphaText != null) m_AlphaText.text = alpha.ToString("P0"); //Set panel background transparency } Note that we store a reference to the interface for use by the listener methods Make sure to set the Loaded Flag to true if needed The code for actually turning on the separate panel, or changing the background image’s alpha channel can all be handled within the Unity Assembly Section 5: Turning it On: Now we have to be able to actually turn on the UI. To do this we need a reference to the UI Prefab and a button somewhere to trigger the UI. We can let KSP load the AssetBundle that was exported from Unity, anything with a .ksp file extension should be loaded, or we can load it ourselves (KSP won’t load it twice, so there is no duplication of resources doing it this way; you can also just remove the .ksp extension to hide it from KSP’s asset loader). I’ve been loading it myself, it works find, and it allows me to open it immediately upon starting KSP. If we need to process or update all of the prefabs it can be useful to load in all of the prefabs, but to generate a window all you really need is the primary prefab (anything that will be created directly by the KSP Assembly). We can store prefabs as references in our Unity scripts by adding a serializable GameObject. A simple KSPAddon can be used to manually load and store a reference to the prefab: [KSPAddon(KSPAddon.Startup.Instantly, true)] public class BasicOrbitLoader : MonoBehaviour { private static GameObject panelPrefab; public static GameObject PanelPrefab { get { return panelPrefab; } } private void Awake() { string path = KSPUtil.ApplicationRootPath + "GameData/YourMod/PrefabFolder"; AssetBundle prefabs = AssetBundle.LoadFromFile(path + "/your_bundle_name"); panelPrefab = prefabs.LoadAsset("Your_Prefab_Name") as GameObject; } } Then we need an object that implements our interface; this can get its data from a persistent settings file, or a scenario module, from in-game data, or any other suitable source: [KSPAddon(KSPAddon.Startup.Flight, false)] public class BasicExample : MonoBehaviour, IExample { private string _version; private static BasicExample instance = null; public static BasicExample Instance { get { return instance; } } private void Awake() { instance = this; _version = "Assembly Info Version"; } public string Version { get { return _version; } } public bool ShowOrbit { get { return BasicSettings.Instance.showOrbitPanel; } set { BasicSettings.Instance.showOrbitPanel = value; } } public float Alpha { get { return BasicSettings.Instance.panelAlpha; } set { BasicSettings.Instance.panelAlpha = value; } } } To open the window we just need to setup a toolbar button as normal and use the Open function to start the UI: BasicOrbit_Example window; private void Open() { if (BasicOrbitLoader.PanelPrefab == null) return; GameObject obj = Instantiate(BasicOrbitLoader.ToolbarPrefab, GetAnchor(), Quaternion.identity) as GameObject; if (obj == null) return; obj.transform.SetParent(MainCanvasUtil.MainCanvas.transform); window = obj.GetComponent<BasicOrbit_Example>(); if (window == null) return; window.setInitialState(BasicExample.Instance); } The arguments in the Instantiate method are used to set the window’s position and rotation The rotation is set to zero Here the position is set using the Toolbar Button’s GetAnchor method There are several canvases that could be used, but in general the MainCanvas will probably be best We can get a reference to the UI script since it is attached to the newly instantiated object The window can be closed by either hiding it or destroying it You can hide the window by setting its gameObject.SetActive(false) This can be used if the window has a complicated initial setup and you don’t want to keep repeating that This should be enough to get a basic window into KSP. Future sections will go over dynamic UI generation and UI layouts elements, specific UI features, KSP-style UI elements, and using TextMeshPro for all text elements. They should also, hopefully, be much shorter, since they won’t have to cover so much information. If you want to setup your UI with the legacy Unity GUI style elements, they are available for free on the Asset Store. You will need to import them into Unity and use the Sprite Editor to set the Splicing lines properly (so that the images stretch to fit whatever size is needed). After that you can simply drag the sprites into your Image elements wherever needed.
  4. A replacement for stock engine particle FX. If you are tired of seeing the same old effects, HotRockets is for you! Note: SmokeScreen + ModuleManager are required dependencies. Download the legacy version here (compatible with KSP 1.1): Download HotRockets Note that HotRockets is primarily my set of replacements for stock engines. I no longer support FX packs for mod engines, but you are able to use the HotRockets assets for your mods. Many mods now make use of HotRockets assets to improve engine FX; some will add support for mod engines, and some have additional features for stock and mod engines such as resized plumes or easily added preconfigured effects. Mods using HotRockets art assets Kerbin Shuttle Orbiter B9 Aerospace Space Shuttle System Realplume Realplume stock configs Mods with HotRockets support for new engine parts Vens Stock Revamp License: HotRockets Art Assets: http://creativecommons.org/licenses/by-nc/4.0/ Powered by SmokeScreen + ModuleManager(by Sarbian): http://opensource.org/licenses/BSD-2-Clause Screenshots of HotRockets effects in-game: -------------- Basic guide for getting custom particles functioning in the game The method for getting custom engine FX working is fairly simple with the new system, but unfortunately was not covered by an official tutorial on the forum. This will be a small guide for getting them working in game and it will leave the details of the effect up to you. Note: the effect being animated like a heat effect is not necessary with the ModuleEnginesFX system. 1) Game objects Create an empty game object at the origin that you will use for exporting. This will have a partTools component on it that you will use to write the .Mu file to your FX folder. Create an empty object as a child of the exporter object. This object will have the KSPParticle Emitter script on it. I call mine 'emit'. This allows you to easily tweak the position of the effect within the actual exported object. I also make an additional object and name it smokePoint so I am able to move the smoke transform away from the flame transform, but this is not required. 2)Texture Create a new material for each effect you make. This will ensure you don't overwrite the properties of another effect you have. I work with all of my effects in one unity scene by duplicating exporter objects and changing what I need to, so once I duplicate an effect, I create a new material in Unity and add a texture to it. Assign your material to the particle effect using the "Material" property on your KSPParticle Emitter. To create the appearance of a glowing flame, you will need to use the KSP/Particles/Additive shader. Create a 256x256 or smaller image file with alpha that you can use for the effect. Creating the actual image file is fairly straightforward if you look at the current files being used, but I will say that for a transparent additive effect even your strongest colors must have extremely low alpha, almost making the effect invisible. To create a smoke effect, you will want to use Alpha Blended instead of the additive shader. 3) Parameters on the KSPParticle Emitter This is how you will control the style of the effect you make. It will most likely require a lot of small changes and reloading the game to see your effect, because it will not look the same in Unity. So enjoy experimenting =). A couple important ones: Simulate World Space - this parameter, if unchecked, will keep your effect local to the transform it's on. This is how you create a flame that looks like one cohesive effect, and not something that sprays in every direction or curves. While you would use this for smoke, having an effect with the box checked in addition to one without it will cause HUGE errors in the current version of KSP, and is the reason my effects use stock smoke right now. Nothke and I spent tons of time trying every method to get around it, but a plugin or fix by Squad seems to be necessary, and I am not a plugin creator. Energy - the lifetime of your particles. With the current system, this seems to be one of the parameters along with growth that can only be changed in the Unity editor. Emission - amount of particles emitted. Use as low an amount as possible while achieving the effect you want. I have used ranges near 150 or as high as 350 for my FX. Shape - controls the shape of the emitter, mine use Ellipsoid. Local Velocity - you will want at least 10+ velocity on Z for a fast looking effect. Most of the other parameters are something that just needs be be experimented with to get the style you want. Try animating the color of your effect, and lowering the alpha as it progresses through each color. Shadows - all of my effects have Casting and Receiving unchecked. When you think you have the parameters set the way you want, select the PartTools object and click "write" to export the .Mu file and texture to your chosen folder. 4) Game configuration file For adding an effect into the part config for an engine, I will typically comment out each line of the old effects, preserving them if needed, then highlight the following lines in the config MODULE { name = ModuleEngines thrustVectorTransformName = thrustTransform and paste this to replace them: EFFECTS { powerflame { MODEL_MULTI_PARTICLE { name = flamethrust modelName = MP_Nazari/FX/flamestandard transformName = thrustTransform emission = 0.0 0.0 emission = 0.05 0.99 emission = 0.75 1.21 emission = 1.0 1.25 speed = 0.0 1.70 speed = 1.0 1.65 } AUDIO { channel = Ship clip = sound_rocket_hard volume = 0.0 0.0 volume = 1.0 1.0 pitch = 0.0 0.2 pitch = 1.0 1.0 loop = true } } powersmoke { PREFAB_PARTICLE { name = flamethrust2 prefabName = fx_smokeTrail_light transformName = smokePoint emission = 0.0 0.0 emission = 0.05 0.0 emission = 0.075 0.25 emission = 1.0 1.25 speed = 0.0 0.25 speed = 1.0 1.0 localOffset = 0, 0, 1 } } engage { AUDIO { channel = Ship clip = sound_vent_medium volume = 1.0 pitch = 2.0 loop = false } } disengage { AUDIO { channel = Ship clip = sound_vent_soft volume = 1.0 pitch = 2.0 loop = false } } flameout { AUDIO { channel = Ship clip = sound_explosion_low volume = 1.0 pitch = 2.0 loop = false } } } MODULE { name = ModuleEnginesFX //engineID = rocketengine runningEffectName = powersmoke directThrottleEffectName = powerflame thrustVectorTransformName = thrustTransform Edit the path to any effect files, change effect properties or add modules as needed. -For the method to add this to an existing engine with ModuleManager, see the actual config file included with HotRockets. -Note that powersmoke and powerflame are simply what I wanted to name my effects for flames and smoke. You can create your own effect name. -If you use two flame particles in one effect, give them each a unique entry under "name" -Remember to make the thrustTransform in the effect match the transform you want in the engine. -EngineID is used for multiple-mode engines, check the rapier config to see the setup for that. -Emission curves within each effect: you may have seen curves used in a few other modules when modding KSP. This is also fairly simple. The first number is the level of engine power, the second is the percentage of emission/speed/etc divided by 100. I believe that covers everything needed to get a custom engine effect working.
  5. This guide is based around the propellor parts - specifically, variable pitch propellors. In @Brikoleur's guide to helicopters, he recommended using servos to change the pitch of the rotors, therefore changing the lift and allowing the helicopter to change vertical speed. The new propellors have built in servos. However I have found them a little hard to understand, so I created this guide. Here is the craft we will be using: The Lux aircraft is not a very good plane, but it is simple. It has 2 counter-rotating propellors. You can make planes with 1 propellor, but the torque from the propellor will cause the aircraft to roll, which makes it hard to control and also sometimes causes the wings to hit the ground and explode. Either you can use two rotors as I have done, which allows this plane to get up to 200m/s, or you can use a freewheeling servo as described in Brikoleur's guide. My craft has been set up so that [ I ] and [ K ] change the authority limiter of the propellors, changing their pitch. Now let's look at the craft pre-launch. Here you can see the propellor blades. The blade is deployed, but the Authority Limiter is at 0. This means that the blade will be at the limiter I set. At the moment, it is 0 - the propellor is perpendicular to how it will rotate. It will therefore cause no lift, but lots of drag. The throttle is also at 0. As I used Axis Groups to tie the turboshaft engines to the throttle, the propellors are not rotating. You can see that as the propellors rotate, they are producing only drag. This is because they are perpendicular to rotation. However, when I press [K]... While the propellors are not yet in the optimum position, they have rotated a lot. They are producing little drag, and the yellow and purple lines (representing lift) are long. (You cannot see the yellow lines from the rear propellors as they are inside the body). This lift moves the plane forwards. The plane is accelerating slowly as the propellors are not in the optimum position, however it can get up to 100m/s in around ten seconds as this particular plane is very light for the number of engines. I have now rotated the propellors into (currently) optimum position. There is little drag and a lot of lift. You can see here that the lift has decreased. This always happens - I think it is because we are reaching the limit of the props deployed as they are. You can also see that the red drag lines have increased in length as I rotate the blades. There is a balance to be struck between lift and drag, which determines the speed of the aircraft. Often (but not always) pressing [ I ] will increase speed and drag. There are a few different (and annoying) things which can happen with your aircraft when flying. Firstly, the propellors can rotate past 90 degrees, and cause increased drag (like at authority 0) or even for the plane to start flying backwards. Secondly, the lift from different rotors can cancel each other out if you set the axis groups wrong. Finally, it is very difficult to set the propellors exactly and this can mean that your plane has some unwanted behaviour. However, there are advantages to propellor planes. Without a specialised engine like the Wheesley, you can reverse thrust and land quickly. As well as this, the engines are very efficient, and even the electric motors do not draw much power. Finally, they are the fastest (if not the cheapest) option for exploring Eve, Duna and any other modded planets (such as Tekto in OPM) with a non-oxygen atmosphere. I hope this guide is useful and allows some more people to build their own propellor aircraft. Please do not copy the above aircraft, as it is not very stable and a pain to land. Copy this aircraft instead! Link to KerbalX.
  6. Tutorial covers the basics of the UI, how the timeline works, as well as examples & tips to make things far easier to work with. Breaking Ground - Robotics Tutorial on Youtube
  7. [Edit: For the updated stand-alone version of this tutorial, go here] So I started off getting my video recording & editing software back so I could make an animated GIF for reddit to showcase my robotics powered rover deployment system. But of course I ended up remembered how much fun doing videos can be, and wanted to share the method I found that took my programming time from 3+ hours to less than 1, so the 6+ hours I'd spent programming the arm & doing a comedy showcase GIF ended up spiraling into another 8+ hour editing session. I think it's my most polished video thus far; spent sooo much time working on the timing and ironically half way through editing I realised that if I used THE SAME METHOD that worked so well for the robotics programming I'd be done already. It was nice though, got the last bit done far faster ^^ Well, enjoy, I hope it is useful!
  8. I am a few months into KSP and I was not enjoying Career mode. I wanted to explore the Kerbol System in a logical way, but without the extra restrictions of Career mode. Science mode seemed like the answer, if I could do it without having to grind, or to do missions that were more science focused than exploration/progression focused. So here you have my “Logical Progression” Science Mode guide. There is minimal non-destination science or biome hopping, and each mission gets you progressively further into the Kerbol system. Part 1 – Kerbin and it’s Moons Mission 1 – Learn to Science! Mission 2 – Go to Space! Mission 3 – Orbit Kerbin! Mission 4 – Fly by the Mun! Mission 5 – Land a Probe on the Mun! Mission 6 – Land a Kerbal on Minmus! (and Return) Part 2 – Interplanetary Travel To be continued… *Note - This guide does not teach you how to play KSP. Use the in-game tutorials and/or watch Scott Manley videos on YouTube. Mission 1 – Learn to Science! - We don’t have the technology to get to space yet, so we’ll just learn how to science - In the VAB, build a ship with o Mk1 Command Pod o Mystery Goo Containment Unit - Name/Save the ship and Launch - From LaunchPad o Crew Report (1.5) o EVA Report (2.4) o Take Surface Sample (9.0) o Observe Mystery Goo (3.0) - Recover Vessel (Mission 15.9/15.9 Total Science) - In the R&D Facility unlock o Basic Rocketry (5) o Engineering 101 (5) o 5.9 remaining - The liquid fueled engines and decouplers should help get us to space and back Mission 2 – Go to Space! - We should be able to use the liquid fueled engines to escape the atmosphere - In the VAB, build a ship with o Mk1 Command Pod o Mk16 Parachute (Stage 0) o 2x Mystery Goo Containment Unit o 2x 2HOT Thermometer o TD-12 Decoupler (Stage 1) o 5x FL-T100 Fuel Tank o 4x Basic Fin o LV-45 “Swivel” Liquid Fuel Engine (Stage 2) - Name/Save the ship and Launch - Launch! - In Space Near Kerbin o Crew Report (5.0) o EVA Report (8.0) o Observe Mystery Goo (10.0) o Log Temperature (8.0) - Decouple and Parachute down - From wherever you landed (try to save Kerbin’s Water for later missions) o EVA Report (2.4) o Take Surface Sample (9.0) o Observe Mystery Goo (3.0) o Log Temperature (2.4) - Recover Vessel (8.0) (Mission 55.8/61.7 Total Science) - In the R&D Facility unlock o General Rocketry (20) o Stability (18) o Survivability (15) o 8.7 Remaining - Larger fuel tanks and radial decouplers should get us an orbit-worthy ship Mission 3 – Orbit Kerbin! - We don’t have an efficient enough engine to get to the Mun so we’ll settle for high orbit - In the VAB, build a ship with o Mk1 Command Pod o Mk16 Parachute (Stage 0) o 2x Mystery Goo Containment Unit o 2x 2HOT Thermometer o 2x PresMat Barometer o Heat Shield (1.25m) o TD-12 Decoupler (Stage 1) o 5x FL-T200 Fuel Tank o 4x AV-T1 Winglet o LV-45 “Swivel” Liquid Fuel Engine (Stage 2) o 2x TT-38K Radial Decoupler (Stage 2) o 2x RT-10 “Hammer” Solid Fuel Booster (Stage 3) o 2x Aerodynamic Nose Cone - Name/Save the ship and Launch - In Space High Over Kerbin (250KM) o Crew Report (7.5) o EVA Report (12.0) o Observe Mystery Goo (15.0) o Log Pressure Data (18.0) o Log Temperature (12.0) - De-Orbit, Decouple and Parachute down - From wherever you landed, as long as it’s not the same place as before (Water gives more) o EVA Report (2.4) o Take Surface Sample (9.0) o Observe Mystery Goo (3.0) o Log Pressure Data (3.6) o Log Temperature (2.4) - Recover Vessel (10.0) (Mission 94.9/103.6 Total Science) - In the R&D Facility unlock o Advanced Rocketry (45) o Basic Science (45) o 13.6 Remaining - The LV-909 “Terrier” is our ticket to the Mun Mission 4 – Mun Flyby! - Let’s try to get a closer look before trying to land (and some science for a nice probe) - In the VAB, build a ship with o Mk1 Command Pod o Mk16 Parachute (Stage 0) o 2x Mystery Goo Containment Unit o 2x 2HOT Thermometer o 2x PresMat Barometer o SC-9001 Science Jr. o Heat Shield (1.25m) o TD-12 Decoupler (Stage 1) o FL-T400 Fuel Tank o LV-909 “Terrier” Liquid Fuel Engine (Stage 2) o TD-12 Decoupler (Stage 3) o 3x FL-T400 Fuel Tank o 4x AV-T1 Winglet o LV-45 “Swivel” Liquid Fuel Engine (Stage 4) o 2x TT-38K Radial Decoupler (Stage 4) o 2x BACC “Thumper” Solid Fuel Booster (Stage 5) o 2x Aerodynamic Nose Cone - Name/Save the ship and Launch - For an extra challenge, go for a free return trajectory - In Space High Over The Mun o Crew Report (10.0) o EVA Report (16.0) o Observe Materials Bay (50.0) o Observe Mystery Goo (20.0) o Log Pressure Data (24.0) o Log Temperature (16.0) - De-Orbit, Decouple and Parachute down - If you happen to land somewhere new, grab some extra science - Recover Vessel (12.0) (Mission 148.0/161.6 Total Science) - In the R&D Facility unlock o Flight Control (45) o Electrics (90) (26.6 Remaining) - The OKTO, Photovoltic Panels, and Reaction Wheel will be essential to our probes Mission 5 – Land a probe on The Mun! - Time to try a landing…without putting any Kerbals at risk - In the VAB, build a ship with o Probodobodyne OKTO o 4x OX-SAT Photovoltic Panels o 4x Z-100 Rechargeable Battery Pack o Small Inline Reaction Wheel o Communotron 16 o 2x 2HOT Thermometer o 2x PresMat Barometer o SC-9001 Science Jr. o 2x Mystery Goo Containment Unit o FL-T200 Fuel Tank o 4x LT-05 Micro Landing Strut o LV-909 “Terrier” Liquid Fuel Engine (Stage 0) o TD-12 Decoupler (Stage 1) o 4x FL-T400 Fuel Tank o 4x AV-T1 Winglet o LV-45 “Swivel” Liquid Fuel Engine (Stage 2) o 2x TT-38K Radial Decoupler (Stage 4) o 2x BACC “Thumper” Solid Fuel Booster (Stage 5) o 2x Aerodynamic Nose Cone - Name/Save the ship and Launch - In Space Near The Mun o Observe Mystery Goo (12.2) o Log Pressure Data (25.2) o Log Temperature (16.8) - Landed on The Mun o Observe Materials Bay (49.0) o Observe Mystery Goo (16.8) o Log Pressure Data (33.6) o Log Temperature (22.4) - Return to KSC (Mission 176.0/202.6 Total Science) - In the R&D Facility unlock o Fuel Systems (90) o Landing (90) (22.6 Remaining) - The external fuel duct will help us design a return vehicle for a Minmus mission Mission 6 – Land a Kerbal on Minmus! (and Return) - Finally it’s time to go where no Kerbal has gone before - In the VAB, build a ship with o Mk1 Command Pod o Mk16 Parachute (Stage 0) o 2x Mystery Goo Containment Unit o 2x 2HOT Thermometer o 2x PresMat Barometer o Heat Shield (1.25m) o TD-12 Decoupler (Stage 1) o FL-T100 Fuel Tank o LV-909 “Terrier” Liquid Fuel Engine (Stage 2) o TD-12 Decoupler (Stage 3) o SC-9001 Science Jr. o 2x FL-T200 Fuel Tank (Beside the Science Jr.) o 4x Aerodynamic Nose Cone (Top and Bottom) o 2x FTX-2 External Fuel Duct (Fuel tanks to Terrier) o LV-909 “Terrier” Liquid Fuel Engine (Stage 4) o 4x LT-1 Landing Struts o TD-12 Decoupler (Stage 5) o 3x FL-T800 Fuel Tank o 4x AV-T1 Winglet o LV-45 “Swivel” Liquid Fuel Engine (Stage 6) o 4x TT-38K Radial Decoupler (Stage 6) o 4x BACC “Thumper” Solid Fuel Booster (Stage 7) o 4x Aerodynamic Nose Cone - Name/Save the ship and Launch - In Space Near Minmus o EVA Report (32.0) o Observe Mystery Goo (40.0) o Log Pressure Data (48.0) o Log Temperature (32.0) - Landed on Minmus o Crew Report (25.0) o EVA Report (40.0) o Take Surface Sample (150.0) o Observe Materials Bay (125.0) o Observe Mystery Goo (50.0) o Log Pressure Data (60.0) o Log Temperature (40.0) - Retreive Data from the Science Jr. - Decouple and Launch back to Kerbin - De-Orbit, Decouple and Parachute down - If you happen to land somewhere new, grab some extra science - Recover Vessel (37.5) (Mission 679.5/702.1 Total Science) This should be more than enough science to escape Kerbin’s SOI and go interplanetary!
  9. Siguiendo con esta serie de mods de expansión, turno del "Base Planetary System". Este mod añade una serie de piezas para ayudarnos a montar nuestros puestos avanzados en la superficie de los planetas. Tenemos toda clase de módulos, desde habitacionales, hasta laboratorios, invernaderos, inventarios y demás..... BASE PLANETARY SYSTEM
  10. Muy buenas: Aquí dejo otra presentación del mod "Space Y Lifters", un mod que añade una serie de motores de elevación para ayudarnos con el diseño sobre todo de naves pesadas. Espero que os sirva de ayuda..... SPACE Y LIFTERS
  11. Bueno. Otro tutorial sobre lo que nos podemos encontrar dentro de la serie de mods Near Future Tecnologies….. NEAR FUTURE TECNOLOGIES
  12. Empezamos con la introducción poco a poco de mods. Aunque este es un tutorial para el juego de stock, creo conveniente de ir introduciendo o por lo menos presentando ciertos mods que si bien no dan ninguna ventaja en el sentido de hacer más sencilla la dificultad del juego, si que nos expanden la jugabilidad. Este mod lo que nos aporta básicamente, es un espacio de carga para piezas y objetos que podemos utilizar en órbita o en otros planetas..... KERBAL INVENTORY SYSTEM
  13. Le vamos a acoplar a la estación orbital de Muna unos módulos de procesamiento de material para así no tener que enviar combustible desde Kerbin..... ESTACIÓN MINERA
  14. Segunda oportunidad de envío de un rover a Minmus. Esta vez con las modificaciones pertinentes...... ROVER A MINMUS II
  15. Una vez tenemos localizado un asteroide que nos pueda interesar, vamos a ver que procedimiento seguimos para ello..... No hay un procedimiento estándar para todos ellos y muchas veces, depende de la trayectoria que sigan..... CAPTURA DE ASTEROIDE
  16. Nos acercamos al momento de capturar un asteroide, pero para ello debemos primero localizarlos. Para eso montaremos nuestro primer telescopio y lo pondremos en órbita alrededor de Kerbol…... MONTAJE DE TELESCOPIO
  17. Para abaratar costes y tener un plan de escape disponible, subimos un "bote salvavidas" a la estación orbital. Además nos puede servir para hacer rescates en órbita de algún náufrago que nos salga sin tener que hacer un lanzamiento más costoso.... SALVAVIDAS A LA ESTACIÓN
  18. Llegamos a la parte final de esta misión a Duna en la que tenemos contacto con el planeta, y llegan tanto la nave tripulada como el satélite. La primera pasará de largo, mientras que la segunda se va a quedar en órbita y además nos servirá de repetidor para cuando volvamos para bajar a la superficie..... LLEGADA A DUNA
  19. Toca hacer una actualización a la estación orbital..... SUMINISTRO A KLO
  20. Por aclamación popular, aquí tenemos como montar un rover para exploración planetaria..... Eso sí otra historia muy diferente es ponerlo en otro planeta, pero además damos a conocer algún secretillo del juego..... ROVER EXPLORER
  21. Vamos a tomar como excusa el rescate de la cápsula que se quedó en Minmus, para estrenar la "garra" o lo que es lo mismo, la pinza con la que hacer las capturas orbitales de cápsulas y asteroides..... CAPTURA ORBITAL
  22. Buenas. Seguimos con nuestro viaje a Duna. Esta vez con el lanzamiento de las naves que deben ir hacia allá: Una tripulada y un satélite que se quedará allí VIAJE A DUNA II
  23. Hey, I would like to make a mod (a parts pack to be exact) but I don't know how. I have some(ish) programming experience, but I don't know how to start, how to actually make the mod work and what software to use. It would be nice if one of you experts gave me a tutorial or something on how to get to modding. It would also help if you told me how to make textures.
  24. Con paciencia, todo llega. Y ha llegado el momento de dar el gran salto a otros planetas.... Y la opción más lógica y sencilla es Duna. En este primer vídeo vamos a ensamblar una nave que nos permita llegar hasta allí. Más adelante, veremos las mecánicas para hacer la transferencia planetaria y la inserción.... Pero no queremos hacer videos de 3 días de duración..... VIAJE A DUNA I
  25. Muy buenas: Seguimos con nuestro modo carrera haciendo contratos más ambiciosos. Esta vez en Minmus donde realizaremos un rescate masivo pero son sorpresa final...... RESCATE EN MINMUS