Nigeth

A few examples: Try to set a maneuver point when your ship is on a hyperbolic trajectory. Most of the time you can't or the first node you can set is hours or days from your current position. If the game doesn't add a 'clickable' point to that segment of the trajectory curve you can't set a node there. The game usually forgets to add clickable points to highly excentric or hyperbolic trajectory curves. Especially in the vicinity of "poles" of the hyperbolic trajectory. Known since I don't know when Try to add a maneuver node on a trajectory curve when other 'clickable' objects like vessels, asteroids, node markers or other trajectory curves are in the vicinity. You can't because the UI gives privilege to the other clickable nodes over your trajectory. especially annoying when you are on an inerplanetary trajectory and want to make adjustments and 'unknown' markers are displayed on the map. Try to add a maneuver node to a trajectory curve when the patched conic approximation keeps changing its mind due to rounding errors and/or the initial conditions making it hard to settle on a solution. The flickering will make it impossible for you to click on it. Try to design an encounter over interplanetary distances when your ship is still in orbit around Kerbin and you want to optimize your aproach to for example Duna or Jool. Now try it with 'focus view' on Duna or Jool. Now try it with 'focus view' on Duna or Jool and other vessels in Orbit around Kerbin, Minmus or Mun. I could go on and on.

I notiice a lot of 'stuttering' since 1.0.3/1.0.4. Nowadays when I launch vessels the game thread comes to a complete stop every few seconds and then restarts again with 60 fps. You can also see it on the time indicator that always switches from green to yellow color every time the game stutters and comes to a halt. It was perfectly fine before as should be expected on a Core i7 with 3.7 GHz

Why do people care what other people do in their single player game? The whole world could use Mechjeb and it still wouldn't have to concern you since nobody is forcing you to install it. Secondly if you think that MechJeb is 'cheating' then do you also consider NASA or ESA to be organizations full of cheating alpacas? The amount of electronic and computerized help, autopiloting and autostabilization they use is staggering compared to even MechJeb. Read up on just how little manual control NASA uses and used during their space missions to get a feel for it. Thirdly somehere over the several hundred hours I've spent on this game wrestling with the arcane, unfinished and seriously buggy stock flight and maneuver control UI stopped being fun and started being extremely tedious so any help is welcome. I usually don't use it because I get by with KerbalEngineeer and PreciseNode but I chose MechJeb anyway simply because I think that what I do in my game doesn't need to concern any of you.

The problem about "realism" is that you can't talk about realism when you are debating isolated features. If the whole game isn't designed for this all you get is a pocket of enhanced realism surrounded by a game not designed to deal with that. I wouldn't even care that aerobraking/aerocapture doesn't work if the game was designed in a way so that you don't need it and still had a fun experience. If I could easily plot gravity assist trajectories and launch windows for my flights and the physics were scaled down so that I wouldn't need hundreds of aerocapture passes I'd be fine. Currently I can do none of this in stock. I could do this with mods (it would still be more hassle than it's worth though) but with mods I get no support from Squad whatsoever when bugs happen. So I now have a modified aerodynamic model and heat physics and basically no tools in the stock game that help me deal with those changes. Don't even get me started on the fact that those changes haven't really been communicated to all players in a meaningful way. So what I have: - new scaling for engines - new scaling of the aerodynamic models - more realistic heat physics - still the same crappy maneuver node system - still the same patched conics approximation with a maximum of three conical patches - still no advanced trajectory planning and plotting - still no launch window calculator - still a time warp and physics timewarp system that can't even deal with 'normal' physics without choking some of the time. So the only thing the new system gives a normal player is even more headaches than before. To experience a new physics model you don't really need to bother with since fuel is essentially 'free'.

Installed the latest KW release due to the claims that it will work with 1.0.4. First ship I made and took to orbit exploded due to the KW decouplers. So I'd advise people to be cautious with KW rocketry and 1.0.4

The moderators have made it unmistakenly clear that they won't even bother to look at this issue since it affects a modded install. Due to that development I don't see any reason to keep the files up any longer if nobody bothers to look at them.

Final notice: I will leave the files on my dropbox account until Sunday 07/12/15 9 pm CEST. After that I will assume that squad has no interest in looking at the issue and fixing this longstanding bug and I will delete those files. I've tried to report this issue for more than two weeks now. I've done my due dilligence and if there's no interest in fixing this then so be it.

Yes. You can also see it because the heat overlay is deep red. Which is the lowest temperature

