Pontiac

I laughed. hahaha

@Majiir> STOP UPDATING SO FAST! I've not even been able to use the Kerbal Blender as I've still been wrestling with the new drill!!! SLOW DOWN!!! {smirk} JK man. Awesome work. I'm at work so I can't verify, but, are you still using a single seed for all planets, or, does each planet get its own seed? The reason I'm asking is if it is one seed for the entire solar system, and I'm mining in two different locations (As someone above mentioned between Eve and somewhere else when using the debug generator) and I generate a new seed for a location I'm sitting on, then, all my other sites get screwed over with new locations. However, if each body gets its own seed, then I can regenerate without affecting anywhere else.

Easy enough. You're referring to the top button where you drag the assemblies to? I've been pondering that one myself. I've been thinking that instead of dragging and saving, skip the dragging part, and click the SAVE button and it'll save the assembly as is, and would get rid of this stupid issue of pipes and struts not connecting. Brilliant. POSSIBLE support could be added to check other saves so you can import your ships, instead of having to drag them around. The only problem I foresee is that you MIGHT have to have a root part on screen. But I'm going to play with that and see if I can convince SAL to allow for an immediate load. The most "parent" or "root" part becomes the part that has the focus, and I "think" that root parts top node becomes the active node. Single parts seem to act differently, but assemblies with more than one part fall into this. I'm not entirely sure as I'm usually focused on dropping a single part on, or, a bulk part that is supposed to have a single accessible node. As I'm still a noob when it comes to C# and how its handled in KSP, I'll be asking for help. For sure. :] I should also mention that I won't be able to work on this mod until after Jun 24 due to RL commitments.

I backup my persistence, quicksaves, craft files, and anything else I deem necessary, all automatically in real time, all DURING the time I play the game with a tool I wrote, with ZERO interaction from me beyond loading whatever profile I want and press a green button. I can pull up anything from any time the application was on, and running. If something bad happens, I go back to the space center, go to my application, restore any version I want, then continue on my way.

I use Chrome and installed an plugin called YouTube Video Deck. You log in with your google creds, and it looks at who you're subscribed to. You setup panels for the person/feed or groups of people/feeds and it'll sort it out chronologically, newest at the top, oldest at the bottom. Eliminates YouTubes idea of sorting entirely. A Kerbal seemed to have designed the new youtube scheme it seems.

This was freak'n epic. Awesome story!!

@hugix> Could be a "What not to do" training video?

Hit up YouTube for "Kerbal Space Program" or "KSP" and you'll find a bunch. My fav is Scott Manley. He does do a lot of tutorials and has a few stories going. Its taken me about a month to catch up on all his material JUST for KSP start to finish.

As I tell my youngest kid who plays this game, "This game is broken. Don't get upset about it.". Hell, he's given ME that same sage advice when the damned rockets won't fly the way I want them too. Gotta love being told what you told your 6 year old.

Looks like no. Only swimming, walking, and running are supported. I am so adding this to my repository of "How this stuff works". Good content as I look through it.

Looking at the source code, looks about right. I'll compile this when I get home in about 2 hours and see how well this works. I'm interested in seeing if Kerbals can walk through each other. The code looks as though it checks distances between the active Kerbal and the following Kerbal, but, I don't see anything that depicts other following Kerbals vs other following Kerbals.

I laughed. Sorry.. I had to. I've never seen English being termed as "Shakespeare language". haha. Just for that, I'm going to bookmark and download and play with something that isn't conventional to my standard daily operations in KSP.

Tritanium Helmets Manufacturing?

Every planetary body has Kethane, even the Sun.

There is no way to make it "infinite", no. Tack on a few zeros to the end of each and that'll be as close as you get.

This thread can be closed. The methodology of saving the subassemblies is doomed to fail due to how 0.20 handles moving things around. Pipes and struts are temporarily disconnected, and that state seems to be saved.

http://forum.kerbalspaceprogram.com/showthread.php/35664-Kethane-Usage-and-Proper-Fuel-Routing @Majiir> Maybe throw that link in the first post, right after the banner, in big huge letters "Problems with converting fuel? See HERE"?

I thought I should make mention about post #2. The problem isn't with subassemblyLoader. The problem is with the state of the ship when you go to save the assembly. You'll easily notice that the fuel lines and struts are not attached when you detach them from the main assembly. So when you added the decoupler, you can save the ship with SAL by dragging the new decoupler root part to SAL, save, and done. Basically skip the entire file management routine. I'm not sure if the behavior of the lines and struts changed between 0.19 and 0.20. Thank you *VERY MUCH* Temstar for that post. We're talking about it in this thread: http://forum.kerbalspaceprogram.com/showthread.php/30696-0-20-Subassembly-Loader-0-20-Compatibility-Patch?p=452032&viewfull=1#post452032

