HoneyFox

I know this might de-rail the thread a bit, but i want to know whether you have plans for Real Fuels so that those fuel tanks especially cryogenic ones will emit water steam particle fx to give more immersion? it will also work as a hint for us to know what tanks will slowly lose fuel inside I guess...

Should be working if you set proper coefficients & reverse options into them. Currently these tweakables are only available in VAB/SPH, i guess it might be better to allow user to control these "Reverse" toggles during flight too... One more tweakable that i'm currently trying to add is the maxGimbalRange, which i think will be quite useful if user doesn't want over-steering when using some engine that has quite large gimbal range (like KOSMOS' engines, they normally have 3~4 degrees of that, quite big compared to stock engines'). And this will also be tweakable during flight because IMO this is just a constraint to the flight control system instead of engine's capability limitation. EDIT: Ah, the TweakableEverything plugin seems to already have GimbalRange and GimbalLock as tweakables, I wonder if it's necessary to do that again.

Hi, there're several types of gimbal extensions already, but i still write this little plugin and i think utilizing the tweakable system is good for users to have more control. It provides: Control coefficients on all three axes. Including reverse control. This allows single-axis gimbal to be achieved to emulate some of these vernier thrusters in RL, and allows roll control capability when using twin engines that have all-direction gimbals or with 4 single-axis vernier thrusters. Max gimbal angle tweaking during flight. Test capability in VAB/SPH. Roll control by these two engines. The tweakables. It has test capability so you can check if your settings are correct in VAB/SPH. (some new options are not displayed in this screenshot) Single-axis vernier thrusters. Yaw command is given and only two of them are tilting. The same 4 single-axis vernier thrusters. Clockwise Roll command is given. Watch how these thrusters turn. Two of these four vernier thrusters taking pitch-up action with the main engine that has no TVC capability. Download link: V0.2.1 https://www.dropbox.com/s/pzh84u9brz94ow7/TweakableGimbal%20V0.2.1.zip Source: https://github.com/HoneyFox/TweakableGimbal/ Light User Note If you don't want so many options for tweaking, you can try the light-weight version of TweakableGimbal (it provides GimbalRange & ReverseControl function) comes within TweakableEverything mod made by toadicus. His/Her mod also provides lots of tweakable options in other modules like solar panels, docking port, etc. Link is here: http://forum.kerbalspaceprogram.com/threads/64711-0-23-TweakableEverything-For-all-your-part-tweaking-needs NOTE of compatibility issue Do NOT install both TweakableGimbal plugins in your KSP, choose the one you want and delete the other one. If you choose to use my plugin while you still want other functionalities provided by TweakableEverything, toadicus designed his/her mod so that these are separated libraries for different types of PartModule. Thus you can pick the "TweakableGimbal" one out of them and delete it. Changelog: V0.2.1: Fix a bug which occurs if you're not launching the rocket from VAB. V0.2: Change the coordinate system of attitude input/output so that it can now work well with symmetric parts. Gimbal range becomes tweakable. Reverse control becomes available if the related coefficient is non-zero during flight. A README file containing several useful hints is provided. It can easily achieves: roll control & single-axis vernier thrusters. V0.1: Initial release. This plugin uses Module Manager to automatically add the module into all parts that has "ModuleGimbal".

Perhaps you can make it automatically switch to KillRot mode when the delta V is smaller than a certain threshold (a bit bigger than the threshold that judge the completion of a maneuver), then use RCS thrusters to do the last bit of tuning. Of course such procedure would be better to have a switch so users can decide whether they want this or not.