I've now reported that issue multiple times. In other threads and by messaging mods. Somehow my reports seem to be ignored. This is my last try to get this issue to the attention of the mods and squad. Until now most reports by others have had the problem that the issue couldn't be reproduced. I've included my 1.0.4 career save and steps that can 100% reproduce the issue (see dropbox link) https://www.dropbox.com/sh/h5hbwow5dmgcyr5/AADQhQ72gdPeJypWJRZ-lyn-a?dl=0 KSP 1.0.4 steam version Macbook Pro 15'' (early 2013) Core i7 2.7 GHz 16 GB RAM Geforce GT650 M 1 GB VRAM Windows 8.1 Mods: KerbalEngineer Redux KW Rocketry Module Animate Emissive Procedural Fairings Scansat Copy the save folder "Nigeth" to KSP/saves Start the game Resume saved After the persistent save has been loaded hit "ESC" Load the "quicksave" You'll end up in orbit around Jool Hit "." to time warp You'll get the "cannot warp while under acceleration" message I get the message every time I load that particular save. I also included my output_log.txt

I have a really small issue with FAR. It's more of a nuisance really but maybe you would be interested to know this anyway. When I install FAR (FAR only, stock otherwise) the engineer report no longer recognizes parachutes that are attached to a vessel. The engineer report in the VAB will always report that "parachutes are missing". Even if they are attached, integrated in the staging and actually work. If I remove FAR the engineer report will instead report "no issues".

I can delete them manually. They just don't automagically (love that word btw.) delete themselves. It's more of a nuisance but I use that feature a lot and at some point deleting a double digit number of expired timers is getting a bit bothersome.

The new release will no longer delete standard timers added due to warps. If I warp to apoapse or peripase or indeed any node (SOI, DN, AN etc.) Kerbal Alarm Clock will add an alarm that will never get deleted once the warp is finished. Eventually this will lead to the window being chock full of old alarms that have expired a long time ago

No it is not "getting increasingly more hazy". Just because it is easy to treat people - that have already paid on steam early access or kickstarter - to a game that is perpetually in alpha development doesn't mean that the lines have blurred. It just means that you are being unfair to your customers because you have to face no repercussions. Since they've already paid and have no recourse or refund options anyway. Also because the game is "technically still in beta". The "technically this game is still in alpha/beta" philosophy is probably one of the more toxic new ideas in SW development. It treats people with legitimate complaints as if they had no legitimate reason to complain since the game is "technically still in beta" and therefore people can't resonably expect it to be finished. Combine that with early access or kickstarter and you get a game that is perpetually in an unfinished state that people have already paid for. This is even less reason for developers to actually finish and polish games. Then there's the "without early access you wouldn't even have a game like this" defense which completes the trifecta of "reasons why you can't reasonably complain about the state of our game". Even worse it puts the developers in a mindset where they themselves are led to believe that they don't need to 'finish' or 'polish' their games since it's still "technically a beta" and therefore people should expect the product to be unfinished and buggy anyway. This is not a paradigm shift. This is just an effect of a toxic development mindset combined with the fact that you can actually hold your customers hostage and string them along for the ride since they've already paid on the promise of you actually releasing a finished product eventually. This shouldn't excuse any development studio from doing its due dilligence and actually delivering a reasonably finished and polished product. It does currently, but it does so on the backs of a very passionate and patient fan base. The more broken games that get never finished appear on early access the less people will be interested to actually buy one just for a promise that is usually never kept. You can see it with AAA games already where the standard recommendation has become to buy it on steam 6 months post release or wait for the GOTY edition that includes all the DLC and has fixed most of the bugs. And steam greenlight and early access have already become a wasteland full of shoddy cash grabs released by developers who never intend those games to be finished ever.

People who spend the time and effort required to register and post comments love this game. If they didn't they wouldn't care enough to do that and simply stop playing

Quoted, because you exemplify the point I'm trying to make. Suppose for a second that Squad would approach all in-game systems with the same attention to realism as it did with heating. Would you still be OK? What if the heating stays as it is but hauling an insane amount of delta v and mass became impossible for the sake of 'realism' and you also couldn't use nuclear engines or any other sort of 'near future' propulsion system? What if they added something like TAC life support and you'd also have to make sure your Kerbals survived for years in deep space? What if they implemented something like "Dang it!"? What if the implemented something like remote tech? You can't just pick and choose and somehow be OK with all the systems you don't care about being less realistic just as long as the one you care about is. Well you can but the result is not added realism just a game that is differently not realistic. It also might not necessarily something that is still fun to play. I also don't really get why all of this has to necessarily be a part of the stock game when there is already a great and vibrant modding community that provides mods like realism overhaul, real solar system, FAR, DRE, real fuels, TAC life support and many more that already do what you want.

