Deadweasel

That's a little weird. Usually electric charge is distributed and drained evenly across the whole ship. There shouldn't be a situation where you have to transfer charge, unless the pod is somehow isolated from the rest of the ship by a part that can't transfer electricity...?

Unless you're using the surface-mount panels, which don't extend and are always "on" anyway...

DO NOT WARP when transitioning from one sphere of influence to another. Almost every time I've done it, the ship becomes completely unresponsive and frozen. No throttle or positional control, no access to context commands on antennae or fuel tanks etc. It's almost as if the command pod is losing its position in the hierarchy of the ship if it's time-warping across the SoI. Jumping out to Space Center and back to the ship almost always corrects the problem though.

As a site owner and developer myself, I'd like to say that there are (figuratively) a hundred justifications to just let YouTube/Vimeo/etc host the videos, and maybe a couple against it. The primary qualifications that apply to users are at least two-fold: Simplicity: YouTube allows the user to focus on content creation, accepting a range of possible formats. The site handles compression and transcoding automatically to offer up a quality stream that is difficult to achieve on the submitter's end, without practice and lots of trial and error. The submission interface is fast, easy to use, and intuitive, not to mention that the bulk of potential submitters will already have a YouTube account anyway. Reliability and flexibility: Everybody knows YouTube, and it's uptime is almost unparalleled among video streaming sites. There's something to be said for having things operating on Google's own massive and widespread infrastructure. If the host site becomes unavailable for some reason, so does any content hosted there. For site admins: Bandwidth/storage: Videos take a LOT of bandwidth to offer out to a large audience, and it's not cheap unless -like Google- you happen to own and operate the lion's share of that infrastructure yourself. Most site owners don't have that kind of luxury (or money) without some serious commercial backing or sponsorship. Simply allowing for embedded video links -like what is used on the KSP forums- places the burden of performance and bandwidth on YouTube instead of the local site. This is why most large sites serving up media will either rely on YouTube, or if security and control is a concern, will develop or sign up with a content delivery network (CDN), which centralizes all media off of the main site, while also shuffling off the additional bandwidth load, ensuring the site itself stays live, even if the media server is being swamped or having trouble. Design and operational complexity: Hosting video locally creates a situation where the site designer(s) are forced to essentially re-create the wheel in order to accommodate users who may not have the related technical knowledge to submit a good quality video render, meaning it's more likely that submitted files will be unnecessarily large, of low quality, or potentially both. Hosting videos locally places a large -and I feel very unnecessary- technical and financial burden on the site owner, next to the simple task of setting things up to play embedded video linked from another host purpose-built for the task, in this case YouTube. All in all -and especially where video is concerned- simply allowing for an embedded video player is the simplest, most reliable and least time-consuming option for both the site owner and the user.

Well that's why #3 is "???" Profit could mean strictly personal satisfaction, unless #3 is legally greenlit to become SELL TO DEADWEASEL RIGHT NOW.

Okay, I am officially intrigued now. Seems you've thought this through pretty well, so I'm going to bookmark this devil and watch it grow! Here's hoping your efforts pan out!

Okay, that got some laughs out of me! Good one! Also: first time I've ever seen YouTube offer 1440p for a HD resolution! Very nice!

Interesting idea, though not the first attempt I've seen crop up attempting to replace SpacePort. So after watching the other one flare for a few weeks almost a year back, then apparently fizzle out completely, let me play devil's advocate to you for a moment: Are you considering your project to be a direct replacement for SpacePort, and if so, how are you coming at the far-from-insignificant step of getting people to translate over to yours instead? Consider the major hurdles you are facing in this arena: SpacePort is linked on the official site (what with having been created by the developers themselves and all), and is among the top Google matches for anything containing the terms "kerbal space program" and "mod" What about .craft uploads, not just mods? Mods only was the initial assumption that SpacePort made, and now look at the mess it has become when people starting sending in craft files too. Accommodating .craft uploads would be arguably the most critical feature to develop, because if you're planning on it from the start, then there's at least some planning for that already happening instead of coming around well after the database is turned into a mess of confusion. Also, providing a central place for people to share their creations from, perhaps with the ability to auto-reference mods they used in the process? Instant-win! Perhaps a submitter could have a means of checking boxes to indicate the mods used, which will create a list of links to each mod also in the database. How many posts do you see of an epic craft, followed by all kinds of requests for the file, or at least to know the mods used? The OP could just link to his submission on your site, which would answer all of their requests in a single link instead of forcing them to go back and think about the different parts all over again. You'd have to have functionality that stands out from the official solution so much more that it outright overshadows it. If you're serious about it, you could also get in touch with the devs and perhaps see about reaching some kind of arrangement with them to take over from SpacePort completely, giving you the opportunity to not just fix that crappy broken search, but also to re-organize everything properly from the ground-up as well. Otherwise, if you're just looking to create another site whose only real selling point is a better search, well... you're going to be fighting a heck of an uphill battle, since it's currently easy to bypass the crappy SpacePort search by submitting "kerbalspaceprogram.com [mod name]" to Google and getting more accurate results. Not trying to dissuade you here, because Jeb knows I'd love to see something better come along and do it right.

