MechaLynx

The game's simulation of physics cannot be both consistent and improving at the same time. with so many deviations from realism (by necessity, both technical and practical) there is a lot of room for improvements to the physics engine, allowing for a lot more interesting engineering to happen, which is why most of us play this game instead of a game realistically simulating real spacecraft. Like any simple simulation, it stops being believable when you reach its limits and all players that explore deeper will find those limits. With such a simple implementation, necessary to keep it real-time and playable, small changes will result in large effects on craft and physics, it's inevitable. In the end, everyone has to bite the bullet and accept that the game will never be "realistic enough" to satisfy every case or even most, and it neither will stop changing since most any improvement to the core physics will alter how craft behave. Personally, I feel a good balance is getting as good a physical simulation as possible without requiring much more cpu/gpu/memory/hdd than the average modern game while keeping the initial difficulty curve accessible (endgame can be as hard as you want really). If you believe that the core physics should never be changed and that it's a bad thing, ask yourself this: would you now revert to .23.5 physics, given the option? do you believe that would improve the game for the average player or even hardcore players? The whole argument that these changes indirectly force players to customize their physics settings, thus making sharing craft a labyrinth, is pointless. The solution is trivial - each posted craft comes with the relevant .cfg files, in a nice zip archive. Even simpler would be to include just the .craft file with a diff of the default .cfg and the player's .cfg, to make it easier for humans to parse. In competitions and challenges, there should be surrogates that test the .craft/.cfg combination for validity - this isn't as difficult as it may seem, since most players experienced enough will know what to look for. In the end, it's not like this is some kind of ksp progaming scene where we need a high-accuracy anti-cheat. It's sharing for the fun of it or at most for challenges - the most spectacular accomplishments will be scrutinized the most and remember: people can already cheat a lot as it is. Players can already cheat in challenges in a way that is nearly impossible to determine. Since KSP has no anti-cheat, there is nothing preventing a player from making small invasive adjustments, just enough to get an edge and then claim it's just that other players don't know how to fly the craft well enough or something. They can use a hacked client, custom mod (super easy), memory editing, video and image editing, glitches, the debug menu and any combination of these to get the desired result. Nothing personal, but you are very wrong on this. It's only easy if they're doing it wrong. I can guarantee you that if someone has enough of an interest in the game to be on these forums, chances are they know about delta-v maps, delta-v calculations, mechjeb and ker, common community wisdom etc. - all they need to do is build a craft with the required delta-v for a trip or challenge, hyperedit themselves into position and change their fuel with enough random variance to be believable, take snapshots of each position at the expected delta-v and add some random trivia ("I lost my right fin during re-entry") to make it even more believable. Unless someone is cheating blatantly, it won't be obvious even to the experienced player unless someone scrutinizes it closely. In essence, most players can leverage community knowledge, mods and tools to cheat in near or entirely undetectable ways. And this has been true since at least .22. You're proposing an anti-cheat. Unless we have one that operates at the level of VAC, nothing will suffice. Even then, players would be able to win challenges and would get banned days, weeks or months later. Custom cheats would never get detected. The problem of detecting cheating in KSP is the same as detecting whether a player deliberately disconnects from a competitive game to prevent a loss or their computer just fails - there is no way to do it with enough certainty without violating laws and rights much more important than the certainty of legitimate play. Thus, you are only left with 2 options: treat any suspicious action as penalty-worthy (this is how disconnects are treated) or use third-party validation (or just assume no one is cheating unless it's blatant). The latter is the solution here I think: each challenge entry must be evaluated by surrogate, non-competing players using challenge-compliant installations of the game. When sharing craft just to share, include both the .craft file and a diff of the player's .cfg files and the default, easy peasy. If lazy, just include the entire .cfg. The only extra improvement I can think of is adding replay functionality to KSP - essentially, demo recording, either through a mod or the vanilla game itself. This way, the player in a challenge includes their .craft and the recorded mission and a trusted third-party runs it on their own installation to see if it checks out. KSP's engine AFAIK is deterministic and even if it wasn't, it would be easy to resolve by just including the seed for the RNG in the demo file. Problem solved. It can even record when the player accelerates time and adjust the simulation accuracy to match, thus allowing variable time acceleration for the viewer of the replay without affecting the accuracy of the replay itself. This. Is saying "Stock, 1.02, normal" so complicated, with the simple assumption that no physics have been messed with and asking for or posting changes (a diff?) of physics changes if pertinent? The "consistent physics framework" argument is essentially a "backwards compatibility" argument, since it would never be an issue if we had this model from the start. And we know that, in practice, those that ditch backwards compatibility early win, those that don't are stuck with being dependent on it forever *cough* windows *cough*. In the end, it's extremely easy to fix when it comes to crafts and when it isn't, consider whether it's worth holding the game back so that some old crafts work. You have a knack for exaggeration. Remember you're not talking to 8-year-olds here, you're talking to adults who actually play the same game, don't be a smartass. What do you mean "barely anywhere"? I just tried it with a mk1 spaceplane, 1 trj and 450 units of liquid fuel and at an altitude of about 16.5km you can get your fuel consumption to around .15-.10 - that lets you do about 60%-95% of kerbin's circumference at ~800m/s. How much more do you need? Here is the craft: http://steamcommunity.com/sharedfiles/filedetails/?id=438074530 Mind you, this is just 2 minutes of building - I haven't optimized anything. Pretty sure that with some gliding and finetuning for TWR and speed you can exceed a circumference of land distance traveled. Most every spaceplane I've tried post 1.0 has either had too much speed or failed due to aerodynamic instability. I usually don't even get to spend all my fuel going up, especially with the trjs - my problems are usually that I'm not good enough to add some rocket engines and rapiers are too middle-ground to be really good at anything.

