Jacke

If you use Part Angle Display mod, you can see how much you've tilted a part just before attaching it with the old method of picking the part up and holding shift and then using the WASDQE keys tilt it by small increments. The mod has a window where you can adjust the amount for each tick above and below the standard 5 degrees. The 3 mods I consider essential in the editor are Editor Extensions (this one), Part Angle Display, and RCS Build Aid.

I have blizzy78's toolbar but for Haystack I preferred it being an edge window with a tiny tab to pull it up when I needed it. With the large-button stock bar, I'm trying to limit what's on both it and blizzy's bar. Would it be possible to put in a config setting for the original window behaviour?

Oh come off it! This game versus simulator argument was tired in the 1970's when it was about board wargames. Some games are more abstract and some are more detailed. Some are more realistic and some are more artificial. Spectra of nuance. But they all have to be games. They may vary in the steepness of the learning curve and the demand they put on a player, but they have to be a good game to be good. They have to be smooth and appealing and give sufficient reward for what a player has to put into playing. And there's going to be some games that some people love and others they hate. Making it a binary choice is just wrong.

Using 1.29d, found a minor issue. The values for the names of KeySetName1 and KeySetName2 in the included AGExt.cfg is "ModTest" and "ModTest3" rather than the expected "KeySet1" and "KeySet2".

Personally I think clipping is wrong because of the 5-pounds-in-a-4-pound-bag factor. I can also see why it was changed too, although it still seems wrong. That was only the first revision. Production got that to 65%!

We do have a HAL 9000.

You keep posting those links in every comment you make. Why? They don't really address the concerns of the KSP players expressed in this thread. They are a bunch of feel-good thoughts and requests for us to trust Squad. Our concerns are based on how Squad has actually turned out the last few releases. Indirect words aren't good enough. I don't think we were ignored, but you wouldn't know it based on what Squad has said. And it's not a "gut-reaction poll". Many people both for Yes and No gave well-nuanced arguments for their positions. But I don't see the No concerns being refuted. It's still 73% No. Yes, Squad is showing us they're working hard. So how about pushing 3 releases in the next 6 months: 0.91, 0.92, 0.93. Then another month for adjustment and bug-fixes and put out 1.0 in August. That would be less of a gamble than hoping they can do it all in one fell swoop.

Well, today's Devnote Tuesday is out. And the only references to calling the next version "1.0" was using that as the label for the next version. Not a word about that 3/4 of their player base think "1.0" is a bad idea and for well-thought reasons about how it will impact Squad and KSP. Obviously Squad is ignoring this issue and hopes it just will go away. That's sad. On second thought, maybe Devnote Tuesday would be the wrong place for such a statement. That statement would be difficult too.

That is a recipe for disaster. Even if you have "placeholding code", like the old aero model (at that scale a problem in itself), you have to debug the code because what else is that bug masking? And how do you know it's actually in the feature planned for overhaul until you find it? Prioritize the bug fixing according to how serious it is. But you can't afford to ignore them. Nor forever give an excuse that resources weren't available for debugging. Yeah, the pace and tone of the commenting here has been...rather intense. Lots of good thoughts too. And a lot of people showing they really care about KSP. A lot of us are wondering what's truly driving the decision to make the next one 1.0. Good point about being lumped in with other early access games. But does Squad really want KSP to be lumped in with all of the badly-executed released games ?!? Because to a lot of us, with a lot of experience of game development including as developers, there's a large risk of that happening.

You started by saying this: So, you don't make an argument for or against whether the next version of KSP should be numbers 1.0 or not (the whole point of this thread and its poll). You attack modders saying they're only taking a stand against calling it 1.0 because they think they can pressure Squad to buy their mods. Broax said it best about your words: And all you can counter that with is more brickbats at mods, saying Squad's working on it, and talk about KSP being relatively bug-free. But Squad working on bugs hasn't fixed the decoupler bug for the last 4 versions. Nor prevented new bugs including memory leaks from cropping up with the current release.

