HebaruSan

Cool, that'll be a nice one to have. A related suggestion: when Angle Snap is on, it's easy to place the first side of the strut exactly where you want. However, the other side is always completely free-form in its placement even if you leave Angle Snap on, so you either have to zoom in and move the mouse very precisely, or just accept that there will be some structural asymmetry in your craft. It would be handy to have the option to snap both ends somehow, while still being able to opt for free-form placement by disabling Angle Snap.

I don't even blame them for that (much). SQUAD had zero experience with console ports before this, and it's hard to justify extra expense (to your boss or to yourself) when you can't quite rule out the possibility that the lowest-bidder option will work out fine. Now that they've seen the problems that approach can cause, a much stronger business case can be made by SQUAD staff that you get what you pay for.

I don't play on console, but thanks for communicating well with those who do. Blitworks looks like a much better choice of porting partner based on their web site. It sounds like SQUAD will be more actively involved in the port this time, which is also a good sign. The plan of regular updates is particularly encouraging. It's a shame that you had to spend however many weeks getting out of and into contracts, which understandably would have been difficult to communicate about; I can't imagine reading a dev note like, "Good news, we met with our lawyers again this week, and they said..."

For what it's worth, the PC version also overshot wildly until fairly recently. It was a longstanding issue with the core game, as opposed to something that Flying Tiger Entertainment broke in the port.

How about an astronomy segment with a big telescope, especially if you're on the far side? This could be done either with mods or with stock parts imbued with the magic of Role Playing. Some of your habitation could be designated as a luxury hotel for the exclusive use of tourists. An emergency escape system could be kept on-hand to ensure that all crew members can be evacuated at any time. Presumably your fuel processing would already include service trucks to refill visiting landers. A real future moon base would need plenty of life support systems, including waste reprocessing and greenhouses. These could also be done with mods or with stock parts and Role Playing.

Sorry. I did that because it looked like a case of sincere ignorance that any rules existed, and it didn't feel fair to jump to reporting in that circumstance. Back on topic, rockets flipping is actually a sign of improvements in the aerodynamics compared to older versions. So the answer to this post's titular question is, "Yes, in version 1.0.0." I can understand why it would be frustrating for someone who hasn't taken the trouble to re-learn that element of the game.

FYI, saying that something is "not working" or "just unplayable" is an ineffective way to draw attention to it. Developers mentally click "ignore" immediately when they see you have not expressed any concrete complaints and don't even realize it. Plus it's kind of rude and entitled-looking. You're demanding that they spend weeks or months glued to their computer screens all day, running test cases and having meetings and debugging code to make you happy, but you can't even be bothered to take a single screenshot or type a short description of any specific problem? If it's as broken as you say it is, demonstrating it should be trivially easy. How can they satisfy your demands without knowing which changes would help?

If I recall correctly: Build a giant tube, stick it in Uranus, then induce fusion inside so exhaust shoots out the end of the tube and pushes the planet. Eventually maneuver it to fling Earth into orbit of Jupiter.

Specifically, in case anyone else is wondering what 'it' means: So instead of finishing the part overhaul, the art crew is helping with translation efforts and making plushies. The upside is that SQUAD is not saying, "Eh, this revamp was a mistake, let's forget it ever happened." They might return to it at some future date.

