RoboRay

Members
  • Content Count

    1,624
  • Joined

  • Last visited

Community Reputation

1,336 Excellent

About RoboRay

  • Rank
    Rocket Surgeon

Recent Profile Visitors

2,044 profile views
  1. Definitely need to keep dV in KER... The KER UI offers a much better presentation, whether you prefer a comprehensive or a minimalist approach.
  2. Definitely concur on the need for a new thread. Even without the inability to edit the OP, the changes in RP1 are so significant that keeping the info for RP0 in the same thread as RP1 is just going to confuse and mislead the unicorns who actually try to read previous posts and figure things out for themselves instead of just asking questions first.
  3. RoboRay

    [1.3] Real Fuels v12.2.3 July 30

    The PEG algorithms are the ones actually developed by NASA for guiding the space shuttle ascent, so it's absolutely tuned for RSS and not stock KSP. I really doubt it would be useful on launches from Kerbin.
  4. RoboRay

    Engine has negative mass

    Tweakscale causes most negative mass issues.
  5. If you have the same floating tiles thing that most people have, it only seems to happen on reentry from suborbital flights. If you quicksave then quickload at apogee, it shouldn't happen.
  6. If you have data (theoretical or even just plausible data is fine) supporting realistic alternative history, modern or futuristic engines, feel free to implement them. RO is community-driven, so you are one of the people in a development role for RO. The person who has an idea is usually among the best people to implement it... they understand the issue and have motivation to resolve it.
  7. RoboRay

    [1.5.x] Radar Altitude

    Having the toggle tied to an action group would be nice... for example, to switch to AGL when you extend the landing gear.
  8. Improved 3rd-party mod support is pretty much always wanted... it most likely didn't get a response due to lack of knowledge about kOS due to lack of usage of kOS, meaning improving kOS wasn't a priority for them. But if it is a priority for someone and they do the legwork (in my short time watching RO/RP-0 development), it gets accepted and incorporated. I think it can safely be ignored for now. Like you said earlier, the current basic implementation doesn't account for it, so it's either already broken or not actually an issue. Once the kOS parts are added, actual usage of them should reveal whether or not it's a problem. I need to improve my own knowledge about some of this, but will follow up later on Github.
  9. Actually, SmartParts is something else I'm looking at for integrating into the RP-1 tech tree. I've been missing some of those things. But yeah, I get that there's not a direct correspondence between the kOS functionality and real-world computers. Just having a vague ballpark idea would help... something like "Part X might represent late 1960s computers, while Part Y could be early 1980s computers." I think the future plans to limit IPU by processor part would be a very desirable feature in an RP-0 implementation. I'm willing to help with addressing this issue, but I'm new to RO/RP-0 and am still learning my way around under the hood.
  10. Then it would seem it was an error to not include the kOS parts. Adding the baseline functionality to probe pods still makes sense, but the separate parts are still needed. It may also be that the parts were not deliberately removed... they may just have never been placed in the tech tree to begin with, and hasn't been a priority for anyone to do because the pods have the basic functionality. RP-0 is mostly community-driven, and its often the people who raise an issue that have the best understanding of the issue. It's also often the people who raise an issue who have the most motivation to get it fixed, since it's impacting them. You may want to just dive in and try to work out how to fix it yourself. It might save a lot of waiting, and you can be a contributor to the project. I'll look at the issue you raised. Edit: It seems likely that nobody has any idea where they belong on the tech tree, or what they should cost so they simply haven't been included. They don't seem to be listed in the spreadsheet that generates the tech tree configuration at all. I don't think that it is intended for kOS storage capacity to not improve over time... it's just that implementing it has been neglected. Not being a kOS user, I have no idea... but if you suggest a year in which those parts might logically be available, and a reasonable price (converted to 1965 US dollars), that might help. The key thing to remember about balancing in RO/RP-0 is that it's supposed to be realistic... so, balancing parts for gameplay reasons isn't really a thing. If you can equate the kOS capabilities to real-world computer capabilities historically (or projected into the future), that will indicate about where they belong in the tech tree. And likewise with costs.
  11. I think that it could be possible for the capacity to increase over time, based on tech node unlocks. Doing it via specific probe cores isn't ideal, since many people use the procedural avionics instead. What does (non-RP0) kOS do if you install multiple kOS parts with different storage capacities? Does it add them, or just use the highest value? If it just takes the highest, it might be simplest to bring back the 10k, 60k and 255k parts as storage upgrades further down the tech tree... leaving the 5k config in all probes and avionics by default. I'd suggest opening this as an issue on the RP-0 Github for discussion... especially before devoting time to actually implementing possible fixes. They may have some ideas.
  12. Even if you don't use RSSVE, the RSSVE thread provides useful information on which version of Scatterer and other visual mods work properly with RSS.
  13. There is some "KSP 1.5.1" activity happening on the RO GitHub.
  14. If you are only including the portion of Ferram's content that he has released under GPL v3, then no, you don't actually need his permission to fork the project and publish your own version. He already granted that permission by releasing his work under GPL v3. However... It is customary and, more importantly, polite to inform him that you plan to do so.