krenshala

I'm pretty sure there is a more detailed description in the first couple of pages of this thread, but i don't remember exactly where. Short answer, is to add a new entry to the remote tech config file for parts. Duplicate an existing entry, change the values to match the antenna/dish you want to add, save and start. The config file is, iirc, GameData/RemoteTech2/RemoteTech_*.cfg depending on which file you need to edit for the part you are updating. I haven't done this myself, so I might be missing some small detail that makes it easy, but I know this is the general instructions.

Would it be possible to give us a field to have the burn start at a certain time before the node? e.g., We know from the node that the burn is 1m36s long, so we tell the FC to start the burn 48s before it reaches the maneuver node. It is slightly more work for the user, but at the same time, it meets the request with minimal programming requirements.

While for the most part I agree with you, thecoshman, having omni's sweep for signals would be perfectly reasonable but dishes would need to be properly oriented to receive the target signal. Usually this would be by uploading a targetting program so the dish points in the correct direction, however, I can also envision the sat being preprogrammed with at least one fall-back target in case its primary comms link goes down and the satellite in question isn't the problem. I don't know how much extra work it would take to change the targetting behavior to allow a secondary target to be specified. Probably not worth the effort when your suggestion of letting the player retarget the dish is easier to implement. Then things get back to "how much realism do we want?". On the one hand, letting the player retarget can simulate preprogramming. On the other hand, the player making decisions is currently assumed to be programs uploaded from KSC and if you are 'not connected' you can't upload programmatic changes. On the gripping hand, its pretty much up to Cilph how he will resolve this one in the end.

Well, a quick search turns up that the ISS crew members are assigned approximately 1.8kg of food per day, per person. If kerbals need half that we can round a bit and call it 1kg per kerbal per day. I'm not sure what volume that should require, however. It just becomes a matter of determining what density the food should be. We know the mass (1kg per kerbal-day) so the density allows us to derive the volume needed. From that we can either determine how much the current containers can actually hold and what their mass should be, or we can determine what volume the containers need to be to hold the desired mass of food. Assuming the same (inefficient) packaging that we use here on Earth, then approximately 75% of the waste mass will be food packaging (the wiki page showed ~65% to 90% waste was food packaging on various missions). Not sure how that would play into the mod, however. It might be easier to just gloss over that part.

Scott, not sure if you hadn't figured it out or just didn't bother for this test/demonstration, but all you need to do to prevent the vehicle from turning back-end over front and "crashing" when you brake is to disable the brakes on the front wheels and let the front wheel(s) just roll out. Very nice demonstration of how lifting bodies are able to "fly".

Wheel placement determines stability. If you have three wheels, but two of them are non-functional cosmetic additions, it will be exactly as stable as just using the single, fully functional wheel by itself.

I notice the center of thrust is way lower than the center of mass. Have you already tried aligning the two so it thrusts through the CoM instead of under it, causing it to pitch up?

Can't wait (though I must ). Deadly Reentry is the last mod I'm waiting on to get my game going again.

For 1, which is the correct path? I have TAC installed as {KSP}/GameData/ThunderAerospace/TacLifeSupport(|Containers|HexCans|Recyclers), however, in my output log I see mention that it cannot find the TacLifeSupport module. I'm assuming I have something installed incorrectly though I cannot see what it would be (copied the contents of GameData in the zip to my {KSP}/GameData directory). EDIT: Wierd. Dug back through the thread to find the latest test build and pulled it from your drop box link and now things are working.

I just thought I'd let you know I pulled the latest verison from GitHub today, and it appears to have fixed the crash-to-desktop I was getting while using 0.5.133 (I pulled from Spaceport a couple of days ago). I haven't experienced any problems ... yet. Its early in Career mode for me, however, so nobody has gone more than half-way to GKO so far. Just got my comm-array in orbit, so next is a trip to the Mun; I'll get a good test of lifesupport on those missions.

Here is a shot of the KSV Kerbin in its current state. I docked the final outer (communications and fuel) pod, and have the first engine pod on its way to a rendezvous. This picture is the result of nine successful launches (and about half a dozen failures). I have one fuel pod (the four inner orange tanks) that I need to redock because it is turned about 2.5 degrees so only one of the three docking ports are properly attached. I believe all the rest are connected as intended. Once I get the first engine pod docked (at the other end) I'll find out how much ÃŽâ€V it has.

Even the B9 cockpits could use some improvement in this area.