This looks like as good a place as any to dump my latest attempt to digest all the threads about human spaceflight and colonization... Life for humans is far safer and more pleasant on Earth than anywhere else. We already live in the best place we're ever going to find in terms of gravity, atmospheric composition, atmospheric pressure, temperature, radiation, and on and on. The only thing that's kind of difficult here is getting to orbit. For a colony to grow to self-sufficiency, it's going to have to match Earth in enough of those essentials and offer enough advantages that a lot of people are motivated to choose to go there and stay there. That's part of the reason why I've started to conclude that to really live in space, we'll need O'Neill cylinders with complete functioning biospheres powered by solar or nuclear. If we can make it to that point, then suddenly there's both a workforce and a market for mining asteroids and manufacturing in space. The residents of the cylinders will want materials to make replacement parts, consumer goods, habitat expansions, etc., and they'll be well positioned to acquire them, so they'll have a natural incentive to expand humanity's space footprint exponentially. But until then, until there's a vital human force sustaining and driving the development out of pure self-interest, any other human spaceflight is trying to force it prematurely, in a way. Yes, NASA could be super-funded to embark on the century-long project of building a sustainable Mars colony, but what if the funding gets cut a few presidential administrations down the line? Not only would the project itself be halted, but now someone has to decide whether to mount a rescue mission, and we've got nothing to show for it. If we were already at the point where space activity as such was profitable, it wouldn't be as big of a deal, because other sponsors would want the colony for more reliable reasons. But when NASA/ESA is the only game in town, it may be for the best that they focus on laying the groundwork by sending robots to look at Ceres and discover that Mars is covered in perchlorates.

But I thought millennials appreciated state of the art computer animation??

DEVICE=C:\DOS\HIMEM.SYS DOS=HIGH,UMB DEVICE=C:\DOS\EMM386.EXE NOEMS FILES=30 BUFFERS=20 Often followed by manual configuration of the sound card's IRQs...

Uranium and its byproducts are so powerful and useful; why waste them here on Earth? We're already 8 light minutes away from a gigantic fusion reactor that distributes its copious output in all directions for free, inviting us to collect as much of it as we need. But if we want to operate anything out past Jupiter, we're going to need those denser energy sources.

In case this was unclear, "not checking his/her flight instrumentation" is not involved in the launch-to-rendezvous scenario. The pilot does check his/her flight instrumentation, and it is set appropriately for the action of locking prograde at the time that decision is made. Then, later and without warning, the flight instrumentation changes itself automatically, and the craft swerves out of the pilot's intended alignment. Yes, we can work around that problem by watching carefully for the moment when the malfunction sets in and tapping 'F' to reset the SAS mode, or clicking the nav ball until it's back in the correct mode. But being able to work around a problem doesn't mean it's a non-problem.

What error is the pilot making in the launch-to-rendezvous scenario? Targeting the target? Locking prograde?

For my part, I don't think it's a question of play style or what anyone personally likes or dislikes, because of course your craft designs don't affect me. Personally, I have installed and used TakeCommand before, and found it convenient for certain purposes. Rather, this is a question of the design decisions that structure and balance the game mechanics and available parts, because what SQUAD does with stock determines the default behavior that all players get before they install any mods. I'm not even saying the seat should or must have its current limitations, just that it's entirely justifiable for it to have them if SQUAD wants it to, both from a game balance perspective (408 kg discrepancy to account for between otherwise equivalent setups) and from a realism perspective (safety of launching crew to space in open air) if we wish to invent such reasons. I'll even admit that a smarter version of the same limitation concept would be preferable, such as if crew actually did die when strapped to the side of a supersonic rocket, since then we could test crewed rovers while still having reasons to use command pods for rockets. But the status quo is really not that bad. The game now has an orbit editor built-in, so launches are no longer strictly necessary, depending on your play style. Does that mean the launch gameplay should be obliterated and replaced with a popup box in the VAB that asks you to input your desired orbit altitude? Of course not, because the primary experience is intended to include launches. Similarly, the command seat is intended to provide the player a trade-off design choice between less mass and greater functionality.