I don't know, but I've got a slight suspicion that this is actually the case. I made a craft for a Mun flyby in career and practiced with it several times in sandbox (as I do with all career craft) and it flew just fine. I was quite confident I could control it most any time during ascent, but when I tried it in career it flipped over in 3 consecutive launches (the first one killing Valentina ) until I upgraded the fins. By that point I'd made it consistently to orbit over several attempts. I'm still not sure it wasn't just me messing up though, the margin of error on that one was quite small.

Thanks for this Claw, it really helps understand some unclear behavior I've been getting (although, I must say the new aero force overlay is such a lifesaver and mythbuster!). I have one question in my head: How do struts affect anything, if they do anything at all? I know that due to the simplified model in which crafts are stored, there is a limit on how many node connections each part can have (most parts have only 2 node connectors IIRC, with very few exceeding that). But how do struts interact with the drag and aero calculations? Or do they simply affect the orientation of cubes and alignment during calculations, while being treated as if there was otherwise no connection at all (which is what I assume happens)?

Yeah but that doesn't mean a kid will be turned off by that - I'm pretty sure I'd have stuck with it if I was 8 years old. Probably in the minority here. And if I was 8 years old and gave KSP up, I would have done so even without the new aero, heat and isp scaling. What made you think KSP was viable for an 8-year-old to play before? As if there weren't enough complications with ÃŽâ€v calculations, centers of mass and lift, launch windows and lead angles, the oberth effect, staging, science. Pretty much everything, even back in 0.18.3 would still be overwhelming for an pre-teen child to take on by themselves. This hasn't changed, unless you feel that you're not comfortable enough with the new features that you can explain them to a child. But that's not an issue with the game - explaining even the basics in order for someone to play KSP at any level besides just pressing WASD when you tell them to, is going to require quite some teaching skill and imagination no matter how you cut it. tl;dr if you thought it was viable before, it's just as viable now - the only thing that changed is how comfortable you are with the game. Give it 20-30 hrs of gameplay and then consider it again and I bet you'll find it just as viable as before.