Today, the ground crew of the Duna Explorer mission received an unexpected surprise from home, months after calling back with a suggestion to re-task the Sherpas for air-based exploration, and requesting a ground-based supply of RCS fuel to help save the time consumed with trips to and from Bruin to top off. Jeb wasn't sure what to make of the newly-arrived equipment, until he got a closer look at it. "Uh... guys?" he called back to the station crew, "You're not going to believe this. It's a service platform!" Delivered by a specially-built automated harness, the landing and service platform gives the mission's dropships a ground-based means of replenishing their RCS fuel. Jeb is all about being the first to take off from it. Here's hoping he doesn't launch off at full throttle!

The problem stems from the way the game maintains a ship's hierarchy. It is a straight tree, with branches sticking out for the docks. This makes it possible for the engine to figure out physics effects for every part on the ship. Trying to couple multiple dock ports from one component to another creates a loop in the logic flow. Now, instead of the docked vessel just being a branch through the one docking port, it tries to create a loop through two or more ports instead, conflicting with the linear nature of the engine's physics logic. You can sort of get multiple ports to align and "believe" that they're docked sufficiently enough to serve your purpose thanks to the magnetic attraction feature of the ports, and due to their proximity and general alignment at contact, but the reality is that the physics calculations are still doggedly proceeding through only one of the ports. If you have a ship with a very high T/W ratio available on the "top" docked section, you might see the evidence of this for yourself when you fire the engines on it, and it swings wildly away from its connection, along the one dock port that was actually considered to be properly and fully connected. Best option is to use Docking Port Sr where possible, and quantum or docking struts where not. Otherwise, it might be time to see about refining the entire vessel design somewhat.

To switch control modes, use the buttons on the small display at the bottom left of the screen. To switch from flight to translation mode and back. A couple more tips: Four-wheeled rovers can flip out while braking or turning. You can decrease the chances of these happening by disabling the motors and steering in select wheels. Four wheeled turns can cause the vehicle to flip at-speed, so try locking the steering on the rear wheels if this happens to you. Steering will be slower, but it's just a matter of planning a little farther ahead when you want to change direction.

3D print mug, create ceramic mold with the prototype Start casting, glazing and firing. ??? PROFIT! (shut up and take my money!!)

Maybe not personally, but that is quite obviously one of the first-year classes in the Kirrim Memorial Planetary Warfare School.

That's going to be an... interesting injection burn. Make sure you quicksave (f5) before you being, because I suspect at least a couple of things might happen. 1. You forget to disable the other engines that aren't assisting with the maneuver and create drastic movements that break something, or 2. The whole thing flexes like a possessed rubber band, possibly breaking components (or whole ships!) off. Whatever you do, don't forget to post pics from the flight, because that looks ambitious as all get-out!

This seems so suspiciously familiar....

Jebediah, offspring of the Breaker himself, is quite comfortable surrounded by fire and doom.

That is completely bonkers right there! Gives a new appreciation for the sheer amount of work and brainpower that went into sending man to the moon!

Is that Jebediah... WETTING himself? Jeebus Whackjob, you know it's bad when you've scared Jeb!

I could see it happening... if Squad threw everything out and bought into the Unreal or Cry engines instead of Unity. So basically, what rewdew2 said. Hehehe

Dammitsomuch... me too. EXACT same error, on a carried shuttle pod that I'd sent all the way out to Duna. Got the dropship linked up, tested the gear, and... oh. :/

