DRVeyl

For those with issues re: the maximum size in sandbox. Please see the release notes for v2.1 in <https://github.com/KSP-RO/ProceduralParts/releases> and note: "When upgrading an existing career, you may need to purchase the part size upgrades in R&D for previously unlocked tech nodes.In sandbox play, you will need to enable "All Part Upgrades Applied In Sandbox" in the Difficulty settings, Advanced tab." @darthgentlyThe parts from Keramzit Engineering are in ProceduralFairings, not ProceduralParts. Re: CoM offset, you appear to be misreading the discussion. A basic CoM offset approximation is already in place for the shapes. The issue is left open for refining the bezier-curve-based shape. If you are seeing incorrect CoM, please post an issue on the GH and include screenshots.

@Ultimate Steve The last 1.3.1-supporting ProcParts release is... 1.3.18. This is before I or the RO team took ownership, so not sure how to help here. @CrimeoThe different default masks / paint jobs are recolorable. Use the Textures Unlimited recoloring GUI. You can also change the shininess this way.

@darthgently Most parts don't have a CoM Offset, so the position of the part is the position of the center of mass. What you want is part.position + part.CoMOffset. That CoM offset I believe is part-local, so if the part is placed upside-down you may need to account for this. Interesting catch on the HASPHYSICS flag. I don't know quite what that translates to, exactly, in the KSP part info. But it does seem like ProcParts should definitely not be physics-less and should not apply their mass to any parent parts. Maybe part.physicalSignificance or part.PhysicsSignificance? @HebaruSan I don't know what the downside would be of enabling all PARTUPGRADEs in Sandbox. Sandbox inherently doesn't have a tech tree, and the way PARTUPGRADEs work, you generally would not want "side-grades" where they come with actual tradeoffs. I don't know why that flag is an option, really, since the only choices are "all" or "none."

Please see the release notes for v2.1.0, particularly in regards to part sizes. "When upgrading an existing career, you may need to purchase the part size upgrades in R&D for previously unlocked tech nodes.In sandbox play, you will need to enable "All Part Upgrades Applied In Sandbox" in the Difficulty settings, Advanced tab." If you are not able to play on 2.1.0, v2.0.3 is probably a reasonable fallback. 2.0.4-2.0.6 attempted to re-institute some volume limits that were around in the pre-2.0 releases. This illustrated a few inconsistencies in how we were handling the tech limits, and so I moved away from the roll-your-own approach since adjusting just the dimension limits in the UI fits the stock PartUpgrades model very well. One such example is the nose cones not having the right end size. That should be fixed in 2.1. I don't have any idea what the ProcParts part has to do with the lift generated by a different part (the winglet).

Realize this is the 1.5+ thread for this, but highlighting an issue I'm coming across in 1.4.5. Opened an issue on rsparkyc's github page, re-posting here for visibility -- or someone to identify what I'm missing or that it is fixed in 1.5+. Context is running 1.4.5 + RO/RSS/RP-1 (github latest). -- KSP 1.4.5, with Procedural Fairings 1.4.5.5 (via CKAN) (Technical: Unable to set KzResizableFairingBase 's MODULE[ModuleDecouple].stagingEnabled to True. It is unset in KzInterstageAdapter2 but set to False in KzResizableFairingBase) The Payload Fairing - Base (Extended) does not show a staging icon when added in VAB. The fairing staging works as expected, the payload base is the issue. Right-clicking the part gives the expected menu items (Extra radius, strut/size toggles, fairing nodes, interstage toggle, size tweakable, mass, cost, decoupler force percent, crossfeed toggle) but nothing to enable staging. The decoupler can be activated by action group or right-click menu on the payload base during flight. Seems the toggle got lost from the GUI? Non-scripting workaround is add a separate decoupler part above the payload base. Scripting workaround (assuming you will ALWAYS want to use the decoupler?): @PART[KzResizableFairingBase]:AFTER[ProceduralFairings] { @MODULE[ModuleDecouple] { %stagingEnabled = True } } Same for @PART[KzResizableFairingBaseRing]:AFTER[ProceduralFairings] Scripting workaround works as expected: decoupler icon for staging shows in VAB, triggers appropriately upon vessel staging in flight.