Game or sim? Word of the law or spirit of the law? Let's see: 1. "The Vehicle Assembly Building and the Space Plane Hangar allows players to build spacecraft out of any imaginable combination of parts." Not really since there are quite a few combinations of parts imaginable that will never work in game. I'm sure most any experienced player can think of a few so this is, going by the interpretation of those complaining, false advertising. 2. "Fully-fledged, Physics-based Flight Simulation ensures everything will fly (and crash) as it should." Wasn't true in the beginning, isn't true now, won't ever be true - if you take it 100% literally. One could easily point to this line and argue it isn't true even if KSP was the most accurate simulator in the history of man-kind, since even then, it would not be a perfect model of reality since such a thing is impossible. So is KSP realistic enough or not? Up to interpretation to be sure, but I would argue this: what kept all the people complaining it isn't good enough of a simulation playing all this time? Hope? False hope? Expectations for something they were never promised? 3. "Take your Kerbal crew on expeditions out of the ship with Extra Vehicular Activities gathering data and precious minerals." Kerbals can't gather rocks on EVA can they? Or does getting a surface sample count? Another line that anyone could argue is true or untrue to their heart's content. Argue that they shouldn't be advertising it this way and someone is certain to come along and point out a bunch of good marketing reasons. Propose a better way to state what you can do and someone else will come along to give you another bunch of evidence demonstrating how difficult it is to do this kind of promotion, how expectations operate in marketing yada yada, etc. etc. When you take things literally like this, all that's left is circular logic and infinite strings of nonsense. 4. "Procedural Terrain delivers detailed terrain at a vast scale. The Kerbal Planet is 600km in radius." Not very detailed. Vastness means nothing these days - the Minecraft engine delivers more detail per square unit of surface if one wanted to compare. I could go on from here, but I think it's pretty clear that if we were to take any of this literally enough, then we can go on complaining ad infinitum that we're not getting our money's worth (the most disgusting of arguments ever conceived). If you want an accurate simulator, KSP, or any game, will never be enough. Ever. I don't think people realize that accurate simulation software tends to operate very very far from real-time and still has massive inaccuracies when the algorithm used is applied to situations it isn't accurate for. Take a look at various orbital simulations and what algorithms they use and what criticism they come with. Materials, statics, thermodynamics, chemistry etc. we could go on forever and slap in the most insane simulation libraries to get an incredibly accurate game but it would require a few supercomputers to run at 30fps and people would still come up with reasons why it's unsatisfactory and you know it. In the end, when you buy KSP, are you really, really under the impression you're buying a simulator? It's on Steam and has little green men for crying out loud. Also, these complaints make so little sense when the same players have accepted a solar system as small as the game's but with a lot of real values turning everything extremely dense, when we are still working with SOI-based gravity (not even N-body, which is quite basic in orbital simulators), when there are no robotic parts, no sloshing of fuel, we get science from being landed on the launch pad, no life support systems, no telescope science, no comms delay, no preprogrammed probes and very little automation etc. etc. I saw someone argue on another thread that they have to learn a new physics system every few weeks, which is a ridiculous statement, but it shows very well what the kind of mentality that goes with these complaints is. In all, the game is the same it always was but better - if you ever had a reason to play it, now you have more. If it was unsatisfactory before, due to physics inaccuracy, it will always be. There's a difference between constructive criticism and suggestions, versus this mindless whining about "Squad should never have released an unfinished game" and "I was promised a simulator". Can anyone, truly and honestly raise their hand and claim they feel cheated out of their money for KSP as of 1.02? Can anyone claim the game is getting progressively worse?

I managed to get there before any building upgrades using this: http://steamcommunity.com/sharedfiles/filedetails/?id=437063352 That's using the 5pt nodes and the 20pt node (iirc). It doesn't have a lot of room for failure and I still haven't figured out the proper angles and thrusts going up, but it did get me there, circularized and had enough to get back. If only I hadn't forgotten to do the science lol xD Ironically, the weight and part count wasn't the limiting factor with this design - it was height, which prevented me from adding a decoupler between the science jr and the liquid stage, which was an issue with landing since the fuel tanks crash into the science jr and without radial chutes there's nothing to prevent it (although I did do a few test runs where I managed to preserve it).

It works perfectly fine on Firefox which is all I use (except when testing). Also, nothing personal but, working on Firefox does matter (but since it works anyway, it's a moot point).

Oh man I was actually quite worried that would happen with my ginormous tables sorry about that, I just don't have a better solution given the amount of information I consider necessary to make the tables work. I just tested the page on my tablet (7 inch, 1280x600) and it looks ok in landscape, even the tables are readable (lol) - in portrait it sucks monkey**** however. My first attempt to navigate to the offline section landed me at the deprecated table lol xD

It isn't listed under deprecated lol, check the table. edit - if you go by the table of contents it looks like everything is under deprecated, but the link points to the subsection of deprecated tools, which is a collapsed table, not the main table. this is because offline tools haven't been split into categories unlike the online ones. This is a side-effect of having less offline tools, so when I made the first entries I didn't add categories there so that we wouldn't have a section split into 3-4 tables with 1-2 entries each - categories are only needed for clarity anyway. I did think of splitting the offline tools into subsections eventually, but I didn't get around to it then and the only reason to do it really would be so that it doesn't look from the toc like there's only deprecated offline tools - but as it is clearly unlikely someone will just jump to that conclusion without even taking a look and casual inspection proves otherwise (not to mention that it would take some planning to decide how to split them up - it isn't as clear as with the online tools), so I left it as it was. I would be surprised if someone only clicked on "Deprecated" instead of "Offline Tools" if offline tools is what they're looking for. I'd advise against creating subsections for the offline tools as there aren't that many, but if you want to do the work go ahead. I really don't think it's a problem however.

