RoboRay

There will be.

I can confirm that the recompile seems to be working fine with KSP 1.8 on Windows 10.

Tweakscale is generally regarded as being incompatible with RO. It breaks stuff. I was under the impression that RO actively disables Tweakscale if you try to use it, but I could be mistaken.

I'm not aware of any Procedural Parts branches explicitly stating that they support KSP 1.7, but these are just textures so they should be fine in any version of KSP that you can get Procedural Parts working with.

It's already in your hands. Your pull requests will be much appreciated.

Very nice looking!

Stock parts were deliberately gimped by Squad, because parts with realistic masses and performance characteristics would make the toy-sized stock solar system so trivially easy that the game wouldn't be fun. Any craft built using stock parts (or mod parts balanced with stock parts) will have the same unrealistically poor performance. In a realistic, full-sized solar system like RSS, you can either use the Realism Overhaul mod to give the parts accurate real-world masses and performance, or use something like the SMURFF mod to rebalance the stock parts to have more realistic characteristics.

Taerobee has some stuff that you will use early in the career (like V-2 rocket and X-1 plane parts). Vostok Continued has early manned Soviet craft. SSTU has lots of versatile tanks and and engines plus parts for mid-game to late-game manned American craft.

But you're only implementing the capsule itself. Trying to include the service module features into the capsule would imbalance the DLC Gemini capsule compared to the mod Gemini capsules. It would also be unrealistic, since the Gemini capsule doesn't have sufficient volume to make room for all that equipment and storage containers. Your best bet is to simply implement the capsule config for what the capsule actually provided (using the FASA Gemini as a reference), and assume that the service module features will be provided by an attached service module.

I haven't tested it yet, but this fills a big hole in the "everything is procedural" approach to craft design. Thank you! I'm really interested in pursing non-US/non-Soviet entries in the space race, and this will make it a lot easier to not be limited by the design impacts of using historical US or Soviet engines.

I would look at the RO configs for FASA Gemini and work with those numbers. They should be pretty solid.

Definitely need to keep dV in KER... The KER UI offers a much better presentation, whether you prefer a comprehensive or a minimalist approach.

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.

Go right ahead!

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.

Tweakscale causes most negative mass issues.

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.

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.

Having the toggle tied to an action group would be nice... for example, to switch to AGL when you extend the landing gear.

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.

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.

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.

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.

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.

There is some "KSP 1.5.1" activity happening on the RO GitHub.