After a fourth re-read of what he's done, he's not doing anything different in the assembly of a ship, other than changing the root part from a command pod to a decoupler. He skipped a lot of steps to get the results that he desired in his post which caused me to do the re-reads and filling in some of the blanks. I'm not discrediting him, and I think this definitely good stuff. Here's what he's doing step by step for his "delete root" trick. - He first takes and removes all his fuel stages, and puts it to the side, but keeps his decoupler attached to the main part of the ship. - He then takes the rest of the ship (Payload) and deletes it, so now he's left with an unselected fuel assembly, and no root part. - He goes into the Structure tab, selects the decoupler. The decoupler now becomes the new root part. - He re-attaches his fuel stage to the decoupler, and probably adds the RCS jets. - He then saves and does his file management stuff. With the existing methodology SAL uses, I can't reproduce all those steps. First, I can't do any activity in the editor without a root part. Second, selecting the parts that need to save and dragging them up to the SAL icon is borked because of the temporary disassembly of certain parts and their state when the save is done. So using his methodology to get the ship to a certain stage, as long as you drag the entire ship up to the SAL icon, you're golden, and SAL is working as intended. This never was the fight I've been having, although I may have skewed by looking at command pods only. Should have been looking at the "root" part. Unfortunately I associated the root part as a command module. The bottom line differences at the actual saving stage within KSP is that when SAL saves, the ship is partially disassembled, UNLESS you drag the root part. Using his method, the ship is assembled. By all rights, all he has to at that point is just drag the ship up from the decoupler to the SAL icon, and he can skip on the file management. So this means one of two things, and I'm open to a third, fourth, fifth... hundredth option; A> Leave things as is and just deal with broken pipes and struts. Just throw a warning if a fuel line or decoupler is found saying something like "Loading this structure may not work due to fuel lines and struts not being attached during the save process" when saving. B> Allow saving only if the root part of the ship is selected. Error/cancel out if the part isn't selected. Option A seems the most tasteful as there might be times when you just want to save an overly complicated RCS tank with about 50 RTGs.

Thanks Fish. I'd like to hear your ideas though! So after a good 12 hours worth of sleep, I finally caught on to what is happening with the pipes not attaching, and it took me a whole 30 seconds to SEE what is happening, and I doubt there is anything I can do about it, even with attaching a fake command pod as a root part. The problem seems that if you pick something up that isn't the root part, pipes and struts are temporarily disconnected. So when you click on the subassembly icon to save, the ship is saved in that state, with pipes disconnected. Forcing a command pod to be attached during the saving process, then removed at when loaded, I don't think is going to help any, because the pipe doesn't have a proper connection point when its saved, but when its reconnected to a part of the vessel that has parts connected, it works. Things I know: - When a subassembly of the ship is removed from the main part of the ship with the root command module, the pipes are temporarily disconnected. - When that segment is reattached, the pipes know who to connect to. - If you duplicate the same segment of the ship and attach, the pipes know who to connect to, and its not the prior part. - You must save the ship in a state with all parts connected. I *THINK* part of it comes down to a routine in the code that checks to see if things are connected or not. It doesn't actively do anything other than return TRUE or FALSE. I'll poke at that for a while.

I'm not looking at the code right at the moment, but I THINK it does. I recognize rootPart but I don't recall where its from, be it another class or a variable name, or whatever. I'll poke at it some more tomorrow. Been up +24 hours so far.

Whoops... So I did. I'll fix that and submit. Thanks. @Hoy: I think he got lucky. I'm going to play with this some more tomorrow and see what I can come up with. I'd rather not muck around with files to "get it to work" but if I can get the software to do the job, even better.

I can just see Jeb just smiling and laughing away...... while the Bob and Bill are screaming their heads off...... only because Jeb ate too many Borritos and.. well... you know...

For Subassembly Loader, there is a bug in which how KSP stores your ship if it doesn't include a command module as the root part. I don't expect Squad to fix this issue any time soon since we're obviously going outside the spectrum of what their game is supposed to do. The save routine basically breaks any mirrored part. The "source" part of the mirror is properly placed, but the parts mirrored parts aren't. So I'm trying to work my way around this limitation by forcing the current command module on the build to be included in the saved assembly, then on load, rip out the command module, and resume work as normal. The save part works, meaning the command pod I inserted in the structure shows up both on screen and in the craft file, but the load part isn't working to expectation. The entire ship shows up, but I cannot, for the life of me, figure out how to properly delete the unwanted command pod. So my question is, how do you delete the very first part in the VAB editor right after you load the assembly? What is happening now is the command module shows up, but it becomes inert. You can't do anything with it. You can spin the camera around, and you can still see the modules different sides, but, clicking on it, or attempting to attach something to it fails. If I leave the VAB and come back in, the extra command module is gone from the screen. Additional Details: When looking at a working, versus non-working craft file, the working craft file has an additional cdata entry that points to the proper part ID, such as fuel tanks. In a non-working craft file, the cdata is pointing to a gas tank, but, with an invalid ID. That invalid ID is -1. My guess is that the each component of the vessel that gets saved is assigned an ID number. This happens when the save occurs. If a command module is clicked saved, then the craft loaded up works, but when just an assembly with no command modules on, the mirrored parts break due to the -1.

I'll revert what I've done (Not much) in regards to a work around for not saving the fuel lines, and upload the delete part. Edit: Link: