Fengist

If you're talking about my reply: I'm now using that for all of my mods and it seems to work beautifully. The method for loading the .png using WWW should work for most any application.

And ya know... when I was writing that reply I was thinking about the link in your sig and realized, "I need to steal that."

Thanks for the snip @Val, Good call. I got the email of the original post. @Tazarak the Brutal. It is rather difficult for a mod author to diagnose a problem when you give one generic error line from the logs and a "completely broken" description of the issue. That really tells me nothing. As of this reply, KE has 3,716 downloads on Curse. This is the first time I've heard of an issue with a nullRef. While I am aware of an issue with the pan-tilt, no one has provided me with logs yet so I don't know what the exact issue is. That tells me that, more than likely, this is a rare occurrence and was caused by the particular situation the spotlight is being used it in. Again, not telling me what this situation is does NOT help in getting it fixed. This mod is still listed as a WIP - Work in Progress. Even in the Curse listing it's noted as being a BETA. It is NOT my intent to break your saves and it's definitely not my intent to have nullRef spam. But, there are risks when using any mod, not just a WIP. Had you given me more details on the exact problem and pm'd me, used an @ or quoted me to get my attention, it's likely I could have come up with a patch, uploaded that patch to Curse and had it in your hands long before you finished your 8 hour editing stint. (Regarding the part that was snipped.) What exactly leads you to believe that a mod listed on CKAN is any less likely to have issues than a mod listed on Curse? I've gotten nullRef spam from the stock game just a few weeks ago and it's definitely not on CKAN. (and when I did I reported it on the KSP bug tracker with a log snippet to point out the issue and a description of what I was doing to cause it.) As it stands now, I have looked over the FixedUpdate code and nothing jumps out at me as a cause of this. Since I have no way of determining what's broken, I don't know what to fix. If anyone else is getting nullRef's... let me know! For future reference with this (or any mod for that matter). PLEASE take the time to contact the author politely. Work with them to help them figure out what the issue is so that not only is it fixed for your particular circumstance so that you don't have to take an axe to your save games but also, so that it's fixed for everyone to enjoy.

Umm, just wanted to drop a quick note to say ummm. Wow. Kerballoons Reinflated has jumped on CurseForge from nothing to being in the top 200 for popularity (Page 4 out of 47). It's the ONLY mod in the top 200 that has less than 1,000 downloads (granted I had a bit of a head start on the popularity thing but it's still impressive that it's getting that many downloads). Glad everyone is still interested in it. Let me know what you do and don't like and what you do and don't want. I'm still working on my other project so now is a good time to give some feedback before I dive into it's code and make radical changes.

Right, that's where it's running now in the editor and is creating the issue with the cloned part. I'll test it in flight and see how it goes. Thanks guys.

Thanks Sarbian. This code is connected with @allista's AnisotripicPartResizer which allows part resizing in 2 dimensions. For now, these parts are only resized in the editor. Once the ship is launched, their size is fixed. Obviously, changing the drag cubes when a part gets resized will be essential. But from what you're saying, I'm assuming 2 things. That DragCubes.Procedural should be set to false since the drag on these parts won't change once launched and that this code could be run once in the OnStart if the scene is flight and have the same effect?

So, here's the code: part.DragCubes.Procedural = true; part.DragCubes.ForceUpdate(true, true, true); part.DragCubes.SetDragWeights(); Pretty simple eh? Well, here's the problem. If, procedural is set to true and I try to SetDragWeights, attempting to attach a part to a mirrored part takes on all the aspects of a pogo stick ride. I have these 3 lines running in my OnStart event. I place any part in the hangar. I then place a mirrored part with my partmodule on that one. I then try to attach a part to the stack node on one of those mirrored parts (also with my partmodule). As I move the stack nodes closer together they snap into position. That creates a new mirrored part and executes my OnStart. Those 3 lines then break the snap between the stack nodes and I assume the mirrored part vanishes. Then the original part tries again to snap to the node. The mirrored part is instantly created again, running my OnStart event causing the part to vanish... ad infinitum. So, here's my questions What does procedural actually do? (ya, this is someone else's code being used with permission.) If it set it to false, I don't get the part hopping. Next, what does that SetDragWeights actually do? If I leave it out, I don't get the hopping. I spat out the array part.DragCubes.WeightedDrag after each of those lines and at no time did I see that weighted drag array change. (and the part size, mass, etc definitely changed in the process.) Thanks.