Hi, thanks for the suggestions and feedback about the ModuleEnginesFX wrapper and that "IGNITED" bug. I will see if I can fix it, though this bug won't give any real trouble. You mentioned some sort of manual mode that both engine activation and shutdown require manual control. The design is a good one and similar ideas have been raised earlier (also in this thread). While this might work well if you always control the rocket manually (it will still bring some trouble if you cannot shutdown the engine at accurate time), I'm quite worried about that if used with autopilot system like MechJeb or RemoteTech's flight computer, the engine which has a non-zero minimum thrust won't be shutdown by the autopilot system and that will cause more trouble than benefit. One suggestion to you if you really worry about accidentally shutting down the engine, you can make use of the "ThrustLimiter" feature introduced in 0.23. Say if you put your throttle at 10%, which i think is safe enough, you then adjust the ThrustLimiter to around 20%, you will now actually have 2% of thrust. And i think that can provide enough accuracy. P.S: Talking about engines that have non-zero minimum thrust, the "Real Fuels" mod currently owned by NathanKell has lots of engines with non-zero min thrust. That gave lots of trouble for these autopilot systems so he implemented a feature that will reduce the engine's min thrust to 0 temporarily (not by shutting down though) when the throttle is totally 0. So yes it still turns the engine into NOT_IGNITED state when the throttle is accidentally set to 0, but perhaps there would be no perfect solution unless all these autopilot systems are designed to really shutdown the engines after the execution of a burn.

Wait, I'm confused, are there two or three versions of stock-alike engine configs? i thought you were all maintaining the same version before...

It looks like that some transform (either that jettisonName or that bottomNodeName) that the ModuleJettison needs cannot be found. and perhaps with the transform == null, the force is automatically applied by unity engine in world coordinate system. Just my guess.

Aren't Skylon's wings tilted a bit so that the wingtip is higher than the wingroot? this will help a bit also... Besides that, perhaps it does needs some pitch-up moment, especially due to its length, relative small canards & relative small wing areas.

I've tried some other gimbal module, "SmartGimbal" IIRC... but i was quite disappointed to its performance on one of my design that resemble Ares I (yes, i was using that 1:1 replica shuttle solid booster mod). The gimbal strangely turned quite a lot when i was giving roll channel input. I wonder if it's because there's slight error of the x/z coordinate of the thrust transform, that leads the SmartGimbal to turn quite a big angle just to generate slight roll moment, while at the same time making the rocket to pitch/yaw wildly. I would hope that a gimbal module can provide three tweakable coefficients for each axis, so that you can set to 0 if you don't want it. Or even negative value if you want to invert that.

I remember this has been discussed before and in that discussion someone said that the "pufff..." or "kssss" sound of RCS might not be loud enough for crews to hear even though there is media (vessel hull, air in cabin, etc) to transmit. instead the sound of internal devices of RCS like valves or pipes might emit some sound that crews can hear.

I'm thinking if we can give an alternative SRB part with TVC capability, but it needs an additional resource like N2O4 to make TVC gimbal work, just like the one on Titan III C's... Nah, ModuleGimbal doesn't seem to have capability to consume any resource. whatever...

I met a "bug" with RSS. First, I use RT2, and i haven't established lunar commsat network yet. And I landed an unmanned moon lander sometime earlier on the moon (so it must have a clear LOS to the earth, though the location is quite near the edge). After several other missions, I want to go back to see it, only to find that it's now at the back side of the moon (the longitude shifted for about 20 degrees or so), which means i cannot establish communication link directly. This is strange, shouldn't the moon be tidally locked to the earth? why would this happen?

