DarthPointer

Missing dependency? Did you install all of them?

RMB on KCT ico in mods tray in KSC scene.

For 1.12 they changed Unity version, didn't they? Not a surprise mod built for 1.11 has issues. I did not get into the maths behind the mod's momentum conservation (which is left unchanged after the adoption). But I have tested it and this axial momentum exchange seems to confrom the idea of conservation to some extent. Like if you get some positive pitch and then roll for 180 degrees, you end up with changing the sign of RW accumulated pitch momentum. So you can't cheat the wheels to provide you infinite momentum. UPD: How to make sure it is fine: disable reasonless regeneration and get a craft into space. Have no RCS input and no atmosphere to disturb the craft. Ensure your RWs are fresh (0 accumulated momentum, or all axes are 100% free). Spin the vessel however you like. Then enable SAS to make a full-stop of rotation or stop it manually. You should end up having zero momentum accumulated in the RWs.

Yes, as long as you want to improve the quality of further engines of that model.

As a LGG mod user I would really like his mods to keep KAC option. Currently, stock AC has severe issues I have heard of. So I share the opinoin that used AC should not be switched, but only get a new option. Moreover, replacement will force all users willing to get mod updates to migrate to 1.12.

1. While the mod author warns us that the "physics" of the mod are pretty much different from IRL ones, all the conservation laws seem to be "conserved" from my experience. (The author, not me, I'm a fly-by user who rebuilt it with adding few QoLs, having nearly-to-no-idea about the maths behind the core feature.) In case you spin with unstable axis, axis flucuations and swaps (modeled by stock in-scene physics when not warping), momentum usage of RW's axes changes. The way that if you disable "reasonless" momentum recovery, if you start spinning and then terminate vessel spinning back to initial momentum (both using RWs only), your RW's will have same momentum load as before you started spinning (relative to what is your current "inertial reference" of scene). 2. You open RW Window (via PAW or stock mod toolbar), there you choose vessel you want (active vessel will be outlined as green). There you will see all the vessel's RWs and on the right of each RW part name there are dump buttons. They consume monopropellant and electricity, emulating that you decelerate the wheels and perfectly compensate recoil burning RCS. Yes, not any realistic, not involving RCS thruster parts. But I fully appreciate the idea of having it in the game for this mod beacause the only alternative I see is kOS/kRPC/insert any other KSP brainquack lang. REMINDER: this feature availability is toggled in SSWR's tab in "Difficulty Settings". 3. That is a matter of config, SSRW assumes there is monoprop only. The best solution I see is using B9PS to alter "fuel" resource to what your vessel's RCS fuel is. So that you have to give these parts a B9PS module that switches one of the fields between what RO assumes to be RCS fuels. IIRC SSRW emulates consumption via ficticious RCS PartModule so it shoul be possible to feed it a mixture like UDMH+NTO.

IIRC most provided configs, including the default one, allow "multy-threading". The window where you upgrade construction speed of your VAB/SPH lines has buttons to boost existing ones or open new. It should look like you have a zero-speed line under existing one, upgrading it once effectively opens it. Number of lines you can have can be limited in configs, limit usually depends on VAB/SPH level.

Using runtime code to change power of RW is generally a bad design. IMHO this should be left for an MM patch with FINAL pass. Probably I should pack a plug'n'play .cfg into downloadables with single value to be changed by player, but definitly not a sort of a slider in difficulty settings.

That was my JNSQ modded career game... Wanted to add 3 engines in symmetry. And the things got BROKEN. Have already experienced such a bug in P2P. Found out that previous optimization attempts were a bit excessive and broke it. Fixed by reverting this part of optimization - I don't think anyone will be bothered with this as it is not in Update tick cycles. v1.5.6.4 is out. ## Fixed: - Excessive optimization was causing bugs and NREs when placing symmetrized engine parts.

A maintenance uptdate 1.5.6.3 is released. With possible performance uptweak and multimode/multimodule and rollout behavior engines fixes. ## Added: - Rolling out an engine with 0 ingitions left (used before, fixed failure but did not refill ignitions) now (almost) instantly triggers "Out of ignitions" state. - Moved EngineDecay PartModule logics to Update ticks from FixedUpdate to improve performance (I can't tell if it was a problem but better I do it now). ## Fixed: - Rolling out a burnt engine with refreshed ingitions could (almost) instantly cause a failure without starting it. - Multimode engines used to get both modes' modules activated for new parts and after reenabling engines. - Engine part startup and reenabling opertations now should be valid for both multimodule in single mode and multimoded with MultiModeEngine module. - Misconfiguration warning now is not thrown for multimoduled singlemoded engines.

To make the things clear: wrong numbers are displayed in the "total vessel cost" of stock's recovery report only in case of negative cost change from modules. Have not tested if it is the case if overall change is negative or it gets inconsistent even if only some of the modules bring negative change regardless the sign of sum. @Gotmachine pin-n-ng, I guess I better make sure you are notified.

I have seen that post. And the OP is about "nice plumes, but I would like the plumes to vary depending on exhaust interaction. Like what you can see for Falcon 9 engine assembly of Tundra Exploration" (once again, IIRC it was that mod).

Kerbalism removes its modules from the engines if it sees P2P. All the other subjects to reliability are not changed, kerbalism reliability system keeps affecting reource converters, antennas and so on. P2P is engines-only reliability mod so we only made ksm give up engines reliability in favor of a more specialized mod, if it is installed.

A performance update 1.5.6.2 is here. I have fixed a logspam bug and found a way to build Release (not Debug) binaries. Simply readding broken links was the only thing I had to do... ## Fixed: - Logspam after engine reaching warning time not in simulation. - Finally built binaries in Release mode.

Some time ago we have been teased with engine exhausts from the WIP of KSP2. But all the scenes featured only one engine. I guess similar results are possible even in KSP1, using combination of Real Plume and Waterfall mods and spending *some* time to adjust the configs. However, realistic plume is not only about making your single engine in the scene produce a beautiful exhaust. As we can see from Soyuz, Falcon9/Heavy and other launches with multiple engine exhaust bells, the effects of plume interactions can be very interesting. One of the mods (Tundra Exploration IIRC) provides such plume effect for its engines assembiles. Is it possible that we will see such effects in KSP2 not static, not configed per engine assembly in single part, but dynamic, "calculated" by the game during runtime?

Hi! Yes, it can consume monopropellant. It is the "dump accumulated torque" feature to do it. It is here to "simulate" you decelerating the wheels and burning RCS simultaneosly the way you dont affect vessel's rotation. AFAIK it is disabled by default, you can change it in difficylty settings. When the feature is enabled you will see buttons to activate the torque dumping in the RW Window. And it is the only case the wheels consume fuel. Apart from this "torque dumping" it does not need anything but EC. You still can dump the torque manually just for EC, The only difference is you will have to counter the "recoil" after that using your regular RCS.

Thanks @Lisias, now it is possible to run P2P on KSP 1.11 and have the recovery costs being what they should be! 1) Since KSP 1.11 it is strongly recommended to use KSP Recall. It is not a hard dependency, but without it recovery refunds can be VERY BROKEN. Here is the KSP Recall thread. 2) I'm releasing P2P v1.5.6.1 - the only change is added support for new part replacing pre-1.11 TwinBoar. (Can anyone tell me what is the hecking difference between Size2LFB and Size2LFB_v2, apart from different partname?) Added: Support for KSP 1.11 new TwinBoar

