Quiana

I stumbled upon this, it's a very interesting concept. Mission notations as a whole let people communicate it much more clearly and rapidly when everyone knows the particulars. I would like to see flow-chart remain, because it also has an additional use beyond after-mission reports. Preplanning phase. I imagine 'breakoff' ships could go up/down in a vertical sense and flowchart along with the main ship until they rejoin (or do not) the main 'timeline'. This would assist large missions when planning out how to accomplish them as it lets you see at a glance where your ships are (possibly even have a basic timeline notion for preplanning but not mission report phase). It might also be worth building it to allow a vertical format (where there are multiple ships but fewer active events). That would conserve space that might be consumed by a horizontal timeline of the method I mentioned about 'breakoff' ships.

If you're on Windows 8.1, then the drivers currently do not support it correctly. He's working on a fix by the sound of it, unfortunately supporting the DX11 inputs appears to be problematic in relations to making KSP happy.

I am so very thrilled to see someone modeling what was mentioned before in the DRE thread, the actual heat mechanics in general. I know it says that the ablative shields are in progress, so does that mean that the heat transference is currently done well enough that carefully-built reentry profiles would be alright without the ablative shields? If so, I may go ahead and replace my DRE install with this, but want to verify before I start frying capsules on re-entry in my career. Otherwise, I'd be concerned about the heat building up too fast for the 'shield' and thus causing spectacular failure.

Hi Duo, The logs have always been a favorite of mine. Don't forget to update your post to reflect the version #, it helps those of us looking for updates.

Thanks a bunch, I'll be looking forward to the update. Let me know if you need me to test out on 8.1 as well, as the input delay does irritate me (as well as the odd way that KSP doesn't read the throttle 100% correctly). If I go around 20-40% it will 'flick' to zero and back, and around the 60-70% range as well. Makes it hard to set a precise throttle, I'm hoping this is just a KSP bug (as I do not notice it occurring during Windows controller testing).

Hi Nlight, I appreciate this mod for sure, but I am apparently having an issue. I recall on the previous page that someone mentioned about the Cyborg X/Saitek drivers having issues with KSP. I have used my joystick for a bit, not realizing that the delay was indeed a driver conflict. It was my hope that this mod would solve that, but I am unable to get the mod to detect the joystick while in the flight scene. I can control the example pod I have on the pad with the normal controls and delay, but the mod apparently does not see the joystick at all. I have plugged it in a few times just to check if it will register and it apparently never does. I can see the mod itself, select the keyboard/mouse entry, even see the values updating as I move the mouse. If I have to do what was suggested before (removing the Saitek driver) I will, just wanted to know if you'd experienced this with any Saitek reports. As a side-note, when I unplug/replug it up, the default controls will not rotate the pod/etc with the joystick, but the throttle still works (which is odd). EDIT: Unfortunately the attempt to get windows to use its drivers failed. The joystick just doesn't work without the Saitek drivers in Windows 8.1.

Ippo, I noticed you mentioned about spare parts and remote control items. Easiest way? Do a crew check. If the crew capacity is = 0 and it has a control module, it must be a remote device rather than a crewed vessel to put in spares to.

The title itself lists what version it is, as well as the date the change was made. Ferram's very good about ensuring that the dates and versions are listed. It may not have a change history/record (which is likely in a txt file inside the download) but it will at least be easy to spot that when you're used to looking for it. It's nice seeing more modders ensuring that date stamp is on there as well, as sometimes it is difficult to tell the difference between a version change.

Simple, if you're worried about decoupler force, either grab tweakables and set that decoupler to 0, or use a docking port instead as the decoupler device. I'd recommend the tweakables myself, having a decoupler that serves as a 'holster' for items is useful, rather than explosive jettison.

While that will be true, I wouldn't recommend going overboard on mods with that overhead lifted. It can still slow down KSP in general, and there are some performance benefits oddly enough using ATM that justify it being used (even on a 'lite' method for larger textures). If you can't tell a minor difference in it then I'd recommend using it anyways. Mainly due to the way that KSP handles textures/models in the unity engine.

With some MM fiddling you can do Interstellar support. Basically, do some comparisons between the objects in the stock DRE configs, and use MM to write temperature values for the appropriate items in Interstellar. As an example, since I part-scoop from some other mods, here's part of my 'DRE everything' config. In this case, I modeled the small nerva engine after its larger cousin and used the general tank values for RLA tanks on the small size. Now, in theory, while the materials themselves would have the same temperature tolerances, you would likely have a lower overall tolerance as there is less material to absorb/dissipate heat and the overall heat 'resistances' would be smaller in a smaller tank. But without having more advanced heat plugins this is about the best you can do with the stock modules and DRE.

Here's an interesting question. With Ippy having released his individual crew files system, could FF be adapted to make use of such functionality for the features that SmarterThanMe wants? It can, in theory, track each kerbal as a complete individual, with merits, ranks, whatever you want to add. From what I understand, it saves this information into the persistent file as well, so it could be leveraged for easy use of making them have specific titles or ranks. I know Ippy plans to use it for his DangIt mod (which I look forward to seeing finished) to track the perks for your repair levels on each kerbal. It could even, oddly enough, probably be adapted to an experience system so that kerbals that do more, in theory, get 'better' ribbons awarded for their achievements.

May want to update the OP with the patch notes as well, so it's a convenient place to keep up with what version we're on as well as the changes since our current version. Also, have some rep, because I love this mod. Encouraging people to use kerbals to get them all into space like a big team is a great thing.

