Kobymaru

Hey there! I'm having some trouble using the KSPTOT porkchop transfer planner with RSS and Principia. I started out in 1972 (KSP year 22) and I wanted to go from Earth to Venus with as low dV as possible. Here's what I did: Installed the KSPTOTConnect plugin Started KSPTOT Edit -> Time System -> Use Earth Time Edit -> Gravitational Parameters -> Use RSS-like Create New Bodies File from KSP Load created bodies file Departure Body: Earth Arrival Body: Venus Earliest Departure time: Right-Click, Enter UT as Date/Time, year 22 Earliest Arrival Time: Right-Click, Enter UT as Date/Time, year 24 Compute Porkchop plot Get result: Y23 d221, which translates to August 3, 1973 This, however is way too late. I am pretty certain that there was a launch window in March 29, 1972: first of all, there was a real launch by the UDSSR, namely Venera 8. Second, I used @Arrowstar 's old TrajectoryOptimizationTool (v 2.1.1) for Orbiter to find the window, and that calculated optimal departure on March 30, 1972. I double-checked the bodies.ini file that was created, and the orbital parameters for Earth and Venus seem to match RL almost exactly (compared to this: https://nssdc.gsfc.nasa.gov/planetary/factsheet/venusfact.html). While writing this post, I figured out what could be the culprit: the inclination of all bodies seems to be very high, around 23°. I'm pretty sure that this is done in principia because rotating the whole solar system is the only way to implement earths axial tilt. Is there a way I can generate a proper bodies.ini file that works for porkchop plots?

Thanks, finally found the menu for editing a craft. I did that with two crafts, and the crafts came out at 23% and 73% changes! Which I don't quite understand because they had those changes even before I even touched them in the editor.

Hey there! I'm using KCT version1.3.9.0 on KSP 1.3.1 with Realism Overhaul 12.1.0, RSS 13.1.0 I have problems with recovery: I can successfully recover a craft that has landed on the runway, and I can launch the craft again just fine. However, it is turned 90° upwards (causing it stand on its tail). Also, the tanks are never refilled but are just as empty as they were when the craft was recovered. Is there any way to fix this? Am I using it wrong? How can I refuel my craft and launch them in the right orientation?

First of all, they gathered personally identifiable data without my consent. Mind you that a blanked "we gotz all ur data" in the EULA does not constitute consent. Consent to data collection under the GDPR requires that it's made explicit can't be bundled with other questions can't be used as a requirement to agree to the contract, unless the data collection is inherently part of it (which it's not). So Take Two is clearly in violation here. They also cannot forward your data to a third party, but they are. There is Take Two which is selling this game to me and collecting this data (without my consent) and they are sending this data to a third party, namely the RedShell servers (the servers used are here). More information on what is actually happening in this reddit post. Again, Take two is clearly in violation here. It's "nice" that SQUAD took out RedShell, but I'm afraid that's not good enough. The law has been violated, data has been collected, user rights infringed upon. The only thing that has to happen now is a formal and extensive GDPR complaint. I don't know if this effort is going on somewhere in the community, but will try to figure out how to do this complaint thing and file a formal complaint with my countries data protection agency. I encourage all EU citizens to do the same.

This argument has been made about 5 times, by each side. I think it's time to put this thread to rest, everything that there is to say has been said, SQUAD did the SQUAD thing and said nothing, as usual. See you guys in the next "pls implement dV readout" thread!

That's not an atmospheric prediction, that's the the time point of the intersection of the (vacuum) orbit with the ground. Hence me wondering where a predicted g-force readout comes from.

Since when does KER do a Trajectory prediction? can you make a quicksave File and Upload it to GitHub to an issue? preferrably one that can be loaded without mods.

The answer is: vacuum dV. It's perfectly correct in space and on/around most of the bodies, it's almost perfectly correct in the upper atmosphere (for second stages) and it's still a reasonably good estimate for first stages because even those don't spend much time in the lower atmosphere. And please, stop succumbing to the perfect solution fallacy, where the absence of a perfect solution for every single player somehow prevents a big improvement for the majority of players. Perfect is a bit better than imperfect, but imperfect is a lot better than nothing.

This is where we'll have to disagree. I think it's about as necessary as an Apoapsis marker. That's very nice, and there are plenty of useful suggestions on how to do it. There's actually even consensus in this thread itself: implement it with a toggle. The problem is, there's no comment from SQUAD ever, in this or any other thread about this topic. And I can guarantee that this topic will come up until the end of time or until SQUAD implements it into the game. Even if all people in this thread will collectively agree to never speak of this again, there's probably a guy buying the game right now who will ask the very same question in half a year.

