Sandworm

Don't have steam = no play KSP. It's a mandate to use a third party service. And that third-party service is deciding who is and isn't allowed to play. And steam tracks player time/location, along with other metrics. It's DRM by another name. Steam should remain an opt-in option for those who want it, not a mandate for those who do not.

Me too. But that looks like it might change with the move towards steam-only builds. Today it's "temporary". Tomorrow, the steam client may be mandatory, an effective DRM scheme.

Have squad asked for help with this distribution problem? They may need some big pipes to distribute files, but they aren't youtube. Putting files onto a server for access by listed members isn't rocket science, even with thousands of customers. There are plenty in the community who could setup/manage such a project in short order.

Great. Another beta test group I'm not allow to participate in, this time because I didn't purchase through steam. Really, an opt-in beta for a fully released game is silly. On the other hand, I can understand why Squad wants to retreat back into the world of "it's still beta".

For people's love of flare, take a moment to look into how much effort is put into avoiding such artifacts. No camera maker is ever proud of seeing the internal mechanisms of their device in the final product. The fact that we now add simulated flare under the assumption that all cameras must flare all the time has generations of engineers spinning in their graves,

>>> I find it interesting, when visiting the suggestion forum, many of the problems raised still come from the more fundamental problems with career that were raised more than a year ago. Rather than interesting, I find it downright disappointing. The media may applaud squad for it, but I see them as totally ignoring the fundamental problems with career mode. I remember day one, the day we got contracts. Before even playing I dug into the configs looking for how we would write and edit contracts. I hoped for an explosion of mods offering interesting stories and challenging projects. What I got was "take X thing to Y place " .... and that was about it for career mode. Squad's pathetic attempts to "balance" career mode are like teaching a hippo to dance Swan Lake. The mistake is the attempt. To quote a much regarded movie: "the only way to win is not to play".

I wouldn't yet say they have jumped anything yet, but ending an already vague dev notes with a poem did have me looking for a shark.

Has there been a public release that didn't involve some change in physics, be them aerodynamics, joints, heating, or thrust profiles? I expect nothing different for this release. I also have absolutely no sympathy for people complaining that new physics breaks old craft/saves. KSP physics is nowhere near real, nor it is attempting so to be. Squad's every-changing view of how the game should play shouldn't be hampered by such things. They make the changes and we adapt. If that means re-testing and re-flying ... isn't that what the game is about?

The only thing I would have done differently would be to have purchased it directly rather than via steam. Valve does take its cut and given there is absolutely no difference in gameplay, I'd rather Squad get that money.

And the youtube crowd. There is crossover between beta testing and publicity. Mr Manley appears to be both. And it is known that youtubers get their hands on releases that are still in development, as evidenced by all the different build numbers used in the preview vids.

Yup. Impossible contracts have been a bug since day one with career mode. Maybe fixed tomorrow or maybe not. At least your experience is better than the early days of trying to test launch clamps landed on mun or while flying at duna. The issue of testing parts in strange places, typically large lifter parts (mainsails/large srbs in orbit etc) seems now just part of the game.

There is no official cycle but over the last few years they have followed a pattern. It is verbotten to speak of future release dates on this forum, but past releases have been seasonal. http://imgur.com/pjErWPB

The game and the show are using sounds taken from ancient sound effects libraries. I noticed that a few episodes of Doctor Who use sounds (door closures) apparently lifted from the original Doom games. It's not that Doom was the origin, just that for me that is where I heard it first.

>> Nope. That wobble was there since 0.19 (.20?) when I started playing. It used to rip apart space stations. They fixed it for the heading hold prior to us getting the pro/retro grade holds. The overcorrection also goes back a long way.

>> Like what, the PID controller? That just requires tuning, and it will never satisfy eveyone; it's not a bug. Staging is being rewritten for the Unity 5 release. What else? Like the wobble that occurs with certain sas holds. They fixed it in relation to heading hold but not pro/retrograde holds. Or the overcorrection when making large (ie 180*)changes. Switch a space station from prograde to retrograte and watch the system struggle to decide how to move, inevitably overcorrection all the way and sometimes creating a perpetual loop. Or the fact that engine movements are dictated from the perspective of the control pod regardless of the orientation of the engine at the end of the wobbling rocket, again resulting in constant over-correction. While these behaviors are considered aberrant in any sane control system and are readily addressed, they have been so long a part of KSP's characteristic silliness they shall never be fixed. What was once a bug is now a feature.

And some bugs are so persistent that they span years worth of development. We regulars don't even notice them anymore. They are now "character" and so remain forgotten and shall never be fixed. Top of such true bugs would be several aberrant behaviors in KSP's control system, followed by the jittery orbit calculations/display. Lower on the list are things more akin to content such as the total lack of engineering data. These are so longstanding that fixing them would change much of KSPs character. Nobody should hope that they will ever be fixed.

