Fengist

Right now there are only 3 envelope parts. I'll explain why in an update. But, balloonets are optional from within the VAB or SPH. If you go traditional and have one fore and one aft the main UI has buttons that will inflate or deflate both equally. Right clicking on the part will give you buttons to inflate or deflate just that balloonet. If I remember, I'll also set up actions for that so you can inflate or deflate with a keystroke. But, with all the other things that this mod is already doing, you may not have enough keys to go around. For now, these are considered rigid. Once you get into non-and semi rigid, you get into a nightmare when it comes to resizing the envelopes outside the hangar. Multiple cells, while entirely doable present another problem which you quickly identified, controlling them all. There will be a 'solution' available if you wish to go that route with this mod tho. You could theoretically have a lot more than the Hindenburg. I've yet to test this tho, still trying to get them off the ground without exploding... (foreshadowing). As for open cells, well... dunno if you heard but I was recently allowed to take over development of KerBalloons. Dunno why I'd have an interest in that mod. Thank you sir. Yea, I did a bit of research. And face-desking, I'm a couple months and several thousand lines of code into this. Haven't quite decided on how to handle that. At the moment, my testing is with just hydrogen and helium. And for those, heating is a case of diminishing returns. Hot helium or hot hydrogen don't offer that much lift over ambient. Where heating gasses really works is when they're dense like air. I'm going to have to fiddle with numbers (weight vs lifting advantage) to see how that'll all play out. But that's down the road. Still trying to get parts designed that look half-way decent but are light enough that these things get off the ground. Oh, and I kinda got helistats working today along with rotating engines.

Duno if you saw this but I'm working on some airships and learned a bit about UI's. I'm using one to help regulate the lifting gasses. If your'e really getting into subs, take a look at this. You may just skip the tweak UI and build you own.

Oh, you are asking the wrong guy. I spent weeks on it and the best I could come up with is a 'guess.' I can get you the code I use on my 'computer' but it's far from perfect. I found in my subs with 1869, the best solution was to do it manually. About the only way I know where it can be done right with code, is to have the user tell you which part is the forward and the aft. Figuring that out with code isn't always easy. Plus, what if they have 2 of your subs welded together. Then you end up with 2 forward and 2 aft and if the user doesn't tell you which is which, it gets real messy trying to find transforms. Plus, in my opinion, the more things you have code do, the less immersion there is. Code should create things to do, not make it easy... which is why I ditched MechJeb years ago. If I were to do it again, I'd just do a UI_Float range and a few buttons. The UI range so they can adjust how much ballast goes into or out of a tank per fixed update and 3 buttons for fill, empty and blow. But, that's just me. *edit* Besides, if you do it all for them, you never get to see crazy excrements like flying paddlewheelers. If you need help creating those buttons and the float range, just let me know and I can PM you some examples.

LOL, congrats on the mod. I just now found it. If you need any help, just give a shout.

Does this mean I get to post videos of your subs flying around Kerbin?

Update to the OP - alternate lifting methods I have actually taken a look at that design and, here's the good news. The method I'm currently using is what I call mole counting. While pressure, volume and temperature will change, one thing that will remain constant (assuming no leaks) is the number of molecules of a specific gas. And, the airships in the screenshots are already using that method. Basically, I have a list with a bunch of info, including the number of mol's of each gas. From those mol's, every other part of the ideal gas law can be calculated. This list also means, I can track the temperatures of each individual gas. While heated & non heated gasses in the same envelope is going to be on the list, it's not on the top. But the infrastructure in the code to have a hot air/helium airship already exists. But... I don't do nukes. To me, reactors in the game are like RTG's. They're just too cheaty for me. I'll come up with another solution but it'll likely use some kind of fuel. As for emergency venting, already there as well. While other mods have vented gasses, this one will be a bit different. If you look at the first screenshot, on the top of the envelopes, you'll see 3 black dots. One forward, mid and aft. These are vents. You can also just see one in the second screenshot on the top. The way they'll work is via manual and automatic settings (which you can turn off). You give them a pre-set pressure and should the envelope exceed that pressure, they'll begin venting. The bad news. The rate of that venting will be fixed. The good news, for just a few more kilos... or pounds... you can add more vents. In the video I posted you can see the automatic vents fire off a few times when I expanded the balloonets a bit too much during landing. As for damaged gas cells, for now I don't plan on that and here's a quick reason why. A good friend and former modder, InfiniteDice has been tossing in idea (and laughing at me) through this mind bending coding process. Once I had the physics down to the point that the airships actually flew, his response was, "now, make them fun." While they will pop if you over-inflate them, just like any good KSP part should do, having random damage appear isn't in the foreseeable future. Thank you for the long and well thought out reply! It's greatly appreciated.

In testing: A quick update on the progress of ideas. I've got some preliminary code working to log various bits of data. Here's a sample of the output: https://pastebin.com/ZAjjUmgi The plan is such. I'll be creating a new datalogger part. With it, you'll be able to set intervals between 1 and 60 seconds. Once turned on, it will log data to a .csv file in a new folder called KerBalloons/LogData. It currently looks for the scientific instruments available from the stock parts. If the instrument isn't turned on, it won't give any data. That means, once you turn on, say the thermometer, it'll start using electricity. This has also, in my head, created a need for some other parts. One being a clock. Without it, the datalogger won't know what time to record. And, a new instrument, an atmospheric density recorder. And another instrument. Let's call it a sextant to log latitude and longitude. If there are any other instruments you'd like to see created so that data can be logged, let me know here and I'll see what I can come up with.

Thanks for the long reply @kerbiloid. I'll try to get a response and the next installment of my ramblings out tomorrow. Don't have much time today. But, I did get one thing done. Here's a quick video to browse. Sorry for the 480p! I know it really sucks. I didn't realize it was such low quality till after I uploaded it. But, I still think you'll get the gist of the testing going on and keeping the details secret might just be a nice hype generator... eh?

Maritime Pack 1.12 is now available for download via the OP. Major changes: Hovercraft! - With this comes a warning. These hovercraft actually hover. That means, KSP considers them to be flying. If you exit out of these craft while still hovering, very bad things can happen. If you quicksave while hovering, very bad things can happen. Always, land your hovercraft before saving or changing scenes. Resizable ship parts - Most all hull parts are now resizable. There is one known issue with fuel switching. If you resize a part and then change the fuel, the fuel amounts will revert to the 1:1 size. Either choose your fuel before resizing or drop back down to size 1, change the fuel and then resize. Fuel amounts are updated on resizing but you'll have to reopen the part UI to see the change. Icon - You should see a new icon in the part category list. That big anchor should have all of the Maritime Pack parts in it. For now, those parts are also in the stock categories. Animation fixes - A number of animations were bugged. This required a rework of the way FengistAnim works. You should not see a difference. As always, if you find any issues, let me know here. Enjoy.

That must be new. And 512 kb isn't... well... Can you upload it to somewhere like dropbox or google cloud where I can download it and take a look?

Pay? Pastebin? No. At the most it may make think it spam and ask you to enter a captcha.

So, why hasn't this been made a sticky????

Good question. I haven't been asked that in a while so it's time for the full response. I will not be distributing this mod on CKAN. I only distribute on CurseForge and here's my reasons. 1. CKAN has hijacked mods in the past, including one of mine. They assumed that because SOMEONE gave them permission to distribute a mod then it MUST have been the author. I like to know where my mod is being distributed. 2. Curse gives me one vector to distribute my mods, of which I have several, which is very convenient for me. I don't have to keep track of where my mod needs to get uploaded to or what hoops I need to jump through get it installed in this or that. I upload, they approve... done. Furthermore, as was the case with a Maritime Pack user recently, Curse maintains my archive of older versions so that should someone ask me for a KSP 1.3 version of my mod, I know exactly where they can download it. 3. Curse allows me to keep track of how many downloads each of my mods are getting in one very convenient place. And, I can even gauge how popular my mods are based on their placement. (Which is real nice since everyone has seemed to taken the lazy way out and click those like buttons in the forums rather than spend 30 seconds to actually type out, "Hey! Cool Idea!" 4. While it's paltry to the point of being a joke, at least Curse does give a minuscule cash reward for downloads. (In over 100,000 downloads I think I've accumulated enough points for $30.00 worth of Amazon gift cards... whoopeeee.) 5. Unlike other distribution vectors, Curse actually has an approval process whereby someone actually inspects the mods before they're being downloaded. This you should consider as a huge benefit because they take some responsibility to make sure the code is what it says it is and that it at least meets some approval standard. 6. And this one you should also appreciate... its the only download vector that is both, Squad approved AND has it's own button in the game menu. Now, I realize that was a rather lengthy reply but, I REALLY appreciate when someone takes the time to post a question, or comments or pictures on one of my mod's forum threads instead of clicking that like button. To show that appreciation, I'll also dedicate some of my time to respond. Hope that answers your question D: And feel free to like this response. ---->>> Oh, and this note from CKAN which was linking to Curse: "NOTE: The Curse API used by CKAN is disabled as of March 17, 2018. This prevents CKAN from automatically indexing mods hosted on Curse." If they ever get that worked out then I won't have a problem with my mods being on CKAN. Yea, it was a guess. I just recently took over this mod and asked the previous owner to either shut down his Curse project or at least redirect people. I guess he forgot. But, now you know where to find it.

Ok, here's the silly question. Did you download from the link I have in the OP or did you just find it in Curse and download it there? It sounds to me like you have v 0.4.2 or earlier. 0.4.3, the one in the OP, fixes that exact problem.

Ok, that sounds like an issue with either the plugin or the icons are missing. All of the balloons are set to category =none so if the plugin isnt' working they won't be visible. The parachutes though will. Did you have an old install of KerBalloons? If so, you need to delete it before installing this one.

Agreed! I do that for some of the files I use to save data with ConfigNodes so they don't get loaded as a .cfg file. It just never dawned on me to do the same for a .ksp file. Code in the tutorial changed and notes added. Thanks for the lesson D! Much appreciated.

Thanks, coming from the resident master of the UI and me being a bumbling hack, I take that as a compliment. I'm sorry I couldn't follow your tutorial, I did try at least 3 times and got lost all 3 of them. The reason I've been doing that is because I had an issue where one of my UI's, everything but the canvas vanished. Once I restored from a backup, I got in the habit of dragging down a new copy of the prefab, deleting the old one and renaming the new one. Now that you've explained a bit more about that blue color I've seen and that apply button I've also seen, I'll try to adjust my habits. I know there are certain files that KSP loads. like .cfg files. I wasn't aware that it loaded the .ksp files automatically. This method that I've stumbled into is more or less a collection bits and pieces from dozens of examples, either from the Unity docs or someone else's code. I'm guessing that somewhere I found that code to load the prefab and that it was with the .ksp extension and loaded in the Startup.Instantly. Thus far, and I've been checking the log frequently, I haven't had KSP hiccup or belch and it loads every time. I know with many file types I'm loading that the extension isn't needed. I'll start lopping it off in my code. The only odd thing I've noticed is the first time that I open the UI, it takes 2-3 second for it to appear. After that, it loads almost instantly. I'll make some notes in the tutorial to point to your comments. Thanks D!