You hit that nail on the head. Either people are asking for more parts or complaining a mod is bloated. I think the other problem you would have with this, should you wish to pursue it and it wildly succeeds, is creating an elitist division amongst the modding community. Who here is qualified to say which mods are the 'best' and are to be included and who's are amongst the worst and need to be excluded? For example, one of my mods is consistently in the top 40 on Curse but has nothing to do with rockets or aircraft or even space exploration. Which of those facts would cause it to be included or excluded. I personally wouldn't want any of my mods in said pack. The day I feel I have enough confidence in writing code that I can look down on someone else's mod as being 'not good enough' is the day I need to turn my computer off and take up something truly humbling like golf.

Update to the OP - Getting them back down again In the next installment, a babbling of how to get airships back on the ground.

Well, hollowing out the center of a clipper hull would be easy enough to do. I could probably have a part made and in-game in about 30 minutes. But you'd still be facing the same problem you have now, it wouldn't work with 1.2.2. I'm not always happy with the direction that games take. But, if I'm going to mod for one of them, I have to work with the version that the mass majority use. Let me know what you decide. I'll probably be a bit before I release another versions so you have time.

Unfortunately no. 1.4 came with some new .dll files and Maritime Pack has been recompiled with those new .dll's. That means, it's incompatible with the .dll files that came with 1.2. If you really want to stick with 1.2, here's a link to an older Maritime Pack that should work with it: https://kerbal.curseforge.com/projects/the-maritime-pack/files/2348048

If you're going to do Kows then you're going to have to get into flying saucers and Kattle mutilations. You just can't have Kows without that. I mean, what would all the Konspiracy theorists have to talk about if you didn't? And of course, you'd have to have science missions to examine said mutilated Kows. And, you'd have to scatter a bunch of dead, mutilated Kows around the flying saucer on Kerbin just to justify their existence. Who knows, you play your Kards right and you might be right up there with @NecroBones's flying hamburger. (god I'm bad at this)

Once upon a time there was an attempt to make a weather mod. It sorta got into closed alpha but I could never get my hands on it. One of the plans was to use parts of the old Kethane mod which created, essentially, a geodesic dome over the planets. Each of the grids was going to contain specific weather data for just that grid. The brilliance there was, all neighboring grids could affect the one you're in. As I see it, one of the huge problems with creating any sort of weather mod is the vast amount of data you have to keep up with. Unlike say Kethane where it placed a set amount of resource per grid, a weather grid would need to constantly change and contain lots more data than one variable. And then, there's recreating weather patterns, adjusting variables that affect vessels like temperature, atmospheric pressure, wind, rain, snow and not least of all, applying all of these effects to a player's vessel. And that doesn't even get into the particle effects you'd need to simulate all that weather. IMHO, planetary weather is something that Squad needs to add in. Trying to put all that in a mod would be quite an undertaking.

Update to the OP - a comparison of fruits. In the latest of my ramblings I attempt to build a GoodYear blimp and compare stats and capabilities. Enjoy.