Wow, that's the height of intelligent argument. Do you even follow mod threads? See how much work they have to put into developing and maintaining a mod, hooking into KSP where they should. Field players problems. Identify the errors and warnings in the logs they receive. And identify stock issues and bugs. And do this over and over again. You original post was an unfair attack against the modders who add polish to KSP for no benefit other than praise. Many players wouldn't be playing the game without the essential mods. Squad's game is many times better for them.

I don't think that's a far appraisal. The more serious modders have a better idea of the guts of KSP. And they are more familiar with the stock bugs as they need to rule them out when getting issues reported to them. And it's few modders that will get their mods incorporated, even with a rewrite. For example, the new aero model is all inhouse by Squad. Apparently they aren't talking to ferram4 at all.

Better Than Starting Manned has a single Life Support resource and it works quite well to put a limit on flight operations. darqen27, [i vehemently disagree]. This is about Squad pushing for version 1.0 too soon and not money or any other issue. KSP players have been raising serious concerns in this thread. A lot of them have experience (good, bad, and horrible) with games going from alpha into beta in release as players and as developers. They are concerned that Squad is making a serious mistake. They see a trend of bugs not being dealt with. Despite getting good additions with each version, we also see new bugs and general instability increasing. Now Squad is going to put out the largest collection of changes that has even been in any version. We like seeing improvements and fixes. But we also know with that much new code there will be a bumper crop of new bugs. Two whole new systems (realistic aero and extractable resource) are being added and will need more work to get right. That's not what you put in a v1.0 release. The next version should be 0.91 because it is still no more than beta.

The only thing they keep from the old aero is that there's drag, lift, and and angular torques acting on the craft. The code to calculate all those values will be almost completely different from whatever was in the old aero, especially the drag and somewhat the lift. The new code has to calculate drag as not some fraction of the mass of the craft but based on the size and shape of craft. Lift has to be revised for wings and now included for other large parts as well. The torques (pitching, yawing, rolling, including that of control surfaces) will have to be revised too. Values will have to be determined for individual parts as well as handling the effect of the whole craft, shape, stuff like area rule too. Almost nothing of what came before can be used. There will likely be revisions in the performance models of rockets and jets. Rockets and jets will fly differently. Delta-V values are going to change for bodies with atmospheres. I suspect this project was underway before 0.90 released. It is massive. And it is equivalent to putting in a whole new major system. Expect a lot of issues with it. Learning to fly with new aero alone will be significant and that's without any problems.

The new aero drag *and* lift model is not so much a change of an existing feature as the complete replacement of an existing feature. That's a lot of significant work that will touch on all parts as well as the overall vehicle, rocket or plane. Squad appears to be doing it right and covering sonic effects (thus the comment on the relative simplicity of adding re-entry effects which are sonic phenomena), but it's still removing the old aero model and creating a new one. To get the true scale of that work would need comment from ferram4 or someone who's worked with him a lot on FAR, but from my knowledge of real world aero, it's going to be a big, big project. That alone would be a significant alpha/beta release, but Squad says they're going to pack in more--and getting that stuff is good. More power to Squad if they pull it off with just the usual level of new bugs and degradation to the code that we've seen in the last few releases, but I think it's going to be a bear. Easily expect to see one or two point releases to deal with then in the month after release. Those would better to be numbered as 0.91.1 and 0.91.2 than 1.0.1 and 1.0.2.

Here's something to consider in judging whether the next release of KSP should be v1.0: how many mods players play with. And how few players play and would keep playing KSP stock without any mods. I'm well into the double digits of mods and there's more I'd add except they conflict with my current career play. Sure, some of them are really simple (like DefaultThrottle), but a lot of them are complex. And there are at least 10 or so I wouldn't play KSP without. The only games I've played that are as heavily modded as KSP are Europa Barbarorum, a total conversion of Rome Total War (for the original v1, now based off of Medieval II Total War for v2) that turns a poor unhistorical game in a fantastic accurate one, and Silent Hunter 5, a completely broken and abandoned game made into something first workable and then fantastic by a strong community of modders and players. As with KSP, I wouldn't play the base unmodded games. This level of modding indicates a game lacking in its subject representation or otherwise very limited. I personally think stock KSP is nowhere near the level of bad that unmodded Rome Total War and Silent Hunter 5 are. It's a great game--for something that's barely beta. Because the devs enabled and documented how to mod KSP, a lot of modders have given it the polish to make it fantastic. But the shear breadth and depth of serious mods that many players consider essential indicates stock KSP still needs a lot of work, more than can be put into one release.