"Achievements"...? Really? You need Steam (or XBox or whatever) to TELL you when you've done something noteworthy? Look, when it's part of the gameplay mechanics (like GTA's little stunt jumps etc), that's one thing, but I've always believed that the real attraction in KSP was the fact that it doesn't restrict or suggest what I can or should do in any way. Are the snowflakes really that hard up for compliments in their lives that it's necessary to have a GAME tell them "good job"? Nobody gets a sense of satisfaction out of setting their own goals and accomplishing them, no matter what they might be? The nice thing about NOT having those stupid achievements is that there's nothing built into the game to usher me in a particular direction or flat out tell me what I've done that is particularly noteworthy. Also: who decides what those should be... in a SANDBOX game? Just think about it seriously for a moment. Are the folks who get warm fuzzies over "official" achievements really so disconnected as to believe that everybody has the same particular goals in this game as to require a standardized set of them? That is... unless we're talking about exceptional feats of riduculous craziness here... You know, the kinds of things you wouldn't normally run into in the course of just playing the game otherwise. ((Your 1,218 part vessel has unlocked the WHACKJOB-LEVEL COMPLEXITY achievement!))

LOLWUT. See, the first thing I think of when I see this is: "You know you play too much KSP when your woodland cabin has a delta-v value listed in the mortgage", but that's a different thread entirely. (seriously.. That. Is. AWESOME!)

It's not Squad's fault. Blame the manufacturer (now AMD) for being reluctant to support a platform that can't seem to figure out where it wants to go or how to get there. Blame Unity for having the unmitigated gall to try to ensure their flexible framework's stability by focusing on support for the most prevalent (and stable) hardware providers first and foremost. Or go ahead and blame the Linux community for being so pig-headed and confrontational with itself that it refuses to impose any kind of official standards in the name of "Open Source, Man!"

[TABLE=width: 800] <tbody>[TR] [TD]Equipment deployment procedures for the Duna Explorer mission continued today, starting with the first of the Kurb Burner rovers! The dropship, already previously docked to the vehicle to perform systems integrity tests, releases its payload from the Bruin cargo carrier. The Sherpa is able to maintain absolute stability, even while connected to the rov- HOLD UP; WTF IS THAT? Are those decouplers on backwards?! *sigh* The Sherpa is able to maintain absolute stability, even while connected to the flawed rover, which has recently been re-designated as a landing profile development dummy. KSC has committed to sending another cargo launch with the re-designed components needed for the mission. The descent begins with Sherpa aligning itself prograde, then rotating toward the vertical, engines swiveling to hover mode. This configuration allows the dropship to maintain control, even under full thrust. Initial de-orbit burn completed, guidance is set to target the current position of the research station, ground-side. Primary deceleration burn ended slightly off-target which was anticipated and of little concern, as at this point the Sherpa can remain aloft and make any necessary adjustments to its course for a few minutes. However, its time in the air is limited, as it is now on battery power alone, and will not be able to keep its fuel converter active after the batteries have been depleted. On final approach, Charlie brings the ship level and begins canceling lateral momentum, preparing to enter full vertical hover. On touchdown, Charlie ensures the rover is reporting contact on all four wheels, then locks rotation controls and initiates the final delivery procedure, topping off the rovers small RCS fuel tanks. With that step completed, he triggers the final decoupler mechanism, permanently releasing the rover from its carry harness, before shifting a short distance away to discard the harness itself, then landing in the designated staging area to begin recharging the dropship's systems for the return flight to Bruin. A short while later, Sherpa's fuel and power systems are fully charged, and Charlie signals his departure to the Cardinal station as he lifts off. Once the ship has traveled a safe distance from the station and gathered enough forward momentum, Charlie directs the engines into lateral flight mode, blasting full throttle for his orbital insertion. The second rover, used to test survivability when dropped via fly-by, guided itself to join its twin at the parking pen. Were it not for the flawed rover designs that render them difficult for the crew to operate directly, the Duna Explorer mission would now be entering the planned actual exploration phase. As it is, the delivered rovers will have to be used on a strictly automated basis to do a little unofficial looking around, while the crew waits for delivery of the redesigned units that they can actually drive. Their contingent of Sherpas are similarly unusable and have been completely powered down until the orbital fuel supply shuttle arrives and begins operations to top off their RCS tanks. [/TD] [/TR] </tbody>[/TABLE]

...or when you can't go to sleep at all because you're too wrapped up in thinking about the order of operations for your next big multi-phase mission.