I've seen several examples of how real airship/balloon probes would function. Most of those are of the probe variety which I'm going to eventually attempt with KerBalloons. As for anchoring methods. I did check one idea and realized why it won't work. To be considered landed, a part has to actually touch the ground. KSP has a limited distance at which parts can be from each other, which is why no one has yet been successful at building a space elevator. This is also bad news for anchoring or tethering anything that floats. In order to do it the proper way, you have to be within that visible range. If you are, it is possible to fake it and essentially attach a part on to the ground, connect it to the vessel and, you're landed. However, controlling the physics of a tethered vessel could be a bit tricky, but not undoable. And I was able to find a copy of Discreet parts on Curse. If it's the same mod, with a blimp, then it uses Hooligan for it's base code. Hooligan does have a method called 'anchoring'. Two problems exist with it. 1. The current maintainer of Hooligan's has made the code all rights reserved and it's been that way for a few years. I doubt he has any intent on changing that. (which is one of the big reasons I'm writing my own code from scratch). 2. Hooligan's anchoring is just another name for air parking. As a matter of fact, the code looks pretty damned similar. And looking at one of Discreet's .cfg files, it used Hooligan's anchoring. So, in theory, it's possible to tether at distances farther than KAS does and likely consider the vessel landed. That's something I'd have to experiment with well down the road but tethering a colony 20km into the atmosphere, don't hold your breath.

I'm glad you found this. I remember watching this same video years ago thinking how cool it was. So, let's explore the possibility. First, the modelling. Modelling the exact thing that's in the video isn't going to happen. Adding in the physics of cloth and the unfolding and inflating would probably have a very bad effect on the physics engine. But, that's not to say it can't be done. KerBalloons resizes it's balloons. It cheats though. The model was created full size and then massively scaled down in order to simulate expansion. And that, is possible with airships as well. So, can a model be created that at least simulates what happens in the video? Sorta, kinda, maybe. Now, let's examine the physics. Venus has an atmosphere that's extremely heavy in CO2. Because CO2 is a very dense gas, the plan with HAVOC was to use good old Earth air as a lifting gas. Duna has a very, very thin atmosphere so air isn't going to work. While Eve has a much, much denser atmosphere, it's gravity is nothing like Venus. Venus is very close to Earth gravity. Eve's gravity is almost double that of Kerbin. Unfortunately, there is no planet like Venus in the Kerbol system. So let's look again at Duna. The simple formula to determine how much lift you can get from a lifting gas is: (d1-d2)*v=L Where, d1 = Atmospheric density in Kg/m3 d2 = Lifting gas density in Kg/m3 v = volume in m3 L = lift in Kg For this calculation, gravity is unimportant thanks to Archimedes' principle. So, here's some numbers for Duna: Atmospheric Density = 0.0963 Hydrogen Density on Duna = 0.00448 (pressure and temperature affect this number so it's very different than on Kerbin) Now that looks actually pretty good. You want the lifting gas to be much less dense than the atmosphere. If we subtract one from the other, we get 0.09162 Kg. That means, that 1m3 of hydrogen on Duna can lift around .09 Kilos of mass. Ok, so far so good. Converting that to metric tons (which KSP uses exclusively) we get 0.00009162 Mt. So, some quick math tells us that if we want to lift 1 metric ton of mass on Duna, we'd need 10,914.65 cubic meters of lifting gas. Ok, that's a bit. If you look at the screenshots of the little airships I've been flying around, they're only around 1,000 m3. So, we'd need something 11 times that size. Well, that's still doable. But there's another problem, the weight of the Hydrogen itself. Depending on where you look, hydrogen gas weighs in at 0.083 kg per m3. Convert to metric tons and we have 0.000083. Now, multiply that by 11,000 m3 of hydrogen and we get 0.913 mT. This means that 11,000m3 of hydrogen gas could only lift 87 kilos on Duna. (1mt - 0.913mt) So if it takes 11,000m3 of gas to lift 87 kilos, then to lift 1mt we'd need 126,436 cubic meters of hydrogen.... just to lift 1 metric ton? 126 of the little airships I've been flying around??? That's.... well that's this big: Wait? Are those numbers correct? Of course not. Other factors get involved, like the fact that Duna's air pressure is so low that you can fill 11,000 m3 with a very small amount of hydrogen so it's weight is going to be a LOT less. And then, because Duna's gravity is much lower than that on Kerbin the amount of lift (in kilo newtons) generated by the lifting gas is going to be much higher than it is on Kerbin. So, less gas and more lift would also figure into these equations. What I've done here is to intentionally give a somewhat misleading example of the kinds of calculations that need to be done in order to figure out the real physics behind airships. I don't want to give you all of the numbers you need in order to determine if an airship of a given volume and given weight will get off the ground on any particular planet. That would defeat half the fun of figuring it out yourselves. Is it possible to fly an airship on Duna? Yes. With the first release of this proposed mod? Maybe, maybe not. The current airships are designed to be rigid airships and will intentionally have a weight that supports that design. It may take a non-rigid blimp with some extremely lightweight materials. You'll have to experiment and find out. So, does this mean your suggestion can be done? Yes, and no. The physics and the modelling are possible. Where this runs into issues is with KSP, which I mentioned in another recent reply to KerBalloons. Once you leave the ground, a vessel is considered flying. You can't leave that vessel while it is and have it remain where it is. If you try, you're pitched into a wormhole and warped backward in time to your last game save. There is a technique called air parking whereby a vessel is taken 'off rails' and is fooled into thinking it's landed. The problem there is, when it is taken off rails, physics no longer applies to it and it becomes sorta frozen. That means, that while the airships may be doable, having them perform as in HAVOC won't be. You'd have to either land them or cheat and air park them. And as for the air colonies that were proposed in phase 5 of HAVOC. Again, you'd have to cheat and force them to be landed. Then again, thinking about it, there may... I say may... be a way around all that cheaty stuff but that will take a lot of digging and testing. It may be something for the future. Thanks for the idea and it'll stay stuck in me 'ead for now.