The closer to the center, the closer you are to being aimed directly at the port you are trying to dock to.

Using RAID and/or newer generation SATA devices might help, but only if the load times are due to disk reads being the bottle-neck. The simplest way to test whether the drive read times are the problem is to time game startup run from the HDD and again from a RAM drive. If the drive is the bottle-neck the RAM drive should load significantly faster since it has a much wider bus to the processor. If, as other have pointed out, the problem is with KSP/Unity processing the data it is reading in, however, then you will see little to no improvement when loading from a RAM drive compared to a SATA device. While I've only started playing about two days before 0.21 came out, for what this game loads the start time isn't unreasonable in my opinion.

Just thought I'd share a screenshot of the KSV Kerbin that I've docked together yesterday and today using DAPI. This is the (current) results of six successful launches. It isn't ready for flight yet, as I still need to add living space, landers, probes and engines, in addition to the other three fuel/comms pods (the nearest part). Each module is docked with either three or four docking ports and the DAPI allowed me to easily line everything up correctly. One thing I have noticed is that rotating the docking port during construction will affect how DAPI sees its orientation when you try to dock. This caused all four of the inner fuel modules to dock at 180 degrees according to DAPI. Not really a bug, but I thought I'd mention it in case others hadn't noticed or figured it out yet.

And just before I got to your post I was looking at that GPS satellite and thinking to myself, "Okay, I know the engineers wouldn't just add spirals on it for fun. Not when even the mass of the paint matters at launch time. What the hell are they for?". Thank you for answering that question for me.

You mentioned that it tracks/transfers orbital information just fine. I would think it would be (relatively) easy to define the movement of other vessels by transferring their orbital info and when they started that orbit, so the data transfered would be the ephemerus, a timestamp, and an angle on the ellipse defined by the ephemerus. This would give you both a time and position on the orbit, and the game should calculate the vessel's current position on the orbit using its normal routines. You should only have to update the data on other clients when the controlling player performs a maneuver (an RCS or engine burn). This, of course, only covers those situations where the other players are not close enough to actually render the vessel (or kerbal) being controlled. If the ship is close enough to render you would also need the rotational data (initial rotational position, plus changes), which it looks like you have done a good job of setting up already. On the timewarp issue, I agree with the calls to stop beating the horse. Once this mod gets to the point where it will matter, however, my preference is for something like the mod that lets you warp at will and logs your maneuvers, playing them them back for the other players at whatever speed their clients are running at. This keeps celestial positions sane (which appears to be what some folks overlook when discussion warping) while still allowing official time to catch up when nobody is controlling a vessel at a lower speed. In my mind this does have the oddness that a player could launch a ship into a long orbit, time warp forward on it, do some things, then return to the Space Port (and "server" time) to launch another ship and see himself performing actions on the first vessel from a different perspective. I like this unintended feature, but thought it should be pointed out for those that overlooked it. Pwolf, keep up the good work. I'm curious to see what you come up with.

I just have to say, thank you for posting this. It makes docking both easier, and more fun, while at the same time making it feel more like doing a "real" docking maneuver. I've been using the previous version for a few weeks, and just noticed the upgrade today (and switched immediately!).

I'm using the X4-r1 version and it appears to be working just fine with the current v0.21.

Well, you are Uncle Mort after all.

15,787 days for me.

I suspect either thrust to weight is too low for one or more early/mid ascent stage (which I've done to myself; feels like you just can't get enough fuel no matter what you pile on), failing to stage off empty portions of the ship quickly enough (again, eats up fuel you need for the rest of the ascent), or has a thrust to weight ratio that is way too high (air drag causing the engines to eat fuel like candy due to how the game handles thrust vs drag). It could be more than one of these things working together considering what he describes.

With the Remote Tech mod, its a required feature to control things away from Kerbin and possibly in Kerbin orbit as well; I haven't tried it yet so I'm not clear on the range for "basic" communication with it installed.

It would be nice if we had a toggle to switch fuel tanks from full to empty and back in the hangar/VAB. That would make some of the design process easier for these kinds of things.

If periapsis is under 60km then it should only take two, maybe three, orbits to bleed off enough velocity through aerobraking to deorbit the capsule. If you are below 69,500m you will aerobrake at Kerbin (personal experience due to a similar situation with one of my first capsules that didn't have the deltaV needed to circularize ). I've noticed it will drop your apoapsis faster so don't be discouraged if it seems periapsis isn't falling. It is.