HoneyFox

Nice. I will try that. And later I will release my own cfg for NovaPunch engines. For some other major mods: KW, AIES... are you planning to write configs for any of them?

Thanks a lot. I was trying to find some time to do such module manager cfg edit... but finally the debugging took all these time. And two suggestions (though we can edit ourselves anyway): 1. we can still have some engines that are not ignited by hypergolic fuels, especially those engines with low thrust, normally used on probes, orbiters or small landers, etc... for these, you can consider using ElectricCharge as the ignitor resource to simulate a spark-plug. and that gives another usage of electricity. 2. some of the biggest engines (like mainsail) can be set to only ignitable by external ignitors, which can be installed on launch clamps. This will give players some requirement of their ascend path/gravity turn. EDIT: Ah, just saw that the external ignitor has been installed into the launch clamp. And also the Mainsail doesn't carry the hypergolic fuel itself, rendering it as an engine with no self-ignite capability. EDIT2: Oh, i see the type1 for Mainsail. Well done. And generally speaking, most of engines in your config have quite a lot of hypergolic fuel for more than 20 ignitions. This seems a bit too simple, but i understand that it shouldn't be too tough for casual players.

If you consider the history versions of KSP... well we did have Mk1 Pod long before we had un-manned probe. This is not human's space program, it's Kerbal's.

Forgot to mention, this result was achieved with FAR. So it may have some reduction if you don't. Perhaps 25~30 tons?

Alright... maybe this can be implemented with Mission Controller... i would ask if the author can add this feature...

Can we have passive mission that will gain science points instead of cash (or maybe both?) over time? that would be perfect for sample-return missions...

Currently the science points awarding design is a bit weird IMHO. We can actually get some ideas from the Mission Controller plugin, remember the passive missions? So the point is: If we use comm antenna to transfer data back to the KSC, the logic can follow the current design. the reward of science point will be one-time, instant one, and can have diminishing returns also. However if we successfully return the sample to Kerbin, we can design the logic so the R&D center will start to take some time to research the sample and gain science points over a period of time (like several kerbin days or a bit longer if the research content is very complex & profitable). We can even design a research queue so that if we don't have sufficient employees in R&D center, the research will have to be started one by one. The rate of gaining science points will be slower than the comm-antenna way, but scientists can access the sample directly instead of just having limited on-board sensors to get limited data, they can use more sophisticated devices/equipment to check the sample and thus, much more science points will be gained at last.

Lots of these features seem to be possible by Modular Fuel mod. They can modify ModuleEngines' parameter including fuel types (if we need to consume Xenon for pressurization) and responseTime (if we need to simulate a slow start) etc... I will do some tests about the ullage some days later, it may be quite interesting in KSP actually. I should keep in mind that i need take some RCS fuel and RCS ports with me to test the ullage state values under different situations... and then get some tweaking of these coefficients. And so i would like to know some more info, like how long time does ullage burns take in RL. Some of you have mentioned above that it will take several seconds, which is longer than i thought before... oh and i guess this is also affected by the length of the fuel tank, these bubbles will take more time to reach to the top of the tank if it's higher.

I remember there's another game named World of Goo...

Im just wondering ... why don't the KSP devs set the default values of the TechRequired to "basic"... i need to check whether module manager can judge if a parameter is absent in a part config. EDIT: Checked both Module Manager and Module Manager Extensions plugins, no they don't seem to support adding a parameter when it doesn't exists... And it may be easy to add that to MME's code base.