Transfer Window Planner!

I suppose I outlined my objection to this in my earlier post. It's not about the features that the base KSP provides that are absolutely necessary. It's not even about the features within RO itself (or its dependencies). It's about all the ongoing development in other mods that become inaccessible to the RO player because RO does not upgrade, and it's questionable that other mod developers should be expected to maintain development and release for older versions of KSP. As an example, RemoteTech fixed a breaking bug w/RO compatibility in March with its 1.8.10 release and update to 1.4.1. It had to re-release in JUNE with 1.8.11(.131) for RO. It's fair that a mod suite with external dependencies like RO is slower to update. I think it is harmful to development to argue that new features in the core system aren't necessary, so no update should happen. And its a flaw in the development cycle if an individual external mod is holding up your compatibility, for apparent lack of activity in that mod. [I have no insight into Ferram's situation or why FAR appears to be going without development. I love FAR as a mod. But from a programmatics standpoint, losing supply of a required component is a program risk, and there doesn't appear to be any mitigation.]

I keep lurking around Bornholio's Golden Spreadsheet for 1.4.x (https://docs.google.com/spreadsheets/d/1jqFjaHCo0gdIj5mX61V8D02Ma6v1WfH2Zuv0ddXgG5M/edit#gid=0) and appreciate all of the updates he and a few other anonymous contributors make to it. It attempts to track the compatibility of various mods required for the RO and RP0/RP1 mod suites. So practically speaking, what -is- delaying release of a newer version of RO? FAR & KJR are both Ferram's. Starwaster's DRE. Real Solar System + textures (tho textures shouldn't have any dependency on the version of KSP). Testflight has a PR waiting. What else is an actual dependency that would halt release?

Probably blasphemy, but I definitely see the point of the question. There are a couple PRs in FAR with recompiles for 1.4.x that haven't been merged in for quite a while. RO updates have lagged because of dependencies, which makes sense but there's also something to be said for RO itself to be a forcing function / show desire for those dependencies. An argument for just playing older versions doesn't work very well since bug fixes on many systems [that are RO dependencies] often don't get older versions re-released. This also ignores that players might want new features from base game upgrades and other mod updates [required or otherwise for RO], and also that it becomes a much bigger lift to catch up multiple significant releases later. After the last long hiatus from releasing, I think the RO team wanted to move to something more spiral-development with smaller monthly releases. But... RO's last release was 90 days ago, and is 30+ commits behind the master branch at this time. With FAR, I assume [speculation] that nobody else has privileges to merge into master.

Start with 1.3.1 and pull from CKAN. Then manually pull just RP-0 (or rather, suggest the developmental branch on github aka RP-1) and the suitable version of RSSVE. I believe the dev branch of 1.3.1 has the correctly-compiled RP0.dll.

I'm uncertain why you're looking for a 4-stage tier-0 *reliable* orbital rocket design. If you DID prove one out, would that suggest that whatever you design contains gear that doesn't belong in tier-0 nodes in RP-1? Or is the conceit that American rockets used as an upper-stage to heavier Russian first stage rockets could have done better than either nation's approach, given some hypothetical world where cooperation drove development rather than competition?

Ouch. I'm nowhere near as fast as they are. But I didn't feel like fighting for achieving orbit before the 1956 Orbital Rocketry tech, where an LR79 + AJ10 definitely has the capability at ~40 tons [requires a pad upgrade.] If you know when you're <3 years out, the 500k advance for achieving orbit pays for the pad upgrade (75k), the rocketry entry costs (~150-200k?) and several upgrade points. Early, each point seemed about +10% to research speed or production speed. Being way too cautions in buying upgrade points, I got 1956 orbital rocketry tech mid/late 1955. Most of my funding came from doing way too many repeated missions for sounding rocket altitude and difficult sounding rocket payload missions, and some of the world-first payouts for altitude. IMO this time period could use some balancing, as it feels like you need to do the missions to generate cash [especially if playing with the recommended "hard" settings] but it is a long time between interesting new capabilities from research. I wasn't doing anything interesting or different with the launches, and had designed an LV that would generally last through several iterations of contracts. I was aiming to keep rocket build times around 30-40 days. I freely admit that my opinion about balance is based on not knowing an optimum path through this early game [specifically when to take which advances, what upgrades/unlocks are absolutely necessary, what excess funds should be assigned to upgrade points and spread across build/tech times]. I stayed at KSC, so didn't spread any to get "quicker" access to different biome sciences eg flying/high atmo/space low from different launch facilities. I missed the whole "sounding payload in pressurized tank-1," too, and ended up waiting for service module 1. Thus... I certainly wasn't spamming the payload missions until a little later, and it was basically just altitude!