That has nothing to do with how Squad releasing Kerbal Space Program v1.0 will be judged. It will be judged by people who know little of astronautics. They will run a completely stock game. They will depend on its tutorials. They will depend on it running very well. And they won't like how stock KSP looks. And they will encounter bugs. There will be the game reviewers, the YouTube video players, the Twitch streamers. Not just the ones we have now. Others. They will judge KSP as what they expect in a professional game released for $30. And if you follow any of them, right now the AAA game industry is doing a crap job at that. Those reviewers and players and streamers have a lot of experience looking at and playing games critically. And finding games wanting. And saying so in blunt terms. KSP isn't going to get kid-glove treatment here. It's going to be taken up by computer game test pilots who will see in a few days all the crap that's there right now. I'm not sure what possessed Squad to call the next release v1.0. Whatever they hope to gain from that, I think they will lose even more.

It's all good. My words were open to misunderstanding. Editted that first post of mine to hopefully make it more clear. As for jet engines, there's a lot of good stuff in the Advanced Jet Engines mod thread. It appears that stock jet engines are sort of (but not quite) like a rocket engine that only needs fuel and not oxidizer. Whatever their problem the performance of the basic jet is cringeworthy: use as a first stage engine?!? They don't get out of efficient speed before they are staged partly due to stock aero drag being so high, but I suspect they need more attention that just fixing the aero model. And all it took was "...the next update will be our 1.0 release...." Seriously, I hope they really reconsider changing that stance. It's in their own best interest. Nothing good that will last will come of trying to push out a v1.0 release next. If you haven't yet - be sure to read both links Doesn't matter how long they take to put out the next release. The changes in a release are never truly tested until it's pushed to a large number of players. Which for KSP means it has to release to be truly tested. I think they need 3 more real beta releases to do that. And calling it 1.0 is a major step and will change how KSP is judged. Making the next release 1.0 is wrong and will get KSP slaughtered by reviewers in the shape it will be in. Many others in this thread have brought up this issue. It isn't going to go away just because the next release took 6 months instead of 2.

The aero model is the fix that Squad will be judged on more than any other. Squad has to get it right. That they don't take the advice of ferram4 and others that have been dealing with this for a long time is very disturbing. And you have to have realistic re-entry heating and damage and destruction because that is a critical part of landing through atmospheres. High speed heating is another sonic speed effect and if they get that right they get re-entry heating too. Yes. New engine models as in a new aero model. Stock rocket engines have fuel flow that varies with atmospheric density, which is wrong. Rocket Isp varies with density. That is literally a one-line fix and is done in at least 3 current mods (Better Than Starting Manned, KIDS, Real Fuels). Jet engines will be more complex. See the Advanced Jet Engine mod for details, but basically the performance of stock jet engines are way way wrong. As Stargate525 has pointed out, everyone of my points except for #8 has been done in at least one mod, some of them several times over. And those mods are popular. And except for large numbers of parts they don't impact memory or processing that much. What would stop Squad implementing them into stock? Yeah, that decoupler bug looks like it's going for tenure. Yes, there are crazy numbers that need fixing. Try comparing prices between parts. Especially related parts like the adaptors.