Does that mean we will have some trouble when we want to install some mods (mods that have set their parts' TechRequired settings) after we started a career mode game, because the tech tree is "solidified" once the career mode game starts? I mean both playing stock KSP and playing KSP with this mod.

I wonder... at what moment can a plugin get into and do the update job. Because you have to update that right between the vanilla KSP UI update codes and the render calls. Otherwise your modification won't affect that.

No need to do that. Do the divisions in double type form and floor() it to a small integer for year/month/day/hour/minute/second units.

I thought that it will detect the part attached to the nose-cone's only attach node and the nose cone will decrease that part's drag coefficient dynamically but now it seems like i guessed wrong.

Some other guys can write a config file for his/her mod. Something like this i guess: TECH_NODE { name = ... parentNode = ... ADDITIONAL_PREREQUISITE { name = ... } // I don't know if the current tech tree supports multiple prerequisites. ADDITIONAL_PREREQUISITE { name = ... } requiresSciencePoints = ... UNLOCK_PART{name = ...} UNLOCK_PART{name = ...} } And this sub-tree will be loaded and added into the entire tech tree.

Any possibility to support incremental tech tree nodes for 3rd parties mod packs? therefore other modders can add sub trees onto it and set customized tech for their own parts.

Doesn't the 3rd stage (and also Briz) have four small nozzles that ignite before the main one for several seconds?

Lots of info though they look quite complex... and i don't think we need to simulate all these mechanism of engine's turbopump, gas generator, heat exchanger, etc. Oh, and talking about a simple ullage simulation, i got a brief design. I will use two sets of range to represent the gas (bubble) state in the tank. One for vertical position and another for radial range. Vertical position: -1.0 ~ 1.0 represents the bottom to the top. For a fuel tank of a rocket before lift-off, the vertical position will be 0.8~1.0 which means the bubble is at the top of the tank. Vertical position will automatically tend to change to -0.9 ~ 0.9 to simulate the natural out-gas. it will tend to change to 0.8~1.0 when accelerating forward(gravity belongs to this case) and -1.0~-0.8 when accelerating backward. to -1.0~1.0 if side acceleration exists. to -0.1~0.1 when pitch/yaw rate exists. to -1.0~1.0 when roll rate exists. Radial range: 0.0 ~ 1.0 represents the center to the tank wall. For a fuel tank of a rocket before lift-off, the radial range will be 0.0 ~ 1.0. Radial range will automatically tend to change to 0.0 ~ 0.9 to simulate the natural out-gas. it will tend to change to 0.0~1.0 when accelerating forward/backward (gravity belongs to this case). to 0.8~1.0 if side acceleration exists. to 0.0~1.0 when pitch/yaw rate exists. to 0.0~0.2 when roll rate exists. The probability of a success fuel inlet will take both values into account. to list a few: if the lower bound of Vertical position >= -0.8 it will be successful because we have quite much amount of fuel at the bottom of the tank. if the lower bound of Vertical position < -0.8, we need to check Radial range. If Radial range's lower bound >= 0.3, it will be successful because we have sufficient fuel near the inlet. ... I don't know if this design can simulate most general cases... But it's simple enough to implement and test.

You take the space of bladder also into the ullage space? i thought that it was the space between the bladder and the liquid... Well...

So that actually works more like a placeholder in the tank to keep the ullage space small enough when a lot of fuel has been used? Thanks for the info. is this normally used on tanks of small size? i wonder how much the bladder can expand, or do they use multiple sets of bladders from top to bottom and expand one by one?

One thing i don't understand is about the pressurizing. If we simply pressurize the tank in non-gravity environment, how can it make all liquid flow to the bottom part of the tank where usually the fuel inlet is located? Shouldn't these gas just create lots of bubbles in the liquid everywhere? Plus, why not gaseous helium? I remember that its boiling point is lower than hygrogen ... About the Proton's 3rd stage, (it seems like they also exist on Briz upper stage) how are these four small engines ignited? do they use the same type of fuel? how are the fuel pumped? perhaps by natural out-gas? The ullage simulation is interesting and that's why i'm evaluating it. Hope that i can get a simple-but-not-crude design later.

Any plan on radius-adjustable fairing bases? I mean those white ones. Right now only that dark one (interstage fairing base) is radius-adjustable... and that one is not very good at making fairings for top-mounted payload IMHO...

I'm still gathering information about the ullage, and i want to know the "many interesting ways" you mentioned. Could you share that with us? Currently what i know is: 1. ignite the upper stage when the first stage is still providing acceleration. 2. have specified ullage motors when separating stages. 3. use attitude motor (RCS thrusters i guess) to ullage the fuel. 4. roll rate brings centrifugal effect and results to ignition failure... Also I'm evaluating whether the ullage simulation should be included in this mod. it is a interesting, complex but relatively small feature, i don't know how much effort it deserves.

Looks interesting ... and may be a good one to interface with some other plugins like Mission Control or with the future official career mode. What about showing us some more achievements... so that we can know how complex & various can the conditions of success be.

Alright, looks like there are two bugs of external ignitors... one of them is due to my not understanding the part.orgPos not being a world coordinate...heck... another of them is due to my carelessness, forgot to unregister external ignitors when you revert launch / get back to space center and start a new launch, etc... I have just fixed them (hopefully, i'm not sure if there's any other issue) and updated the package & OP.