• Content Count

  • Joined

  • Last visited

Community Reputation

885 Excellent

1 Follower

About Kobymaru

  • Rank
    Sr. Spacecraft Engineer

Recent Profile Visitors

4,429 profile views
  1. The force calculation takes into account the temperature/density of the atmosphere, velocity, drag and lift on every part of the ship, every 2 seconds. The value for the drag depends on which other parts are attached, and the value for all of these depends on the position of the ship. The position of the ship depends on the values in the previous steps, and the values depends on the position in the previous steps, ... There is no single value you can paste.
  2. I think we might have made a mistake with the "backport" releases: we prepended the KSP version to the Trajectories version, and the CKAN robots might have gotten confused. I'll try to sort it out in the next release.
  3. Hi there! Hey there! I am using KSP 1.3.1 with RealismOverhaul, Realist Progression 0, RSS and a bunch of other mods with Principia 2018120707-Erdős-0-g3e2334a95bcfc6869b5464ecda5ae48b5412dba0 . Unfortunately, my Scene load times seem extremely long. Without principia, a scene change takes 10 - 15 seconds. With 2018081110-Desargues, every scene load took at least 1:30 minutes. With 2018120707-Erdős, this became even worse. Now every scene change takes 3 minutes!! During that time, the Memory usage drops quickly by 2-3 Gb and then slowly builds up these 2-3 Gb until the scene change completes. My savegame has about 36 vessels, and the save file has a size of 10 mb. Is this to be expected with principia? I know 1-3 minutes doesn't seem like much, but it seriously disrupts the gameplay. Is this a bug? Is there a workaround for this? (I have reported this on GitHub as issue #2038)
  4. 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?
  5. 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.
  6. 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?
  7. 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.
  8. 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!
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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?
  14. 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.