HoneyFox

Sounds like a LANTR working in LOX mode... higher thrust with lower Isp than NERVA... a good trade-off between acceleration and efficiency. (reference: http://www.projectrho.com/public_html/rocket/enginelist.php#lantr)

Is this plugin creating joints around the rocket by the assessed radius when a rocket "OnFlightStart" / is docked to another vessel? haven't checked the source codes... just my guess.

Ah, that would be nice.

Hey, why not interconnect the rate of generating Eurekas with the stupidity of the kerbalnauts inside the science lab. This may then be the first mod that utilizes the properties of kerbalnauts... and this makes sense too: cleverer kermen can do science more efficiently. And thus you may want to send clever kermen onto the science lab with the risk of killing them if your rocket design is not robust enough... It will be even more interesting if we also use some mods like TAC or IonCross Life Support, thus making these clever minds more precious.

By this: engine.SetRunningGroupsActive(false); Though i don't know if any side-effect will be brought in, till now it seems working quite well.

Engine Ignitor V3.0 has just been published! See OP for full introduction and download links. Change-log: 1. ModuleExternalIgnitor can have IgnitionsAvailable & IGNITOR_RESOURCE limitations too, similar to ModuleEngineIgnitor. 2. Simple ullage simulation implemented. You need to take care of this before you want to ignite your engine especially after you have coasted for quite a while or you have adjusted attitude of vessel a lot. Several measures can be taken to solve the ullage issue. Fuel flow state will be displayed in the engine's context menu. 3. Several bug-fixes. Including the engine flame keeping displayed after a failed ignition, ignitor count quickly decrease to zero when IGNITOR_RESOURCE are depleted, etc...

+1 with this... such plugin used by multiple mods should go to GameData folder as a common base, thus easier for players to keep it up-to-date. Otherwise we need to copy the plugin to lots of mod folders, which is quite tedious, much tedious than manually checking the version and judge if older version should be replaced.

It is doable by: 1. Create a small engine which doesn't simulate ullage to emulate a venting device. (I may need to add an option for this later, by default the option will enable the ullage simulation) 2. Install several of them around the main engine, You'd better use an action group to toggle both the venting devices and the main engine. 3. Setup staging so that they will be activated before the main engine. 4. Increase throttle to execute venting for several seconds. 5. Use action group to shutdown the venting devices and starting the main engine at the same time. 6. If we need to re-ignite later, simply use that action group to shutdown main engine and activate venting devices, and then go back to Step 4. EDIT: Ah, i read your post again... you want a module installed in engine to be able to generate small thrust even when the engine is not activated right? Well...that maybe doable, but IMHO it's not very necessary if we can take the measure above. but... i will think about it later.

The vessel.acceleration's magnitude will be nearly 0 when the rocket is landed, and will be 9.8 when orbiting, so all i need to get the correct reading is to use vessel.acceleration - FlightGlobals.getGeeAtPosition(vessel.GetWorldPos()). Note that the getGeeAtPosition will get a negative direction so i need to reverse it. After that it will be converted into engine's local transform. This will work for all situations except 5x+ time-warping. For 5x+ time-warping, the vessel.acceleration reading is quite strange, so i changed to use either 0 when orbiting or -FlightGlobals.getGeeAtPosition(...) when landed/splashed.

stack separators may not be enough... it only gives a push when separating, can push most of fuel to the bottom of the tank, but may not be enough to remove gas bubbles in the fuel completely i guess... spin on pitch/yaw axis already works. And is usually used as an emergency procedure. (I've just done that once yesterday night when my craft had been coasting towards Mun for several hours, and i forgot that the ullage would fail the lander engine ignition... oh that was a real busy moment, luckily i made it by pitching quickly (i didn't bring RCS so that's the last resort) and successfully ignited the engine before it's been too late.

Alright... i've seen too many engines exposing much more than in RL to the outside...

Actually i like that there's fairings for the engine, which is seldom seen in KSP rocketry mods. although i can build one with Procedural Fairings plugin for any engine...

Ok, I'd like to give some update info in case any of you are expecting... The ullage simulation is under way, right now the vessel can read acceleration correctly in its local transform's space. it can also handle time-warp correctly now when landed/splashed or coasting on orbits. The simulation is nearly finished, and some parameters are being tweaked. The fuel flow will become stable when we have sufficient acceleration while it will go bad when you roll the rocket too much or after you coast the rocket for quite a while. I'm still finding a way to show the fuel flow stability to players... probably i will show it also on the engine's context menu so players can watch that during ullage motor burning and judge if the main engine can be started. For the ullage motor, there are several ideas: 1. just use the small solid "separatron" boosters, but it can be used only once, which may only be suitable for LKO/KTO/TMO rocket's upper stage. The upper stage can use the first stage's acceleration to start its first burn to complete the circularization and the separatron ullage motor can be used to start the GTO/TMO transfer burn. The GEO or MOI burn will then be executed by the payload's own engines... 2. use a small engine to consume the propellant (same as the main engine) and exhaust with a low thrust & low Isp to simulate venting boiled propellant, may only suitable for light payload, otherwise the thrust may not be enough to generate sufficient acceleration, but it consume the same propellant which means no extra resource tanks are needed. 3. use a small engine which uses MonoPropellant or HypergolicFluid as propellant with higher thrust & medium Isp, suitable for heavier payload, but has limited times of burn due to limited resource. (it can actually be replaced by some specialized linear RCS ports, but it may be quite uncomfortable to control these ullage motors with RCS controls, right? or maybe not?)

I don't know if it's possible to take experiment as a resource, then convert it to "material result" and "data result" with ratio 9:1 for example... and then the data result can be "consumed" to make science points for both transmitting and recovery... while the material result can only be converted to science points when ship is landed/splashed on Kerbin's ground/water.

I've just had the similar thought yesterday night... A way to make a space station useful in career mode: send cargo ships carrying experiments onto the station, do experiments on-board and then get the result back to Kerbin. But i think perhaps we should be still allowed to use antenna to transmit experiment results back to the ground, but with a reasonable discount. This may sound meaningless if the space station is orbiting Kerbin, but if the station is orbiting other planets or even the sun, it would be much expensive to send the cargo ship back to kerbin, so here comes the trade-off. Also, a station orbiting other planets should also get some more science points i guess?

Well talking about that bug, the plugin logic is now working but the engine's fx is still out there due to KSP bugs. I don't know how to disable that though... It will really confuse people a lot.

Ok... I did some tests and reproduced the bug also. By some further debugging, it seems to be quite related to KSP bug though: The plugin will detect if we have sufficient resources to ignite the engine, and it will then call "Shutdown Engine" event of the engine if we don't, just like if you click it in the context menu / via predefined action group. However, the engine's "engineShutdown" parameter is still false, leading my plugin to judge that the user is still trying to ignite the engine, thus it keeps checking and decreases the ignition count repeatedly. I may need to find another way to judge whether the engine is activated or not, probably by judging the Activate Engine/Shutdown Engine events themselves... which one of them is visible while the other one is not... Hope that this solution can solve the issue. EDIT: OK. finally got it fixed. The solution of checking whether shutdown event is active or not finally works. And head back to ullage simulation, I've got some issue of collecting vessel.acceleration, it seems like it will frequently return (0,0,0) to me instead of correct values, and the correct values jump frequently as well. I guess i need to add some simple logic to interlope/filter the noise to get some steady reading of the acceleration. EDIT2: Ok, turn out that i didn't consider other vessels near the KSC, that's why i get (0,0,0) reading because they are stationary. Now the ullage simulation is under way and looking good.

Thanks for the new test video. I'll try to fix this bug once i get back to my home computer.

Good video. I can even see the ignition count decreasing one by one during the final ignition (which should fail) is commencing. A strange thing i noticed in this video is: the Active Engine button replaced the Shutdown Engine button, which indicates the engine should have been shutdown already. That's correct, it should be shutdown by plugin. but for the ignition count decreasing, the logic should only run when the engine is activated... That is very strange, i even wonder that this bug has some relationship with the KSP bug. Could you try another test in which you push your throttle more (like 25%) instead of just a little, and check if both bugs disappear. I cannot access my home computer right now, so my local tests have to be postponed for several hours.

It's kind of weird... by design, once the plugin detects that the engine is short of ignitor resources, it will reduce ignitor by 1 and then shutdown the engine. Can you reproduce the bug and see if the engine is still activated by right clicking on the engine and see if there is "Activate Engine" or "Shutdown Engine" button in the context menu? or perhaps your engine cannot shutdown once ignited like solid booster?

I've published my config pack onto OP. the pack also contains your stock config with some small edits. For the first bug, i need to check it. I remember that i have some codes to deal with it, but it seems to be broken again. For the second bug, well that should be one of KSP bugs.

No problem for that. This booster's curve actually is set according to the RL one. it has a section to reduce thrust during Max Q, though it may not be suitable for all rockets/shuttles because the curve is a static one while rockets/shuttles' TWR may differ.

The thrust curve may help this a bit. During the ascend, the CoM is shifting from the external tank towards the shuttle gradually, if all engine/booster's thrusts are static and don't change their directions, the shuttle will tend to pitch up. And now the booster thrusts will go down due to the curve setting, thus relief the pitch moment the SSME is required to compensate.

I've just written NP/KW/KOSMOS/AIES's configs... need some time to tweak them... And then publish that onto this thread. Also, I used your config and changed something, like NERVA not needing any resource to ignite, and almost all engines have device limitation (depreciation) so that even if you have sufficient HypergolicFluid, the engine cannot ignite unless you use the IgnitorUnit to replace/reload it. The idea of a HypergolicFluid radial tank is good. I'm planning to modify one of the AIES's RCS tank for this, too. That tank is a tiny sphere tank, quite suitable for such job.

Alright, i'm just trying to avoid reduntant/duplicated work. it would be a little bit waste of time if several people create different configs for one same mod pack. (there's one exception: they provide configs of various difficulties for people to choose)