@Cruesoe AFAIK KCT stops warp on its own. May be it can be disabled via settings, not sure.

I have finished my work on first "kinda good" implementation of Sibling Reliability. Now you can make engine models (positively) affect reliability of other models and fit diffirent switchable models in same part with B9PS. I will have to spend some time reflecting this at github wiki. Support coverage has also been increased, thanks @Vidga4 for help with this boring stuff. Added: Coatl Aerospace support config. Knes support config. Tantares/LV support configs. Reworked Sibling Reliability graph configging. Sibling Reliability for Bluedog DB, Tantares/LV. Failures are disabled during KRASH simulations

I have to report that P2P shows inconsistent behaviour with KSP 1.11.x. The story starts here As the result, P2P gameplay with 1.11 is severelly broken. Eliminating payoffs from recovered engines is one of the key parts of the design, which is now impossible to do with sane usage of IPartCostModifier. tl;dr: SqUaD folks broke their KSP API.

Also MIT as I can see from the repo license. Am I right?

Hello @linuxgurugamer! I want to using KRASHWrapper.cs in my reliability mod as I have seen others to use it to prevent failures on simulations. Is it legal to simply copy it into the project without any changes in license (MIT in my case)? Should I explicitly mention the origins of the file somewhere or is your disclamer in the file enough for everyone to use it without changes?

It has turned out that the issues on loading KSP were connected with game language. KSP that use non-EN locstrings for RCS modules descriptions (GetInfo if it helps you understand what I'm speaking about) were affected as one of the modules used to depend on EN version of string. Version 2.1.2 is out to fix it. Fixed: Non-EN KSP versions throwing exceptions or even failing to load.

Hi! 1) Check few posts above, you may find the answer 2) Test it on your own. Both mainteiner(s) and users would be happy to see any report about this. I personally stay on 1.8.1 and only install higher versions for brief compatibility tests so I have stopped asking this question few years ago. xD IMHO: chances are KCT will be fine with 1.11.1.

A new version 1.5.5.0 is released. It adds BDB (BDB is *quite big*, did not test all the parts) support, Sibling Reliability Progress, ability to make some engines more reliable on ignition and config custom engineModelId for tracking progess and fixed one NRE case. Added: Sibling reliability, supporting it in Stock and ReStockPlus. ignitionIssuesChanceScale field to make some engines more reliable on ignition (provided config makes ignition issues chance 10 times less for SRBs). EngineDecay module can be configed to use specific engineModelId instead of part's name. Bluedog DB support config. Fixed: NRE when opening a gamesave with the mod for the first time.