Tonas1997

Which version of Orbital Decay should I get for KSP 1.3.1? The releases page is kinda confusing

Erhm... huh, this is embarassing. My save wasn't loading the configs because my Kerbalism is using a custom profile suited for RSS, not the default/classic ones. Which makes perfect sense. On the same subject: do you think any of the already implemented profiles would be suited for RSS? I know this is more of a Kerbalism-related question, but I used that mod's own greenhouse as a baseline and multiplied resource inputs/outputs by 1.8. This number was a bit of a rough estimate based on the notion that a land-based greenhouse would be far more capable (and costly, resources-wise) than a spaceborne one - Kerbalism's greenhouse was undeniably designed to be used in space habitats.

Quick heads-up: the Kerbalism compatibility patch doesn't include a proper "greenhouse" module. I used Kerbalism's own greenhouse as a baseline and wrote some shoddy configs - haven't tested them yet - but they should work as intended.

Is there a particular reason as to why SSPX's greenhouse config depends on the default profile? @PART[sspx-greenhouse-25-1|sspx-greenhouse-375-1]:NEEDS[ProfileDefault]:FOR[Kerbalism] I had to change the NEEDS: tag to "StationPartsExpansionRedux" in order to be able to use the greenhouse on my save, which uses a custom Kerbalism RSS profile.

Ok, there's no way around avoiding that ComSatBus resource... Basically, I've been deleting its references in each and every contract parameters, which should've been a straightforward solution. However, the reward funds parameters also take into account the weight of the satellite. Example from TundraSatellite.cfg: rewardFunds = 35000 + (@VesselGroup/HasComSatBus/minQuantity * 2) I have a feeling removing this reference would produce unfair contracts, since there wouldn't be a direct proportion between a satellite's weight and its reward value (kinda like real life). So what the hell, let's try to to port over the resource declaration for the ComSatBus resource! ...alrighty then. There doesn't seem to be any RESOURCE_DEFINITION tag in the RP-0 configs, which is strange. And I can't simply load the original contracts in a non-RP0 modpack without removing the resource, since doing so will trigger a "error parsing non-existent resource 'ComSatBus'", or something like that. So, basically, I'd like to implement the resource nonetheless, but without the full mod. In this accord, I have two questions: 1- Can I simply declare a "ComSatBus" resource with the standard method (e.g. by using a RESOURCE_DEFINITION loose config)? 2- If so, do I need to add any further configs to avionic parts - probe cores, for example - or, at least, to procedural tanks, in order to add the resource to satellites, thus fulfilling the requirements?

Same here. I updated my 1.3.1 modpack to the latest version of Kopernicus mainly to get rid of the "flickering orbital lines" glitch, but the backports don't seem to include the fix...

Does anyone else have lightning problems with Real Exoplanets? I'm running a 1.3.1 modpack with RSSVE and, when REX is installed, the sunlight received on the Earth is WAY dimmer than it should be.

Thanks for the answer! I'm checking the agents.cfg and just noticed something: the logo URLs have a path rooted in the GameData folder, NOT the contract pack folder. Since the ported contracts were not placed in some "RP-0" folder, the agency flags could not be found, meaning it's only a matter of changing the paths. As for the ComSatBus, I should've guessed it was only about removing the requirement . Nonetheless, the idea of having a minimum mass limit for certain satellites seems about right (since real-life modern satellites weight a couple of tons). But I think it would be way too complicated to extract the resource and add it to probe cores...

I'm really sorry if this question comes across as a bit off-topic, and believe me: I think RP-0 is a great mod. However, some of its functionalities just aren't for me; I prefer the Community Tech Tree and the kerbal retirement/tank tooling mechanics aren't really suited for my playstyle. Therefore, I chose not to include it in my RSS/RO modpack. Despite this, there are a couple of its (great) features I'd like to implement in said modpack, mainly: Contracts - the provided contract packs are just what I look for in KSP: solid, varied, and fun contracts that give off the sensation of actual progression in a space program. Porting the contracts to a non-RP-0 modpack should be as easy as placing them on the GameData folder and removing any :FOR[RP-0] as to avoid ModuleManager shenanigans (plus the Agencies folder that comes bundled with the mod). However, I've come across a few problems: Some contract groups still lack an agency, showing a white rectangle as the "flag". The satellite contracts don't load due to a reference to an unknown resource, ComSatBus. I don't find any reference to this "resource" in the GitHub source RP-0 folder (apart from the contract configs themselves), which means those contracts are, effectively, rendered useless. KCT preset - looks quite realistic, since it now takes months to build rockets. I think I only have to copy the KCT_Presets folder. Once again, sorry for not discussing the mod itself on this post; I posted a similar question on the ContractConfigurator thread a while ago, but I figured it would be best to ask someone who knew the innerworkings of RP-0.

Quick question: does the 1.3.1-13 backport include the "flickering orbital lines" fix?

Was this issue fixed on the latest release?

Thanks for the answers, I'm extremely inclined to trying this out on a career mode As for that "station-keeping" feature, could it theoretically be implemented?

Yeah, I guess that only becomes a major problem once the vessel gets too close to another orbiting body, like the Moon. Most LEO/MEO satellites would take years to have their orbits significantly changed, and you're not required to hold it stable for long (I think 2 minutes max) sooo... Contracts evolving heliocentric orbits can be a bit more challenging though

Hmm, I see. But considering most contract orbits can be reasonably approached in Principia (meaning it's fairly easy to achieve a quasi-stable orbit in LEO/MEO/GEO), and that the contracts are quite forgivable when it comes to target vs. current parameters, shouldn't be much of an issue.

As someone who is eager to try Principia on a RSS install, I have a couple of questions (and one suggestion): 1- Is the mod compatible with Trajectories? That is, will the projected trajectory in atmospheric flight be drawn correctly? 2- Since the orbital mechanics are overhauled by the mod, do contracts that depend on precise orbital insertion still work? Let's say a contract requires me to place a satellite on a (e.g.) 500km x 300km orbit, with an inclination of 70º. Do you know if the contract system will register and accept the parameters of a Principia orbit? 3- While transfer planners won't be pinpoint accurate when it comes to transfer windows anymore, can they still be used to obtain a reasonably accurate launch window? __________________________________________________________________________________________________________________________________________ As for the suggestion, please note I'm not exactly an expert when it comes to KSP modding, so I apologize in advance if this comes across as naive and/or too hard to implement, but bear with me: One of the most off-putting things about n-body physics is, in my opinion, the amount of station-keeping that is required to keep satellites, stations and relays on a particular orbit. IRL, this isn't much of an issue; those missions are, at any given point, being managed by dedicated teams that ensure orbital stability, and thus are able to plan and execute adjusting manoeuvres accordingly. In KSP, not so much. A standard career mode will have dozens - if not hundreds! - of simultaneous satellites orbiting Earth, the Moon and so on. Making sure those missions keep a stable orbit would be too cumbersome, since cycling through every active mission gets boring pretty quickly. In that respect, what about implementing a system similar to what Orbital Decay does? Basically, there's an option to "lock" a vessel (put its trajectory on rails) at the expense of RCS fuel, just like orbiting satellites do in real life. Eventually, fuel runs out and said satellite would begin drifting away from its intended orbit, but not before fulfilling its designed lifetime! While this wouldn't make sense for some trajectories, like interplanetary injections, those that return to the same spot periodically within a reasonable margin - and thus can be considered orbits - could allow for background station-keeping (and considerable savings in calculations!). Nevertheless, I suspect implementing such a system would be a harrowing job, given how different the concept of trajectory is between patched-conics and n-body simulations. Just wanted to leave some food for though