It's an incredibly informative tutorial series! Also, check out the wiki on the RP-0 github [ https://github.com/KSP-RO/RP-0/wiki/Tutorial:-Getting-Started ] which includes more detailed installation instructions and a guide for the first couple rockets. Feel free to mix and match parts from the differing space programs. For the most part, the tech tree isn't program specific. Different engines/engine subtypes [and thus fuel types & mixtures] become available as you increase tech level, but boiled down to a game mechanics perspective, you end up selecting for the engine+tank stats, mainly ISP and fuel density. It's neat to know some of the history or space program preferences and/or why that was the case, but your rocket will fly the same regardless!

Note that the "Last edit was made x days ago by y" at the top of the spreadsheet opens a menu to see the change history. I'm not sure anyone is willing to claim they've tested something enough to mark it green. I sure am not. [My KSP activity is extremely bursty and inconsistent.] From my observation, the main holding pattern is that the spreadsheet indicates a lot of updates available via github [usually] that are in mod PRs but not yet merged into the mod's dev or master branches, let alone a release. And if those haven't released, RO doesn't itself want to cut a release when its dependencies are not easily available. I'm not sure why some of the 1.3/1.3.1 update PRs seem to be sitting for a long time in some of the mods. However, if you do follow the spreadsheet for installation, you have a playable game. [I don't know that the significant amount of updates to RP-0 are balanced yet, so a formal (non-beta) release might still be a ways off, but they are playable.] Some of the mods are still marked yellow, but I don't see that any of those should prevent a release. It's also possible that someone just hasn't marked some of them blue yet.

RP-0 will definitely work without KCT. The main effect of KCT is to make time a resource, rather than the default of instantaneous building/construction/research. In practice, I've found that it causes me to spend more time at each effective tech level, rather than "skipping ahead" by researching multiple levels further into the tree and never using some of the intermediate items [especially engines]. Similarly with TestFlight, if random engine failures just isn't your thing, it's perfectly fine to play without.

Link to the RH 1.3 Test DLL is in the GitHub PR: https://github.com/KSP-RO/RealHeat/pull/4 PhineasFreak was nice enough to supply the compiled dll [unofficial, for 1.3 testing purposes only!], also linked from there.

If I recall correctly, the RemoteTech contracts require that your satellites have links between eachother, not that each satellite has its own link to the ground. Try pointing sat-2 at sat-1, sat-3 at sat-2, sat-1 at sat-3. The other dish on each sat can be pointed at Earth IF your satellites are close enough to close the link using the dish+omni.

Bump. I've been poking at that doc and marking things blue that seem to work and generally don't throw exceptions. Have only done the barest testing, usually launching a basic craft with some of the features from a given mod attached, so haven't marked anything green. Looks like just about all of the requirements for RO function in 1.3, and the ones I haven't poked at yet shouldn't be strictly necessary. So if anyone out there has a 1.3-compiled variant that they would like the community to test...

Also had this in RO, which led to a little digging. Went to prep some screenshots but couldn't duplicate. However, think this is related to MJ2+RealFuels, specifically the ullage requirement / propellant state. For "Very Stable" MJ2 correctly calculates "Node Burn Length" and "Node Burn Countdown." If the propellant is not "Very Stable" those numbers become INF. I think this is some fighting between RealFuels (RealFuels/SolverRF ?) and MJ2/FuelFlowSimulation.cs? http://imgur.com/a/vTzAh