• Content count

  • Joined

  • Last visited

Everything posted by HebaruSan

  1. Same. My autocompleted CelestialBody bookmark is updated to remove theName.
  2. No, not at all. Not even close, and I really wish you would stop projecting this attitude onto every single person who criticizes any aspect of this game or its development. I don't care at all about things like "derelict" or "blameworthy." I don't think I'm entitled to anything, and I don't think SQUAD owes me anything. I fully acknowledge that SQUAD responded to development pressures and market signals rationally (and in fact my question assumes it!). Please, please try to respond to the words people actually use rather than concocting nonsense like the above. I am looking at my Steam software library and contemplating whether there are any actions I can take (along with my fellow consumers, possibly with some sort of explicit coordination) to end up with fewer products with "glaring holes" in them (and ideally more products without them, rather than just fewer products overall). That's it, that's all. So I'll skip to the part of your post where you finally address that question. Thanks for the response. I suspected as much, but I figured it wouldn't hurt to ask.
  3. Astrogator A space-navigational aide for Kerbal Space Program. See all the transfers that you could choose from your current location at a glance, including the time till the burn and delta V, and turn them into maneuvers with one click. Automatic maneuver node creation When you're piloting a vessel, maneuver node icons will appear next to the delta V numbers. Click to create maneuver nodes for that transfer: These typically give immediate encounters for transfers to the Mun from low Kerbin orbit, and sometimes Minmus, Duna, and Jool, but some adjustment is usually needed for other destinations. Time warping Click a warp icon to warp to 5 minutes before the corresponding transfer. If it's already within 5 minutes, you'll be auto-warped to the exact time of the transfer. More transfers, fewer clicks Shows transfers for all main reachable spheres of influence, including from parent spheres of influence, not just bodies with the same parent Supports transfers to vessel's target, regardless of what it is Handles "nested" ejection burns, such as when you need to burn at the right time to escape Laythe at the right time to escape Jool at the right time to reach Kerbin Supports burns to bodies within the current sphere of influence, such as the moons of Kerbin from low Kerbin orbit Uses the active vessel's location and orbital parameters to fill in as many of the input parameters as it can Shows you the results in zero clicks Integrates with the game to streamline use of the data Moves the map view focus automatically Sets the vessel's target Automatically opens maneuver nodes for editing Download: https://github.com/HebaruSan/Astrogator/releases Where to report bugs: https://github.com/HebaruSan/Astrogator/issues Source and documentation: https://github.com/HebaruSan/Astrogator License: GPL v3, some icons and parts of code are MIT Acknowledgements: Borrowed icons from Kerbal Alarm Clock, some code from Kerbal Alarm Clock, Transfer Window Planner, and MechJeb2
  4. I hope so, but I'm not working on it actively at the moment. It would be a big project, maybe larger than everything else that's been done for Astrogator so far. I would want to keep the generality that allows you to e.g. plot routes from Laythe to Kerbin today, accounting for the path through Jool's SOI, and with assists in the picture, that effectively means the ability to automate PLAD's famous LKO-Mun-K-E-K-K-J path on the fly, plus any possible similar path. With so many candidate routes to consider, we risk losing the simple ability to calculate and display them all on the fly. The scope would explode, and the whole character of the mod could change drastically, possibly to the detriment of what's effective about it today. That's why there was a sunglasses smiley emoticon at the end of that quote. It's a goofily ambitious thing to say, and I probably shouldn't have typed it at all.
  5. No, I'm not, and your rephrasing loses the point of the question. Other people might have good reasons for how they phrase things, and if it looks wrong to you, it might be worth asking whether you missed something. No, I haven't, because we're talking about a "glaring hole." Super Mario Bros is an old, simple piece of software, but its UI indicators are all fully functional. It would be cool to be able to fly or to add whole new maps, but the features are complete for what they are. I would not describe Super Mario Bros as "things that need to be worked on never are." Is the point clear yet? Sure, but that's only from the perspective of one instant in time. There's also the long term view, over which it should be possible to address the "glaring holes" in a product if development continues long enough and is well planned. And as you noted, the KSP dev train seems to be coasting to a stop now with things like the burn time indicator left out. The point of my carefully considered phrasing was, is there any alternate configuration of customer behavior that could have stretched development out over time so these dilemmas of yours would not have persisted, where they could fix the rover wheels and then also fix the burn time indicator, because development is continuing? For example, if we took the same number of purchases over time and just slowed them down, maybe the anticipation of more customers would encourage development to continue even now? There are reports of KSP money flooding in and being used for other things in the early days, which obviously is suboptimal if evaluated from a bang-for-buck software quality point of view. If you don't think so, that's fine, but yet another "omg dev is hard" lecture isn't really helpful.
  6. I assume you mean the m/s countdown next to the burn timer. That's just the magnitude of the maneuver vector, which doesn't tie into the complexity of craft design at all. Calling it "delta V" is technically correct, but not really relevant. Any thoughts as a professional software engineer on how we as customers/users can prevent situations like this, where things that need to be worked on never are? Should we have refused to buy KSP until it had a working burn time indicator? Should we have sought refunds when we discovered pieces like this were missing?
  7. But is it on the bugtracker? The bugtracker is not limited to bugs only---there's a Feedback option you can use instead. That's the only means available to us to put things on SQUAD's radar. Otherwise they either don't know it's important to anyone or they might even forget it entirely.
  8. Amazingly, someone seems to have sincerely believed this in real life, and this rebuttal was done in KSP:
  9. In Stephen Baxter's Voyage, [EXTENSIVE SPOILERS] the director of NASA announces the crews for the flights leading up to the book's alternate universe manned Mars mission in a few years, and based on previous crew rotation practices all the astronauts can extrapolate who's going to go on the big flight. Two of the main characters (astronauts both) are not initially on that list, but nonetheless they stay pro-active. One of them makes frequent visits to the contractor building the lander, checking out the systems, providing feedback, flying simulations and test craft, generally becoming the leading expert on how to fly the thing, practically co-designing it with them. The other main character is already a published expert on Martian geology, but she continues working on it and teaching it to the slated Mars crew in addition to regular duties expected of all the astronauts. She also keeps her head during some high tension situations and develops a reputation as highly competent but also opinionated. Neither of them sits and pouts that they deserve to be selected already. When one of the planned crew is grounded by medical concerns, our pilot friend is the obvious choice for a replacement. And when another fails to learn even basic geology despite occupying the science slot for the mission, the director can't not pick our geologist lady friend. I think that's a good way to think about life in general. When the opportunities you want open up, they're going to look for someone who's not just got certificates but who has looked for and created opportunities to get experience in the field. I agree with @XLjedi, put one foot in front of the other and build up your qualifications when and where you can. Play flight sims and make a point of learning all the terminology so you sound fluent if and when you talk to industry people. Maybe go to a local small airport and talk to some of the people there, security permitting, just to be involved in what you want to do. I'm sure you can come up with better ideas than I have here. It's a cliché, but at 19 you really do have your whole adult life ahead of you (anyone who says that is jealous! ), and the smallest thing could show your interest and determination when it counts.
  10. But when they say "a window to visualize and manipulate PQS celestial bodies", some players assume "planet scaling", so I can see why some people argue they can't win no matter what. If I may propose a KSP Weekly reader's rule of thumb: SQUAD announcements usually highlight the most exciting things directly, not vaguely and indirectly. If they were going to scale the planets, they'd probably say "We're scaling the planets!" in big bold letters at the top.
  11. I'd like to do assists without porkchop plots, but so far I have not figured out how that would work. Similarly, I want to be able to split the auto-generated maneuver nodes into multiple burns for low TWR craft. Admittedly those are both nebulous ambitions rather than specific plans at this point. Credit where it's due, the sorting was requested by @hab136 on page 1, but I appreciate the sentiment.
  12. I thought that's what "@PROP[RasterPropMonitorBasicMFD]" does. If there's a RasterPropMonitorBasicMFD prop, it adds to it, otherwise it does nothing. Was there a particular change you had in mind? I'm not an expert in ModuleManager syntax. It's optional; Astrogator will integrate with RPM if both are installed, but it will still work solo.
  13. There's a trade-off between precision and performance. Transfer Window Planner chooses precision, so it does intensive calculations to find optimal timing for one transfer at a time; each pixel of the porkchop plot represents a separate transfer calculation that it makes, and it selects the best one that it finds out of all of them. If you want optimal timings for the perfect transfer, go with TWP's numbers. Astrogator, by contrast, chooses performance, because it's dealing with multiple transfers and updating them in real time. You really don't want me to run 6+ full porkchop plot calculations every 5 seconds during burns, or when you tab through the tracking station. This sounds duplicative of TWP to me. If you want to dig in to porkchop plots, there's already a mod for that. Also, is "advanced planning" actually useful? When I used TWP, I always used the solution that it highlighted for me, because I never found much reason to care about travel times or launch dates. Besides, what Astrogator really needs is support for gravity assists. Do you mean sort the table in the current UI? Because that's supposed to happen already if you click the column headers.
  14. Not without substantial effort. I've tried to imagine such a process: Create two standalone installs with Memgraph, one including the mod to be tested, the other stock Run a standard suite of test cases; they should be clear and simple enough that different people can easily do them the same way every time (e.g., build a specific 10-part ship in the VAB, switch to a specific 100-part ship in orbit, load a save with 100 flights, fly supersonic in atmosphere, etc.), possibly via a standard downloadable save file For each test case in each install, capture stats from Memgraph; bytes per second of garbage generated? Collect all of it in a big spreadsheet with one mod per row and one test case per column so you can sort to find the worst offenders The trickiest part would be accounting for variations in hardware of different testers, but we could at least hope that truly severe problems would stand out on any system, and using measurements of stock as a control should help. Then it's just a question of defining the test cases and setting up a repository for the data. Interactions between mods may matter, but we really need to tackle the individual case first. Some modders might take issue with being "called out" in this way; ideally any such project should take the approach of providing information for potential users, not trying to bully someone with bad stats. Finding and fixing a few bugs would be nice, but right now we can't even answer simple questions like, "Which mods should I uninstall to try to reduce my stuttering?"
  15. I have. I'm well aware of the details of the situation. Not in the sense of having done the development themselves, but unfortunately that's not what "responsible" means. They're responsible in the sense that they 1) hired the company that did the port, 2) did QA on the port, 3) receive money paid by purchasers of the port, and 4) have the option to have the port pulled from stores. Yes, I know. Meanwhile the previous port is still being sold to new customers, who will not be able to receive refunds once they discover it's broken.
  16. I agree on the PC side (and I'll probably buy the expansion). However, on consoles they continue to sell a broken product, and customers have reported difficulty getting refunds. (Yes, I know that's technically the decision of Microsoft or Sony or whatever company runs your game store. But SQUAD could pick up the phone and tell those vendors, "Listen, we have a PR disaster here, and we'd like to work with you to make special arrangements to help the people who feel like we ripped them off.") I don't want to derail this into a consoles debate, but this caveat should be included when praising SQUAD's integrity and professionalism.
  17. Nearly all KSP mods are written in C#. (Principia is at least partially in C++.) I'm under the impression that most people use Blender these days. A tutorial thread is pinned to the top of this subforum:
  18. No, no one does.
  19. Congrats!! There's a good chance that your first launch to orbit was a ways off from an optimal trajectory; it takes some practice to launch in a way that uses the least fuel. What you decide to do next is really up to you; if you want to learn to optimize launches, you can spend quite a while fine tuning to do it within 3400 m/s (or even less, supposedly). Or if that sounds boring to you and you'd rather explore further off targets, you can continue blasting to orbit with a bit of overkill. The game won't penalize you much for wasting fuel. Yes, there are a few options. The simplest one is to have your Kerbal exit the capsule, collect the science data, and store it in the pod so it doesn't matter whether those parts burn up, but Career Mode may not let you do that if you haven't paid for the requisite upgrades for extravehicular activities. You can also try to shield those parts from the heat, either by putting them in a service bay or moving them upwards so they're behind the pod itself. Yes, that just means it's below the surface of the planet. Your projected path is still an ellipse shape even if part of it is invisible. It sounds like you're catching on pretty quick, so I'd suggest taking a look at those Mun contracts. They'll be challenging, but you'll have fun trying to figure them out.
  20. In my opinion, yes. You can calculate it by hand using information available in the game: mass of vessel, mass of fuel, thrust of engines, specific impulse of engines. That's effectively what @Kerbart did in his subsequent posts. (Differences between our numbers are due to his inclusion of a heat shield, which I didn't see in your screenshot, and using a slightly different engine; otherwise we would have calculated the same numbers.) TWR and delta V themselves are not shown directly anywhere in the stock game, which is a common complaint/request of players.
  21. Let's calculate the TWR and delta V of your rocket: I'll use the mod Kerbal Engineer Redux to simplify the process: The TWR is 2.74 at liftoff and jumps to 5 after staging, so that's acceptable. It's a bit on the high side, but that won't keep you out of space in itself, and a high TWR gives you the option to add more fuel without having to increase thrust. The total delta V however is 2397 m/s, which is less than the 3400 m/s you need. So we can regard this problem as a lack of about 1000 m/s of delta V. If we add those extra FL-T400 tanks, it changes to this: Now the total delta V is 3597 m/s, which should be enough, and the TWR is still comfortably greater than 1. So this fix checks out number-wise. You might encounter other issues, but they'll have different solutions depending on what they are.
  22. For those who just want to know why there aren't any cool JPEGs online yet: