Kobymaru

Members
  • Content count

    1,096
  • Joined

  • Last visited

Community Reputation

881 Excellent

2 Followers

About Kobymaru

  • Rank
    Sr. Spacecraft Engineer

Recent Profile Visitors

4,181 profile views
  1. 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?
  2. 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.
  3. 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?
  4. Kobymaru

    Unity Analytics and the GDPR

    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.
  5. 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!
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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?
  11. 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.
  12. 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.
  13. How the hell would they have case against me? No, because I want to open up my code and ensure its survival.
  14. 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:
  15. 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: