Kurld

To be clear, the mod I'm referring to is SOCK. The "cockpit" part has two different control from here options. You still need to pick the one for the zenith-facing docking port. The difference is (now) you don't have to completely change the RCS configuration to get it to work smoothly with DPAI.

The "problem" was the way that the mod used to be set up with specific RCS thusters for the three different axes. You had to configure them in specific ways depending on which control point (i.e. "control from here") you used. This allowed for very fine control. . . as long as you used the "forward" control point and not the one for the docking port. The mod's author has since updated it so that it is set up like other command pods and now it "just works" regardless of which control point you use.

Let's say a person playing a non-RO game wanted to have engine thrust spool up and down instead of being instant on and off. You can set useEngineResponseTime to True and then give some values for engineAccelerationSpeed and engineDecelerationSpeed. The stock jet engines and solid rockets work this way, I think. Smaller numbers mean a slower spin-up or down, bigger numbers mean quicker spin-up. My gut says that liquid fuel rockets are somewhere in the middle between jets and solid rockets as far as how quickly they can respond. I can take a WAG and make what "feels right" but is there any source of information for how long it took for e.g. the Rocketdyne J-2 to go from zero to full-thrust? I've seen information about the 1, 3 or 8 second pre-burn for this specific engine, but what I'm talking about is how fast did it take to go from firing the spark plugs to running full blast. Barring a documented source of information, is there some kind of rule of thumb that might inform an educated guess? My understanding is that LF rockets do this in RO, but. . . I can't for the life of me figure out from the code/configs on the github where or how it is getting applied. Thanks!

Nah, I'm not talking about the neon green thing. I did see that at one point as I was trying to figure out why it looked so very desaturated already. I did have the old/correct scatterer and tried a variety of TUFX profiles and even tried to roll my own. In the end the only thing I could figure was it was some kind of artistic choice to make the home planet look like 1970s Los Angeles on a bad air day. Anyway I got rid of it and moved on to solving other problems, lol.