So perhaps we need to change the way NuclearFuel/Waste (BTW why we don't have capital "N"?) density & volume are used. We might need to use milliliter(or even smaller one) as the volume unit for them, and reduce the density accordingly...

I have this issue too. The ModuleGenerator seems to be broken. Even if i change it *NOT* to be alwaysActive and later switch it on by context menu, the efficiency of it is always 0.00. And i cannot get any electricity which then results to lose of control of my unmanned ship.

And i want to inform of you that EI has completed the support for ModuleEnginesFX by writting a wrapper to populate function calls/member access. (Though not tested yet) And... i'm not hastening you. I know this might need some time (e.g. different ambient pressures give different shapes of flame FX, different fuel types give different color/texture/transparency of flame FX, etc...) but that indeed will be gorgeous.

It will. But this should be considered as an emergency operation if no other better solution is available. Plus, this measure will make the engine easily go flame-out shortly after you ignite, because the fuel will get into an unstable state when the upper part of the fuel moves down and splash into the bottom part of the fuel. To avoid this, apply small throttle for the first several seconds and gradually increase the throttle.

I think you can simply use !MODULE[ModuleEngineIgnitor] {} to remove any existing one before adding the one used by the default engine configuration of MFS. That's what i'm doing with my own local MFS' stock-alike engine cfg.

Ok. The first three options are quite self-explanatory. X means radial, Y means longitudinal. NaturalDiffusion means, the air pocket will spread naturally with time. TranslateAxial means accelerating forward/backward. this is the main factor for simulating ullage motors, it controls how fast the air pocket will move along the longitudinal axis. TranslateSideway means accelerating up/down/left/right. Similar to above, but is not simulated well TBH. RotateYawPitch, controls how much the centrifugal effect will make fuel move to top&bottom part of the fuel tank. RotateRoll, controls how much the centrifugal effect will make fuel move to the side wall of the fuel tank. So for a more forgiving ullage simulation, you can consider increasing the TranslateAxialY, this will reduce the acceleration time you need especially when using low thrust RCSs.

In the next release i will add some information about it, just like the ignitor resource requirement display in the current version (V3.1).

If the acceleration is too small, it might be overrun by natural diffusion rate. (perhaps the rate is not forgiving enough) And, plus, you cannot ignite the Mainsail without assistance from an external ignitor (integrated in launch clamp).

Ah, that one, i wouldn't call that... small

I've read that 0.0001g acceleration too, but EI does demand much more than that. perhaps some coefficient (stored in the config.xml) tweaks are needed.

Hi. 1) yes. if the temperature is higher than that and you cutoff the engine, it will be in HIGH_TEMP state, before the temperature drops you can reignite without consuming ignitor / resources. 2) it will somehow simulate gas pocket distrubution in the tank. acceleration & rotate rates will affect it. So yes, if you are deaccelerating with prograde attitude due to aerodrag, it will spoil the fuel flow (they might stick to the top). In next release, MFS + EI integration might give you pressurized tanks & pressure-fed engines. In current version, several engines (e.g. these stock small radial engines) are made to ignore ullage issue. they are best choices for multi-restart ullage motors. (RCS thrust might not be enough, and solid boosters can only work once obviously ) 3) Umm, I'm not good at modeling at all. so for that eye-candy sparks-sprayer... well. plus that might be just fuel burner to burn these vented gasous fuel before launch instead of ignitor.

Ah... for those actions (shown in action group editor) or events (shown in part's context menu), they are stored in a list in part modules(including modules implemented by 3rd-parties plugins, as you stated "future parts"). So the Jebnix plugin can of course scan these lists to acquire all available actions/events. However, Jebnix plugin will never be able to know what an action mean, to invoke which action/event should be decided by users, so Jebnix needs to provide some kind of debugging tool to list all these actions/events so that users can choose which one to invoke. To make things more understandable. Here is a simple process: 1. User enter something like: List part(...).module Jebnix returns names of all part modules in that part, might be something like this if used on an engine: ModuleEngines, ModuleGimbal, ModuleAlternator. 2. User enter something like: List part(...).module(ModuleEngines).action Jebnix returns names of all actions in that part module, might be something like this if used on an engine module: active, shutdown. 3. User now know what choices are available. And he can write something like this in his script: Invoke part(...).module(ModuleEngines).action(shutdown). Hope that i made it clear to you.

I don't think KSP has provided interface in FlightCtrlState to individually command a reaction whell / an engine to adjust attitude. The control is a global one and all parts will try to follow that if possible (has reaction wheel / engine has gimbal) and if allowed to (reaction wheel enabled / gimbal is freed)