I have not tried that. But, flight globals I do know are coming back with reasonably correct numbers. Therefore they should be loaded. I haven't tried checking for OnStartFinished, I will look into that. For now, I did the laziest thing I could do. I set up a delta time of 1 second in the fixedUpdate. Prior to that 1 second, it uses temperatures from FlightGlobals. After that, it switches to vessel.atmosphericTemperature. Although there is a difference between the two, it's not 9 MILLION degrees out of whack and blowing up my parts ;). Thanks for the suggestions. I'll check those. As I mentioned above, FlightGlobals is giving me somewhat correct answers. I just blindly assumed that if FixedUpdate was running (which is supposed to be for physics) that all of the physics was ready. Guess not.

Introduction I tried. I tried really hard to follow @DMagic's tutorial. I really did. I have one problem though. I'm old. How old am I? Old enough that the first programming language I learned was on a TRS-80 model 1 (with the cassette drive). I'm old enough that I know at least a dozen flavors of BASIC, to include GW Basic, Basic A, Commodore Basic, Amiga Basic, Visual Basic... and the list goes on. Being that old, I come from the school of line numbers. Everything should happen in linear sequence with gosub's and goto's. When look at what people today are calling object oriented and this callback and that callback and this get : set and... well... when I look at code like that I feel like I'm on a perpetual pogo stick and I can't get the hell off. Unfortunately, when I tried DMagic's tutorial I found that pogo stick and it dropped me on my head. Sorry D, you're way above my skills in coding. I needed something simple But, I really wanted a UI. I first tried the popup thing with a few buttons on it. And yea, that works, but it's not a "REAL" UI with cool things like sliders and buttons and checkboxes. And I know that Unity and KSP can do it. I've seen it. But the god awful examples I found were telling me I was doomed. I had to create these UI's from positions, and coordinates and lines and a gobbledygook of code that I couldn't even begin to visualize. Surely, there had to be an easier way!? And here it is. Proof that if you hate hard work, you can alway find a way to avoid it. The Lazy Coder's Guide to KSP UI Design This is no way a comprehensive tutorial on UI design. This tutorial is to give you the very basics. If you follow these steps, you should be able to create a working UI within KSP without creating any scripts in Unity. This is purely a Unity design-it, KSP execute-it method. With this working example I hope you will have the basics for adding a few controls from the Unity UI and be able to read from and manipulate them at run-time. This tutorial does make a few assumptions. That you have a basic working knowledge of Unity, that you have PartTools installed and working and that hopefully, you've created a few parts and a small plugin and you're ready to advance to UI's. In Unity In Unity, create a File/New Scene.. Up at the top of the scene, click on 2D. In the hierarchy panel in an empty spot, right click to bring up the pop-up menu. Scroll down to UI and in the pop-out menu, select Canvas. The Canvas is simply a container to hold the UI you're going to be working on. It's size is unimportant. You should also have seen that it created a new item called EventSystem. The default settings for both of these game objects is fine. Next, right click on the Canvas in the hierarchy and again, scroll down to UI and select Panel. This panel is going to be the background for your UI. Before we get into changing the background, we first need to set the size for our UI. By default, Unity sets the anchors for the panel at Stretch/Stretch. With the panel selected, look in the inspector and you'll see the anchors at the top left of the “Rect Transform” With stretch/stretch as the anchor method, Unity expect you to size your UI by the screen size. The settings it allows you to change are top, left, bottom and right. Those measurements are the distance from the edge of the canvas you created. For this tutorial we're going to make a UI of a fixed size. With the panel selected in the hierarchy, in the inspector click on the square with the blue plus symbol in it (one of the green arrows in the image points to it). This will create a popup that will allow you to change the anchor method for the panel. At the top left of that popup, select the image under the column 'top' and in the row 'left'. This now tells the Panel that you want it to align to the top left of the canvas. More importantly, it changes the rect transform to allow you to put in a height and width. There are two ways to adjust the height and width. One is to manually enter the numbers in the rect transform height and width boxes. The other is by using the mouse. Up above the hierarchy, click on the icon of the square with the dots in each corner. This will allow you to use the mouse and drag the corners to get the proper size. To change the background, with the panel selected in the hierarchy you should see in the inspector an 'Image (Script)'. The two important parts of this Image are the Source Image and the Color. By changing and adjusting those, you can choose the type of background you want for your UI, including how transparent it is by setting the color's alpha. This image shows some of the controls I've mentioned up till now and where to find them. A quick note. There's one very good reason to get in the habit of setting your anchors at least, to the same location. Once you get into more complex UI's it's becomes real handy to place groups of components onto even more panels. By anchoring to say, top left, you can always drag those panels around and all of the components under them stay in the same position. Next, we're going to add some controls to the panel. Select the panel in the hierarchy. Right click, scroll down to UI and select “Text”. This should put a new text object in the center of your panel. Let's change it's anchor to the same we used for the panel. With the text selected, in the inspector for the rect transform, open the anchor pop-up and select top left. Now you can either drag your text object around to where you want it placed or you can enter a Pos X and a Pos Y in the rect transform to place it. Following that basic procedure, place a toggle and a slider. Be sure to set the anchors to top left and make sure they're all under the panel in the hierarchy. Once you have them place, we need to change the names on these game objects. Rename the panel to “MyCoolUIPanel”. Rename the Text to “ImportantText.” While you're there and have it selected in inspector you'll see a “Text (Script)” In the box named “Text” change that to “We need to change this.” Next, rename the Toggle to “CheckThisOut” and rename the slider to “YouMoveMe”. At this point, your scene should look a lot like this: Next, in your assets folder, create 2 new folders. Call one UI Save and the other UI Export. Now, file/save your scene into the UI Save folder. You can name it whatever you like. In the project list, click on the UI Export folder which should be empty. Click and hold on the MyCoolUIPanel and drag it down to that empty folder. It should create a blue cube in that folder. That's the prefab for the UI. With that blue cube selected, at the very bottom right where it says “AssetBundle None”, click on the None and then select “New” It will expect a name so call it mycoolui. Your screen should look like this. (minus the day-glow arrows and such). A brief explanation. The reasons we put the saved scene and the prefab into separate folders is to prevent a collision. You CAN give the folder an Asset Bundle name and, in theory, it will try to take everything in that folder and create an asset. If you have the saved scene in there, it will promptly crash and burn. Therefore, the safest way I've found is to create two separate folders and everything that needs to get bundled goes into a specific folder. If this doesn't make sense now, just trust me. I'm saving you much pain. So, now we have our UI created and we've assigned it an asset bundle name. It's time to export it. In the main menu, select KSPAssets/Asset Compiler. A new window should pop up with some buttons. With any luck, you should see one that says mycoolui with a button that says “Create” beside it. Click on the create button. That hopefully made some new buttons available. If you want to see what files are being included in the prefab you can click on view. Click on Show All to get back to this menu. The two important buttons here are Update and Build. First, get in the habit of clicking the update first and then, click the build. A brief explanation. What we just did was we created an asset bundle that KSP will recognize. Any time you make changes to your UI or you add new items like graphics, you need to place them in the folder that holds the export and assign the asset bundle name. For example, if you change an item in the UI you'll need to delete the old panel prefab, drag the panel back down to the export folder to create a new prefab, set the asset bundle name and then, in the asset compiler, click update then build. Update: DMagic, the master of the KSP UI has informed me that replacing the prefab as I have been doing isn't necessary. His comments on how to update the prefabs are here: Once you click on the build, it will likely take a second or two. First, make sure that nothing went wrong. Click on the console tab at the bottom of Unity and make sure that you don't have any red exclamation marks. If you do, click clear on the console and try to build again. I'm not going to go into the possible errors but if you do have one, I warn you, they will often be cryptic and I wish you luck figuring out what you did wrong. So, assuming everything went right, you have a new bundle. The problem is, you're not going to be able to find it in Unity. So, close out Unity and open your favorite file explorer/manager. Navigate to the folder where your project is and along with the Assets folder, you should see a folder called AssetBundles. Open that folder and, if you were successful, you have a new file there called mycoolui.ksp. That my dear pupil, is your UI ready for use. The Code Now we're going to dive into the ugly part. The coding. But before we do, we need to get a few things set up. We're going to need to create a new plugin and, we're going to create a very simple partmodule. So, in your GameData directory for your KSP install, create a new folder and call it “mycoolplugin.” Open that folder and create two more folders, Parts and Plugins. Go back to your Unity project / AssetBundles folder and copy the mycoolui.ksp file into the Plugins folder you just created. Now, change the file extension on the mycoolui from .ksp to something else, like .dat. More on the reason for that in a bit. Now, let's get busy coding. (At the end of this tutorial is the full code needed for both the partmodule and the monobehaviour.) I'm not going to go into depth on how to set up to code. This is a tutorial about making a UI so some knowledge of your IDE and how to set up references is assumed. The only thing out of the ordinary that you'll need to add is the UnityEngine.UI as a reference. First we'll need a part. I have conveniently appropriated one from the Squad repository and repurposed it for our needs. Here's the .cfg info. Copy this and save it into the part folder as... oh... part.cfg. PART { name = CoolUITestPart module = Part author = RoverDude rescaleFactor = 1.0 node_attach = 0.3, 0.0, 0.0, 1.0, 0.0, 0.0, 0 TechRequired = precisionPropulsion entryCost = 1200 cost = 50 category = Propulsion subcategory = 0 title = Cool UI Test Part manufacturer = #autoLOC_501633 //#autoLOC_501633 = Probodobodyne Inc description = #autoLOC_501812 //#autoLOC_501812 = Often, and mistakenly used for playing ball games. attachRules = 0,1,0,1,0 mass = 0.01375 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 2 crashTolerance = 5 breakingForce = 50 breakingTorque = 50 maxTemp = 2000 // = 3000 fuelCrossFeed = True bulkheadProfiles = srf tags = #autoLOC_501813 //#autoLOC_501813 = fueltank ?lfo liquid oxidizer propellant rocket MODEL { model = Squad/Parts/FuelTank/FoilTanks/RadialTank_Round } MODULE { name = CoolUIPM } } You probably noticed that I chopped out most of what we won't need and added in a couple of lines to call our plugin. The partmodule is going to be really simple. We only really need it to do one thing. Open the UI. But, I'm also going to add in a progress bar and a few lines of code that we can play around with. The first bit we'll add in are two KSP fields. One is our toggle button to open the main UI and the other is the progress bar. namespace mycoolplugin { public class CoolUIPM : PartModule { //Create a copule of cool things for the part UI that we can play with //a button to toggle the UI on and off [KSPField(guiName = "Open UI", guiActiveEditor = true, guiActive = true, isPersistant = false), UI_Toggle(controlEnabled = true, disabledText = "Closed", enabledText = "Open", invertButton = false, scene = UI_Scene.All)] public bool openUI = false; //and a progress bar that we can play with [KSPField(guiName = "Cool Slider", guiActiveEditor = true, guiActive = true, isPersistant = true), UI_ProgressBar(minValue = 0f, maxValue = 1f, scene = UI_Scene.All)] public float PartUICoolSlider = 0.0f; In the OnStart, we need to create a callback. These few lines of code are going to perform a critical function. Any time the part UI toggle button is clicked, it's going to call the function to either show the UI or destroy it. Wait? Destroy it? Why would we want to do that? Simple. The UI's are very persistent ... really persistent. If you open a UI in the editor and then launch, it stays open. If you open one then switch from the SPH, to the VAB, it stays open. It'll even stay open when you exit out to KSC. For our purposes, we don't want that. We only want it to show the UI when the user is where that part is. So, whenever the user clicks on the partmodule toggle button, we want to either open or destroy the UI. This chunk of code triggers that. NOTICE: This callback is set up to work in the editor only. Note the .uiControlEditor. That prevents that callback from working anywhere BUT the editor. If you want your UI to be available in flight, you'll have to change that to .uiControlFlight. public override void OnStart(StartState state) { //This creates a callback so that whenver the UI_Toggle openUI is clicked, it either opens or closes the main UI Fields[nameof(openUI)].uiControlEditor.onFieldChanged = delegate (BaseField a, System.Object b) { if (CoolUI.CoolUICanvas == null) { CoolUI.ShowGUI(); //if the UI doesn't exist, create one and show it. } else { CoolUI.Destroy(); //if it does exist. they're closing it so get rid of it. } }; } Next, the FixedUpdate. The first thing we need to do here is check and see if the UI is already open. The reason we do that is because we may have a bunch of parts on the vessel with our same partmodule on them. If the UI is open, then that means someone clicked on the button to open it. We need to set all the UI_Toggle buttons on all of our parts to true. For this example if the UI isn't open (it's null) then leave FixedUpdate. Otherwise, trying to get info from a non-existent UI will create a null reference error. In the final 2 lines are were we're going to manipulate things on the UI. First, we're going to set the value of our progress bar to the same value as the UI slider. Next, we're going to update the UI text so that it shows us a text value of the slider's position. public void FixedUpdate() { //This checks to see if the UI is being shown. If so, it will update any other CoolUIPm partmodules so that they show the button as being clicked. if (CoolUI.CoolUICanvas != null) { openUI = true; } else { return; } //if not, we don't want to call UI functions because they'll create a null ref. //This is going to take the partmodule UI_ProgressBar and make it the same as the UI slider. PartUICoolSlider = CoolUI.CoolSliderPosition(); //This calls the procedure to update the main UI text give a number representation of the slider position. CoolUI.UpdateText(PartUICoolSlider.ToString()); } } } Ok, that's it for the partmodule. See, it was easy. Now for the harder part, the Monobehavour. The first thing we need to do is to create a loader. This monobehaviour, CoolUILoader, has the sole responsibility of finding the asset bundle and loading it up as a gameobject. We're going to do this in StartupInstantly so that it gets loaded early. This code is looking for the bundle in the same directory that the plugin is in. So hopefully, when you create this plugin, you put both it and the bundle in the same folder. Update: DMagic, the master of the KSP UI, has informed me that loading the prefab manually as I do in the code below and with the .ksp extension may not be necessary and may even cause issues. He also suggest renaming the extension from .ksp to something else which makes perfect sense. KSP loads a number of files automatically, like .cfg files. By changing the extension of the file name, you can guarantee that KSP won't load it before you do and thus, create a problem when your code tries to load it and can't because it's already loaded. Therefore, if you remember, we renamed the bundle file to mycoolui.dat. Here's where we load it. You can read his comments here: using System.Collections.Generic; using System.IO; using System.Reflection; using UnityEngine; using UnityEngine.EventSystems; using UnityEngine.UI; namespace mycoolplugin { [KSPAddon(KSPAddon.Startup.Instantly, true)] public class CoolUILoader : MonoBehaviour { private static GameObject panelPrefab; public static GameObject PanelPrefab { get { return panelPrefab; } } private void Awake() { //The way I was doing this which does seem to work. //AssetBundle prefabs = AssetBundle.LoadFromFile(Path.Combine(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location), "mycoolui.ksp")); //DMagic's method without the .ksp file extension AssetBundle prefabs = AssetBundle.LoadFromFile(Path.Combine(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location), "mycoolui.dat")); panelPrefab = prefabs.LoadAsset("MyCoolUIPanel") as GameObject; } } Next, the meat, the UI code itself. Taking a look at the code, the first thing you should notice is that it's a Startup.Editor only. This matches the code in the partmodule that indicates we only want to show our UI in the editor. You'll need to change this if you want users to see it anywhere else. First, we declare some variables. I'll explain them as we get to them. The first function is the Awake function. This has one line but an important one. This creates a callback so that any time the KSP scene changes, our code can be notified. The next function is what that callback calls and it's really simple. If the UI exists, call the Destroy function. This ensures that any time we switch scenes in KSP, the UI gets destroyed and the canvas gets set to null. The Destroy function also does one other small task. It looks for all of our partmodules and sets the UI_Toggle button to off. This makes sure that when the user opens the partmodule UI that all of the 'open ui' buttons look the way they should. [KSPAddon(KSPAddon.Startup.EditorAny, true)] public class CoolUI : MonoBehaviour, IBeginDragHandler, IDragHandler, IEndDragHandler { public static GameObject CoolUICanvas = null; public static GameObject CoolUIText = null; public static List<CoolUIPM> CoolUIParts = new List<CoolUIPM>(); private static Vector2 dragstart; private static Vector2 altstart; private void Awake() { //this creates a callback so that whenever the scene is changed we can destroy the UI GameEvents.onGameSceneSwitchRequested.Add(OnSceneChange); } //If we don't get rid of the UI, it'll stay where it is indefinitely. So, every time the scene is changed, we need to get rid of it. void OnSceneChange(GameEvents.FromToAction<GameScenes, GameScenes> fromToScenes) { if (CoolUICanvas != null) { Destroy(); } } //This actually destroys the UI. But it also goes through the partmodule's toggle buttons and turns them all off. public static void Destroy() { CoolUICanvas.DestroyGameObject(); CoolUICanvas = null; foreach (CoolUIPM thisPart in CoolUIParts) { thisPart.openUI = false; } } The next function shows the UI. The first thing we need to check is whether the UI is already on the screen. If so, we need to stop. The next 3 lines handle calls our loader and assigns the prefab to the CoolUICanvas. The easy way to think of this, the CoolUICanvas is the main panel we created in Unity where all of the controls are placed. The next line tells the canvas that it should make the main screen canvas it's parent. Then, it ads the UI to the screen. public static void ShowGUI() { if (CoolUICanvas != null) //if the UI is already showing, don't show another one. return; //Load up the UI and show it CoolUICanvas = (GameObject)Instantiate(CoolUILoader.PanelPrefab); CoolUICanvas.transform.SetParent(MainCanvasUtil.MainCanvas.transform); CoolUICanvas.AddComponent<CoolUI>(); The next 4 lines in the ShowGUI are setting some information we need. The first one locates the text object we put on the UI and assigns it a variable, CoolUIText. The next 3 lines create yet another callback. This callback will fire any time the user clicks on the main UI toggle button (the check box). You'll see the words AddListener and then delegate. Basically, any time the checkbox is clicked on, it will fire off the function OnToggleClicked and pass a variable, isOn. This isOn variable is read from the Unity prefab and tells us if the checkbox is checked or not. //Find the game objects that we gave cool names to in Unity CoolUIText = (GameObject)GameObject.Find("ImportantText"); //This is a toggle so we need to create a callback for when it gets clicked on GameObject checkToggle = (GameObject)GameObject.Find("CheckThisOUt"); Toggle toggleButton = checkToggle.GetComponent<Toggle>(); toggleButton.onValueChanged.AddListener(delegate { OnToggleClicked(toggleButton.isOn); }); } One thing to take note of in these lines of code: We're telling Unity to find certain game objects. The name you pass to this has to match the name you gave them in Unity. For example, if you remember, we renamed our text object “ImportantText” in the Unity prefab. Here, we're telling the code to find that object by name and assign it to CoolUIText. If we look at the next few lines of code, the OnToggleClicked function, it starts to make sense. If the checkbox in the UI is checked (ison=true) we send a screen message. Otherwise, we send a different one. //this is the callback we created for when the toggle button is clicked. static void OnToggleClicked(bool ison) { if (ison) //ison is determines if the checkbox is toggled. In Unity it's in the "Toggle (Script)" as "Is On" { ScreenMessages.PostScreenMessage("Hey, you turned it on!"); } else { ScreenMessages.PostScreenMessage("Bummer, you turned it off."); } } The next small function allows us to set the text in the UI to whatever we want. We take the text gameobject, get the text component from it, and change the .text field. //this function is where we update the text component on the UI. public static void UpdateText(string message) { CoolUIText.GetComponent<Text>().text = message; } The next 3 functions are all about moving the UI around. If you were observant, you probably notice that at the beginning of the monobehaviour declaration there were a few extras: IBeginDragHandler, IDragHandler, IendDragHandler. These are basically telling this monobehaviour that we're going to be doing some UI dragging. And that's handled in the next 2 functions. OnBeginDrag sets a couple of vectors to remember where the drag started in relation to the screen and where our UI was located. In the OnDrag event, two more vectors are calculated to determine where the UI is moving from, where it's moving to and how far the UI should be moved. Then, it plops the UI in the new position. While this at first seems like an odd way to do it, that it's constantly picking up, moving and dropping the UI. But, it happens so fast that it appears extremely smooth. There are other drag events that you can tie into. I included the OnEndDrag event with just a comment and give you something to think about. If the drag event is ended, the UI position will be at the CoolUICanvas.transform.position. The code I have here creates the new UI and essentially plops it down screen center every single time it's opened. Could you possibly use the transform's position and the OnEndDrag event to save it's position and then, when the ShowGUI event is run again and the UI is created, it's restored it to the position where it was last dropped? //this event fires when a drag event begins public void OnBeginDrag(PointerEventData data) { dragstart = new Vector2(data.position.x - Screen.width / 2, data.position.y - Screen.height / 2); altstart = CoolUICanvas.transform.position; } //this event fires while we're dragging. It's constantly moving the UI to a new position public void OnDrag(PointerEventData data) { Vector2 dpos = new Vector2(data.position.x - Screen.width / 2, data.position.y - Screen.height / 2); Vector2 dragdist = dpos - dragstart; CoolUICanvas.transform.position = altstart + dragdist; } //this event fires when we let go of the mouse and stop dragging public void OnEndDrag(PointerEventData data) { //humm... this would be a good place to record the UI position after it moved } Finally, a short function to handle our slider. This function looks for a slider gameobject on the UI named “YouMoveMe” and gets the slider component. It then returns the value, which is the position of the slider in a range from 0 to 1. In Unity, you can change the slider range easily by changing the min and max values. You can also make it slide right to left, return whole numbers... just a whole range of options. //This function grabs the position of the UI slider public static float CoolSliderPosition() { GameObject slider = (GameObject)GameObject.Find("YouMoveMe"); Slider thisSlider = slider.GetComponent<Slider>(); return thisSlider.value; } } } As a matter of fact, you can easily create a UI to look pretty much any way you want. Each component of the Unity UI has the ability to change the way it looks, not only by color but by adding in custom graphics. If you do decide to play around and add your own graphics, you need to remember to add them to the asset bundle. Which is another reason I suggested the export folder. Drag your graphics to the export folder and add them to the asset bundle (remember, Unity, bottom right, mycoolui). When you update and build your asset bundle, the Asset Compiler will include those graphics in the bundle and... like magic they get included in your cool UI. So, if you got all of your UI right and you got the asset bundle created and in the right spot, and you create this plugin and have it run flawlessly, you should see something like this in KSP I hope I've done a reasonable job of explaining what I think is the easiest method for creating a Unity UI. If you have any questions or if I didn't explain something well enough, ask me. Be sure to @ me or quote me for a faster response. I'll attempt to give you a reply without using line numbers. If you see any glaring mistakes in my code. TELL me so I can fix them. If you have an urge to update, upgrade, refactor, optimize or otherwise 'improve' my code and then tell me that I did such and such when instead I should have.... allow me to give you an old coder's axiom. “When the only tool you have is a hammer, everything begins to look like a nail.” I really like my hammer. It's simple. I understand it. It works. And it'll beat the crap out of a pogo stick. *snort* And finally, here's an example of a UI I'm using on a current project. These are all Unity controls but I've replace the graphics with some very simple ones I created. But, 5 simple images that took me 15 minutes to create, it completely changed the look of the UI from the stock controls we're all familiar with. I'm looking forward to seeing some of your cool UI's in the future. Complete PartModule Code Complete MonoBehaviour code Spoiler. How to save and load your UI's position so that it always reappears where the user put it.

Ok, you had me for a second. When I recompiled the mod for 1.4.x I didn't actually test the spotlight. I did test the idiot lights which use the same plugin. So, I downloaded the mod from Curse and installed it and, the spotlight rotated for me. So, that pretty much eliminates what is always my first suspicion, that I screwed up. What you're seeing in the .cfg is just information the plugin uses so that it knows that that part can use the pan and tilt and that's normal. It's not exactly a stock animation as you would see in the .cfg the words AnimateGeneric. It's all custom code. The blinking is also controlled by the same plugin. So it makes sense that if one doesn't work, the other won't either. But, the lights turning on and off is also the same plugin so it doesn't make sense to me that part of it should work and another part won't. But, it's entirely possible. So, let's go with the assumption for now that it's your specific install that's having issues. What I'd like you to do is to perform a quick test and allow me to take a look at the KSP log to see what might be causing the problem. Let's try this: Fire up KSP. Go into the SPH or VAB and place any random part. Place a spotlight on it, right click the spotlight to bring up the UI. Click on the pan and tilt speed bars so that they are both around 50% green. Click on the 'pan/tilt' light button to open that UI. Try to pan and tilt. If it doesn't pan or tilt, do the next steps. Exit KSP. Go to your KSP install directory. Open the KSP.log file with an editor like notepad. Select all of the text and copy it. In a browser, go to pastebin.com Paste the copied text in the box provided and select 'create new paste' Copy the URL that it sends you to. Quote this post and paste that URL here. (make sure you quote this post or use an @fengist so that I get the notification. I have 4 mods and about a half dozen threads I watch. Quoting me or @ing me gets my attention the quickest.) Forgive me if I oversimplified that process.

If you're talking about AVC you need it in two places. The first place is with your mod. The second place is somewhere on the internet. The basic way it works is the AVC/MiniAVC mod looks at the .version in your mod's folder. It then looks at the URL you have in the version file and compares that to one you have on a website. If the two matches, it does nothing. Otherwise, it gives the notice. Here's a basic PHP file that I use for Maritime Pack. You'll note that I have id=1 as the query string for the URL. Buy doing that, I'm able tell MiniAVC to check the same PHP file but have it select from multiple mods. If you have any questions or need help making a PHP file, PM me. Not sure if @linuxgurugamer still has it, but there used to be a website where you could create and store your remote .version files. Check here: <?php header('Content-Type: text/plain'); if ($_GET["id"]=='1') { echo '{ "NAME": "MaritimePack", "URL": "http://www.datainterlock.com/Kerbaltopia/AVCCheck.php?id=1", "DOWNLOAD": "http://kerbal.curseforge.com/projects/the-maritime-pack", "VERSION": { "MAJOR": 0, "MINOR": 1, "PATCH": 11, "BUILD": 0 }, "KSP_VERSION": { "MAJOR": 1, "MINOR": 4, "PATCH": 0 }, "KSP_VERSION_MAX": { "MAJOR": 1, "MINOR": 4, "PATCH": 99 }, "KSP_VERSION_MIN": { "MAJOR": 1, "MINOR": 4, "PATCH": 0 } }'; ?>

Just a quick note to give an update. Still working heavily on the other project. But I did get time to look over the old parts and the files left by JoePatrick1. What I discovered was well... he said in the original thread that it was a bit disorganized and he wasn't kidding. But, I was able to accomplish one goal. I was able to extract one of the balloons from the Unity project files and move it into it's own folder (Joe had ALL 16 balloons in one Unity scene). With that one balloon I was able to do some testing. Another modder, Allista (I won't @ him either, he's quite busy) has given me permission to fork some of his code and use it in my projects. His plugin is officially know as the anisotropic part resizer. While that's a bit of a mouthful, it's just a souped up tweak-scale. But, It does allow you to resize parts in 2 dimensions. While not as adept as say Procedural Parts and probably not as well rounded as Tweak-Scale, it has one huge advantage. With him allowing me to re-purpose that code and include in my projects. it means that I can choose parts from my mods and allow users to resize them without having any dependencies. Those of you who are familiar with my other mods know that I loathe dependencies. So, what does that mean for KerBalloons? I was able to take the model for the 3.75 balloon, scale it up and scale it down and have it work perfectly. One of the things I hope to use this for is a sweeping part reduction overhaul. As it stands now there are 16 models and 48 .cfg files. With the part resizing and by taking the .cfg file data, stuffing it into the plugin and have it as selectable items in the part UI, I think I can reduce that to 1 part, 1 .cfg and still provide all of the functionality and flexibility KerBalloons currently has (maybe even add some new sizes in). So, if you have a potato with limited ram, I may be making some room for yet another mod... Soontm The little white specks are Kerbals

A study regarding the feasibility of airships using real-world physics within the scope of KSP. Disclaimer: First and foremost, this is not a rant. Don't portray it as one as you'll be promptly ignored. Secondly, this is not a criticism of any work by any modder. God knows there are fewer and fewer of us left and I'm not one to chase any of them off. This is merely my opinions and nothing more and is in no way intended to be insulting to anyone. Years ago, I fell in love with a mod. And not long after it's birth, it was buried. This dissertation, wall of text, manifesto, ramblings of a mad man, call it what you wish, is me thinking out loud to the KSP public about the creation of a very similar mod. This thread will serve 2 purposes. A place for me to place these ideas and a future reference for those who will want to understand my reasonings. A place for you to discuss and, more likely, correct my mistakes. A brief history of the KSP Airship. Hooligan Labs Airships - This was the first airship mod to grace KSP. Coming to the scene in 2013, it was the first mod that attempted to broach the lighter than air concept (as far as I know). The models used to the parts were very futuristic in concept. Some appear completely hollow yet somehow generate lift. While this in itself isn't a bad thing, it did require a bit of imagination to convince yourself that they were airships. After passing through several hands, it's still pretty much as it was when released having spent the last couple of years in maintenance mode. You can find it here. pros: It got fans of airships off the ground and allowed players to experience flight in the slow lane... or maybe the static lane would be a better choice of words. It worked on any planet with an atmosphere. You could stick them on top of a rocket and they'd normally survive reentry. They also featured envelopes that expanded procedurally which meant that you could leave them uninflated until arrival at a launch destination. cons: Unrealistic flight model. There were virtually no real-world physics calculations involved with Hooligans. While atmospheric density and g-force were included in the calculations, the buoyancy model was such that they were more like helicopters. You could maintain precise altitudes by just setting a slider and then rocket your balloon around mere meters off the ground. Procedural Airships - This mod entered the scene less than a year after Hooligan's. Based on the Procedural Parts mod, Procedural airships allowed the player to not only size and scale the airship, it also allowed different meshes to be used for parts like end caps. This meant, instead of adding yet another part to the collection, the user clicked a button to cycle through those available. The first nail in it's coffin was a major update to the Unity UI system. I once spoke to @RadarManFromTheMoon about reviving it and he basically said the entire UI was trashed and didn't have the time to rework it. The final nail came when Procedural Parts became orphaned for a period of time. Without this dependency working, ProcAirships wouldn't work even with a new UI. Though it hasn't worked since 0.90, you can find it here. pros: Actually looked like real-world airships. Being procedural, they could be scaled and resized in the editor to suit the players needs. It used many real-world airship features like ballast dumping and balloonets. It also had the ability to vent lifting gasses. It's flight model took into account not only stock atmospheric modelling but that of FAR and NEAR. Most importantly, it used the ideal gas law as the basis for it's lifting calculations and took the molar mass of lifting gasses into account. Once you learned how to fly them, it 'felt' like you were piloting a zeppelin. cons: Dependent upon another mod for all of it's parts. Instead of using familiar lifting gasses RadarMan created his own, Liftium and Combustium, which roughly translated into Helium and Hydrogen. I list that as a con because KSP is a game replete with resources and the more familiar ones could have been used without detriment to the mod. Difficult to fly. This was the first mod I ran into that pretty much required you to follow it's built-in tutorial. There's a review of the mod by @Kottabos where he detonated an airship while sitting on the runway from accidentally overpressurizing it. Blowing them up was wayyy too easy. Limited parts. There were only 3 parts, 2 envelopes and 1 ballast tank. But, they were procedural so it felt like more. Aerostats - This mod came out in early 2016 as a WIP and, unfortunately, never progressed beyond that state. @wasml, the author of that mod, had the basis for an airship that followed real-world physics. Using Hydrogen and Helium for the lifting gasses he also applied the ideal gas law in order to achieve lift. Because this mod never moved into release status, I'm not going to list any pros or cons. Suffice it to say that what he had and, from the code I've seen, what he was planning on, would easily rival the two previous mods. One thing I will note is that wasml intended on having his envelopes leak (which is very realistic), and in the WIP I found, leak they did. They stated leaking the instant I launched. If I still had any lifting gas left and managed to get airborne, I spent more time clicking on the envelopes and then clicking on his 'repair' buttons than I did flying the airships. I did get this mod working but I believe it required that I recompile the plugin. You can find it here. Heisenberg Airships - Also coming out in 2016, @Angel-125 has done a fine job modelling airships and of all the airship mods, his has the most extensive part collection and allows for very historic looking airships. Because this mod has Hooligan's asa dependency, I won't go into any pros or cons for it either. However, I will say that because Hooligan's physics are the underlying code for lift, it allows for some rather unrealistic, albeit very unique, designs. You can find it here. *edit* I've been informed that I kinda forgot one though I'm not sure it qualifies: KerBalloons - Originally by JoePatrick1, KerBalloons are very simple devices designed primarily to gather science. While I have seen some cases of people strapping engines onto them and using them for sky-diving platforms, I don't really consider them to be airships. An entertaining mod and useful for gathering cheap science on a variety of planets, they don't use any real-world physics, including the fact that their vertical ascent is hard-coded. Though they do simulate balloons to a reasonable degree and they are capable of carrying Kerbals aloft, the only methods for controlling vertical ascent is to completely deflate them or wait for them to expand to the point they pop. Just recently JoePatrick1 gave me his blessings to take over this mod. And now that you have an idea of what's on my brain I assume you can see my interest in it. If these experiments go well, KerBalloons may be using real-world physics in the future. You can find it here. *end edit* So, if you haven't guessed, my preference toward airship mods is slanted toward those which are based on reality. Unfortunately, it's been a couple of years since such a mod existed or was even being planned. Now before you start shaking a finger at me and pointing toward some of my more unrealistic mods and resources (compressed water), yes, I do have my quirky side and I fully realize that the only way to simulate real life is with... well, real life. But for the most part, I do try to base my mods on reality (ok, 1869 is an exception where I just do what I want.). When it comes to flying an airship tough, I want it to feel like I'm wearing a tophat and try to relive some of their victorian history. The basic physics of airships So, before I go jumping off any bridges, an understanding of how airships work is in order. Airships, and naval ships for that matter, create buoyancy by displacing something heavier. A ship on the ocean floats because it creates a hole in the water. It does this by shoving water aside and replacing it with something much lighter, air (for the most part). Airships employ the same principle. They are able to float because they create holes in the atmosphere. Their envelopes allow them to shove air aside and replace it with something much lighter, lifting gas. When this hole is created, lift is the result. In the world of Kerbals, air and water are intangible objects. You can't create holes in them. But, the physics around them are accurate enough that you can simulate a hole. For the purposes of an airship, this simulation can be accomplished using the Ideal Gas Law. The ideal gas law basically states that if you know a few things about a gas, you can discover others. For example, if you have a gas inside a balloon and if you know what elements the gas is comprised of and what the pressure and volume is, you can calculate the temperature. As strange as that sounds, the balloons you played with as a kid can act as a thermometer. Fortunately in KSP, a lot of those pieces of information are already programmed into the game like air pressure, temperature and substance densities. Volume can be calculated by performing some basic geometry on the parts in the game. So, all of the numbers necessary to plug into the ideal gas law either already exist in-game, or they can be calculated with a bit of math. Once you start looking into the ideal gas law, you find out you can come up with some other calculations to help simulate the hole. For example. If you know the density of the air outside your craft (which KSP provides) and you can calculate the density of your lifting gas, finding out how much your airship can lift is easy. It's (atmospheric density - gas density) * gas volume. You're replacing a volume of air with the same volume of a lifting gas. So, the amount you can lift is equal to the weight of the air you shoved out of the way. If you take that number and multiply it by the local gravity (which KSP provides), that formula will tell you how many newtons of force that volume of gas can exert. If you know KSP, you know all thrust in the game is based on newtons. Lifting Gasses Lifting gasses are what we replace the air in the atmosphere with when we create those holes I mentioned. Traditionally, we're familiar with hydrogen, helium and hot air. The requirement for a lifting gas is that it have a density less than the surrounding atmosphere. The ultimate lifting gas isn't a gas at all. It's a vacuum. Francesco Lana de Terzi (known as the father of aeronautics) realized as long ago as 1670 that a vacuum would be the perfect lifting medium because, unlike any lifting gas, it has no mass. Every bit of air shoved out of the way by a vacuum would be converted into lift. The problem there is, the mass of the container you need to hold a vacuum would weight more than the air you moved out of the way. Perhaps in the future when material science creates something strong and light enough, a vacuum airship will be feasible. Today, it's not. While we're familiar with most of the common lifting gasses, there are literally dozens of possibilities. And with the KSP system of resources all of those are possible. It'll even be possible to simulate coal gas by converting in-game ore into a gas. So none of those are out of the question. But if you read closely, at the bottom of that list, you'll see something KSP doesn't do well, mixing of resources. Up till now, lifting gasses in KSP airship mods have been one gas at one density. In the real world, gasses can be easily mixed. And the math behind mixing of gasses is easy. You add the pressure created by one gas to the pressure created by the other gas and you have the total. Here's the problem. When you mix two gasses, like hydrogen and helium, the density changes. All KSP resources have a fixed density. If you mixed two gasses together and came up with a new density, you'd have a new resource. That also means that even a small fractional change in the mixture of gasses, would also change the density and thus, yet another new resource. So, as you can see, mixing of gasses in KSP would be a bit impossible . You'd essentially have infinite resources clogging your computer memory. Unless, that is, if you didn't consider it a resource at all. It would be easy enough to track how much of each gas (say hydrogen and helium) go into a bottle. By remembering how much goes in, you could calculate the densities and thus, it's lifting potential. So mixing gasses is possible and realistic results could be achieved. The down-side to that is, you wouldn't be able to use those gasses as a KSP resource. Meaning, moving the gasses between various parts wouldn't happen. The question is then, which would be more realistic? Allow the mixing of lifting gasses or have a single gas but treat it like a resource? There is another option, and this is something no other airship mod has attempted (to my knowledge). Liquified gasses. Hydrogen, like many gasses, can be compressed into a liquid form. Suppose an airship mod allowed those liquified gasses to be moved around, loaded onto trucks or rockets and even bolted onto the side of the airship. When the airship needed a lifting gas, it would simply open the valves and instantly create the gas. You'd have a very compressed form of the lifting gas, a resource that several mods already include as collectable/minable and you could take a supply with you. Once converted from liquid to a gas inside the airship, it would be a 'use it or lose it' though. And, lifting gasses would not be a resource you could fill in the editor. It would be something you'd have to create after you launch. Weighing in at roughly 0.68 mt at launch, this is a rather small test airship. Using hydrogen it's total lift was just over 0.91mt. In this image 700 L of liquid hydrogen was used to fill over 800 m3 of volume (I blew a lot out the forward vent because I over-inflated the nose, was tail heavy and lost a lot of gas balancing.) Other lifting methods So, if you took the time to look over the available lifting gasses on Wikipedia, you probably noticed there are quite a few. Most, if not all of those can be turned into a lifting gas in KSP. So, the physics needed to get airships off the KSP runway exists. There is a slight problem though: being able to make the ship realistic yet, light enough for the gasses to lift it. While my testing is showing that even a small airship of a metric ton or so with enough space to carry a couple of Kerbals around can get off the ground, the envelopes are filled almost to capacity, leaving very little room for cargo. Fortunately, lifting gasses aren't the only way to get an airship off the ground. The USS Macon (above), given to the US as part of Germany's WW1 reparations (corrected, that was the Los Angeles) had a rather unique engine arrangement. By placing the engines inside the airship skin and mounting them at a 90 degree angle to the direction of travel, it allowed the props to be rotated. But, if you look at the second and third image, which is supposedly from the USS Akron, the Macon's sister ship, you'll notice that the mounting brackets prevented the props from rotating directly upward, meaning they were most likely used exclusively for descent. Whether they were connected to a transmission that allowed the prop rotation to be reversed, I wasn't able to discover. Either way, this was a huge improvement in engine design compare to earlier airships like the USS Shenandoah. Prior to rotating props, airship engines were so large that the designers actually called them cars and they were large enough that the crew worked inside the compartment. Today, modern airships employ the rotating engine technique. Most everyone knows that airship, the Goodyear blimp. Here's a good shot of two of it's engines rotated for an assisted take-off. But hey, we all play KSP and we all know the ultimate solution to getting off the ground is always moar boosters. Well, apparently that was thought of too when it comes to airships. The first attempt at moar boosters was with the Piasecki PA-97 helistat - a conjunction of helicopter and aerostat. If EVER there was a Kerbal airship, this would have been it. What do you get when you take a 50 year old blimp, weld up a bunch of pipe and then, bolt on 4 junked Sikorsky H-34 helicopters with their tail rotors chopped off? And then, you put a pilot in ONE of those helicopters with a bunch of cables running to the others so he can control them.... well, you have a Kerbal day in the making. Now keep this in mind. This thing was built in the 1980's. Yes... that's right. The Concorde had been flying for over 10 years and this thing, a $40 million investment in 1980's dollars, was supposed to be a technological leap forward? Well, as I said, it was a Kerbal day in the making. All it took was a gust of wind across the tarmac a vibration ensued and all 4 helicopter rotors became unbalanced, ripped through the blimp and then promptly broke off the tube frame. Unfortunately, the pilot lost his life in that accident. Fortunately, that's when the project came to a screeching halt. But. That was not to be the last word on the marriage of a helicopter and an airship. Boeing has teamed up with a Canadian company (who holds the patents) and are in the early stages of creating the SkyHook (HLV) heavy lift vehicle. While this is just one artists rendition of it, if you do some digging you'll find the images presented by Boeing are considerably different. I can't post them here, they want MONEY for their images. While this is still in the early stages, they're claiming it can lift 40 tons and carry it some 200 miles. And then, there's the hybrid airships. Some include wings, like aircraft and some, like the hybrid being built by Lockheed-Martin, is a lifting body, So now you've seen some of the alternate lifting methods that have been associated with airships. Here's the good news. None of these designs are outside of the scope of KSP physics. All the lift and thrust elements are there. Now, which ones are going to be practical to design? Rotating engines? No problem. Helicopter rotors? No problem. Wings? Already there. Lifting bodies? Already in the game but... that's a stopping point. While it would be possible I don't foresee at least me doing it. And the big reason would be, it would require a specific shape. Old airship and blimp designs may have some lifting properties to their shape but it would be so negligible in KSP that I'm not going to spend that much time trying to factor it in. Creating an airship specifically with lifting body properties would lock players into a pretty rigid design. And that's not what KSP is about. But helistats? Yea... I want one of those. Even if it is a Kerbal design in the making. At roughly 1.2 metric tons, this airship was the first test flight of a 2 Kerbal gondola. Still learning the balancing properties, I wasted a lot of liquid hydrogen getting it adjusted. If you look at the cell inflation bar, it's at about 90% so there's still room to get a bit more lift out of it. But really? A comparison of fruits. So far in this rant, dissertation, manifesto, I've focused on the physics of getting airships off the ground. And, as you've seen from the screenshots, those numbers can be applied to KSP and made to work. And I've even delved into the fanciful of helistats and from the screenshots in some of my replies, even they appear to work. But seriously. How close do these airships come to what really files? Thus far, the airships I've shown have been rather tiny by historical comparisons and pretty small even by modern standards. Even the helistat I posted below was breaching the limits of it's capabilities just lifting a 9mt weight. Up until now, I've been testing the lower limits of what was possible. I wanted to make certain that at least on Kerbin that a simple 2-Kerbal airship was doable and easy enough to fly. From what I've learned, if an airship is light enough you can get away with not much more than 1,000 m3 of gas. When you compare those small airships I've been flying around to say, the Hindenburg, they're microscopic. The Hindenburg's envelopes held right around 200,000 m3. And by most accounts, it was even slightly over-pressurized when it lifted off. So, maybe my numbers are way off. Maybe I have some calculation that's not quite right that allows these tiny ships to fly when they're 1/2% the size of a real airship. Maybe I'm nuts, wrong or both. Today, I decided to test that theory against a known airship that we're all probably familiar with, the GoodYear blimp. For this comparison, I'm using the stats available directly from GoodYear. For the sake of you Euros, I'm going to be converting the relevant numbers into metric. Stat WingFoot KSP LTA Overall Length 75.1 m 78.2m Maximum Envelope Width 14.1 m 18 Envelope Volume 8425.03 m3 8231.3 m3 Maximum Weight 8.97 mt 6.32 mt Maximum Speed 32.6 m/s 46.2 m/s Gondola Seating Up to 14 humans1 2 Kerbals2 Total Usable Lift 1.83 mt 2.93 mt Number and Type of Engines 3 Vectored 2 vectored Engine Power 200 hp each 5 kN each Endurance 24-40 hours3 7 hours w/200 LF4 1Seating configuration for the new Goodyear blimp is subject to adjustment as assignments and lift conditions vary. 2What lift conditions. Every day is pretty much perfect for airship flying 3Based on cruise power, maximum fuel load and optimum atmospheric conditions. Maximum endurance is in conjunction with optional extended range kit. 4 Approximate flight time at maximum speed. Maximum flight duration undetermined due to leaks not being incorporated yet. So, I attempted to build an airship pretty close to the WingFoot stats in order to compare apples to apples. While the shape is a bit more pointed due to the parts I created, most of the stats are pretty close. The length and width I had to increase to get closer to the size of the WingFoot envelope volume. I'm having to use some pretty basic geometry to calculate the envelope volumes and it's not 100% accurate but it's within a few percent. There's also a fair difference in the weight of the two. Then again, mine doesn't have a 12,384 pixel lighted sign with the accompanying hardware. LTA medium sized rigid airship parked outside the SPH. This airship is an attempt to size/stat compare an LTA airship to the GoodYear WingFoot blimps. Taking the WingFoot's billboard into account, the usable lift difference would probably be a lot closer were it removed. While the WingFoot has what appears to be a considerably longer endurance and a much larger seating capacity, one thing to keep in mind is that WingFoot is pretty modular. They're able to adapt it to the mission. If you noticed the notes at the bottom, the WingFoot has an 'extended range kit' they can install. Because this was the first flight of my replication, I over judged the amount of gas needed and ended up packing around an extra 1,300+ liters of liquid hydrogen. Oh, and for us "Yanks" I did the reverse math on the fuel usage. That's about 13.7 mpg. You tell me if that sounds decent enough or should it be less (it's definitely not going to be more). Another thing you'll see in a screenshot below is that the envelopes on mine are only filled to about 80% capacity. For this particular airship, I didn't place any ballast on it. The WingFoot, last I read, used 75 lb. sand bags. Were I going to keep this one around, I'd definitely add in a ton or two of ballast so that the envelopes could be filled closer to capacity where the balloonets would become effective and aid in ascent/descent. In this case, I ended up using the engine vectoring to assist in landings and takeoffs (which worked beautifully). So, the purpose of this test was to compare apples to apples and I'm going to have to say that I'm satisfied. This little 'blimp' replica, even with just the 3 ailerons/rudders like WingFoot flew beautifully. I did bounce a bit on touchdown, but once I got stopped, I reversed and rotated the engines to push downward so the brakes on the 2 wheels would hold better and that worked. I'm much more confident that the the numbers I'm using are close enough for KSP and reality. If you want to get picky, yea, you'll find things are off a bit. Of course, if you are that picky, you could always call Zeppelin NT and buy your own blimp and all the numbers would always be perfect. Next post, I'm going to explain a bit more about how the balloonets and ballast system is going to work. On the way to the Island Runway About to land on the Island Runway. This is the only shot I got on this short trip that shows the UI and fuel gauges. Note, the vectored engines are rotated and reversed so that they push down and backward. It worked much better than the wheel brakes. Balancing on 1 wheel long enough for Val to hop out and take a selfie. Getting them back down again So far, my ramblings here have been focused on how to get airships off the ground and performing tests to verify that the numbers look good enough for KSP (government) work. And so far, I'm pretty satisfied with the results. One other test I conducted that I won't go into in extreme detail is an attempt to replicate the lifting capacity of one of, if not the, largest airships ever, the Hindenburg. That test is still ongoing however and so that I don't spoil all the fun of making your own I won't say a lot. However, I will say that the Hindenburg was able to lift somewhere around 230 metric tons. I was able to match the basic length, width and envelope volumes and the lifting capacity was very, very similar. And, there was enough lift left over that I had to put on a BUNCH of ballast. Which brings me to the topic of this section, bringing them back down again. At the turn of the 20th century, when airships were starting to get lots of attention, inventors, scientists and engineers realized that getting an airship off the ground was easy enough. You filled it with a gas that had a really low density compared to air and, up it went. And getting them back down again was pretty easy too, you poked a hole in the envelope, let the gas out and down it would come. There were two problems with this method. Hydrogen, the best possible lifting gas, is highly explosive. It was easy enough to produce but flying around strapped to a ticking time bomb wasn't exactly the ideal solution. Helium, which is very close to hydrogen in it's lifting abilities was the next best solution. But, it was, and still is, impossible to manufacture. It's only found near deposits of radioactive material. While Helium is plentiful in the universe, not so on earth. The only way we could possibly manufacture it is in a fusion reactor, which we still haven't perfected. To make matters worse, at that time, only one source was known to exist with any viable quantity and that was in the United States. And that meant, if the Americans didn't like you, your helium got cut off. Hydrogen valuable enough and helium was hard enough to get that the designers behind balloons and airships started coming up with ideas on how to conserve lifting gasses. Even those engineers in the US where helium was easy to get realized that there was a finite quantity and they needed to conserve as much as possible. The theory that came out of all of this was that once they put the lifting gas into the envelopes, do everything possible to keep it there. In order to try to replicate the value placed on this resource in KSP, you won't be able to fill gas envelopes inside the VAB/SPH. You'll have to do it the old fashioned way and fill your envelopes using a compressed resource like liquid hydrogen outside the editor. Once you fill these envelopes, recovery of the lifting gas won't be possible. You'll have to pack along some extra or find a way to have some delivered to you. This also means that keeping what gas you have in the envelopes will be something you'll have to consider. Blowing it out the release valves won't be a long term solution. Engineers building early airships realized that blowing gasses out the release valve wasn't a long term solution either. The Hindenburg held 7,062,000 cubic feet of lifting gas. During a typical Atlantic crossing, they'd vent some 1,500,000 cubic feet of gas. The reason this was necessary was to compensate for fuel loss. At normal speeds, the Hindenburg would consume some 130 kilos of diesel fuel per hour. At it's best, an Atlantic crossing from Germany to the US, it took almost 53 hours of non-stop flying. (For us 'Yanks' the Hindenburg got less than 2 m.p.g.). Some method had to be developed to help compensate for that loss of weight. Venting - While the least desirable method of descending, it's still a very valid one. You just have to realize that each time you do vent, you lose precious lifting gas. Like modern and historical airships, this mod will have valves that you can open and close. Unlike other mods, these vents will be actual parts that you have to place and they will have to be on an envelope to work. The way they'll work is pretty simple, with both a manual and an automatic mode. In automatic mode, you set the pressure at which you want them to open (somewhere between 1 and 5000 Pascals). Should the internal pressure of the envelope exceed that amount, they start venting your gas. You an also turn them on manually to vent as needed. The bad news. These vents have a fixed rate at which gas can escape through them. The good news, you can set up action groups to turn them on and off and you have have multiple vents on an envelope. Ballast - While ballast alone doesn't prevent the loss of lifting gasses, it be came, and still is, necessary for the proper operation of airships. Later, it became important in conserving the lifting gas. Rigid airships have a structured frame with one or more balloons inside them. In order to keep that balloon from flopping around and risking puncture, it had to be inflated to a minimum volume. Even today's airships are non-rigid or semi-rigid and have to have a minimum amount of lifting gas to retain their shape. Depending on the payload, ballast had to be added or removed in order to help achieve a neutral buoyancy, where it neither ascended or descended. Even today, the GoodYear blimps are designed to have an expected payload. When that payload isn't exactly met, sand bags are added. To give you an idea of how critical ballast has become, in 2011, a GoodYear blimp pilot lost his life as a result of ballast loss. In a condensed version, the pilot of the blimp and 3 passengers began to smell fuel during a flight. Making an emergency landing, a fire aboard the airship broke out and the pilot instructed the 3 passengers to disembark. The ground crew hadn't arrived to secure the blimp and as a result, it shot back into the air due to the ballast loss. Ultimately, an investigation by German authorities attributed much of the disaster to pilot error. He was also credited with being a hero for saving the life of his passengers. While tragic, the point I'm trying to make here is that historically, and even with today's airships, ballast plays such a critical role in maintaining a perfect balance in these airships that even the loss of a few hundred pounds is enough to radically alter their aerodynamics. Balloonets - The idea behind balloonets dates back to the late 1700's. Their purpose was to decrease lift by adding to the envelope a much heavier gas, air. Whenever the airship needed to descend, a balloonet was inflated inside of it, creating added weight and the airship descended. Thus far, I've tested this in KSP and, surprisingly it works. In a video I posted further down the thread, you can see one of the test airships lift, fly around and descend without a significant loss of lifting gas by inflating and deflating balloonets inside each cell. Balloonets also had another important function. By inflating or deflating them and depending on their location in the airship frame, they could be used to trim the pitch of the airship. By TraceyR [GFDL (http://www.gnu.org/copyleft/fdl.html), CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0/) or FAL], from Wikimedia Commons In KSP I've had to take a slightly different approach to balloonets. In the image above you can easily see that anytime the inner balloon is inflated, the volume of the outer balloon doesn't change but it's size does. Because the airships I'm first trying to replicate are of a rigid design, I've had to allow for some creativity in how balloonets work. It'll be easier to think of them as two opposing pistons inside a cylinder. Each balloonet can be inflated up to 25% of the capacity of the cylinder. One of the problems with replicating a balloonet has to do with the density of air. In the image above, no calculation has to take place. You blow up the inside balloon and it works. In KSP, temperature and air pressure all have an effect on how the ballonet works and need to be factored in. In the first iteration of this mod, it's going to be much simplified. The air added to the balloonet won't have any weight. Instead, this is how it will work. Up until the point that the lifting gas envelope is 75% filled with lifting gas, the balloonet will have no appreciable effect. Once beyond that 75%, the balloonet effectively reduces the maximum volume that the gas cell can hold. This causes an increase in the pressure of the lifting gas and, as a result, it's density increases. This also has the effect that since the total volume of lifting gas is reduced, the 'hole' it creates in the atmosphere gets smaller and thus, the airship isn't able to lift as much mass. How balloonets will work in this mod. The mass of air in the balloonet isn't insignificant. When you start working with airships the size of the Hindenburg, 50,000 cubic meters of air has a significant weight. And eventually, I will be adding this mass but not at first. The reason being is it will take some careful mathematics. For example. Assume you're on Kerbin and you fill your balloonet to maximum. Let's set the air density there = 1. When you're ready to lift off, you deflate the balloonet and you're on your way. Now let's assume you're doing some high altitude flying and you're at say 20km. Up there, the density is only 0.25. That means that the mass of the air for the same 25% volume is only 1/4 of what it was at the surface. To make it even more interesting, assume that you deflated the balloonet at the surface and very slowly, as you ascended, you started inflating it. In order to calculate the mass of the air in the balloonet, you'd have to constantly sample the air. Take that air and it's density and then add that volume and density to what's already in the balloonet and come up with a new density and thus, a new mass. Now this can all be done, I'm just not going to do it in the first iteration of the mod. Blau Gas - Blau Gas was a rather unique idea. It was a gas distilled from naphtha that had two very desirable properties. First, it was flammable. Second, it's density was very close to that of air. This allowed airship designers to add a fuel that the engines could run off of and as it was consumed, replace it with air. In essence, this created a 0 sum game whereby weight wasn't lost or gained. I do plan on adding this into the mod but it too will take some work. In KSP there's basically two choices that I'm aware of. 1. Make an engine that runs specifically off of a type of fuel, which would require more parts, or 2. Write a plugin that would allow specific engines to 'switch' fuel types at the user's choosing. For now, I'm not sure which I'm going to pursue but I do want this fuel type in the game. The burnable gas may come into existence as a by-product of creating a lifting gas from KSP ore. *edit* I just did a bit of research and this will be a lot easier than I initially thought. RAPIER engines already have a dual mode. The only thing that would be needed to switch and engine between LF and Blau Gas would be a .cfg file. Problem solved. Ballast Reclamation - One of the other solutions to loss of mass was to create your own ballast on-the-fly. Interestingly enough, about half of what comes out of the exhaust pipe of an engine is carbon monoxide. The other half, is water. Engineers during and after WWI set their attention to collecting this water and using it to replace mass loss. One engineer, Robert F. Kohr, wrote a paper describing how he and a team of engineers in the 1920's worked on a method to extract this water from the exhaust of airship engines. Ultimately, their method consisted of creating condensers and mounting them on the sides of airships. They conducted numerous experiments and the math gets pretty heavy. But the basic conclusions they drew was that between 70% and 90% of the mass lost to fuel consumption could be collected from engine exhaust as water. If you're interested in this work, you can read about it here: https://nvlpubs.nist.gov/nistpubs/nbstechnologic/nbstechnologicpaperT293.pdf Kohr and his team experimented with LOTS of different fuel types and atmospheric conditions. For the sake of my sanity, I'm not nearly going to be delving into the mathematics that he did. But, I will be adding a part into the mod that will reclaim water from the engines in a MUCH simplified manner. The amount of that water reclamation will have a number of factors involved including air pressure, air temperature & engine thrust (or throttle position). And, if you took a look at the pictures in that .pdf, there will be condensers that you can place on the airship to collect this water which you can turn on and off. Another thing that I will factor in is which planet you happen to be on. While I haven't seen anything that indicates the oxygen content of any particular planet's atmosphere, breathable air will obviously provide better results. Engine Vectoring - In the pictures above there is a shot of the USS Macon or Akron's engines. As far as I can determine, it was one of the first, if not the first, to use vectored thrust. By taking the forward propulsion engines and rotating them up or down, engineers essentially added or subtracted lift. This mod will also employ vectored thrust. Thus far, and as far as I can plan, all of the engines designed for forward propulsion will be able to rotate 180 degrees, front to back. You'll also be able to adjust that rotation speed to your liking and stop the rotation at any point. You'll be able to assign action groups to this rotation and stopping so that, if you set all of the speeds the same, you can have the engines point any direction you like and stay there. And, with all of them having reverse thrust that can be placed in an action group, that gives a full 360 degrees of thrust rotation. In the replica of the GoodYear blimp above I was able to exclusively use vectored thrust from just 2 small engines to ascend and descend as well as move forward and in reverse without changing the volume of the lifting gas. I will be creating both an LF and an electric version of each engine used so that you can still use them on any planet with an atmosphere. Time to get serious. If you've managed to read this far in this rambling, you've probably noticed that thus far, I've been playing around with some pretty small airships. Nothing I've attempted yet has even come close to those monsters that once used to blot out the sun. Well, in this installment, I'm going to attempt just that. It's time to get serious and see just how the physics and my math come together when the numbers get really big. The Kindenburg The largest airship ever built was the Hindenburg. It was 245m x 41.2 m and held some 200,000 m3 of hydrogen. It's total lift? Well over 200 metric tons. In order to see if those type of numbers could be achieved using KSP physics, the first task was to build a monster of roughly the same size. It took me several attempt to come up with a working design even with the knowledge of knowing how all the physics should work. What I ended up with was this: Hindenburg Kindenburg Length: 245m 236m Width: 41.2m 40m at the envelope edge 53.6m with the engines Envelope Volume: 200,000 m3 207,000 m3 Weight: 219 mt fully loaded 116.9mt empty 149.5 mt as tested Estimated lift 232 mt 229 mt You've probably noted a rather large difference in the weights of each of these. The engineers on the Hindenburg had years to calculate how much it could carry and they had it down so precise that the Hindenburg even had an aluminum piano on board. For my test, I purposely didn't try to get close to that weight since I wasn't positive the numbers would all work out correctly. What I discovered was, I didn't have nearly enough weight. As it was I put on about 35 tons of water ballast, entirely too much fuel for the short jaunt to the island runway, I ended up blowing out gobs of gas because I underestimated the inflation of the cells. I had all of the balloonets fully inflated for the entire trip just to try to keep the beast from launching into the stratosphere and still had had to use the vectored thrust to keep it's altitude low enough to have a prayer of landing. After this test flight, I had the gut feeling that I could have easily went into the 200+ mt range with ballast and still made the flight. Here's some screenshots of the test: Coming in for a landing at KSC I had to patiently wait for the envelopes to deflate. A view from inside one of the buildings on the Island Runway. Here I have a number of the GUI's open to show some detail. One thing to keep in mind is this is all part of the development. Much of this detail won't be shown to the end users. Those tiny white dots on the top of the envelopes are relief valves. You'll be able to attach them to envelopes and they will allow the lifting gas to escape. You'll be able to turn them on manually by right-clicking or with an action group. You'll also be able to set a pressure at which they automatically open. Heading back to KSC. This shot of the landing on the Island Runway should give you an idea of just how large the Hindenburg was. While I was able to even park the smaller airships inside those hangars, the Kindenburg wouldn't quite fit. Landing at KSC. Being still over-inflated I chose the option of vectoring the engines downward in order to land. Another shot of the flight back. In this shot you can see the UI has had a minor change. The pressure bar now changes to yellow and red to help indicate when you're reaching over inflation. After my friend inadvertently blew up his airship he politely informed me that he had no indication it was in any danger. Now, he does. Another ting to notice is the two white spots. Those are end caps on the water ballast tank. You'll be able to start dumping your water ballast via the main UI or you can right click and manually turn on each one. This was my attempt to partially emulate the rear propeller arrangement on the newer Zeppelin NT's. While it did work, it required several action keys as main forward engines also had to be shut down. My own initial impressions: I'm glad I wasn't an airship captain. The smaller airships I've been flying around up to this point have been mostly fun. They haven't taken a lot of thought or planning and I've been able to balance out the envelopes just by eyeballing it. This monstrosity was a beast to fly. Not that it was uncontrollable, it actually flew quite well. The maneuvering of it was where it took some effort and that shouldn't have come as a surprise. When you have 150 tons which is essentially dangling on a thread, the laws of physics SERIOUSLY come into play. When it starts to turn it wants to keep turning until you make it stop. Once going forward, it keeps going forward. While there are drag cubes on these parts and while it will slow down eventually, 150 tons moving at 60m's is like a freight train. You don't stop on a dime. One of the things I HAD to do was to set the port and starboard engines to have their reverse thrust set to separate action keys. Once this thing came to a stop, if I needed to turn, reaction wheels were NOT going to be much good in an atmosphere. This, was a challenge to fly. And the more I think about it, the more I realize just how much planning and forethought it must have taken to fly a real one. This was also a test of a new part. In the previous section I gave some details as to how real airship engineers attempted to reclaim water from exhaust gasses in order to compensate for the loss of weight due to fuel consumption. Trying to emulate their methods I have created a condenser. Here's 3 of them on the port side of the Kindenburg. The way they'll work is something like this. First, each one will have a random efficiency (which you won't see or even know exists) assigned to it. As long as it's part of the vessel, that won't change. As your engines generate thrust, the condensers will capture that information and begin to generate water. A number of other factors will also be considered. There will be a temperature range at which they're the most effective. As the temperature gets colder or hotter, you can expect reduced efficiency... to the point that they freeze up or can't condense because the water is boiling off. And I'll also admit that the engine to evaporator ratio to achieve maximum efficiency is NOT 1:1. You'll have to experiment to find out which setup works best for your situation. In the first few sections of this rant, I described basically how airships worked. In the last few I've dug into some details and described how this mod will work. For just a moment, I'm going to go off-rails and give you an idea of how this mod can work. Because the envelopes are going to be resizable... and because they'll be independently controlled by the plugin, you won't be restricted to what does exist. While the basic shape of the envelope is fixed. It's arrangement and the number you choose to use, won't be: The whole point of this mod is going to be the emulation of real-world physics as it applies to airships. The engineering creativity you decide to come up with in using that physics, will be entirely up to you. The beans are burning (Well, it was a good idea at the time) So in this part of my experimentation I decided to work on using the Kerbin atmosphere for a lifting gas. The theory is pretty simple. Hot air balloons work because when air gets hot, the molecules move around a lot faster. In an enclosed environment like a balloon, this causes one of two things to happen: either the volume increases or the pressure increases. In either case the density of the air lowers. When the density inside the balloon is less than the density outside the balloon, it creates lift. So, the theory is pretty simple. What I discovered is the implementation wasn't. The first problem to solve was a somewhat realistic way to make the air hot. The second problem to solve was how to make the air cold again. We all understand the basics of thermodynamics thanks to soup. If you put a pan of soup on the stove and turn on the burner, it gets hot. If you turn the burner off, it gets cold. But that's just the basics. Lots of other factors apparently go into determining what the actual temperature of that soup is, like how much soup are we talking about? What's the temperature of the burner it's sitting on? What's the temperature of the air in the kitchen? How much surface area of the soup contacts the air? And then, there's a magic number called the heat transfer coefficient which is different for everything you encounter. Pea soup has a different coefficient than chicken soup which means, they would heat and cool at different rates. And this is just scratching the surface. Then there's things like the 'heat equation' which states: "The heat equation is a parabolic partial differential equation that describes the distribution of heat (or variation in temperature) in a given region over time." Ok, I'm trying to simulate... simulate mind you... airships. I am not working on a master's thesis. ________________________________________________________________ "All of physics is either impossible or trivial. It is impossible until you understand it, and then it becomes trivial." - ERNEST RUTHERFORD the 'father' of nuclear physics ________________________________________________________________ In this case, the trivial became obvious thanks to Sir Issac Newton. In 1701, Newton published an article that describe the relationship between the temperature of an object and time. While he didn't express any formula in that article, he did lay the foundation for what's become "Newton's law of cooling." His law basically says that the heat loss of an object is proportional to it's temperature and the surrounding temperature. What I discovered is that the equation used by this law could be turned around and used to determine the temperature of an object over time: In this equation T is the temperature of the object's surface and interior. (SI unit: K) Tenv is the temperature of the environment. (SI unit: K) t is the time. r is that mysterious heat transfer coefficient. KSP gives 2 of those variables. The atmospheric temperature and the time it takes for the code to run an update. The temperature of the object (air in this case) I could change and that r I could just plug some numbers in and see what happens. To make a long, boring physics story short, what I discovered is, for the purposes of hot air, this formula works great. The hotter the air is, the faster it cools toward the atmospheric temperature. The closer it is to atmospheric temperature, the less cooling occurs. This formula could also be used in reverse. If, instead of the environmental temperature I substituted the temperature of say, a big gas flame, then I could also simulate heating (just so happens Newton's law is also called a law of heating, yay!). There are few things this formula didn't take into account, like the volume of air and the surface area of the envelope where the gas was. But, these numbers could be plugged in later. This was enough to allow me to test hot air in a somewhat realistic manner. Heating would happen in a gradual slope. As more heat was applied the temperature would slowly rise toward the burner temperature. The closer it got to the temperature of the burner, the faster it would rise. In reverse, the cooling process would work in as rapid cooling process when there was a big difference between the gas temperature and the atmospheric temperature. The closer the temperature got to air temperature, the less it would cool. Hopefully, somewhere in the middle, the heating and cooling would meet and find a balance. Ok, so here was the goal. According to Wikipedia a hot air balloon should have these basic characteristics: The lift generated by 100,000 ft³ (2831.7 m³) of dry air heated to various temperatures may be calculated as follows: air temperature air density air mass lift generated 68 °F, 20 °C 1.2041 kg/m³ 7517 lb, 3409.7 kg 0 lb, 0 kg 210 °F, 99 °C 0.9486 kg/m³ 5922 lb, 2686.2 kg 1595 lb, 723.5 kg 250 °F, 120 °C 0.8978 kg/m³ 5606 lb, 2542.4 kg 1912 lb, 867.3 kg So, with my new formula plugged in and a couple of new parts to try out, I started testing: In this screenshot you may need to zoom in to see the numbers. But, what I did was first, inflate an envelope to roughly 2,800 m3 with Kerbin atmosphere at the atmospheric temperature. I then turned on my 'burners' and heated up the air. Once I reached around 427 degrees Kelvin (307k ambient + the 120C from the table above) I looked at the UI. It was saying that it should lift around 1.2 metric tons. This was about 50% more than what Wikipedia suggested. Ok, so the hot air was generating more lift than expected. At least it wasn't less than expected. I could live with this minor discrepancy. Now, let's see what it takes to get this 5 ton airship off the ground. Here's the things to note from this screenshot: First is the cool burners I've created and placed on the bottom of the airship. Next is the odd shaped item just in front of the burner. That's a 'blower' that can be turned on and off to pump outside air into the envelope. What you'll want to take close note of is the numbers in the UI panel. It's showing that the highest temperature of the air inside the airship is over 900 degrees Kelvin! And in this test I even cheated and didn't use any type of fuel to run the burners. Hot air balloons are extremely light. The gas volume of the balloon compared to the payload is a rather large ratio. When it comes to airships, that ratio drops significantly. Airships are inherently more massive than a balloon. Plus other problems arise. In all of my testing, each envelope was it's own unique part. For lighter than air gasses, this has worked great. For hot air, it's a nightmare to control. Imagine 3 balloons bolted together with each having it's own independent temperature and volume of gas. This means that air density in each one could be vastly different from the others. In the screenshot above, the rear envelope was at 900+ degrees while the forward one was at around 750 degrees. This creates vastly different amounts of lift between the front and the rear. Combine that with the fact that at these temperatures the cooling is (and should be) pretty rapid, I was having to fire up the burners every 30 seconds or so to stay aloft. And when they cooled, they cooled rapidly when meant, it had a tendency to start dropping like a rock. Next add in the fact that because the envelopes are at different temperatures, adding more heat creates even more varied temperatures. And finally, there was that minor issue of temperatures that could melt aluminum. While I still haven't explored all the possibilities (like having a uniform temperature across all envelopes) the biggest problem I see is that in order to generate enough lift to get something as massive as an airship off the ground, that air needs to be hot, really, really hot. The only other viable solution I can see is to vastly decrease the mass of the airship itself. Either way, if hot air is going to be an option for a lifting gas then there's going to be unrealistic temperatures or unrealistic mass. Since my plan was to make an airship mod based on real-world physics, perhaps the best answer is neither. Then again, there may be another option. Using hot air to boost the lift of helistats without having to carry around a lifting gas. Hummm.... *edit Updating the Hummm...* Performed a quick test with a helistat. The basic results were, it's viable. The theory behind helistats is is that the airship lifts itself including the rotors. The rotors are then used to lift the intended cargo. While hot air won't achieve that goal, it can help. In a quick test of the screenshot below, at roughly 520 degrees Kelvin (still considerably warmer than a standard hot air balloon but not an insane temperature) the hot air was able to lift about 3.5 metric tons out of the total 8 ton airship weight. While that still puts a 4.5 ton demand on the rotors it does have one large advantage over lifting gasses... I didn't need any. -------------------------- -- to be continued -- Feel free to follow this thread. I'll create a new post when I update this OP. And while this is technically a WIP, it's no where near ready for testing. I will start a WIP thread when it is ready but for now, I'd hope to start a discussion about my ideas and your expectations.

Quick update. Allista has PM'd me and granted permission to use his his code. If my schedule holds up, by the weekend scalable ships will be in your hands. For now, I only plan on scaling hull and CV parts but that should give everyone the larger parts they've been asking for.

So, while loading config nodes I explosively ran into this little problem: One of the things I'm working on, the atmospheric temperature plays a vital role. I discovered that while quicksaving and reloading that some things weren't quite... ummm... right. During the first few cycles of FixedUpdate this.vessel.atmosphericTemperature = -3037904.50608881 or -4566205.7098681 or temperatures exceeding 9 million degrees Kelvin. Since those temperatures and my math causes my parts to explode... at exactly what point can I expect to get ACCURATE information from this.vessel because it seems FixedUpdate is running well before that info is set? And this is occuring after - if (!HighLogic.LoadedSceneIsFlight) return; - comes back true I've looked at changing this to: FlightGlobals.getExternalTemperature(FlightGlobals.ActiveVessel.altitude, FlightGlobals.currentMainBody) But there's issues with that. That appears to return an 'ideal' temperature that doesn't change unless the altitude does. The difference between that reading and the one from this.vessel... well, I'm seeing 15 degree variations. *edit Also ran a check to make sure that this.vessel.loaded was true before allowing a FixedUpdate with the assumption that if it were loaded then it should have accurate info. Not so.