toric5

according to the thermal sim, FissionFlowRadiators add heat instead of remove it.

so, when using mods like dmagic orbital science, you quickly get vast sums of data for a single experiment. If you want to transmit these experiments all in one go, you end up putting almost 1 ton of batteries that serve no other purpose than to feed the antenna for certain transmissions. I would like to be able to transmit over a longer period of time, as my EC generation allows. Now, I know that I can turn on 'allow partial tranmissions' on the antenna, but that leads to significant data loss. A fix for this could do one of 3 things: transmit data as available, not draining the batteries below a certain (tweakable?) percentage. have a 'transmission limiter' slider on the part action menu, allowing us to manually controll the speed between packets, similar to an engines thrust limiter option. simply remove the science penalty for partial tranmissions. This would be less than ideal, as one could not reliably controll a probe during a long tranmission due to constantly running out of electricity. I am comfortable with ksps cfg system and modulemanager, but have never touched ksp .ddl modding, nor really any sort of coding beyond bash/python scripting and automation. If no one else wants to give it a shot, could someone point me in the right direction for getting a linux toolchain set up and where to find documentation for ksp-spesific calls?

soo... try as I might, I cant recreate it in a sane craft... I swear I wasn't dreaming, but I could not get TCA to mess up during a quick mun mission using the same craft as last time... The only weirdness I found this time is that TCA doesnt always free the gimballs again after turning TCA off.

Ill see If I can re-create it with a stock craft... The question is, why does the stock SAS seem to handle my craft so mutch better?

During the manuver, the crafts PID seems to have too mutch gain, causing quite a bit of overcorrection with the engine gimbal. (the craft doesn't normaly need other controls because it can flip in less than a second with engine gimbal). Partway through the burn, a couple of things happen very fast... the spacecraft goes into a spin, the thrust cuts out, and the gimbal locks. Is it possible that the oscilation causes the crafts heading to stray too far from the desired heading, causing TCA to cut thrust in order to reposition? Is there any way for me to tune the PID? EDIT: After some more testing, It seems like the PID gets less agressive over time... That could cause an issue.

Ive noticed that sometimes TCA just decides to not use gimbal at all, even on crafts where it is the only source of controll authority. Am I doing something dumb, or is this a bug?

I haven't been able to find a clear answer doing a quick topic search, but should this mod work on a linux system? There were some things about it not working with OpenGL previously in the forum.

I basicly use near tea and MKS, and thats about it for large part packs.

I completely missed the atmospheric TWR... Anyways, PR incoming.

Ok, I think an ISP buff should be all it needs to balance with LH2s lower density. However, I did notice that in closed cycle mode, Project Eeloo has a TWR of 5.5, the best solid core NTR save for the Scylla. Just checking to see if this is intentional. Also, the stubber says it is supposed to be a high thrust engine, and yet it barely outperforms the Posiden in TWR, (3.3 vs 3 in LH2 only, 8.4 vs 7.5 with oxidizer.) (comparing it to the Neptune isn't much better.) However, its TWR is 275 seconds lower than other solid cores. Again, just checking to see if it is intentional, as the only advantage I can see is landing leg length.

Manual patch it is. However, I am completely clueless when it comes to balancing. Ill probably compromise between what the dynamic patch would do and the HL2/Ox patch for the NF areo jets. @Streetwind, anything I should be aware of? I don't have much experience with balancing. as for the multi patch, that is completely my bad. I was testing removing the multi-mode restriction, and the comments in the config reference the dynamic patch in a couple of places. I should have tested on a clean install first.

Ill try. I could remove the multi-mode restriction, but I think there are some possible edge cases where it could affect non-nuke engines. (I think. It might be safe...) Also, when did the LV-N get the patch to become a liquid fuel-LH2 hybrid? that patch needs to be applied after the dynamic NTR patch, so something like :FOR[zzzKerbalAtomics]. Ill pull request when I have something.

You cant launch to an inclination that is less than your latitude. You have to do a plane change.

Need a patch for the project eloo engine from NF aeronautics. the dynamic patch doesn't cover multi-mode engines.

The copernicus and nalatius say they cant be retracted in the description, but you forgot retractable=false in the configs. the halo (the giant circular blanket) has the opposite problem.