Call me silly but I tend to use a two-drive setup inside. One's the primary OS/game drive (though in the future I'd go to a three-drive SSD OS setup) and the other is my 'storage'. I back up the crucial files from the storage into media as needed outside the PC, just in case the lesser-accessed storage drive finds failure. I'd recommend always putting in two drives into any machine you design for that reason. After all, it's rather easy to put a new OS on a drive, keeping it isolated from work files/media/etc is what really makes it painless when the OS drive takes a dive.

Question: Do the hitboxes on these also change when retracted into the vessel? I'm curious as this hasn't really been mentioned yet and I am ASSUMING it would do so, but haven't the Kerbal hookspah to attempt jousting with where the hitbox should be between two vessels (at least not yet).

You can use the 2.1.X structure of MM now to make things work when other mod DLL files are around. You could, for example, make your CFG include RealCHute support using something like this: @PART[something]:AFTER[RealChutes]:NEEDS[RealChutes] Not knowing the realchutes DLL name offhand, I can't get it precise, but that would work to let you only add in that support if RealChutes is available. EDIT: This is useful for many reasons, the least of which is letting you keep everything in one CFG and not having to cfg-swap. It can also be used to run CFG changes before or after a mod loads, such as only loading after Realchutes (updated example to reflect this).

You would be correct. The best kind of correct. That setting causes physics to stop calculating for anything but direct physical impact (such as landscape surfaces, other craft, yada yada). Another possible fix is to increase the node connector size in the cores, giving them a bit more rigid stance. That would only be for the core itself and not any wedges. This would be probably the better option, seeing as the core itself, while 'small' in the middle, is technically supporting the framework to the outside edges so it could logically have more structure (larger node) to support. Might want to try testing that out to see how it does.

I too wouldn't mind it if we had, say, a config to turn it into a 'deadly reentry' style system for failures. On that note, a possible suggestion for cfg use. For spare parts, perhaps a nice add-on would be configs to put in KAS support. Example: Filling KAS containers with a 'spare part' instead of merely putting it in Capsules. It would encourage you to always carry spare parts or 'mission critical' replacements if necessary due to explosions (if implemented). Might even be able to extend the spare parts concept into 'Duct tape' for leak repairs, electrical components for alternator, and so on. EDIT: And going on from that point, I realize certain spares would be heavier/lighter. This would let you configure each vessel with the kind of spares you'd expect to need due to failures. Lots of fuel storage? Probably going to need a lot more duct tape even if it's lighter. Significant engine amount? Better pack more of their replacements.

Could it be possibly extended? Its current form is rather nice, but I'd also like something useful for rover ABS systems. Instead of a 'toggle until stopped and off', could we also have the ability to set it to 'on press' toggle? Such as holding B and having it pulse rover brakes for us to slow down without flipping? Letting off B would automatically turn it off. Anything like this in the future for it?

It's an interesting, simple design, though I forsee problems with the 'pull' attachment ports. You'll have to shutoff that engine most likely to haul anything behind it. may want to consider mounting something radial for the engines and free up the back for pulling. Not OP, but the basic requirement for a craft certification is to go from LKO (75k or so) to the mun and back to LKO circular orbit. I think if you provided that basic shake-down he'd be likely to approve.

If you have Stupid_Chris' stock rebalance, he moved the nodes to reflect their correct COM on some spaceplane parts. Either Pork can line up for that, or line up with bare stock. If you want to line them up but not remove Chris' changes, find the rebalance nodes file and use // to comment out the sections for MK parts. Either way, honestly, once I get all the parts organized I'm just simply replacing stock S2 parts for the space planes with this pack as it is far more pleasing to me.

It also has to be capable of moving from LKO to the mun and return as its maiden vessel flight.

To remove from staging selection? Tweakable Everything. VERY handy mod, allows you to set a few things and also to deploy solar panels/comms etc in the VAB. That way you can preview how it'll look rather than guessing. In this case, it also allows you to remove decouplers from staging so you don't have to have your staging bar filled with extras that are manually undocked. In this case, KSP gave me the saddest thing ever. It just decided that the engine had priority on mouse-over and won't target the decouplers. EDIT: I think I'll end up just either flushing their engines to the engine pods entirely or perhaps docking ports instead of decouplers. It's probably the girder that is preventing them from being targetable. EDITx2: It APPEARS that Ion engines cause a rather hideous and evil effect I'm simply calling 'bad hitbox'. No matter how I organize the decouplers/docking ports, the ion engines appear to cause a band around them that will prevent selecting anything within one part of them. This is not noticeable in VAB, I've been having to put vessels on the pad to find this out. I just have to action group the dang things at this rate.

Welp, I'm having to redo my plans on Mission one. The satelites can't be deployed. Why you may ask? Because the decouplers weren't staged. They were left out so I could manually decouple them.... and now I can't select them.

God-send your mod good sir! I love my Joystick, so it can be frustrating that there isn't a way to immediately lower inputs in order to make it a little easier on some situations. Good examples are requiring hard control inputs for large vessels that turn very slowly, countered by tiny craft that spin like a top barely even touching the joystick. As a side note, do you think it would be possible to use a secondary throttle control and tie it to the 'precision' controls as a variable? I know not everyone's joystick has one, but it would be very useful to be able to scale the control inputs via my currently unused dual-throttle's right side.