ss8913

yeah, has to be no atmosphere, 0G, and the ship can't be under any kind of acceleration.

I don't think I know yet exactly what your problem is.. can you elaborate?

Unfortunately vtol itself requires at least 2, for thrust balancing around a shifting CoM... (using TCA for that)

I've noticed on my latest 1.3.1 install.... I'm not sure what's going on, but some parts just either don't have categories, don't show up IN the categories, and/or don't show up on the search. Not exclusive to MKS, although the orbital construction dock is always a bear to find... but some things, like the realchute double cone chute.. in prior versions, there was a parachute category. now, no. search doesn't find it. Manufacturer tab is all b0rked. Only way to find the chute is filter by tech level 6, which is weird. Maybe it makes a difference if you install all 130+ mods at once or if you load a few at a time and start/restart KSP? If you find an answer to your part filters, please let me know, as your gamedata is significantly smaller than mine, and may be far easier to troubleshoot on your install... takes 10+ minutes just to load on my rig, so iterative testing is somewhat problematic

huh. never thought to use it for the magnetic nozzle. I was just using it to power heavy Alcubierre drives to move a 2000t ship at 250x lightspeed so I could colonize Thallo. Sadly, bugs in that planet pack (such as your entire base exploding catastrophically when you moved outside of physics range, due to the biomes and elevation maps not matching, causing the physics engine to suddenly think your base was 200m in the air over water as soon as you leave physics range, etc) ... prevented that endeavour, but the QSR with enough radiators will definitely push 250c on a 2000t ship I will be.. reattempting my ambitious colonization efforts once again, as soon as the multiple-antimatter-thermal-engines-wasteheat issue is addressed.. @FreeThinker I believe that Mine_Turtle opened github issues on that on my behalf.. full text of the issue is in the thread above...

I haven't used the QSR in the 1.3.1 version of this mod, but previously you'd need a lot of external power to keep it running. I was using a plasma core antimatter reactor + charged particle electric generator (3.75m or bigger) to drive it, and that worked. Oh and you'll need a lot of radiators for the QSR, esp. if you want to run it above 10%. Why haven't I used it in 1.3.1? Well, until I get a new PC with 32gb of RAM which will let me effectively use extra-kerbolular planetary systems, the 3.75m antimatter + CP generator is enough to run the alcubierre drives fast enough for any in-system jump. If you're using a beamed power network, however, you may have different requirements than I do.

Found a new bit of relevant info, @Mine_Turtle and @FreeThinker - what's going on is that when only ONE antimatter-reactor-powered thermal engine, wasteheat is manageable and works as I had come to expect from the previous version in KSP 1.3.0. When *more than one* such engine is activated, wastehead generation increases by literally 3 or 4 orders of magnitude and it overheats the reactors within seconds. This is a level of wasteheat that would require hundreds of tons of radiators to dissipate.. not sure there'd even be room on the craft, even with part clipping, for the number of radiators required to keep it in check Hope that helps narrow it down.

I have Kopernicus installed, for Astronomer's Visual Pack... but... not sure that counts as a terrain mod? I can try uninstalling that... the only issue I'm reporting that's a serious bug with no workaround that I can find is the framerate one, but yeah I can see how the framerate problem could be caused by a calculation going into some kind of loop... I'll go back to SVE and remove Kopernicus and try again. UPDATE: Yes, this fixes it. It seems to be an incompatibility between Kopernicus and TCA, which is odd because in KSP 1.3.0 I used these two mods together without any issue. Removing AVP and Kopernicus (replaced with Stock Visual Enhancements) solves all of the problems 100%.

OK so.. new behavior observed now vs the last 1.3.0-compatible version... @FreeThinker I fly a lot of spaceplanes. Almost always with the same engine configuration - 1 to 2 thermal ramjet nozzles pointing out the back of the plane, and 2-6 VTOL thermal turbojets pointing downwards... all attached to antimatter reactors. The main (horizontal) engines also have charged particle generators attached. I stuff a bunch of winged edge radiators in my wings for heat management. Everything was happy this way in the previous (1.3.0-compatible) version. Oddly enough, in the new version, the horizontal engines do the same - waste heat is manageable. However engaging the VTOL engines for 8-10 seconds is enough to overwhelm the craft with waste heat and cause reactor shutdown. Things I've tried: 1. Using thermal ramjet nozzles on the VTOL side 2. Using different propellants (atmospheric vs hydrazine) 3. Attaching charged particle generators to the reactors driving the VTOL engines None of this makes any difference. I don't see anything KSPIE-related in the logs showing any errors/exceptions or anything out of the ordinary. What changed/what can I do differently/why are only some reactors causing this type of heat? Ironically, it's the SMALLER reactors generating all the heat. the one that's not overheating the craft is a 3.75m, whereas the VTOL ones are 2x 2.5m.

