HoneyFox

It is quite hard... (that's why KOS integration is important and let's look forward to it in future versions) I would: first plan a burn to remove horizontal velocity as accurate as possible. Then start to design the queue of landing process by placing a maneuver node close to the ground and I can then get the correct delay, then the hardest part comes: you need to calculate the throttle and time. I don't know if there's any useful tool for this, but i've only successfully landed on Minmus and only for once. For other bodies with bigger gravity, even a small error of calculation will result to: crashing due to early engine cut-off, get landed but with something broken due to high touch-down velocity, cannot get landed because vertical velocity turns to positive due to too much thrust, landed safely at first but the ignition doesn't stop at that moment and the vessel takes off again and then crashes back to the ground. My only case of success is because the landing process is a relative short one, and the gravity is really small on Minmus so i can almost use the simple equation of h=v*t+0.5*a*t^2, and then reduce that "t" a little bit to avoid take-off again after it's landed. On Minmus, 1 second of early engine-cutoff won't hurt much you know...

Oh? Perhaps @Dante80 you can try this... I'll take a look at this too.

Oh? I haven't encountered such situation. Three things i know: allowManualControl in ModuleAnimateGeneric: allow/disallow you to manually toggle the animation. DeployFxModules in ModuleRTAntenna: decides the indices of animation modules of this part to be played when it's being activated/deactivated. ProgressFxModules in ModuleRTAntenna: I'm not sure what it is but it seems like to be related to data transfer action, perhaps these animations will be played when the antenna is transmitting science data, etc. So if the animation is playing in VAB, it may because the antenna is set to be activated automatically (there is such a parameter that controls this behavior) while it has DeployFxModules defined, so it will even be activated in VAB and will then play its deploying animation accordingly.

I've made one for my personal use. but i don't know if it's allowed to post it here... And also, i made some small adjustment so that some dishes have separated their activation from their extend animation, so you can have them working while still in folding state, like AIES CL-1 medium dish.

Delayed staging is already supported. Just set up the delay first and then press space bar. A stage task will be added to the queue.

what? shouldn't that be RVEL+ not TGT+?