KSP is so not ready for version 1.0. As many others have pointed out, reviewers will tear them apart if they do that. Besides the mass of bugs and technical limitations (no multicore, no functional Windows 64-bit client), there still are a lot of corrections and additions they need to do. Some of these are announced for the next release, but until they are out we have no guarantee they will be included in that next release. 1. New aero model with drag and lift, including sonic effects, including re-entry heating, and the parts needed for these improvements (fairings, interstages, heat shields) 2. New operation models for rocket engines (make rocket Isp vary with air density, not max fuel flow, done in 3 current mods (BTSM, KIDS, Real Fuels)) and jet engines (see Advanced Jet Engines for more info) 3. Numerical support in the editor and in flight (some large fraction of what KER, MechJeb, VOID, RCS Build Aid, Precise Node, and other mods provide) 4. Better spacecraft pod interiors (like what RPM and extensions to it provide) 5. Better flight visuals (like what EVE with Astronomor's Pack, HotRockets, and similar mods provide) 6. Improve UI, especially flight information and controls (like what Editor Extensions, Trajectories, Navball and docking mods, and similar provide) 7. Better coverage of both core and extra parts (like what Navigation Lights and other good parts mods provides) 8. Better memory usage (make OpenGL default if needed, get Windows 64-bit working) and other resource usages (multicore) 9. Better career progression and Kerbal tracking (like Better Than Starting Manned, Final Frontier, and similar mods provide) 10. Significant effort to fix bugs and other design issues, like fixing all the parts' numbers (like cost) that often make no sense, especially compared to one another That's a lot that needs to be added on top of what we have right now with KSP 0.90. I think a minimum of 3 beta releases (0.91, 0.92, and 0.93) have to come out to incorporate that many significant things. Then, when 0.93 is out and appears to have no major issues or other shortcomings, they can think of rolling out a tiny bug-fix release and call that 1.0. If they don't do this, Squad can expect to fail and suffer for it. EDIT: Adjusted the wording of #2

Header on the Github Release page section for 6.5.0 says "Deadly Reentry version 6.4.0".

Was MechJeb missing from a sandbox game too? You need to at least provide the appropriate log file. Read the first post on this thread which will tell you how to find it. - - - Updated - - - all of this being said, is the error 1. mechjeb 2. my persistent save 3. my copy of the game? 4. something other? Glad you got spoiler tags working, Higgs. As for Launch to Rendezvous, I did a bit of research. As well, I'm familiar with the orbital mechanics involved. While I can see generating a solution for an orbit inclined a small amount, I don't see how it can work for a large inclination, especially 90 degrees. I don't know how you had it working under 0.25, as it's not a function I've used so far. But you've found something that works. What I suggest to you is: 1. Launch into Plane but to a lower orbit than the target. 2. Use either the Rendezvous Autopilot or a few maneuvers from the Maneuver Planner to rendezvous (Adjust Close Approach and Match Orbit I think they're called). 3. Dock manually (which I like due to low RCS use) or use the Docking Autopilot. That gets your new spacecraft docked with the orbital station and allows you to get on with your game. - - - Updated - - - Very cool, sarbian! Looking forward to this as I suspect it will improve a lot of things.

Well, then, why don't you PM rbray89 with a polite request for him to include the updated .dll's in a new release if that's what you want.

Whoa! That's an understatement. Higgs, you should really editted down those long posts to focus on the important details. It's a rule of thumb that even after you've have a good copy, you can reduce a document by 30% or more by editting for brevity. Otherwise people will just at most skim and often just ignore the post. As well, you should use Hidden stuff! to reduce the length of the post on the page. Have to put them in by hand, like this (with the extra space after the "[" and before the "]" removed): [ spoiler="Visible text, have to have something in the quotes" ] Temporarily hidden text [ /spoiler ] Big thing to remember about KSP 0.90 is a *lot* of things were changed in stock. Many mods have yet to completely adapt to these changes. Some of those stock changes force the mod writers to completely change the mechanisms and even the manner in which to use their functions (like Vertical Snap in the Editor Extensions mod). Other changes are currently unmoddable except in trivial ways (e.g. the new Building Upgrades: a mod can change the cost of upgrading them and what level a building starts a new game at and so far nothing else). MechJeb had to change a lot, especially with the changes to the Tracking Station, and I'm sure those changes aren't finished yet. One thing I'll suggest is that you quote the Build # of the MechJeb you use, as from the Changes page (where you can follow the links on the left to get a download page for each build). The latest as of this post is #388. That MechJeb copy you have on FileDropper appears to be the 2.4.2.0 release build, which is #367 I believe.

In a bit more detail, the old vertical snap was a function in the old stock editor that wasn't mapped to a key or a UI feature. (Why, Squad?!? Why?!?) All EE did was add in the key mapping to toggle it on and off. I actually find the new vertical snap to be an improvement.