HoneyFox

Sounds interesting but might be hard to implement... I don't know how to acquire a vessel's parts when it's not loaded (i.e. not within 2.25km~2.5km range of the active vessel), thus not being able to judge what (and how many) warpable engines exist. I guess that RemoteTech2 should have encountered similar issue too, I need to check how RT2 solved this.

Alright, I've just updated the latest version. (link unchanged)

Stock game logic will and only will explode when it just exceeds the maxTemp, this will however have probability when temperature is getting close to maxTemp.

Well the thread title tells all. Current progress: Basic framework for random failures: can support multiple types of failures now, still lacking "Repair/Replenish" & "Mission Controller additional quality-assurance expense affecting probability of failures" designs though. Some failures implemented: Decoupler random activation due to overheat, Engine random explosion/shutdown due to resonate or exceeded vibration, Engine random explosion due to overheating, Resource leakage due to Gee load and/or exceeded amount of fuel in a tank with a very low dry mass (balloon tank) Source-codes are on GitHub: github.com/HoneyFox/RandomFailures/ Currently the development pace is slow so don't expect it to have many new failures coming out very soon. Also I'm expecting other coders to join and help.

Land launch... hmm... does that indicate that you have plan to create a sea-launched variant? (also a plan to create a sea-launching-platform)

If that v6pre is the one with terrain of real earth, then it is.

Talking about this, it reminds me of the weirdness of the Mars' Phobos in RSS... it has really big difference between its PQS and SS.

For the L1/L2 point, they should partially work if you can put your vessel at that location as well as give your vessel the proper speed (with that speed, your vessel orbit should have the Ap at the orbit's opposite side if you are outside of earth or have the Pe at the orbit's opposite side if you are inside of earth). BTW is 1500000km still in Earth's SOI? If it is, the current implementation has some error that might change L1/L2 location a bit.

You can always disable n-body portion by clicking that icon on the Toolbar. I will add a config to record these options later so that you don't need to close it every time you start a flight. For the Interstellar engines, if the engine is using ModuleEngines/ModuleEnginesFX, it should be compatible. but you need to add a "WarpableEngine" module into it manually. For code example, check the "config.cfg" file in the NBody folder, which is adding that module to all engines that use "XenonGas", "HydrogenGas" or "ArgonGas" (well these are for Near Future pack, so the resource names might differ) as propellant.

Yes, lots of exceptions were thrown and it spams the I/O quite a lot.

That sounds weird... Considering you have 300km*100km orbit, a slight orbit velocity change won't cause the Pe to move +/-90 degrees... I hope that it's not anything wrong inside KSP's orbit calculation... what level of time-warp are you using?

This fix allows the deployed chute to get heated very fast even the chute pack itself is behind the heat-shield. This will disallow players to use parachute during re-entry, if you do, the chute will get heated very fast and might explode several seconds after.

So make sure: you have >= 0.5 EC (which i think should be sufficient in normal cases), and you still have ignitor count available (see the engine's context menu during flight, check "Ignitor: Electric (?/?)"), and you have fuel stable (which you have stated).

Hi ferram, currently an object spinning even in vacuum will de-spin gradually. can you implement a sub function that sets parts' rigidbodies' angularDrag according to air density or something similar?

OK. let me update the OP together with a new release.

I remember that i've added MIT license into the source code base on GitHub... let me check again... Wondering if I need to restate this in my OP?

I haven't put any kind of limit for time-warp rate... if you have sufficient resources (both xenon gas and electric charge) it should work in 1000x or 10000x or even higher rate. As for that decay issue, I'm simply using the inverted direction of the vessel's velocity for drag direction, so it will lose its horizontal velocity all the time but the absolute value of vertical speed might decrease as the air gets denser when falling into lower atmosphere. I will do some more tests to observe that, can you provide some basic information about your debris? i mean, the mass and the speed when entering the atmosphere?

That's strange. There is a design in the plugin which will automatically set the "Throttle" bar back to 0 every time you exit the time-warp (so that you won't mis-maneuver when you get into time-warp again). It seems like you are changing the "Throttle" during time-warp aren't you? if that's right, make sure you still have sufficient electric charge & xenon gas. For some unknown reason, KSP doesn't handle resource consuming/generating correctly during time-warp, you will easily be out of EC with ion thrusters on during time-warp. And to judge whether the ion engine really works or not, just right-click the engine and see its context menu. The thrust value displayed there is kept updated (and propellant-deprived/flame-out information as well) As for moving away from keyboard shortcuts, I'm considering adding some information display. It is not easy to check if certain function is on or off currently.

Frankly speaking, i'm planning to disable/remove the N-body part of this plugin because it's implemented quite inaccurately, the orbit predictor works even worse that it will kill FPS quite a lot. For the rest two features: you can try launching a payload (with ion thruster + xenon gas on-board) onto LEO, make sure your upper stage cut-off and release the payload when orbit's Pe is still in atmosphere (if in stock KSP, I recommand ~50km, in RSS I recommend ~80km) and you need to use payload's ion thruster (set its Throttle to 100 and use time-warp for testing, make sure you have sufficient power supply) to do the last part of job to get into orbit. Then watch how the upper stage finally reentry while you are still controlling the payload.

Technically speaking, it's no difference whether to simulate exosphere or not, but it's too hard & tiring for players to manually maintain orbits for different orbiters, especially when you have an interplanetary mission underway that might take several months or years.

It is quite annoying. and since realistic atmosphere decay will bring more troubles for LEO orbiters, I choose to only simulate the drag when they are really in KSP's atmosphere. (i.e. ~70km for stock Kerbin, ~104km for RSS Earth)

Minor update: Fix issue that happens when multiple engines are running on time-warp. Automatically adjust tweakables of all counterparts in flight, should ease user a lot when he/she is using an array of multiple ion thrusters. P.S: This plugin needs more love.

I'm not familiar with the Rtfs engine config, could you go to VAB/SPH and mouse-over the engine that failed to ignite and tell me what information is given?

Did you ever extracted the IgnitorCfg pack in my latest EI 3.2.0? It contains some configs for Soviet Engine Pack. If you're using RF+Nathan's RftsEngines, you'd better delete the extracted files according to Nathan's advice, otherwise it might cause some conflicts (though frankly speaking I don't know why there's conflict).

How's the fuel flow state? is it stable or not? If it's not, you might need to take some ullage measures.