Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by jrbudda

  1. On the topic of suicide burns: When I started maintaining KER the suicide burn did indeed only account for vertical velocity. I spent quite a bit of time in 2018 re-doing the impact/suicide calculations and adding the impact marker readout. It is a lot smarter than the previous 'vertical only' calculation, now a simulation instead of a simple equation, but it is by no means perfect. It will not account for air drag, nor weight loss during the burn. It uses approximations to estimate the angle of the craft at each step of the simulation, but as with most approximations, stray too far from the typical values and they break down. I tested it to my satisfaction using reasonably parabolic impacts and burns less than a minute or so. I did not test the calculation under on-rails warp, I would not suggest relying on the readout when that far away from the planet, nor when your horizontal velocity is on a higher order of magnitude than the vertical.
  2. I pushed to github and curseforge, see if that fixes it, thanks.
  3. Oh great. I merged a pull request from someone who made changes to propellant calculations. He seemed to know what he was talking about, but maybe that is the source of the problem. Can one of you give me easy instructions to make a craft that shows the problem? and what the calculations should be in vs how they were in
  4. Rebuild KER now against 1.10. Also taking some time to go through recent suggestions and bug reports so it might be til tomorrow or so until I post the update. Existing KER should work in 1.10 anyway.
  5. After some investigation I have determined the following about the new Drain part: It uses a totally new internal module type Active draining resources provide thrust The ISP of thrust is defined in RESOURCE_DRAIN_DEFINITION in the resource's cfg file. The ISP of most vanilla resources is 5 Any unknown resource (i.e. a resource that does not have a definition) is drainable by default with an ISP of 50. The stock dV calculation does not integrate draining in any way. The stock dV calculation does not even update if you drain all your fuel on the pad before launching. In theory an active drain is providing thrust to the vessel and should be considered as a 'engine' in the flight simulation, but honestly I don't see a point. Given that specifically integrating modeuleResourceDrain into the flight simulator will break backwards compatibility for KER. I'm inclined to do nothing with it. Happy to hear any opinions on the matter.
  6. The existing version ( seems to work fine with KSP 1.9 The new drain part looks like it will require an update that breaks backwards compatibility, so I will look into that and a few of the pending pull requests this weekend.
  7. Ya this is what the majority of my time updating was spent on: fixing the XML serialization issues.
  8. Update for 1.8 is now on github. Please let me know of additional issues.
  9. Will update to 1.8 tomorrow, lemme know if there's any issues you find.
  10. Id appreciate if you could file a github issue to better track this issue.
  11. KSP 1.7.0 is out. There are no conflicts with the existing KER. You can safely ignore any version warning. The new version will be out shortly and on CKAN whenever CKAN updates.
  12. Yup Just tested it. If you actually launch the monoprop ship there's nothing stopping you from just sitting there and burning all the monoprop with the first stage. It does prioritize the fuel tank in the same stage first, but you'd have to manually monitor the level and stage at the right moment for the stock dV values to be correct. KER and vanilla may differ, but both are right depending on your stage timing.
  13. I'm preeeeettty sure monoprop doesn't obey crossfeed rules on parts
  14. I finally got some time to look into this. What it comes down to is bad wording on my part. In the code, and the description, I called those 3 readouts time-til/separation at/rel speed at 'closest approach', but decided to label them time/sep/speed at 'Encounter'. This was misleading. The readouts expose the data available when you hover over the approach markers. When you have a SOI transition, there are no approach markers (on the first orbit patch anyway) so no data. I'm renaming those 3 readouts to 'At Approach' instead of 'Encounter' to better clarify. Providing data about the next 'Encounter' (meaning SOI transition) would have to be a different readout. In the future I will look into extending the 'closest approach' readouts to look into the next orbit patch and pull the periapse and report that, but for now it'll remain N/A if there's a SOI transition.
  15. Deleting the CKAN directory and restarting it seems to have fixed it.
  16. Does KER not show up under 'Compatible' in CKAN for anyone else? The .version file is correct, not sure why it shows under 'incompatible' with 1.6.xxx for me
  17. 1.6 is out, but so am I for the next week. Any updates from me will have to wait til after christmas. I verified that the existing release of KER loads fine, with the expected version warning. The dV readings in the VAB match, which is nice to see. Please post any oddities or discrepancies you find with 1.6 and I will take a look at them next week. Cheers and Happy Holidays
  18. There are no plans to remove anything from KER. Even from a technical standpoint the dV calculations are part of the KER Vessel Simulator which calculates much much more than just dV. Mass, thrust, RCS dV, all that good stuff comes out of the simulator. If at some point in the future the stock calculations (which I am very curious to get a look at) cover 100% of KER calculations then I will remove the simulator for performance purposes and populate the readouts with stock values.
  • Create New...