I don't like the changes to the heating very much. Not because of the heat system though. My problem is that KSP doesn't give you the tools and know how necessary to avoid aerocapture entirely. This change leads to a resulting game that is harder for most players for the sake of 'more realism'. Which in that particular case doesn't mean 'more fun'. Also doesn't make the game any more realistic. Real world missions don't use aerocapture or aerobraking (those are technically two different techniques btw.) Except for two notable exceptions (the Magellan probe and the Mars global surveyor) interplanetary missions usually use other measures to adjust velocity. Either gravity assists, burning rocket fuel or a combination of both. Sometimes the delta V budget is so limited that a mission can only achieve a fly by. (New Horizons for example). Cassini-Huygens had to do two gravity assist fly bys of Venus, a gravity assist fly by of Earth and one of Jupiter to be able to end up at Saturn (https://en.wikipedia.org/wiki/Cassini%E2%80%93Huygens_timeline#/media/File:Cassini_interplanet_trajectory.svg) and it took the probe 6 years to arrive there. You can't plan such a trajectory with the limited simulation model KSP provides (it would be very hard at least). You'd need a 'true' n-body simulation. Even then you'd need the know-how and mathematical planning necessary to design such complex trajectories. Even if you'd have all that you'd still probably have to wait years or even decades of in game time for a launch window. The game doesn't help you in any way either. There is no tutorial that explains gravity assists to you. There is no launch window planner if you don't install mods. The default patched conic approximation won't show you your trajectory through the Kerbol system (it stops after 3 conical patches) so that you couldn't even plan something like this in stock without mods even if the simulation model was magically accurate enough to make such an endeavor worthwile. All it achieved is to make the game harder for most players without adding more realism to it, Just because some players are under the false impression that this is 'more realistic'. Even worse it isn't even half as good as deadly reentry, a perfectly fine mod anyone that craves added realism should have already installed anyway. Right now you can't really do interplanetary missions via aerobraking. Worse you can't really do an interplanetary return to Kerbin via aerobraking. So you'll either have to haul huge rockets with insane delta v budgets through interplanetary space (space truckin') meaning that you'll spend more time assembling your mission in orbit over Kerbin than actually doing it. Usually using 'near future' type means of propulsion which doesn't really make the game more realistic (it only exchanges added realism in one game system by making another less realistic). Or you use ore extraction and refuel to generate the insane delta-v requirements in-flight which is not necessarily realistic either. Or you build ridiculous contraptions with a truckload of heatshields and/or abuse the added radiators. Or do what you did and basically turn it off entirely (limiting it to 20% you might as well turn it off completely). All done just because a few vocal players didn't find stock heating quite challenging enough yet were too lazy to install DRE. If this had been a planned feature that had gotten enough development time it may have been different. As it stands the new system is only half baked since the rest of the game hasn't been caught up to speed in order to give you the tools and means necessary to deal with that change. - - - Updated - - - I also don't really understand why Squad assigns its limited development time and budget to implement a feature only a vocal minority claims is needed. Especially when there is already a mod that does the same.

I disagree with the assessment. It's not that KSP is too stable. It's that the mod interface has stabilized. A game can have a stable API and still be broken in places. Just because you won't have to update your mod doesn't necessarily mean that people can actually play the game.

How far we've come that people can now be called 'haters', just for expecting a game they've paid €40 for and that was officially released to be somewhat finished and to not break their save games.

That's why you have testers. That's why you have test automation. That's also why you have to manage risks in actual SW development and can't deploy new features whenever you feel like it. if you actually were a professional SW developer you wouldn't argue against those simple facts. That is professional SW development 101.

I have a few minor questions about your mod, if that's OK I suppose that it is a limitation of KSP that leads to B9 wings only having one attachment point (either fuselage or other wing)? I can't for the life of me get two procedural wing parts to attach to each other and the resulting combined wing to then attach to a fuselage part. Parts made up of multiple B9 wings always tend to only attach to the fuselage and not to each other, leading to the individual parts flexing individually. To get greater stability I'll always have to strut the parts to each other. Which ruins the whole look. To put it another way. Suppose I want to design delta wing. What I'd like is for a way to first design the wing by attaching different procedural surfaces to each other and then make the result behave as if it was a single part that can attach to fuselage parts over the whole root area. Is that possible? I don't seem to be able to do that. Wing parts either attach to each other (which means they are not connected to the fuselage) or to the fuselage (which means they are not atached to each other Is there a way to have modifications made by the sliders not be applied symetrically from the middle outwards but instead from the left or right side? This would make designing parts that fit to each other a whole lot easier. Is there a way to input the numbers represented by sliders via the keyboard or to change the "sensitivity" of the tweakables? Sometimes I can't make two parts fit because I can't for example make one part have the same semi-span as another (slider won't snap to the right value)