>>> Console & PC are two seperate builds, one won't limit the other. I really hope this is true. I've seen a couple developer agreements that stated the console version must be essentially the latest and greatest. The console version was not to lag behind any other version in terms of features. In such cases the console version does limit as new features cannot be pushed to any version until they are ready for console, which can take more testing/money/time. There is also a growing body of evidence that some AAA PC games have been deliberately hamstrung so that they do not better their console versions in terms of graphics. I hope squad hasn't signed any such agreements. Of course if they have, they wouldn't be able to tell us as such things are locked behind NDAs. See the Watchdogs graphics fiasco: http://wccftech.com/e3-2012-graphics-watch-dogs-deliberately-turned-off-pc-next-gen/

I tried this a few times with 64k but couldn't get a consistent assent profile. The options are nice, but every time I revert to launch it forgets the setting and resets to 'best guess'. That makes fine tuning difficult. Also.. (1) Some averaging is needed when it comes to the time to apa. On most of my launches the second stage initially has a rather low t/w ratio. GravityTurn reacts to this by increasing the AoA to push the ApA further away. That's ok, but as the t/w ratio rise GravityTurn returns to prograge and stars feathering the throttle. The combination of off-angle and then feathered throttle is not the ideal solution. The math answer imho is to take the rate at which the time to ApA is reducing and look at the rate of change. If it is slowing, if the time to ApA will never get 0, then offset thrust isn't needed and GravityTurn should continue on prograde. Is it possible to disable the offset feature? (2) Another nice option might be high/low acceleration limits. On long 64k or RSS burns one way to smooth out the turn is to maintain a consistent G on assent, then go full throttle once nearly horizontal.

The assumption is that the only relevant velocity is with other objects within this universe. Under multiverse schema it may be that relative velocities between universes establish some sort of baseline, that universes move relative to each other in a dimension we cannot appreciate but that nevertheless has influence. I've read at least one paper suggesting this as a proposed dark energy.

Considering the forces that the booster survives at launch, when it's 10x as heavy, a 6m/s landing doesn't sound that horrible. Spread over the 1-2m flexibility of the legs it doesn't seem that bad. It would be rough on a human but easily survivable in a good seat. The deceleration burn(s) might be nearly as brutal. 6 would also be the max, with 6.1 probably breaking parts and writing off the entire booster.

https://en.wikipedia.org/wiki/Metallic_hydrogen

That depends on who you talk to about these devices. Many of the IR sensors allege they can detect the heat signature of the compressed air around the missile at speed, whether the motor is still alive or not. If they are doing mach2+ they are definitely warmer than the background. So it seems very plausible. The next level of the tech, sometimes called eyeshine or similar, claims to be able to detect the seeker heads prior to launch. An IR light is emitted and the sensor looks for reflection from optical devices, specifically seeker heats with IR detectors. It sounds fanciful, but consumer hidden camera detectors work on the same principal. Handheld units can detect pinhole cameras out to a hundred feet. Scale that up, add some computing power, and spotting a missile's seeker head at a couple thousand feet seems possible. The thing to do would be to take a seeker heat from something like that hellfire in cuba to an airshow and see if anyone notices.

There are in fact many systems out there to detect incoming IR missiles, even the tiny shoulder-fired ones. Some are based on IR cameras. Any missile at speed is a very distinctive IR object. Others look for higher frequencies, UV, from the burning embers in the rocket exhaust. And in low-sophistication environments even low-power doppler radar can be used. These are not-cheap addons for most airframes but they are not rare. the most well known is probably Saab's MAW-300, which I think is available for commercial civilian aircraft.

(1) Canada has requirements/duties/treaty obligations to meet that include fighting overseas (nato). (2) Canada has sovereignty issues. We need to maintain a rapidly deployable force over our vast territories else they be taken by the russians/US and anyone else wanting our northern oil. We will only ever have a handful of ships and they are slow. Aircraft are the only option. (This isn't about shooting, but flying the flag and asserting legal rights.) (3) Countries like North Korea have substantial air defense networks. Such wars would require modern weaponry. (4) Canada has troops on the ground. They need support, including air power. (5) Canada has a history of excellent fighter training. Countries from all over the world come, and pay, to train in our skies. To maintain those cooperations we need to at least participate in the exercises occurring over our territory.

There are several software steps for firing such a gun. At a minimum there is a command to spin up the thing, another to open the port (which is probably subject to some aerodynamic constraints) a third to actually feed in/fire the round, and one or more checks to see if the master arm switches are allowing any weapons. But physically firing the weapon isn't saying much. These things are only useful once tied into the targeting suite. In most modes, pulling the trigger is simply an authorization for the computer to fire. The bullets only leave when the computer thinks they have some hope of hitting the target. There are no tracers for the pilot to walk onto the target like seen in the movies. The machine may only delay the rounds by a 1/100th of a second, but at speed that's the difference between a miss and a hit. So there are lots of little software tweaks to work out before the weapon is practical.