HebaruSan

Members
  • Content count

    1338
  • Joined

  • Last visited

Community Reputation

1787 Excellent

4 Followers

About HebaruSan

Profile Information

  • Interests http://kerbalx.com/HebaruSan
    http://steamcommunity.com/profiles/76561197970804764/screenshots/
  1. I think my mock-up above demonstrates this to be false. Such a marker in the map view would only appear when the user was knowingly and actively using the transfer feature. New players would not even see it. That probably sounds familiar to many of us: "I can't figure out what a good UI for this would look like, so I'll pass the buck to the end user by making it configurable/moddable, and they can design their own UI." I've been there, but this urge is best resisted; most users are not good UI designers, so your product ends up with a poor user experience (or none at all, for those users who can't or don't want to get into mods).
  2. Yeah, kind of; just a visual marker consistent with other stock map elements. Here's an attempt to flesh it out a bit more:
  3. Just curious, why do you want to go slow? I'm not going to comment one way or another on whether it's realistic, but what gameplay activities are there involving flying planes below 300 m/s?
  4. I think they're close, though; the stock map view needs about one more layer of abstraction. If there was an obvious way to "switch to" a planet to plan maneuvers from it, transfer windows would become much more apparent (by analogy with the timing of burns to Mun), and from there you just need a way to display the corresponding V∞ vector at the SOI edge so the player can attempt to match an in-SOI maneuver to it. I.e., it should convey "you should be moving this fast in this direction at this time to execute your 'outer' maneuver," and then let the player see how far off they currently are in all those dimensions. (*crosses fingers for the birth of "Basic_Transfers"*)
  5. Note that further movement of the node may be needed if you click +orbit more than a few times, because Kerbin keeps moving around the Sun during those orbits, which changes the ejection angle of the node. As an extreme example, if you wait half a year, the "same" node will send you towards Eve instead of Duna.
  6. He already explained that he doesn't maintain the metadata for that mod. Your best bet is probably @politas, based on the commit history of the NetKAN entry: https://github.com/KSP-CKAN/NetKAN/commits/master/NetKAN/ResearchBodies.netkan
  7. I doubt more planets would drive new sales. How many people are there who have not bought the game because Urlum isn't stock yet? When most new players struggle just to get to orbit?
  8. Try adding a DialogGUIFlexibleSpace to the end. Try setting textInput.guiStyle.alignment = TextAnchor.MiddleRight (That might affect more things than you want; you really want to assign the whole guiStyle object.)
  9. First two seasons of TNG. Before they got too formulaic (meeting someone's long lost relative every other episode), before Roddenberry died, when they were still figuring out what the show was going to be, the theme of contact with strange new cultures was still strong, Riker was clean-shaven, the uniforms were the original collarless spandex, and male extras wore skirts.
  10. I'd agree with your guess, probably most of the code hasn't been looked over very much, and the review that has been done is probably heavily weighted towards the big names. I believe the moderators of the modding forum enforce that rule plus a few others. It's fairly common for them to delete a download link because a license isn't specified yet, for example.
  11. Allegedly, forum moderators have been known to download mod packs, unzip them, determine which mods they contain, and then check each mod's forum thread to verify that the licenses were followed: Now, that thread was specifically about what a big burden this was for moderators, so this may no longer be their practice, and it doesn't apply to code copied from one DLL to another piecemeal, but there has been at least some level of scrutiny applied.
  12. For terms that depend on a vessel, I'd recommend designing a simple reference craft. Say, a command pod, some fuel tanks, and a Reliant. Most real craft will be similar enough, and for those that are significantly different, they'd be expected to perform weirdly anyway. I wrote a DeltaVToOrbit function, but it's just a "dirty" approximation, so I wasn't going to mention it in case you found something better. I calculated the simple delta V to orbit for a sample of bodies (Hohmann transfer from surface plus an adjustment for rotation), then compared to the official values from the subway maps to determine some ad hoc linear coefficients for gravity loss and drag loss: https://docs.google.com/spreadsheets/d/1gm2iuQLDDpEAMtfSTAQ-6GEtKC8P8c55Nghg3-WqjmY/edit?usp=sharing https://github.com/HebaruSan/Astrogator/blob/master/src/PhysicsTools.cs#L68-L93 As you can see from the "Err%" column, it results in errors of up to 30%, with Kerbin tuned to be close to 0%. But I have my fingers crossed with respect to your investigation into drag coefficients.
  13. That thread is from 4 years ago, when the old "souposphere" was still in use. Take anything it says about the atmosphere with a large grain of salt. Looks like Wikipedia has a formula for that, as they do for many things: https://en.wikipedia.org/wiki/Terminal_velocity
  14. GM is body.gravParameter.