I suppose that would be possible. I came up with the idea of the list and didn't put a lot more thought into it because it worked. Thinking about it, here's the problem I see. Potentially there will be a half dozen or more lifting gasses available. Trying to set up a single part so that the user could potentially rearrange the volumes for specific gasses would be a bit of a nightmare from the code side and rather tedious from the user side. Limiting them to only say 2 gasses would place some undue limits on them. Let's say, for example, you manage to get an airship to Duna. You packed along helium and hydrogen. But, your airship has been there for a while and most of those gasses have leaked out or you've chucked them out the release valves. To get more, you'd have to have it delivered. But, if you happened to have a mining op with the 'special' ore-to-ore gas converter, you could make a lifting gas. If the cells were pre-set in the hangar to only accept hydrogen and helium, well, plan on a supply run. Resetting them in the field, while doable, I think would add considerably more code to what's already several thousand lines. It's a good idea but I still think what I came up with will work best for now. It allows the flexibility to use what you have on hand and not have to pre-define or, as you suggest, redefine what gasses you're going to use. For that matter, you could mix all 3 the way it is now. Not only that, it's a bit more realistic. And, since the gasses can't be recovered anyway (or rather I've found no examples of them being recovered), they'll either leak out or get shoved out anyway. Plus, while not exactly practical, the only limit to the number of gas cells you can have is your hangar size. Managing volumes for a dozen or more would parts would be... rather boring. Thanks for the idea though. Keep em coming.

Thanks D! This was exactly what I was looking for!

Anyone know of an easy way to add mass to a part at runtime. What I'd like is an invisible resource like intake air that could be managed by code but not seen by the user. One where I set the volume and density and the mass gets added.

SCIENCE! KerBalloons v 0.4.4 has been released. Check the download link in the OP. In this version you'll find the following: Several new parts added, including a data recorder, cross staff and a sundial. The data recorder allows you to record data from any of the following devices into a .csv file which will be located in GameData/KerBalloons/LogData directory Stock parts recognized: Thermometer : Temp Barometer: Air pressure Thermometer + Barometer : Air density Gravioli detector : Gravity Accelerometer : G-force acceleration KerBalloons parts recognized Sundial : Earth Time, KSP Universal Time, Mission time Cross Staff : Longitude and Latitude For now, you're getting altitude data for free. Next update should include a device to record vessel speed and altitude and I'll look into compass headings. How to Use: Take any or all of the above mentioned parts and add them to any vessel. Add the KerBalloons data recorder. The data recorder has two settings, recording frequency in seconds and a record button. To create a new .csv, click the record button. The KerBalloons plugin will then detect which of the science parts you have on the vessel and begin recording data for ONLY those it finds. To record actual data, select the science part and "Toggle Display." The data recorder will give a "sensor inactive" if you do not have the display toggled on. Operational notes: You can turn the data recorder on and off. Each time you turn it on, it will start a new .csv file. Time warping still appears to give accurate data at anticipated times. Please experiment further to verify this. Everything here uses electric charge. Be sure you're well supplied, especially if you have lots of sensors running. The timer is a bit inaccurate. It does not calculate exact seconds (due to when Unity runs it's updates and the fact that you're using a sundial). However, the mission time data is recorded down to 12 decimal points which should be accurate enough for most of us. Bugs: Just noticed that air density gets recorded twice if you have both a sundial and a cross staff mounted. I'll fix that next release. If you find any issues with this release, please let me know!! What to do with this new found data? Unanswered questions (and if you find out don't post the answers unless it's in a spoiler). Does the recorded data on Kerbin vary with latitude, longitude, day, night? How can you get accurate data comparisons when Kerbals don't have clocks? What's the comparison between atmospheric pressure and altitude? How does Eve, Duna and Laythe compare to Kerbin's atmospheric data. Beyond balloons Can you get data from Jool's atmosphere How does this data change if you're submerged? Does the pressure underwater change between Kerbin, Laythe and Eve And there's lots more data collection and comparison I can think of. So, put on your lab coats, break out the spreadsheet and enjoy.

FIrst of all, welcome to the forums. Always nice to have an expert looking over the shoulders of us science enthusiasts making sure we get it right. Second, where were you a month ago when I was trying to wrap my head around the ideal gas law :D. I'm not sure if you've seen this but: One of the reasons I went out of my way to find Joe and ask him about KerBalloons when it became apparent that he didn't have time to work on it was because of that pet project. It occurred to me that both airships and balloons shared a common mechanism when it came to getting them off the ground and I have this grand idea of putting them all under one roof. In response I'm going to regurgitate some of the things I put in that thread but, I'm hoping to eventually get KerBalloons working under the same concept so it applies. In my reply, I'm including some of the internals on how this is all going to work and how it currently is working. My goal is to emulate real physics. If you want to keep imaging that it's real physics, then you probably shouldn't read what I'm about to explain as it will include some of the shenanigans I'm having to employ to make it appear real. So, from the contents of the spoiler you may have gathered that I have much of the code to accomplish what you describe and I believe it to be reasonably accurate. Eventually moving this to KerBalloons will take a bit of effort. The goal will be to mostly keep the same part design and functionality while replacing the lifting mechanism with the code I have now. That will be fun. The Unity engine itself has gobs of capabilities, from simulating weather and waves to cloth blowing in the breeze. The question is, whether KSP employs those capabilities and how taxing it would be on the engine to try to overlay those features on top of the KSP code. The way KSP works is unlike most games. Most consider an entire vessel to be one part and apply physics to the entire vessel. KSP considers each part independently and generally applies physics to each part. That's one reason that having dozens of ships with hundreds of parts lying around turns KSP into a turtle. Trying to add cloth physics on top of all of that would tax the system pretty heavily. I have seen examples from a friend where the actual part mesh's are deformed real-time. The question is, will the visual enhancement add enough immersion that it will outweigh the processing requirements. Because Squad has, for the most part, chosen physics over visuals and that's what the community expects, I don't usually spend a huge amount of time on visuals and instead, try to focus on realism and fun. (As my other mod users know, I'm not a big part/texture guy.). Two of the HUGE problems you're going to see when you get into coding balloons for KSP is flight and weather. The balloons you're accustomed to can stay aloft for days or years. Google's project Loon has stated their balloons stay aloft for upwards of 100 days before they're brought down. In KSP, once a vessel leaves the ground it's status is changed to flight. Exiting out of that vessel while in flight, in stock KSP, simply isn't possible. If you force it, it will instead take you backward in time to the last save game. This creates a huge problem when it comes to leaving balloons aloft for long periods of time. You can't. There is a half-*** work around known as air parking. In this process the vessel is fooled into thinking it's actually landed and is taken 'off-rails'. The problem there is, when off-rails, physics no longer applies to that vessel and it's frozen in position. So, the choices are, stick with the balloon throughout it's entire flight (and on Kerbin one entire day is 6 real-life hours), air park it, or time warp forward. Time warping creates another problem in that it will skip over any data you're trying to collect. In real time you may collect data every second. In time warp, every second could be an hour. (My recent tests indicate that data can still be grabbed during time warp in at least 1 second intervals and appear correct. More testing needed.). Weather is a problem because there is none. There are no winds, rain, snow, nothing. Every day on Kerbin is a perfect day. This means, once your balloon gets launched, unless random physics gets involved, it'll likely come back down almost exactly where you launched it. There have been attempts at creating a weather mod but to my knowledge, all of them have either failed or simply closed their doors. As for helping with the code... what I'd like to do is to publically invite you to the closed alpha testing I'll be conducting for the airships (something I normally do very quietly for contributors). That way, I have at least one expert on the subject to double check my work. As such, you'll have full access to the code to make any changes, suggestions or corrections you see fit to keep the physics real. Once the airship mod is up and out the door, then I'll be focusing on getting KerBalloons using the same code. Thanks again for your post. Feel free to contact me via PM.

I stand corrected. Yep, I was thinking of the L.A. The Macon/Akron came a good bit later and were noted for being (loosely termed) aircraft carriers. I'm not sure I'd have had the umm. intestinal fortitude to try to land an aircraft by flying close enough that a hook on top of the wing would snag a 'trapeze' bar. Don't think I want my passenger airliners doing circus tricks. So, the fun for the day. Testing helistats. Here we have the trusty little airship I've been flying around the past week or so with a few additions. First, the engines I have been using, now rotate. There's 4 small electrics used primarily for forward propulsion that now rotate 180 degrees and have reverse thrust. So, if you like action keys, it has a full 360 degree thrust rotation. Don't expect much from these little guys. Though they will shove the airship around at 20+ m/s, they only have 1.2kN of thrust. Next, the rotors. Liquid fueled and reasonably efficient. At 50kN they're not in the neighborhood of a Chinook but, they perform adequately on this little ship. If you recall, my past flights the airship has been around 1-1.2 metric tons. With the addition of the helo rotors and 400 units of LF, that jumped to 5.5 tons. Something the airship alone (at this size) couldn't lift. (For a comparison, the Kuey rotors from KAX are rated at 100kN) But, combined, 4 rotors plus the airship, well... here's some screenshots of it flying around with a 9.44 mt cargo underneath (KAS winches ftw). This is pretty much at it's weight limit and though the takeoff was NOT pretty (snatching 9+ tons off the ground and then trying to control it), once I got the winches reeled in a bit, it leveled out nicely.

Sorry, wrong topic again

The only time you should need to edit the animation text files is when you're doing an emissive. Part animations and emissives will be vastly different because you're changing vastly different things which is why your YAML files may appear vastly different. Emissives should look like this after editing attribute: _EmissiveColor.r path: Cylinder1_Cylinder1_auv classID: 21 I think you chopped out too much. Yours are _Color.r IF that was an emissive. If not, then it shouldn't have been edited. KSP is likely failing to load the part because the animation isn't what it expects. The BC4.txt is the correct format. Just make sure to save your scenes before writing them out with parttools. And yea, this is a huge bandaid to make unity animations work with KSP