I think the long time it was taking was because it seems to be (by default) searching over the entire synodic period which I think would be some larger fraction of the Mun's orbital period. Setting it with the options to be something like the ship's orbital period covers pretty much the same realm of possibilities (assuming the ship's orbit is more or less circular). There does still seem to be some variability in the results, when run several times in succession. Not nearly as much as I was seeing when it was using the (as coded) default value for max flight time. Shortening the search interval to give more opportunities for it to find the "best" solution seems to help tighten things up, but honestly, the default value has so far been "good enough" so I set it back to the default. It finds a solution in only a moment, so it's plenty fast. From the perspective of "good enough is the enemy of perfect" I will observe that it is still generally finding solutions that use some amount of radial-in or out. It seems to fire earlier/later than it needs to, because of this, or else it adds the radial component to compensate. The amount it adds is a lot less than before. I wonder if it can be further adjusted out by further increasing the maximum flight time? I'll have to test some more.

JNSQ made everything look sickly green and very washed out and hazy looking on my machine. I never could get it to look "right" so I wound up swapping back to 2.5x stock which, while it would definitely benefit from higher resolution textures, at least looks somewhat like a real place where I'd like to spend some time.

It's Rescale, which as I understand it is a SigmaDimensions config. I'll apologize for all my "helpful suggestions" in the post above. Once I got into to the code, I realized it already does them, one way or another. I'm curious now about how I might be able to extend this to be able to find solutions that result in a free-return trajectory. Do you have any thoughts about that?

I think maybe I found the problem. In your documentation you mention that max_time_of_flight defaults to 2* the ideal Hohmann transfer time. This does not appear to be true in the code, rather it just uses the transfer time (not doubled). I think this is why it's trying to use so much radial out.. to keep the transfer times down. When I passed it rsvp:ideal_hohmann_transfer_period(SHIP, Mun) * 2 for the max_time_of_flight and it started giving me very good transfers.

I've been playing with this the past few days. I want to calculate a burn to go from Kerbin orbit to Mun. I'm in a circular/equatorial orbit ~200km in a 2.5x system and generally a transfer from there costs < 1450 dV with the hill-climbing alogrithm I've been using so far. I was intrigued by the possibility of using RSVP to find retrograde solutions and more or less nail the desired PE at Mun. I does this part perfectly. But... First problem I ran into is that, with the default settings for search duration, etc. it takes a LONG time to find such a solution. Several minutes. The solution it finds for a retro-orbit at 50km seems to be somewhat reasonable, but the ETA is days into the future. The CPU in my S-IV analog only has so much battery power available... And this seems unreasonable, both from the sense of waiting around for it to finally do its thing and also . . . I can, by hand, find an intercept within one orbital period that is roughly "good enough" in terms of dV required. And I can do it a lot faster than the solver. Then I noticed it seems to be searching the entire synodic period, so I decided to limit it to searching only within the next orbital period and things go pear-shaped. The nodes presented by RSVP in this case are generally more expensive (1750 to 1800 dV and up). I've noticed that if I wait a moment and try for another solution, it tends to find something entirely different. Sometimes a little better, but sometimes much worse. A few times it presented nodes that were over 2500m/s and included me burning a lot of radial-in... taking me through Kerbin itself. At this point, I tried adjusting the search_interval to give it more chances to find better solutions and it didn't seem to improve things very much, tbh, and it takes an extremely long time if you go very thin with the slices. Most (all?) of the solutions presented include some significant radial component to the burn (usually radial-out), which I don't understand the need for in this case. Is there any way to help it out with some better initial guessing? The phase angle for intercept should be calculable, which should give it a good idea of where to start looking for ETA to burn. The prograde deltaV estimate for a burn from a circular, equatorial parking orbit to the eventual apoapsis near Mun's altitude also seems easy to obtain. Or, is there any way to warn it away from including any radial component in the burn? I think the fact that it is including any at all is skewing the rest of its calculations towards being sub-optimal in the final application. As always, I have to ask, "what am I missing?" because the answer is usually "something I didn't imagine."

Is there any mod that makes the tanks not behave as tough as. . . a tank? The parts in this game seem pretty impervious to destruction. I'm going to guess this is a compromise/limitation of how the game doesn't seem to model materials (at all?). I'm guessing it also doesn't really account for twisting vs bending vs shearing types of forces that can act on them.

Yes, I believe you are correct about that. After making the previous post at some point I was working out some calculations for predicting how far something traveled during one rotation of Kerbin and noticed that it was off by about that much.

Good luck!

This. If you're trying to build something like the ISS, you will have a much easier time if you turn off the reaction wheels for everything except possibly the part that is closest to the CoM of the station. RCS needs to be off as well. When I was on the Z1 truss mission, I forgot to turn off the wheels on that part in the VAB and it took me a while to realize that that was why my shuttle was beating itself to death. The kraken usually only shows up when you speak its name.... You MUST go very slowly. Especially if you are manipulating something as monstrously heavy as the Z1 assembly. You must turn dampening to max. And generally I make docking forces be zero on the end effector and as low as possible on the parts I'm moving. I use the KAL controllers to control the arms. There's no way I'd try to do it in real time. Totally pointless without some kind of inverse kinematics control.

Uninstalled the mod and got 6 hour days. System date changed from Y1 D67 and 4:45-ish at startup to Y1 D84 and 1:45-ish with it uninstalled. This seems roughly what I'd expect for the time scale difference of 1.25x. With the mod installed, it seems to be ignoring useHomeDay altogether. Day length is 7h 30m either way. I think the 7h 28m thing was me being eyesight/math challenged. I'm not sure what's up with kOS but it seems like a kOS issue.

OK, weird. I reloaded KSP with useHomeDay set back to false and I'm still getting 7h 30m days.

It's not really balanced very well for scale 2.5x, either. I had to take some fuel out of the Blok A (stage 2) and Blok I (stage 3) tanks in order for it to have enough TWR in stage 2 to achieve orbit with any substantial payload like a Progress or Soyuz spacecraft. Good news is the Progress and Soyuz spacecraft seem to have ample delta V to get circularized, transfer, etc. For a full scale solar system, since real-world data is widely available for this rocket you might try editing the configs for the engines and tanks to be in line with reality and see if it behaves any better.

I changed it to true and now it's giving me (exactly) 7 hour and 30 minute days. Which seems correct by the Rescale patch where it sets @dayLengthMultiplier = 1.25. I don't really understand where it was gettting 7 hours and 28 minutes and odd seconds before. I'll set it back to false to verify the behavior. Downside is the times reported by the kOS script are still reporting incorrectly. I'm assuming some fraction of the extra 1.5 hours is not being rendered somehow by kOS. The timestamps/actual passage of time seems correct. The calendar day reported by kOS seems correct too. Just that times can be off by 30 minutes (not 90 minutes like you might expect.)

Looks like I have it. Probably not configured correctly...

This is what has me interested as well!

Understood. Thanks!

How does this interact with Tundra's Space Center? I noticed this mod has it as a dependency. What does this mod give me beyond TSC?

How does this interact with KSC extended? I noticed KSC extended has this as a dependency. Do I need to install both? Or if not, why would I want to?

Mine too I got tired of thinking it was done only to come back and see a pesky spent stage STILL somehow keeping itself aloft.

If you play the game very long you will see it: decoupled boosters or other garbage in map view that dips well into kerbin's atmosphere only to emerge on the other side unscathed, and since they are on rails, their orbits never decay and they don't go away until you bother to go into the tracking station and remove them manually. How low can you go and remain safe?

In the part config files look for the section that configures my plugin code, e.g: MODULE { name = ModulePebkacLesController2 hasPitchControl = True stagingEnabled = True } and try changing stagingEnabled to false. Hopefully that will work for you.