HoneyFox

Are you sure these satellites pointing to the rover on Duna will use cone-angle logic for those satellites orbiting Duna? I remember that someone have stated in this thread that only by choosing a celestial body will it use that logic, otherwise it will try to establish direct link to the target vessel *ONLY*. And rover is of course not a celestial body so...

Wait, component? PartResources are now components of a part? Frankly speaking i'm not familiar with Unity so i don't actually understand what "component" is in Unity... And thus i don't know how Squad change the design to such. Guess i need to grab some Unity Reference...

What i mean is dynamically switching. Right now you have to point your Kerbin commsats towards "Duna" specifically. But i want it to be dynamically decided by what vessel you are controlling, just like the "Active Vessel", but with some difference. Suppose if you have two rovers, one on Duna & one on Eve, and you have commsat network established on Duna & Eve. You can make all these satellites pointing towards Krebin, but you need to switch Kerbin's commsats direction if you want to control different rovers. (Yes i know if you have multiple dishes/multiple sets of satellites the problem can be solved also, but that's a workaround and is not about my topic) What i want to suggest is to allow Kerbin's commsats to target the "Active Vessel's Main Body", so that when you are controlling the rover on Duna, the Kerbin's commsats will automatically target the planet Duna and thus establish connection with Duna's commsat network (cone angle works only when pointing towards a planet). And if you switch to the rover on Eve, without the need to do any additional setup, the Kerbin's commsats will switch to target the planet Eve automatically, and since Eve's commsats are targeting Kerbin already (all non-Kerbin commsats have setup to point to Kerbin in advance), the connection will be established allowing you to control the rover.

Oh, i didn't add the toolbox (with replaceable ignitors inside) part into my package. because that's KAS's cargo box model... But you can make your own by picking a model and add two modules to it: KAS grab module which allows you to grab it on EVA's back, and the EngineIgnitorUnit module which allows you to replenish the ignitor count. And i don't know if anyone can help me to make such a model: a small toolbox that can be hand-held/carried on the back, may look similar to KAS's cargo box but with some stripes of yellow & black to indicate its engineering purpose.

Well, why not just provide an option for users to decide... if they have very good calculated rocket deltaV budgets, these rockets can even get into orbit with no communication at all. (though there might be some error of the orbit, but that can be fixed later when they re-establish communication) At least i've done similar thing when using a fully solid fuel rocket... you know solid rocket cannot be shutdown.

Just come to give you a feature request. And i think it will be very useful Can you add a new target named "Active Vessel's Main Body"? This will be very useful to establish interplanetary comm network. Suppose we have several commsats on kerbin's orbit, and they are all set to "Active Vessel's Main Body". Now if the active vessel is in the same SOI as these commsats, we can write logic to make them use "Active Vessel" logic to aim towards the current active vessel. If the active vessel is in other SOI like Mun/Duna/Eve/..., they will use "Active Vessel's Main Body" logic to aim towards Mun/Duna/Eve. Thus for example, if we have a comm network orbiting Duna, and we have a rover on the back side (relative to Kerbin) of Duna, we can set all Duna commsats to aim towards Kerbin, thus establish the Kerbin-Duna comm network interconnection. Now even if you are controlling the rover at the back side of Duna, the Kerbin's comm network won't aim directly to the rover but to Duna so that the interconnection won't break.

What if one type of fuel is exhausted while the other one still have some rest? especially if we have different ratios between main engine and RCS port which both use UDMH+N2O4. I would still lean to the generator way, and i prefer to use something like ResGen plugin so that it will only generate the intermediate resource when it's not full, thus won't cause constant wasting of the two propellants. But yes if you are going to write a specialized RCS Module in MFS that will be better.