I just want them to venture out of Kerbins SOI a little bit. I honestly don't think they do that. Maybe the QA testers do, but the devs and management doesn't. I think they used to care (nowdays not so much), but they didn't think it's a priority because "there's a mod for that". Unfortunately they also subscribed to the notion of "less information is better", and they believed that this is what players wanted. I wish, however, that they would realize how tedious the game is without it. I don't know what their opinions are today, but they have been very actively avoid any mention of this issue for a long time. This is the worst argument ever. The same thing could be said about literally any subsystem: contracts, aerodynamics, heating, and in fact, any project in life ever. Not doing something because of the possibility of not doing it perfectly is ridiculous, and being able to take criticism is just a life skill. You can whine about it, or you can improve your work based on that criticism. The aerodynamics are the perfect example: there was a mod for that, they implemented it anyway, "they still didn't get it right", but it's still in the game. And it's a lot better than nothing. Besides, what makes you think that they can't pull off a deterministic, analytical calculation with at least two working reference implementations (KER and MechJeb) so that it's useful for at least simple vehicles?

I did, in fact, stop playing the stock game and the making history expansion for this very reason. But I'm just gonna quote myself, because I've written this too many times on this thread already: A bit of a mixed message here This thread exists becaue I've been using KER for so long that I forgot what its like to not have a dV readout in the editor. When I was reminded of it (trying to play stock for a bit), I got so frustrated that I started questioning where the fun in the (stock) game really is. Mind you: I'm not saying there isn't. I just couldn't find it. Oh, I do get it. Back in the day it was deemed too hard to implement, now they're just out of capable developers. In short: they just don't care. ps.: I have one simple wish: Let all the devs, every single one of them, preferrably including the management do a Jool 5 mission (that includes a Tylo landing), completely stock, with no KER, no KAC, no Transer Window Planner. Lets see how much fun they have when playing their own game. I'm pretty sure the real reason that we keep having this discussion is that most of the Devs play time is limited to staying in/around Kerbin, or at most going to the Mun, if at all.

Fair enough, but could you enlighten me what they think about the following question: I'm just trying to understand how lack of a very selective piece information can be fun.

How the hell would they have case against me? No, because I want to open up my code and ensure its survival.

Is it? The common argument is that the dV information "spoils" the fun of ... something ... . So having the information available is not good because the user is supposed to magically eyeball the number through experimentation. OK, now let's take this premise and expand it a bit. So why do we have Apoapsis/Periapsis markers then? I mean, they are clearly redundant information, because could be calculated from orbital parameters such as velocity and altitude. They obviously detract from the fun of the aforementioned something, because the player can't experiment and is spoiled the suspense of how high/low their craft is gonna fly. For that matter, since less information is more fun, why don't we remove the velocity info altogether? It can clearly be calculated from triangulating various planets, here's a super easy tutorial on how to do it, and people who don't want to do this can either use this magical spreadsheet or install a mod. Also, why don't we remove the information on how much fuel is left in your craft? Same thing, calculatable from different numbers (integrated burn time, engine ISP, thrust, tank size and ambient pressure), super fun if it's not available, and you might as well install a mod for that. On top of it, it would even be realistic, because usually a spacecraft doesn't know its remaining fuel exactly. What is the difference between one number that can be calculated from other information in the Game and is extremely helpful for mission success and another number that can be calculated from other information in the Game and is extremely helpful for mission success? How is one number a spoiler, and how is the other number clearly obviously essential? My suspicion is that the only difference is the status quo, because one has been around since the beginning and the other one is boycotted by the devs. Edit: this must be the spoiled fun that people are talking about:

Wait, how does this work together with the "not suitable for a particular purpose" clause? I'm pretty sure that nobody can't sue GPL'd code authors for not getting what they expect, because the license clearly states to expect nothing. Yes it does. Either way, I'ma join sarbian and the others on this one and just continue business as usual, assuming this won't happen. Sorry if this is a bit off-topic now, but this meme needs to die, so I'm gonna put my off-topic rant into this box for anyone who cares:

But neither the Mod author nor the User have access to this code. Who is hurt by this "violation"? What's the damage? I find discussions about the ideal and perfect lawfulness of an act ("but technically, it's ... ") pretty boring, I care about real life. So my question in practice, in reality, in this universe (that's a physical, not a legal universe), what is the problem, really? Who is gonna sue who? Who has the damage, who got hurt? Is Squad/T2 gonna sue me for writing GPL code that interfaces with their non-gpl code? Am I gonna sue Squad/T2 for release of their source code cuz I wrote something that could be used to link against their code? Is Squad/T2 gonna sue their customers? Is the FSF gonna Sue all of us for the fun of it, and because they like creating legal problems in situations with no victims?= Why are we getting so upset about this, again?

It's 2018, GitHub exists. That counts as shipping the source code. If it's not on GitHub, the source is usually within the archive along with the binaries. Yes. All code that is licensed under the GPL. Which is the Mod's code, and not KSP's code.

How are any of these "violations" relevant? Who is perpetrating the violations? Does the author violate the GPL by writing GPL code? Does Squad/T2 violate the GPL because users are taking their KSP copy and "linking" it against a GPL mod,without Squad/T2's consent or knowledge? Do Users violate the GPL by linking it to their KSP copy in the privacy of their homes? I don't think so. Distribution is key here. GPL only matters when you distribute. If you "violate" it internally in your company or at home and don't distribute your nonfree programs/modules, nobody cares. Modders distribute their GPL modules, but they ship the code along with it. No violation there. Squad doesn't distribute the Mods, no violation there. Users don't distribute the Mods, no violation there. I really don't think this is a problem.