Hmm...talking about this... an even more crazy idea emerges... [DayDreamMode] Suppose that the satellite has two working modes: reliable / immediate. these two modes just work like TCP/UDP protocols. The signal may have chance of error. The reliable mode will need both endpoints to establish a link and handshake first, which will take several round-trips. Then when a message is sent to the satellite, it will do check-sum and send ACK to the KSC, or send some kind of NACK back to it if the check-sum is incorrect, which results to a re-send operation from the KSC, and if one message got re-transfered due to signal error, it will be put back with corrected timer value according to the time-stamp. For the immediate mode, there's no need to handshake, which means faster transfer speed. The message has check-sum also, andif it fails, the whole message will be discarded; if it passes, there's still a very small possibility (yes check-sum doesn't always work) that the message will be mis-read by the satellite and a completely wrong operation may be generated. Alright... [/DayDreamMode]

I don't know if it's my mis-look or not... but it seems like the flight computer's delay functionality has some problem *sometimes*. And... yes i'm aware that out-of-electric-charge may (or may not) pause the timer. No, in my case I'm not lacking of power at any moment. I enqueued a task which should start about 12 minutes later, but found out that after the time warp, when i got close to the maneuver node, the timer was still having several hundreds seconds left there... and the burn was totally happening at a wrong place/time. And this issue doesn't always happen, i just wonder what's wrong with my operation or with the plugin...

Ok, just updated the OP with information of that ullage engine pack.

Yeah, thanks for these wonderful parts. they will fit into this nicely:

hmm... it's just a built-in module in an engine to simulate several kinds of conditions of a successful ignition. but you can create a part with the ModuleExternalIgnitor module yourself, and surf-attach that part onto your engine. That will work, too.

Hmm... I have written a plugin (see my sig) to modify any part's any numeric parameter in VAB/SPH so this won't be a problem for me. Oh, not meant to promote my plugin here...

I've got a question to ask: does a probe consume as much electricity when idle as it does when transmitting data/commands? for what i know, these data/commands are carried on a carrier wave so i guess the consumption rate will be similar. But think about SPU, it need some more electric charge when processing commands/reading saved science data stored doesn't it?

is that altitude AGL or ASL?

Now all we need is - procedural engines!!! Well, at least some generic engines that can rescale in VAB just like those fuel tanks and their Isp/MaxThrust should be adjusted as well. The bigger the engines, the bigger the maxThrust and slightly lower Isp... After that, all main parts of rockets are rescale-able in VAB and can bring much more possibilities and reduce lots of RAM usage.

I normally start my gravity turn by offsetting about 5 degrees when vertical velocity is approaching 60~80m/s, after that i control TWR to be at around 1.6~1.8 and keep pointing to surf-velocity prograde. Usually with some adjustment of throttle, i can reach 10km~12km when my pitch angle is around 45~50 degrees, and that is a sign of having a good ascend path for me. If the pitch angle is out of that range, after the rocket has raised to upper atmosphere where the instability issue can be compensated by engine's TVC， i will pull up a bit with full throttle to extend the ascent if the pitch angle is too low, or pitch down to reduce some vertical velocity as well as reduce throttle if the pitch angle is too high.

And these stabilizing fins may get into partial stall or at least lose some of their steering effect when AOA exceeds a certain value due to being in the "shadow" of the rocket body, which reduces the stability even more, right? I want to confirm if this is somehow simulated or not.

I hope RT2 author can have an eye on this also, besides kOS...

If you have already unlocked the nodes where these parts are inside, you need to review these nodes and purchase these parts manually. (currently the purchase is free of charge though )

Oh my! that feeling of metal... mmmm, yummy!

Go ahead, since it has already been spammy with lots of mods installed, making it more spammy wouldn't hurt me at all.

Yes, a scaled Minotaur IV I think, with 4th booster inside the fairings together with the payload, though that shape is different from Star-48V. For the Scout, no, not tried yet. It looks so tall with its small diameter around 1.0m. it's probably suitable for sending light 0.625m probes to orbit. I'm a bit worried about its structure, hope that it won't wobble too much even when i have KJR installed already.

This plugin is very useful. Yesterday i used it to design a Minotaur Mun-Orbit-Capable Vehicle. One small issue I found though, that the nozzle of SRB become a bit ugly when i increase the radius / decrease the height. The rocket is basically a 1.5~1.75m diameter one and some upper stage are quite short, which makes the nozzle extremely flat. Is there any possibility to scale the nozzle's y-axis (height) when adjusting the radius of the booster, that will make it look better. Oh and in case any of you are interested in that design, here they are: 1st Stage: Thrust ~800kN, dV ~2400m/s, TWR 1.2~2.0 <- Lift-off stage, TWR is well controlled and reaches ~2.0G before burn-out. 2nd Stage: Thrust ~200kN, dV ~1800m/s <- Circularization stage, dV is still a bit lower than required but with good launch window, i can get to transfer point near Ap point. 3rd Stage: Thrust ~150kN, dV ~1000m/s <- Munar transfer stage, with decoupler+retro-booster+sideway-booster to forcibly cut-off for accuracy injection. 4th Stage: Thrust ~ 120kN, dV ~ 700m/s <- Munar capture and de-orbit stage. Payload: Monopropellant engine, dV ~ 1100m/s <- Finally touch down with this.

Alright, i finally fixed that issue. The game used to add one of my self-made part modules ahead of the part's stocking modules and RT antenna module, which caused the problem, and i then just add !MODULE[...] {} to remove that module first and add it back at the end of the RT's antenna config node. Now all things are working great. Oh and one thing i noticed, the stock medium dish has a list of DeployFxModules = 0 and a list of ProgressFxModules = 1, but it seems like they are inverted. I cannot get that dish to deploy when i activate it unless i exchange 0 and 1. That index 0 seems to be pointing to an animation which blinks the light and index 1 is pointing to the extend/retract animation.

OK.... about the animation issues, i guess i found the reason: I'm using the TweakableParameter plugin (link is in my sig) and i wrote a ModuleManager config file to add that module to all parts. And when i delete that config file, RT2's antennas are back to life (they will extend themselves when being activated). I don't know what's wrong with this, but I wonder if it's related to iterating modules when initializing parts... I checked the debug tool in game and see that in the database, these antenna parts have their config like this: PART { ... MODULE { name = ModuleTweakableParam ... } MODULE { name = ModuleAnimateGeneric ... } MODULE { name = ModuleRTAntenna ... DeployFxModules = 0 ... } } Does that "DeployFxModules = 0" means you assume that the first MODULE in this part is the animation module? If i manually change that to 1 will it solve the issue? And another question that may belong to author of ModuleManager, which i will turn to for help later: how are the order of these configs being parsed, is there any way to control the order?