HoneyFox

Second on this, and it should be not hard to write a plugin to implement this. Though there may still be some problem when we use too high time-warp, so that they cannot be detected passing atmosphere (where Pe is). This issue already exists in stock KSP though.

I remember that there's a plugin named Dynamic Warp that supports slow-motion already...

interstage base + fuselage fairing = adapter. interstage base + fairing = decoupler (with additional debris made though...)

if you use interstage base + fuselage fairings, that decoupler will not actually decouple so that works as an adapter instead. though that staging icon on the stage list is quite annoying when you have many of them.

Interstage Fairing Base + Fuselage Fairings = PROFIT!

1. Oh, I've just seen some screenshots and there's Joker name displayed there so i thought that was the name of the star. 2. If these stars are quite far away from each other, it should work by only tracking the last star in SOI hierarchy. e.g. If the SOI hierarchy is: The Galaxy(can use the current "Sun" as the galaxy center) -> Serious(star) -> ...(planet), then we will pick Serious as the light source.

Just consider the Sun as the center of a galaxy and Joker is the new "Sun" and that's OK. For solar panels, perhaps an derived/extended version of stock SolarPanel module will be needed for multi-stars: the plugin will provide a setting file which contains each celestial body's brightness (for planets it should be 0 or some very low values if you really want to, and for stars they can have different values depending on how bright they are), the calculation will iterate all bodies which have non-zero brightness value and sum these results (which are after ray-cast checking, angle modulating, etc.) up to get the final charge rate. the solar panel will also: have a context menu to allow players to choose Or automatically evaluate which star it will track, so that when a probe is heading closer to the star Joker, it can track the Joker and acquire more electricity.

Perhaps 3.1 or 3.2? I don't remember that...

Just a guess, will it accept sea launching platform? In previous version when trying to launch a rocket from sea launching platform the rocket will be spawned on the pad but once physics simulation starts for that rocket it directly shifted to the sea-bed level and then get destroyed by enormous buoyancy force immediately. Is it possible now in 3.4?

Looks like I mixed up the APU and another system which uses hypergolic fuel and catalyst to generate high pressure gas which can be uesd to start the engine.

Talking about Kerbalnauts having comm devices, will it be possible that we design a part which has electricity generator and antenna built in, use KAS grabbing mechanism to allow kerbbalnauts to carry it on their back? thus allowing them to send data without the need to get back to lander, they only need to be in the communication range of the lander so the lander can relay the data back to KSC.

Not intended to offend, but AIES has provided several good small engines that are suitable for surf-attaching 4x onto the bottom of fuel tanks.

I saw an unofficial released version of MM that claimed to have fixed that issue yesterday... perhaps in the MM 1.5 release thread.

No this plugin has no such capability and I don't know if there's existing plugin that supports this. sorry. Talking about editing cfg and restarting game, you actually don't need to do that, you just need to use the debug menu, there's a "Reload All" button in the "Database" page, which can reload all cfg files when you are at space center, this will take tens of seconds to reload all assets but it's definitely faster than restarting the game.

I knew about APU a bit, but it seems to be used usually during ramp start I guess. and it uses limited resource so that still sounds like a fuel cell (i mean you need to consume limited on-board resources to generate electricity).

Hmm, it can still be useful for aircrafts. and if it's extendable then it wont cause lots of drag when not used, which means it can be used for command pods as an emergency power supply too. This will be useful when using some kind of life support mods which consumes electricity constantly while you are trying to land onto the dark side of some planet with atmosphere (it doesn't matter if there's oxygen inside so maybe it needs a new resource type instead of IntakeAir).

If you could model a small fan (and if it can rotate according to your air speed), it can be made to an ElectricCharge generator which only consumes IntakeAir, which is similar to something in the front of ECM pods equipped by electro-warfare aircrafts in RL. (these fans are to generate extra electricity for these real power-consuming ECM pods AFAIK)

you''re right. i didn't realize this. but at least these fairings have drag and side-force-due-to-AOA themselves so i guess it's not too dangerous.

There's another type of design in which you install a decoupler on your engine, then use the interstage's 2nd uppermost node to attach onto that decoupler, then use 'h' 'r' 'y' 'j' keys to adjust the shape and install fuselage fairings onto the interstage plate. To make them look better, you can invert the interstage and install it below a stage, then install fuel tanks & engines onto its static node, then use those four keys to adjust the shape and install fuselage fairings to shroud them, only leaving the engine nozzle section to the outside. Here is a sample rocket that utilizes interstage for different purposes including (from top to bottom): partial payload shroud (it can also fully shroud the payload if you want to), fuel tank streamlining, normal interstage shroud, NTR cluster shroud and engine casing.

Yes, GC is kind of slow... That's why many games even written in C# or other managed languages still implement their own memory management, just like the old C/C++ way...

I don't know about how hard that would be, but if we simply use the same logic and similar UI used when in flight, these parts should be able to animate as well in VAB/SPH, perhaps the only issue is about updating attach node position, which has already been implemented by some other mods like ProceduralFairings/StretchyTanks, guess that these mods' source-codes can be good references.

Oh... a new version has just come out. Well... i'll still wait for that adjustment-in-VAB/SPH feature... which will give much much more flexibility to players.

I second that. There's no dish on our vessel bigger than those at KSC tracking station. So with more realistic communication distance/signal gain implemented, the tracking station should have a much bigger signal power which means, you should be able to establish a direct link to KSC with current antenna/dish performance without the need of relay satellite when you are doing interplanetary missions. Also, the maximum distance may be farther because KSC ground station should have more powerful dishes for communication than comm-satellites in orbit, though there's ionosphere factor, etc.

Hmmm... that will be handy. And one thing more is, currently the delay doesn't support "d" - day unit... so i have to manually multiple that with 24 to get a correct delay time, otherwise that part will be just ignored.

Two types of comm devices: omni antennas & directional dishes. Conditions of a successful link-up between two vessels: 1. The antenna/dish has to be activated, and you need sufficient electric charge for it. 2. The other satellite needs to be in line of sight to you. If there's any body like Kerbin, Mun, etc. between you, the comm link will be occluded. 3. The signal strength needs to be powerful enough. For this, RT2 seems to have several different criteria of judging whether the signal is strong enough or not. Better check other guys' posts in this thread. Conditions of having control: 1. You have a working manned command pod on-board, this will be Local Control (no signal delay obviously because that kerman is controlling the vessel directly). 2. If you don't have a working manned command pod, you then need a link routed to any command station. A command station can be: a) KSC. any vessel that has some certain part (by default: the stock 2.5m unmanned command guidance unit) AND has at least 6 kermen on-board.