I'm not saying you are throwing parts together randomly. I'm just saying you could perfectly well do it and get away with it, because the stock game is just that easy with the tiny planets and OP engines. The dV number isn't the answer. The Boolean "Seeing if it works" isn't the answer, or the reason I play the game. The spacecraft is the answer, the staging, the engine choice, everything. dV is no more than a tool to be precise about it. I still put in a lot of work into the design of the vehicle. The difference is that I do less (not none) trial-end-error and more reading numbers that are perfectly obvious and shouldn't be a secret. This idea that withholding information is fun really boggles me. It might work in a novel, but not a game about engineering.

How do you "guesstimate" a huge multi-stage launcher with several probes, transfer stages, side boosters and all engines with wildly varying burn times, ISP and TWR? Thanks, I'll check it out. Interesting method, thanks. Really great summary of what bugs me about this whole thing! Full Agreement. So I can get back from Eve or Tylo when I just add 1-2 fuel tanks to my Mun lander? Who knew it was so easy. OK thanks, but that does look like homework again. I did this kind of stuff 5 years ago, not long after I started playing. It got annoying really fast and I'm not interested in this anymore. Either way, I feel like we're missing the point a bit. It's not that I am incapable/unwilling of installing mods, it's just that I'm wondering how the Devs imagined we would play a completely stock game. Is doing math homework in Excel part of how KSP is "meant to be" played? Well exactly. So they wouldn't even give us the answers to the challanges, they would just give us meaningful and helpful questions on how to correctly do our missions. I did use KER (in 1.3 and before) and I probably will again in 1.4. I don't have a problem with KER, it's amazing. But that's not really the point of the discussion, I was just wondering how the devs envisioned the stock game experience, without any mods. Because for me, the big appeal of the game is the engineering challenge. I like to build stuff, and I like to build it to specifications (mission requirements), and I don't really like to add "moar boosters" to things that don't need them. Also, lets not forget just how small the sizes and dV requirements really are, compared to real life. You can throw together pretty much anything and it will fly and do the mission if you have the piloting skills. To me, randomly throwing together parts and having them work out most of the time is kind of cheating. Another thing is that the "explody-loving Kerbal" trial and error thing might be fun when all you do is build ridiculous contraptions in KEO. But once you start building more and more complex missions with launchers, transfer stages, multiple landers, probes, ... that go to places like Jool moons, then it's a different story. "Whoops, my launcher blew up at Kerbin after 15s of flight" is a lot funnier than "Whoops, my lander can't get off of Tylo after 6 in-game years and dozens of hours of RL playtime". I gotta say, this kind of OMG SO RANDOM HAHA IT EXPLODED play style is just really not my thing. It would get tedious really really fast, and if it weren't for Mods like KER or MechJeb, I would have stopped playing years ago.

Hey there! So I bought the DLC and apart from all of the other bugs and issues mentioned in many other threads, I have come to notice something: I'm not actually having any fun playing the Stock missions, and generally the stock game. I would dare to call myself a KSP veteran, having started out a few years back. Building rockets that can go to the place you want to go is quite a hit and miss, until you discover the concept of Delta-V and TWR. After my discovery, I started calculating them with pen, paper and a calculator. Then I switched to Excel, but that still got tedious real fast. Luckily I discovered MechJeb (and later KER) that calculated the TWR and the stages for me. I got used to them, and building rockets became second nature to me. When Making History was released, I thought to myself: "OK, let's play these missions as they were intended: with just the Stock game, no mods". I finally got to the third part of the mission (building Jebnik 1), and I come to realize: Wait, how the hell am I supposed to know if this is going to space or not??? I don't have a dV readout, I can't even do trial and error, because there is no Revert to VAB after I've launched the thing. My options are: Build the most "Kerbal Rocket" and create a giant behemoth that by my *guess* will probably make it to space Do trial and error by cheating Get it right by copying an existing design from the forum Go back to my days of calculator usage, calculate the dV of 3 stages by hand None of these is fun for me. Option 1) just isn't my style, and it's not even a guarantee that it will work. Option 2) feels cheaty, and also doesn't work very well. 3) is plain lame, and I'm just too old to do 4), I have moved past this years ago, and it's way too much work for a game meant for recreation. So what now? I'm usually a critic of statements like "this mod should be stock", but I'm coming to realize that the game really, really needs a Delta-V and TWR readout. What are your thoughts about this? How do you deal with building rockets without KER/MechJeb? ps.: inb4 "Just install KER/MechJeb": I know I can do that, and probably will. But in this thread I want to talk about the *Stock* experience that the game provides and that the developers intended.

No, I want the new one.

Surface mode. No, never.

I have noticed this is well before. This is actually a problem with KSP numerics, and is either part of the "Orbital Drift Compensation" fix that can be turned on/off in the Menu, or part of the Problem that it was supposed to fix.

Oh that's weird! One of these days I'll have to actually understand these weird coordinate systems in KSP. Please do, I also suggest opening a GitHub issue and continuing the discussion there.