Should work. it may take you 5~20 seconds to stabilize the fuel depending on the acceleration provided by your onboard RCS thrusters, The ullage simulation is based on acceleration and rotation rates. So either you get acceleration by main engine/ullage engine/RCS thrusters/some other guy pushing your vessel brutally/landed on the ground/aero drag during reentry (make sure you're heading towards the correct direction or it will push fuel to the upper side of the tank instead)... you'll get the ullage effect And that also gives you a hint: when you stage your rocket during ascend through thick atmosphere, make sure to ignite the upper stage soon after you lower stage burns out, otherwise the air drag will generate negative acceleration and you may not be able to ignite several seconds later.

Are you designing vehicle in the progress of your ModularManager config editing? That may cause some persistence issue (I mean, some values are stored into .craft file so even if you edit the config later, that old value will still be there). Perhaps you can try to remove the engine from that bugged vehicle and reinstall the engine again? plus, you can pre-check the number of ignitors from the part's detailed info box by right clicking on that part's icon.

You need a config pack for engines. There are three available AFAIK: One that comes with MFS' older version, one from Realism Overhaul and another from SFJack.

Ok great. Thanks to NK's great effort, the first engine that has integrated MFS+EI plugin comes out. Well that's quite a lot of config edit though. So this engine has three configs, when using LH2+LOX or Kerosene+LOX, you need to add some MMH+N2O4 into the tank also. If you choose MMH+N2O4, then everything is OK. P.S.:And i've been modifying EI plugin these days. so yes you can now see the required resources of an engine in VAB/SPH by mouse hovering on it. And i have to admit that the StretchyTank's codes are very good reference. I didn't even know that there are OnGUI, OnMouseEnter/Exit functions in PartModule before. If there's license issue here, then i guess i need to add some notes in my code.

Sounds very useful... And i also hate these numbers after the decimal dot.

Thanks. I thought that could be UDMH or HTP... so then if MFS could apply these resources onto the engine, we just need a small tank to add these resources into to make it work. For the ignitor mass, 50kg is a good reference, i will make that balanced.

@Lalwcat, @CoriW Sorry about that, it was a mistake made by me when I was writing the surf-attach detection logic for external ignitors. I set that ignitorRange to 0.1 for testing convenience so that the range check will always fail, while surf-attach logic can override that. And i forgot to undo the value before i made the package.

Do you know what types exactly the hypergolic fuel is? I'd love to use exact resource type instead of something that sounds too generic, especially under MFS+RealFuel environment. Compatible to ModuleEnginesFX shouldn't be too hard if it's implementation is same as ModuleEngines in the engine part. but it will take some time to update. One question i wonder is if it's possible that one part has both ModuleEngines & ModuleEnginesFX modules. that might cause some trouble of identifying engine modules correctly. Talking about ignitor count as a tweakable, i need to find proper moments to increase/decrease part's dry mass. For the mass, there should be some kind of base mass so the total mass for ignitor will be baseMass + massPerIgnitor * ignitorCount. Though i don't know how it is in RL. Do you have any advice?

I may have missed some of these. Guess i might be using some earlier version... Anyway, I've pushed these config files onto GitHub. You can fork it and submit your edit.

Nope, the stretchy tank's dry mass is only 0.008 ton while the 3960 unit of XenonGas weighs 3.9 ton, I wonder if this is correct... The tank is: KI-625 Stretchable Fuel Tank, size is: 0.625m * 0.075m. And i saw a resource definition cfg in MFS folder modifying XenonGas density to 0.001 with comment "at 34 atmospheres". maybe it's out-dated... EDIT: Just checked the latest version, it doesn't have that file in the old folder and it has XenonGas' density 0.000005894. However in another folder named "Fixes" there's a config that defines XenonGas' density to 0.001. So what value is actually used? EDIT2: Ok this modification totally renders ion thrusters unusable... the drop of density results to consuming more XenonGas at a given thrust, that's OK... but the EC usage got increased dramatically too... I wonder if i need to adjust the propellant ratios. EDIT3: NearFuture's DG4S: 3000N * t = m * 23200 * 9.8 m/t = 0.013195kg/s d = 0.005894kg/x x/t = m/t/d = 2.238706/s e/x = 167.07/0.1 = 1670.1 e/t = x/t * e/x = 3738.862885/s Squad's IonEngine: 500N * t = m * 4200 * 9.8 m/t = 0.012148kg/s d = 0.005894kg/x x/t = m/t/d = 2.061031/s e/x = 12.0/0.1 = 120.0 e/t = x/t * e/x = 247.323710/s Even the stock ion engine will now need ~250 EC/s when under full thrust... Guess how many solar panels do we need to install? Perhaps we need realistic ion engine thrust too? like... 0.005kN? Then it will be completely unusable unless we can implement a plugin to allow adjusting orbit velocity during time-warp...

Eh... I just got an issue... Two resources: XenonGas & Argon, have much bigger maximum volume than others in one same tank. (i don't know if it's because i'm not using the latest version) For a small tank that has total volume of 26.4, other resources can only use 26.4 while Argon & XenonGas can use 5280 & 3960 unit of volume... Which leads to a super heavy tank (10+ tons) with tiny size (even much smaller than stock Oscar-B tank)... And for Argon, the NearFuture mod pack has ArgonGas resource, i really agree that we should build up a resource name list so all modders can follow.

Ah, remind me of this website. Somebody may have posted that long before already... http://www.projectrho.com/public_html/rocket/enginelist.php#id--The_Drive_Table Inside you can see LANTR having ~650s Isp using LH2+LO2 mode while having 940s Isp in pure LH2 mode. So that can be a good reference.

Testing it. So far so good. I can't wait to have the new RSS+MFS+Stretchy combination working again. Oh and i'm interested in various configs for NTR... Right now LH2's low density pushes me to design rockets with very large fuel tanks, usually not easy to design if we need to consider aerodynamic stability issue with FAR.

Well i wonder if i can hack to stop the game from setting the main throttle to 0, just like how MJ & RT2 do. (and hey won't that even cause more compatibility issues?)

Oh almost forget... the latest version which contains a config.xml for ullage simulation will be released once i finished checking bugs and preparing plugin package.

So you mean, you want the ignitor count to be tweakable? Currently ignitors don't have mass and i don't know how to adjust weight to the part correctly. For helium purging engine, will it be acceptable to you by making helium as one of IGNITOR_RESOURCEs(guess this should belong to NathaneKell if he's writing auto-config for EI), yes the ignition sequence will be a simplified one compared to the one in RL but i think that's ok. Right now those ModuleManager configs in the plugin pack have setup several small engines to have nearly unlimited ignitions (~200 or so) already, they usually use EC or LiquidFuel+Oxidizer(to emulate engines that use hypergolic fuel), this will also become better once NathaneKell finished the auto-config: e.g. if you choose MMH+N2O4 as the fuel used, the ignitor will be automatically adjusted to use MMH+N2O4 as IGNITOR_RESOURCEs. About the name of "HypergolicFluid", it just works as a "placeholder" and it will no longer be used when used with MFS which completes integration with EI. Something like MMH+N2O4, UDMH+N2O4, etc. will replace it I hope. P.S.: Great. I've just tested EI in 0.23 and it works well (even with the new thrustLimiter feature). I haven't tested it on RAPIER (guess that it won't work because it uses a different class "ModuleEnginesFX" instead of "ModuleEngines") but perhaps i can just ignore this engine since it's a very special type. plus, i haven't give any ignition limitation to other jet engines before, so...

everytime there's an update of KSP, there comes the busy hours of all modders.

Yep. 0.23 is just coming out and i'm still downloading it. it seems to have some nice features like tweakable fuel amount/thrust limiter etc. Guess there's no need to re-invent the wheel again for these functionalities which i was planning to integrate into MFS. So the schedule will change and i will first check EI and several of my plugins to see if they work in 0.23. Will take some time though, and you can also try to test EI plugin in 0.23, there's quite some changes about engines (like RAPIER) in 0.23 so, yeah it's very probably that my plugin needs tweaking. Also i'm considering if EI needs to provide something as tweakables.