You've somewhat intermingled two separate topics here. Updating from Unity 4 to Unity 5 required extensive changes because the Unity developers decided to break backwards compatibility in Unity 5. This means that code that was valid and worked in Unity 4 broke on Unity 5, including much of KSP. This is not related to cross-platform ports; the exact same changes were needed to update the Windows version from Unity 4 to Unity 5 as were needed to update the Linux version from Unity 4 to Unity 5, because the old and new APIs were the same for both of those platforms. 64-bit was stable on Linux and unstable on Windows under Unity 4 because of problems internal to Unity 4 and its support for 64-bit Windows. (I suspect it's "Fixed StackOverflowException handling on 64-bit Windows", but I don't know that for sure: https://unity3d.com/unity/whats-new/unity-5.0) The fix was to update from Unity 4 to Unity 5, because of fixes and improvements made to Unity itself, not to write code in KSP that did things one way on Windows 64-bit and another way on Linux 64-bit. The takeaway in both cases is that the same code runs on all platforms. (Except, of course, for the already-noted limited specific changes that were made to support consoles.)

Most of this is not accurate (especially the "coded entirely differently" part). KSP was originally available on Windows, Linux, and Mac in the first place because it's built on a game engine called Unity, which lists 27 different supported platforms on its web site, including PS4 and the X Box One. In an application that uses Unity, most of the code will run just fine on any of those supported platforms, because Unity has already done the hard work of accounting for variations from one to another. https://unity3d.com/unity/multiplatform Of course that does not mean that a port is trivial, or that simply changing the compilation target and fixing the odd glitch here or there will result in a playable game. Flying Tiger Entertainment did have to re-do certain things where KSP's developers assumed a PC platform, notably parts of the UI (where a mouse and keyboard was assumed but a console provides controllers) and the save system (where a normal PC disk environment was assumed but a console provides some kind of space-limited cloud-based storage system with a weird upload/download API). Since these are the biggest pieces of new or changed code in the console ports, they're also the most likely to have problems in early releases of the ports. And so they have. But back on topic, most of KSP is the same across platforms. Nobody had to re-write the parts that calculate orbits, or engine thrust, or atmospheric heating, or the sound, or the animations, or anything else that works mostly the same across platforms, as long as cross-platform Unity APIs were used to implement those features.

I'm sure that would never result in complaints of, "How dang hard is it to run one more wire from X to a button on the seat?? SQUID PLS FIX"

Hmm, in further testing I'm not able to get any auto-docking at launch at all, with or without struts, even in the simplest possible case of two tanks laying side by side on the runway. The front ports are docked as expected, but the rear ones aren't. If I decouple just the front set, the tanks split into two separate crafts and roll apart. I'm baffled as to how you could be getting this to work. Maybe my mods are interfering somehow.

Thanks for the response, I'll have to take another look. Is there a trick to it? I thought all I had to do was line them up so they "look" docked, but that wasn't successful for me. Should they be farther apart? Closer? Is there a tweakable that needs to be set?

Yup, OP's link says, "EAST is a tokamak, a doughnut shaped device originally designed by the Soviets." (paragraph #3)

But you were -13 years old when Back to the Future came out. What makes me feel old is young scamps like you.

Haven't there been observations that support dark matter being a substance rather than simply an unknown aspect of gravity? For example, the galaxy cluster collisions in which gravitational lensing occurs afterwards in the space in between, suggesting that those galaxies' dark matter has clumped up and gotten left behind as the regular matter continued outwards? I'm not an astrophysicist, so all I can cite is Wikipedia and some online pop sci articles: https://en.wikipedia.org/wiki/Bullet_Cluster#Significance_to_dark_matter http://arstechnica.com/science/2015/03/colliding-galaxy-clusters-offer-stongest-case-yet-for-dark-matter/ http://www.space.com/29115-dark-matter-interactions-galaxy-collisions.html What non-substance explanation could account for such an observation?

Here's an updated version. This time I wanted enough Δv to do something interesting, so the crew segment has an LV-N and triple the fuel. Of course, that required the lift segment to have more engines, more fuel, etc. I also added a probe core so it could hold still during reattachment. I wasn't able to get all 3 docking ports to dock, either at the runway or in space; but thanks to the locked auto-strutting of the landing gear, the craft holds together without even flexing just from the single mini port at the front. I decided to leave the ports on anyway since that feels kind of exploity. Does anyone know whether multiple docking ports can still be auto-docked at launch?