@allista I've run into a problem... the new version doesn't behave like the 1.3.0 one (the last release for 1.3.0) did, and in a cripplingly negative way. Allow me to explain: Most of my space program revolves around mk3 and mk4 spaceplanes using KSPIE nuclear engines, with VTOL capability. This involves one or two horizontally-facing main engines, and 2 to 6 downward-pointing engines for VTOL thrust. This worked perfectly with the aforementioned version of TCA. I found that if I set the horizontal engines to manual control and the vertical engines to 'thrust and maneuver', and then set TCA to 'level' or 'stop', set the altitude, engaged the engines, and enabled TCA, it would lift to the desired altitude, and then I could push the 'Cruise' button, set the heading to 90 degrees and the horizontal speed to ~200 m/s, it'd use the horizontal engines, and do exactly what was asked/expected. At which point I'd disengage the VTOL engines, disengage TCA, and fly to orbit on the main horizontally-facing engines. OK, fast forward to today, 1.3.1, new TCA, same ship design. I notice: 1. The altitude hold is always with reference to the ground, regardless of the 'follow terrain' button. I cannot set an MSL altitude anymore 2. The altitude number used to be red when below ground, green when above ground, now it's always red. May be linked to #1 3. Horizontal engines always 0 thrust when set as above; if I set it to thrust & maneuver, it attempts to approximate the previous behavior, so that might be just a change in the new version which doesn't break functionality 4. Now for the game-breaking bug - as soon as I push the CRUISE button, my frame rate gets cut in half or worse, instantly, and only a revert-to-launch/SPH will remedy the situation. This is definitely new, and I would hope is a bug that can be fixed 5. Side note - "Smart Engines" still does not behave the way I'd expect (I thought smart engines would do what I'm describing above, but, no, it just prevents my horizontal engines from being activated, period. If I activate them manually, it just shuts them off immediately. But the previous version did that, too.) In the logs, I see a lot of: (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) [ThrottleControlledAvionics: 17:54:07.599] P-2-B-V.AttitudeControl: compute_steering: Invalid argumetns: current (0, 0, 0); |v| = 0 needed (0.3672802, -0.04080358, 0.929215); |v| = 1 current thrust (0, 0, 0); |v| = 0 (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) [ThrottleControlledAvionics: 17:54:07.601] P-2-B-V.AttitudeControl: compute_steering: Invalid argumetns: current (0, 0, 0); |v| = 0 needed (0.3673006, -0.04082808, 0.9292058); |v| = 1 current thrust (0, 0, 0); |v| = 0

use TAC fuel balancer... will let you transfer resources between containers. Certain resources such as some nuclear fuels are specifically excluded, but everything else, water included, can be transferred with this handy mod. It's a pretty old mod, but it's still actively maintained and has no other dependencies.

so when I drop a DIY container and expand it.. is there any way to know (or configure) what the orientation of the final product would be? ie if I want a certain piece of the base facing a certain compass direction, how does the translation of the orientation in the VAB to the orientation of the way the DIY kit is placed on the ground, map out?

any chance you could break up IAR into separate system packs? Those of us with *only* 16gb of ram and heavily modded installs are hitting almost full memory usage *by the time we get to the loading screen* with the full IAR pack installed I've toyed with the idea of deleting everything but the TRAPPIST-1 star and Thallo, to save ram, but it'd be nice if the whole pack could be modularized. Esp. if we don't want save-breaking mods to the Kerbol system, but just want exoplanets to explore with KSPIE/etc.

can you make it require more than one part? like a rover cockpit, some wheels, maybe an antenna..? One other thing occurs to me as well.. the construction cranes are.. kind of small, esp. considering the size of 5m kontainers.. any way to add some tweakscale functionality to them so I can make a really big crane to move really big stuff? As you know, having lots of little kontainers around isn't ideal due to part count/framerate issues...

First of all, the ground construction thing is great. I can use DIY kits to build large unwieldy things offworld without the problems that EPL's mechanic introduced with terrain clipping still need EPL for orbital construction though, it seems. My second point - I've maintained for years that there's no practical reason in KSP to ever use a rover. However I came up with one that could be worked into MKS - give some kind of "entertainment bonus" to hab/home time if there's a rover parked <= 150m from your base (within kolonization range) ... the idea being if the kerbals can go do donuts offworld in the rover, they won't miss their K-150/Korvette back home as much .. or something like that. Pretty sure Elon Musk's actual RL goal is to do donuts in a Tesla on Mars, so.. kind of a similar concept

fair enough; although adding the above features would in fact allow it to.

TCA will, for example, follow a maneuver node, or prograde, or retrograde, but it doesn't have control over the roll axis at all. with MJ, I can push prograde and force roll 0, so it'll be nicely level with the horizon, or I can specify what degree of roll I want. Handy for docking, ie, station port aligned NML+ with rotation 0, ship aligned NML- with rotation 0, makes it easy to dock.. that sort of thing. For spaceplane re-entry I like to have it force a heading of 90 and a pitch of 40; TCA will control bearing, cruise, etc, but you can't just say heading X, pitch Y, roll Z, and in a lot of cases that's extremely extremely useful