It's only "necessary" if the stock heating is not "realistic" (whatever that means) enough for your tastes. I'd argue instead that the default game mechanics of a game that is targeted at a broader audience (KSP even has an enducational version) should never cater to the hardcore crowd and instead aim for a system that is "fun" and maybe even "challenging" but not necessarily realistic. The fact that DRE, real fuels and FAR exist and can be installed when you want things to be more realistic and, well, more deadly make me wonder why people even argue for a more realistic stock aerodynamic and heating model.

In my experience no it has not reduced phantom forces. That's actually one of the issues that plague my now abandoned career save. I have two crafts - one surfaced on Eve and another splashed down on Laithe - where the phantom forces make the solar panels disintegrate whenever I switch to them. When I revert to launch sometimes planes flip over or turn sideways. When I revert to launch sometimes my whole rocket yanks sideways and the rocket including launch clamps ends up at an 45° angle. I once lost an atmospheric analyzer mid flight while in transit from Kerbin to Jool that was stowed away in a service bay because it broke off. A few times when I was rotating my craft (with "q" and "e") the solar panels fell off. I could go on. Once my whole ship simply broke apart mid flight. The whole issue where the physics "wind-up" changes orbit and/or velocity once the game switches from physics-less to physics mode is still there also

For example they could have introduced those changes with the 1.1 release that will give us Unity 5 support. A release that will potentially break all of the things anyway and so probably will go through an extensivr testing and beta phase. THis would have given modders and interested players enough time to prepare for its eventual release. - - - Updated - - - So now we're yet again at the point where the "if you don't read all of the forums and all of the blog posts it's your own fault" defense comes out. I could dissect the whole official communication of Squad prior to 1.0.3 now to try and prove to you that they haven't said what you claim they said but since you've already made up your mind I can't really be bothered. Rest assured that even if you are completely right and I'm wrong it still doesn't make the way Squand handled this any better. So let's just agree to disagree on this.

They told us that there would be a release that fixed a few of the bugs and tuned a few of the values introduced by the new 1.0 stock aerodynamic model. They never never said that they would instead completely rework one of the core game-play mechanics. If you can't see that those two things are different and vastly differ in scope and potential repercussions then I don't know what to say to you. Also a third time just to be absolutely clear. No one claims that squad should never ever "change mechanics after release", that's just your interpretation. What people instead are trying to say is that depending on the scope of the change and the amount of stuff changed you need a different approach to how you release your updates and communicate those changes to the community.

That's not what I said so please don't put word into my mouth. Also what you really need to keep in mind is the fact that people are currently playing this game and may have invested a lot of their free time and energy into an ongoing save. 1.0.3 was announced and "marketed" as a maintenance release to fix issues with the new stock aerodynamics model. A maintenance release should never ever break existing saves. Unless it is absolutely necessary and there can be no way around it. If you communicate a release as being purely maintenance you should never ever use it to do a major overhaul of an existing in-game system. The reworked heating system they've introduced with 1.0.3 potentially breaks many many mods and actually broke a lot of existing game files. This has lead to people not being able to play for days or even weeks until all of the mod developers have caught up with the changes introduced in a patch that was communicated as a bug fix release. This has also led to people actually losing their whole progress (potentially hundreds of hours of gameplay) due to save files that are now broken beyond repair. If by some reason you still think you need to do it you damn well make sure that everything works. This doesn't mean that you should never update your game and "forever ride a wave of mediocrity" as you so melodramatically put it. It just means that you have to plan your release schedule (and effort) accordingly. A major rework of an existing in-game system should never be done like the way Squad introduced their new heating system. Without any prior warning or announcement and with no way for people to test it and plan for its eventual release. You might get away with this during alpha or beta but not once your game is officially released.