Mike`

Hey. Thanks for this interesting mod. I've been wondering about making communications more realistic lately when i heard this mod already supports variable data rate based on distance, so i tried it. Works nicely, but the formulas used are still somewhat unrealistic i guess. Kerbalism by default scales data rate linearly by KSP's default signal strength, which itself scales roughly with distance. IRL, your signal strength and data rate change by a factor of 1/4 though when you double the distance. This can be corrected by adjusting the way KSP calculates signal strength, it can be done by giving each antenna and the DSN a custom rangeCurve with an MM patch. I got this working already, even though it was harder than expected due to a stock KSP bug. There's another problem though: The way multiple antennas stack in Kerbalism. IRL, two antennas either work together, thus the total signal strength rises, which allows a higher data rate. Or the antennas could work by creating two parallel connections, which would leave signal strength alone but would double the data rate for equal antennas. In Kerbalism however, both is done at the same time - the signal strength rises with an added antenna, which already leads to a gain in data rate, and on top of that, the raw data rate of the added antenna is added on top. This results in the data rate rising more than what's realistic. I intend to change that, and wonder what you think about it - are you interested in such a change (more realistic data rate attenuation and proper data rates for stacked antennas)? If so, i would try to implement that and could then provide a PR. regards and a happy new year Mike

Does it work with RSS/RO/principia? :) Also, the name somewhat confuses me. Is it a trajectory optimizer or launch vehicle optimizer? Because launch vehicle designer hints at the latter, imo.

You need to install the latest RealFuels version for 1.3.1 (https://github.com/NathanKell/ModularFuelSystem/releases/tag/rf-v12.6.0), it includes MLI.

What do you mean by "not cut part count"? You can add as many parts to your rockets as you like, even with this mod. And if you want more parts, you can combine this with other mods.

I somehow have trouble with the n-body coast not detecting SOI transitions. I do an escape burn and an n-body coast and i keep "orbiting earth". Replace n-body coast with normal coast and everything works, eg orbiting sun or orbiting venus after i optimize the plan to find a venus encounter. Also, the selective SoI search dialog behaves weirdly, when i select something, close the dialog, open it again, everything is reset to everything selected, in the case of n-body coast it is reset to everything but the gravitational bodies selected.

Really no worries, take the time you need, i didn't want to sound impatient. I'm glad you found the wrong transform and now curious how the fixed/moved transform part behaves, but i'll happily wait until you get around to provide it. After all, modding as a hobby shouldn't become stressful.

If FAR calculates/estimates the higher drag correctly, then there is nothing wrong/nothing to fix, i guess. The unfixed LR-101 was clearly broken drag-wise, i haven't seen the fixed part yet and how much more drag it has compared to the old LR-101. I cannot try flying a new atlas because the unfixed new LR101 has so much drag the rocket immediately crashes.

If you could provide me with the updated lr101 i'll load it up in far and try to see if the debug view will work now and might give a clue where the problem is. Well, the fuel consumption of your rocket increases to reach a certain orbit, but the fuel consumption per second didn't increase - so talking about fuel consumption when in fact it looks to be a drag issue can be misleading. But i guess we all got it now so it's fine.

Thanks, glad you found it! That sounds weird. If you want, i can take a look and test it aswell (in a Realism Overhaul install though). FAR allows you to analyze the drag of your rocket directly in the VAB including debug voxels etc, so i could try to check if drag is still higher than it should be.

I asked ferram about it, here's what he had to say: "There's probably a random transform floating somewhere far from the rest of the mesh that's screwing it up". If you haven't done so already, would you be so kind to recheck the model for that?

Hey @CobaltWolf, really liking the new Atlas parts. Sadly, the new LR101 vernier seems to have some trouble when used with FAR - it has a gigantic drag. Do you have any idea why that might be? If not, i guess i'll ask ferram about it.

Well, one small thing that comes to mind is support by Testflight. Supporting testflight/manipulating the thrust of single engines of a cluster would probably require some extra work/an API, if it is easily possible at all.

Can anybody say 1-2 sentences about what extended-body gravitation means for principia? Are the bodies modeled as oblated spheroids, or is the simulation even more precise with measured gravitation maps, taking continents etc into account?

Does anybody know if there is a permanent/persistent way to increase the game's warp speeds, eg. setting better timewarp's hyperwarp as the default warp levels? Sadly, the game keeps resetting to it's default warp speeds on some screen/building changes.

You can fix it by modifying GameData\RealismOverhaul\RO_SuggestedMods\SSTU\SSTU_Engines_GLOBAL.cfg and make sure it contains a part looking similar to: @MODULE[SSTUModularEngineCluster] { @diameterIncrement = 0.1 // Allow increments of 1 cm %adjustMass = false } The %adjustMass part is the important bit which needs to be added.

Can confirm i had this problem as well. Having thought about it later, maybe i should have reduced the thrust of the booster a bit to have a longer runtime/decouple in less dense atmosphere. What i ended up doing was increase the thrust of the radial decoupler separator-boosters somewhat with a patch, so it was able to push the boosters away and the nose of the booster outwards. To do that you also might need to turn down the thrust-level of the lower separator-booster and spread them out so they are at the end of the booster.

Hey, thanks for sharing your work with us. Few issues i noticed in the current release: 1) The Isp-curve of the M-1 is broken, Vinci and probably all other engines that modify the Isp of an SSTU upper stage engine are affected aswell. You cannot patch Isp-curves by just changing key 0 and 1 from the original part, because the part might have more keys defined, like all SSTU upper stage engines (except the J-2) now do. (They now have more realistic curves that do not work at sea level.) 2) In sandbox mode, part-upgrades don't seem to be applied correctly. On first try, none seemed to work. On second try, fuel tank diameter upgrade was applied and thus i could make large fuel tanks, but the upgrades for the MUS, SRBs etc still weren't applied so i couldn't make them large. Edit: Oh, it seems to be caused by the upgrade editor. Even though i don't see any diameter-related updates in its list for SRBs, toggling the shown "number of segments" updates and after that creating a new srb from the editor panel, diameter upgrades suddenly were available. Weird. Yep. Upgrades apply after touching one available upgrade in the editor, then closing it, deleting the part and recreate it. 3) Realplume-configs for the M-1, LR-87-LH2 and Aerobee Sustainer seem to be broken. The M-1's plume is tiny, the LR-87-LH2 seems to have 2 plume effects, and the aerobee flare is far too far behind. It seems that many if not all plumes are not rescaled to match the increased engine size. Edit: Removinbg SSTU's original configs seems to fix the scaling issues. However the M-'1s plume is still tiny, and the LR-87-LH2 has an interesting behaviour, when you use them in a cluster, each of the clustered nozzles has a plume, but there's also a wrong, additional central plume. 4) There still seem to be some errors with the new modulemanager version: 2 errors related to GameData/SRP-0/000_GeneralPatches/RO_General.cfg 1 error related to GameData/SRP-0/Compatibility/RO_RemoteTech.cfg 4 errors related to GameData/SRP-0/Compatibility/FASA/FASA_LifeSupport.cfg 1 error related to GameData/SRP-0/Compatibility/Procedurals/ProceduralAvionics.cfg 5) The fairing on the VA capsule seems to have not been rescaled, while it's fine for the apollo capsule. 6) The MSRB-D1-5 upgrades don't appear in the techtree, even with the old modulemanager version. Trying to figure out what's going on here. Edit: Seems i found the problem, it's the partIcon used: %partIcon = SSTU-SRP0-ENG-SRBGen seems to not work anymore, once i changed that to SSTU-SRP0-ENG-SRBC the icons appeared again in the techtree. 7) The Procedural Telemetry Unit and Pressurized Procedural Avionics don't have any electric charge, probably because you converted the procedural avionics to use the sstu support tank to store the EC and forgot to adjust the other two. 8) The Tiny Tim SRB doesn't work, somehow the renaming of the ModuleEnginesRF to an FX doesn't work, once i changed the RF to an FX in the original config file the Tiny Tim worked. Also, your tech tree does not yet contain the new lander tanks, SSTU-SC-TANK-MFT-LV. The old -L tanks will probably be removed sometime soon. Another problem i noticed is that you can set the diameter of parts to 0.00, which apparently leads to problems at least in the case of the MUS and shouldn't really happen, but that might be an SSTU issue. Edit: It looks like setting the min diameter to 0.1m instead of 0.01m fixes this. As 0.1m really should be small enough anyways i suggest setting that as a new minimum?

Thanks for the quick reply, though that doesn't seem to change it, set it to 0.01 but the SRB still flame-outs. The exact number it flameouts seems to be around 7%. I'll google a bit more for this, i guess. Edit: I've found the reason: Setting flameoutBar to something more sensible like 0.001 for the SRB-parts "fixes" the problem. On another note, i had to be reminded again that the x axis for SRB thrust curves is the amount of propellant left, not the burn time as one might expext, correct? I think burn time would be easier for end-users to use, but probably isn't that simple to implement?

I'm currently trying to create a new SRB thrust curve, however the SRBs seem to flame-out when the thrust curve falls somewhat below 10% thrust, with the message "air combustion failed". Does anybody know the reason for this? It also happens with the "gradual" sstu thrust curve, and causes some fuel to be left unburnt in the SRB.

Payout is way too much in larger scale systems like 10x or RSS. Making payouts based on the scale seems like a good idea at first, but besides being too high for RSS scale currently, it's probably just better to keep them scale-independent and adjust payouts globally in the difficulty settings based on your scale and difficulty-wishes.

I'm playing with a realistic solar panel patch (panels have 1/5 mass and 1/10 power output compared to stock), so, yes, in my opionion scaling the panels would be a good idea for such a use case.

Talking about satellites and probes, what do you usually use for attitude control of those? RCS seems to be useless with stock SAS, unless you have a gimbal engine aswell and only need RCS to point the probe roughly in the correct direction. I tried flying a probe consisting only of the MUS, a non gimballed engine and science experiments to the moon, but gave up when i realised it had a very slight torque caused by the different radially attached experiments and thus couldn't fly in a straight line... I guess my next try will either have gimbal or reaction wheels again...

Well, as far as i know, stock and stock-alike parts usually use a size scale around 0.64x. Weight is a bit more difficult, but i guess even there at least some mods use a certain scale for some parts. All i'm asking is - are there any common scales used in this mod, or are all the parts scaled differently? Btw, this mod is recommended by realism overhaul, that's how i found it.

Is there any info on how these parts' size and weight are scaled compared to real life? I was comparing some weights with their wikipedia value and am confused, because some parts seem to be heavier (for example Deep Space 1 [wikipedia dry mass: 373 kg, ingame dry mass: 939kg] Voyager 1/2 [wikipedia launch mass: 825kg, in-game dry mass: 962kg] and Explorer 6 [wikipedia launch mass 64kg, in-game mass 95kg]) while there also are lighter parts, for example stardust (in-game dry mass including capsule 177kg, real dry mass about 300kg).

I run with patches to allow realistic transmission of science, so i get 100% science value when transmitting the typical "measure stuff" experiments. The things i do have to return are experiments like the goo container, the materials bay and of course surface samples, so i usually use two 1.25m service bays with a heatshield and parachutes to return them. Science container/box functionality would be useful for the samples, i guess.