I never had much luck with the orbital autopilot; it doesn't seem to like to play nice with a lot of the non-stock engines, and I have a ton of mods loaded... for what I *do* use it for, the recompile fixed that functionality, so... it's at least somewhat of an improvement, if you just care about thrust balancing and such. One thing that WOULD help a lot, when you're able to get back to maintaining TCA, is a "force roll" function and a surface velocity/heading autopilot.. like what MJ has, but MJ doesn't do well with a lot of the systems I use, either.. too much control wobble, which TCA doesn't do (TCA is far better at holding a vector, when TCA is enabled.. but it doesn't have the surface-relative functions nor the force-roll functions that MJ does, so I keep having to try to use both concurrently, with mixed results )

I've recompiled it. It works; the current version does nothing except ... not work and prevent other autopilots from functioning when it's turned on, despite the fact that the UI works. Replace your DLL with this: https://www.dropbox.com/s/ym5qvbq1lm4qy6e/ThrottleControlledAvionics.dll?dl=0 and your problem is fixed. @allista it just needs a recompile, no code changes are necessary to fix it. Oh, you will likely need my AT_Utils recompile as well; a link to that is in the Configurable Containers thread, along with a fixed DLL for Configurable Containers - it's a ZIP containing both DLLs (AT_Utils and ConfigurableContainers). I was having KSP crash on load with the previous versions of those, so... there you go.

Here's the new DLLs: https://www.dropbox.com/s/4d2bqt4s55a795m/AT_Utils_ConfigurableContainers_131.zip?dl=0 just install the current version then put these DLLs in where the existing ones are, overwriting them. No problems so far in my install, and it solves the crash-on-start problem.

@FreeThinker any update on the lqdWater issue, or did you already look at it and determine that the cryo tanks aren't supposed to be fast? I did try the other parts that are capable of 'hydrates processing' to turn hydrates into lqdwater (all in one refinery and that.. other part, the extractor i think? weird that only the small extractor and not the large extractor have the function at all...?) Anyway, they're all slow. It doesn't seem to matter how much power I use, or really even how many *converters* I use.. something still seems very 'off' here as to these conversion rates and which parts are even capable of doing it...

that seems promising.. thanks! and yes I'm using VS2017.. maybe I should try this on linux.. I have used linux since 1993, but I figured, perhaps wrongly, that this would be easier on windows... EDIT: Yes, that worked. I'm testing the new DLLs now. With the existing DLLs, KSP crashes on load, so if I can get to the start menu, it's an improvement over the current status. will post a zip with the new .dll files if it works.

still not convinced that it's doing anything.. I can set a wind of any magnitude, and a craft returning to Kerbin via parachute will end up with 0.0 m/s horizontal velocity just before touchdown.. which can only happen if there's no wind.. which can only happen if the mod isn't actually doing anything, despite the UI working and it being configured to produce wind.

thanks! still not able to get AT_Utils to build, though, it seems related to: Severity Code Description Project File Line Suppression State Error CS0246 The type or namespace name 'IConfigNode' could not be found (are you missing a using directive or an assembly reference?) AT_Utils C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\downloads\AT_Utils-master\AT_Utils-master\Configuration\ConfigNodeObjects.cs 16 Active I've looked through every available assembly and I can *not* find where IConfigNode is defined... KSP docs seem to indicate that it's some kind of built-in, but.. none of the assemblies that come with KSP seem to define this..? Opening Assembly-CSharp in the object browser clearly shows it right there, but I'm getting a metric ton (877) errors trying to build AT_Utils with this and other 'undefined' references which are clearly defined... well, seems to be a result of: Severity Code Description Project File Line Suppression State Warning The primary reference "Assembly-CSharp" could not be resolved because it has an indirect dependency on the framework assembly "System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which could not be resolved in the currently targeted framework. ".NETFramework,Version=v2.0". To resolve this problem, either remove the reference "Assembly-CSharp" or retarget your application to a framework version which contains "System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089". AT_Utils System/System.Core that come with VS are version 2.0.0.0, and the versions that come with KSP are 3.4.0.0 ... not sure where the 3.5 comes from but..? I can build AGExt just fine, btw, which is also one of yours.. but it seems to have a separate .sln, although I can't see why that matters..? Please excuse all the questions, I'm trying to learn something here since these modules don't seem to fit the pattern of the other modules I've rebuilt with VS2017. and, as I said, very new to C#/mono/visual studio..

please do Hopefully all I need to do is import the right resources and push F6 to build a new .dll .... I have found, in the meantime, that if you install MKS, it seems that you can remove configurablecontainers-core and AT_Utils and MKS still works. Not sure what functionality I'm missing by not using CC-core, but I haven't run into it yet. CKAN however enforces CC-core as an MKS dependency.