Great work dude and thanks for updating the wiki page as well

I've updated the KSP TOT entry, however, it's a wiki so, if you want the information on your tool to be up to date, you can simply do it yourself instead of waiting for me I don't mind doing it so much, but I made it on the wiki, rather than the forum (like the community addon list) because this way noone has to depend on anyone else to have their information up to date (and definitely not depend on me - i'm quite fickle with games, I spend a bunch of time on one, then abandon it for months or years ) I'll eventually do another forum sweep to update releases and all that, but it'll have to be in the future rather than now since I don't have enough time. When I finalized it I had done a full forum sweep (details in the talk page) so information on the wiki page (excluding KSP TOT as of now) was updated last on that day (17 Apr), so obviously anything that has changed since isn't included (nor are new tools after that date). If I do another forum sweep I'll add the date in the talk page or somewhere on the page itself to indicate when the latest forum sweep was done. In fact I've just added a section on the talk page for just this reason, so if anyone does such a sweep, please update that section as well (it'll be obvious how). By the way, these external tools and calculators, unlike addons, don't really get the attention they deserve I feel (which is part of why I made the page) and judging from the little attention this part of the forum gets, including this thread, I fear that by the time people are aware that such a "registry" of sorts exists, it will have already fallen into disrepair and will be so out of date it will be useless. A wiki without people using it and editing it is a dead wiki and it's also a shame that people now have to dig through the forums or search google to find all this stuff. Thus, I'd ask players that use these tools and authors that develop them, to spread the word a bit wider so that at least people know that it's there. In the interest ofcourse of not replacing this forum section, I've added a link at the top of the page that points to this Tools subsection of the forum, to maintain it as the bleeding edge source of tools and updates.

I've made a page on the wiki that lists all the calculation tools for KSP that I could find (might be missing some recent submissions - (authors, feel free to add them or edit the entries for your tools if there's wrong information - i mean, it's a ****ing wiki lol ). It's also linked on the main wiki page. There's editing guidelines on the talk page for anyone interesting in editing the page. As a general rule of thumb, include only tools that help perform calculations (that can include calculations on what parts to use and fairing calculators etc.) but not utilities for savegame editing, .craft editors and stuff like that, as they aren't really "calculation" tools (although you might notice I probably haven't followed my own rules completely - it's a wiki anyway, it'll come down to community consensus eventually). I hope it's actually useful (has been useful to me so far, especially the science calculators ) and have fun

The new capability to adjust maneuver nodes with the mouse wheel is excellent, but it can be confusing (to me and perhaps other players) that the trimming is independent of what vector you're mousing over at the time (edit - yeah I got it backwards, but I think my point still stands). In other words, if you scroll the mouse wheel up, it doesn't matter if you're pointing at the prograde or retrograde vector, the trimming is done in the same direction. This isn't "wrong" but I'd prefer if there is an option in the settings that allows players to choose whether they want the scrolling to be independent of the vector the mouse is over or invert the scrolling trim depending on the vector. Also, double-clicking periapsis and apoapsis nodes currently makes them stick, which is a huge leg-up and a great feature. I feel it should be possible however to do so for intersection (encounter with celestial objects as well as non-celestial targets) and ascending/descending nodes as well, especially considering the new trim feature for maneuvers.

Your tool's pretty good but it has a bug where, if you repeatedly parse your own files it halves the percentages each time otherwise nice work. A suggestion would be to indicate to the user whether their files have been successfully parsed (I get a bit paranoid sometimes, especially when there's defaults/demos and I don't know what a bad parse looks like). Also TOO MUCH SCIENCE IN THIS GAME xD