RaccoonTOF

Yup, what you are seeing is exactly what I was talking about, as shown in your image there. And for MOST things (sane rockets, with reasonable amounts of control wheels/gimbals) it doesn't actually cause a major issue. However, it DOES become an issue when trying to build large, multi-part/multi-launch ships where small errors can really add up - and where getting the CoM exactly balanced for each part can be very important to the final stability of the completed multi-part vessel. Also very important for certain VTOL designs, or "modular" designs which have a common core but you want to be able to have various options for payloads AFTER the initial build in the VAB. Of course, you can get around this by just building everything in perfect symmetry...but my biggest use of the mod in the first place is for balancing crafts that are NOT perfectly symmetrical EDIT: With a gimbal-less engine centered on a single fuel tank with a probe core and nose cone on top, disabling the reaction wheels, and launching straight up...it appears to not waver on the nav ball at all, even with the off-balance torque. However, if you adjust the craft so that the DISPLAYED torque from the mod is 0 (tested by clipping a test weight into the center of the fuel tank, perfectly centering it with EEX, then using fine adjustment to offset it until the readout was 0kn) it WILL arc the rocket slightly...so definitely an error in reporting rather than an imbalance in the craft itself in the original case.

I realize this has not been updated to 1.10 yet, so if that is what is causing this issue, please just ignore Using version 0.10.0, when looking at ENGINES they are always displaying tiny torque values if located far enough away from the CoM/have enough thrust. This occurs even with perfectly centered engines (unless EVERY LF engine is somehow offset slightly, I've tried about 40 different engines from stock and a huge variety of mods, same issues with all of them if appropriately far from CoM for their thrust), in a stack consisting of nothing but fuel tank(s) and the engine on the bottom of the stack. It is definitely not an issue with the CRAFT CoM being off-center, as I can take the exact same test "craft", slap enough symmetrical RCS thrusters on it at the very bottom to have anywhere from 1kn to over 800kn thrust, and there is never any TRANSLATION torque shown (for the forward thrust direction - obviously there is torque in sideways directions due to them being mounted so far from CoM). The problem is exacerbated by having either higher thrust engines, or further from CoM, as would generally be expected from an off-center mount or thrust vector. EDIT: After further testing, it appears that it is registering a very, very slight off-centeredness in the thrust along the yaw axis that does not actually exist. When on the ENGINES setting, I can adjust gimbals in pitch and roll directions, and opposing directions are always the same torque value, but in the yaw direction, they are off from each other by exactly double the torque value of the "centered" position - again as would be expected by a slightly off-center thrust vector. However, this appears to be happening with ALL engines, and I kinda doubt that all of their thrust vectors are off-center by the same amount relative to their thrust...(could be wrong though...)

Confirming the loading problem is with the heatshields. The new drag cube creation code seems to be causing issues with a number of mods' parts, and a simple recompile doesn't appear to fix the issue (suspecting it is an issue with the .mu files themselves at this point).

Orbital Tug Push Adapter part has multiple node issues. In particular, the outer frame nodes force either 1x or 3x symmetry, rather than 1x, 2x, or 4x which would make sense for the node locations. Also, the ventral-starboard-center node appears to be reversed in direction relative to the other three central outer-frame nodes. This makes using the outer frame nodes pretty much useless for any form of symmetry, and the central nodes on the outer frame unusable even attaching everything in 1x individually. EDIT: Orbital Tug Carrier Module has the correct symmetry modes, but also has one of the central outer nodes in the wrong position - it duplicates the node location of the opposite node. So again, the central nodes aren't very useful, but the forward/aft outer nodes are fine in position and symmetry.

With the addition of a hollow core for the "central payload" and assuming that those open sides are wedge slots with the whole thing scalable like the others (1u, 2u, etc) that does indeed look like an ideal lander structure element Presumably those side tanks are able to toggle between tank types as well? (On that note, would be nice to have the current "fuel tank" core option and wedge parts to have multiple options as well - There are quite a few times that I use them as "science bays" on vehicles that only need liquid fuel...)

Request for a (hopefully simple) addition to the parts with "central payload" capability. In addition to the various tanks and the "crew tunnel", any chance we could get just a hollow cylinder there as well (keeping the normal wedges around the edges)? In particular I see this being handy for LEM style landers, so the ascent stage engine(s) can fit in the hollow (or even fire through it...) but I can think of a few other uses as well (surface mount small drills, inline comm arrays, exotic tankage, etc.).

This is likely due to reaction wheels acting in conjunction with the wheel steering. Two options here if this is the case: a) change all reaction wheels/parts with reaction wheel modules to "SAS Only". Now they will not react to manual steering input, so you can drive normally without trying to torque the whole rover around. b) Edit your control settings so that Drive Forward, Drive Reverse, Steer Left, Steer Right controls are remapped to (or have alternative keys) something that is not the same as the usual WASD. Personally, I disable using the arrow keys for camera control and instead use them for my rover steering.

I have looked into this before, though I've not done extensive work on the math for all the materials yet, nor actually coded any of them for use in KSP. Back over in the original Realchute thread though, I posted this a while back (april 2018): You might start by reading over the referenced manual, which is available at this address in pdf form. Would definitely like to see (at least some of) these additional materials included as Realchute materials - but since the last word I heard was that RealChute as it currently exists was no longer in development, and was instead being rewritten as RealChute 2.0 from the ground up, I had not gone any further with it.

So I finally got around to putting an a Munar ISRU setup, and experienced the same issues as previously with World Stabilizer in 1.4.x, even after updating to the recent release that was marked as 1.4.2 compatible. Yes, it fixes the issues with planes being tossed 1km into the air reported here earlier, but just wanted to give a heads up that it might cause issues for landed craft elsewhere upon load. So I guess we are dependent on Squad actually fixing the root cause of the collider issues for a solution that works in all cases (yes I know not directly to do with this mod, but as it was discussed here a few posts back, just wanted to make others aware that World Stabilizer isn't quite a magic bullet - far better than the alternative for those building heavy SSTOs though...)

Two things here: a) Noticed that it has been reported multiple times already, not sure if it was actually noticed, but parts material settings are not being copied to symmetrical parts when it copies all the other settings. Same issue when mounting a single chute, adjusting its settings, then picking it up in build mode, and placing it back down with symmetry - all of the non-material settings are saved, but material defaults to Nylon on all but the first selected/placed chute. I can add logs as well if needed next time I run the game, but as it had already been mentioned I was primarily looking to see if it had actually been looked into at all yet, as there is no issue report on Github for it. (again, I can create one there with logs after I run again). b) How are/were the values for the various materials calculated originally? What prompted me to look closer was the text description for Silk being "weak" and "cheap", when in actuality it is just the reverse The reason that most military chutes swapped from Silk to Nylon was due to supply shortages of natural silk during WW2, and Nylon was "the next best thing" available at the time - and the only reason we KEPT using Nylon is because it is drastically CHEAPER than Silk. (Yes, Nylon has a higher "total failure" temperature as well, but it has a "full effectiveness" temperature significantly LOWER than silk - silk tends to work nearly 100% until just short of failure from temperature, and then critically disintegrate all at once...) Silk is also STRONGER than Nylon per weight/thickness as well - an equivalent canopy load rating made from silk is about 2/3 the mass of the same load capability in Nylon, and significantly "thinner" (one issue that I think might have caused some of the discrepancy in the values used - while parachute silk cloth does have a higher mass per CUBIC meter than the ripstop Nylon used for parachute cloth, it has a lower mass per SQUARE meter, because it is thinner for the same strength...). Finally, ALL of the actual values used for density, max temp, and specific heat appear to be off in the listed materials definitions - not just in relation to each other, but also in relation to real-world material values. And yes, I know that KSP gets "nerfed" in a lot of its mass values especially, but I thought that this was being done in the case mass (which was described to include all the "other stuff" besides the canopy itself). If desired, I could work out all the math for all the materials (I only directly looked at Silk and Nylon so far) based on the material information from the US Naval Weapons Center "Parachute Recovery Systems Design Manual" - it has full specs and requirements for not only Nylon, Silk, and Kevlar, but also for Cotton Canvas, Rayon, Dacron, Nomex, E Glass, and Graphite (which is particularly interesting because of its complete lack of stretching under tension and a useful temperature up to 2,760 C - hellaciously expensive and slightly heavier than kevlar though). The same source has a bunch of information on masses for the other components in the system, effectiveness of various shapes, etc etc, but the only thing that I can see directly being applicable is the canopy materials info, since we don't have multiple canopy shapes implemented, and case mass is already a sort of fudge-factor for KSP anyway...

The fairing issue is a stock issue with the 1.4.2 patch that supposedly fixed a bunch of placement nodes. Unfortunately, they also broke the rescale factor on the largest stock fairing size in the process somehow...

All looks good so far...but being as it was an intermittent problem in the first place, I'll keep an eye on the log for the next bit just to make sure it is really gone Thanks for the quick turnaround on such a frustrating problem.

Just wanted to report that the Nuclear Processing Lab configuration of the D2 Science Module does not seem to be operating as listed in the description. It claims 150ec/s from the Nuclear Reactor converter portion, but I am actually seeing 67.5 output instead. I've tried both with and without scientists, engineers, and pilots...results seem identical regardless of crew makeup. Anything else that would be causing this inefficiency, or is it just incorrect data in the description area? Added module config below, description appears accurate... The module config seems to show it being 150, and using specialist bonuses...but for the life of me I can't figure out what specialization it needs. or if I'm missing something else...

Voyager with ISRU Drone attached: And on the Mun, working on refueling...

Voyager Heavy VTOL Exploration SSTO - 200t gross fully loaded and fueled Supplies for 15 kerbals for one year (USI-LS) Complete science suite Nuclear and Solar power Dorsal docking fixtures for drones/tenders and/or station docking Ventral cargo bay for carrying/deploying exploration rover and/or longer-term base facilities or ISRU equipment Yes...it has _10_ nuclear engines in two deployment bays for VTOL capability on airless worlds... 18 MJ-88 Mini Vector High-Gimbal Turbojets 2 XJ-48K Vector High-Power High-Gimbal Turbojets 6 FTmN-80 Nuclear Engines Roughly the same total thrust as a single mainsail, but air-breathing so fuel needs are far lower; purely liquid fueled, so much higher payload mass fraction than LOX, and enough gimbal range to allow for an extremely short takeoff roll (or true VTOL capability if using the ventral nukes for launch assist and an empty cargo bay, or on lower-grav planets). Extremely low drag design as well (see below) allows for efficient climbs to apoapsis. Easily capable of 200k+ apoapsis on atmospheric engines alone, circularization and orbital/deep space maneuvers with nukes. Lots of space, lots of lift capacity - but by using the J-series fuselage and 4° angle of incidence on the wings (with slight dihedral on the outer portion of the main rear wings for extra stability) it has extremely low atmospheric drag for its size - less than 3m/s² at cruising altitude and mach 6. Head on flying prograde (as it does after reaching 15k, up until leaving atmosphere) almost all of the drag aside from the cockpit itself just comes from the intakes and the solar panel shrouds. Even the docking fixtures are relatively concealed and drag reduced by the tapered adapters. The vertical-wedge of the J-HT cockpit is amazing for high-mach SSTO aircraft...

J-1 (Original) and J-2 (Upgraded lift capacity) SSTO shuttles docking and transferring resources/crew prior to offloading my Kerbin Space Camp station and bringing everyone home...

Just posting here to let you know that the NRE issues with dust effects are still going on with the 11.8.26 build. Details and log in the github issue tracker.

Apparent success with World Stabilizer fixing the issue on one of my craft that was quite prone to this. Hopefully I won't see issues with the previous 1.4 conflict I saw with base structures on the Mun (I started a new career, so no test base currently) - anyway, thanks for the heads up that it was in fact working still.

Just wondering if this is an actual problem with the mod, or if I've got some other conflict somewhere causing this. The image below shows the RCS ports plume effects "reversed" from the direction of the RCS thrust (probe core pictured is "forward", RCS is thrusting with H translation. Same occurs on all other directions). The thrust itself applies correctly in use, just the visuals are opposite what I would expect (and also a LOT larger than I would have expected from the original screenshots...) EDIT: after looking into the part config and doing a bit more digging on the forums, it appears to be an issue with all parts using ModuleRCS.

Is World Stabilizer working in 1.4.2? I had issues with it in 1.4.0 apparently working against the "fix" in the official patch for bases launching up into the air, and actually ending up launching them even further than WITHOUT World Stabilizer installed. I guess I'll give it a shot next time I have a craft that repeatedly exhibits the airdrop over runway issue... EDIT: According to the mod thread, it has not been updated since 1.3.1 considering that the bug was believed fixed...

The congrats was to LameLefty on hitting 1k posts

It's been going on since 1.4, not limited to 1.4.2, but likely just hadn't been reported prior EDIT: And Congrats on 1k

Unrelated (or at least not limited) to this mod - have had the same happen with various aircraft (some of which used no parts from here), for no unique reason I've been able to nail down yet. Sometimes changing landing gear works, other times shifting the CoM works, and a few times have required a total rebuild/redesign. Adding a single launch clamp can often fix it as well - but other times just results in destruction of the craft on launch as it still tries to catapult up...

I'm not really touching the DCSS/ICPS/SM stuff except for a couple engine tweaks as mentioned above, just to ensure that the total vehicle delta-V numbers match up with those projected for the real life options - just enough to allow me to test the core/boosters really. And even those tweaks should really be part of a dedicated upper stage/payload package, since in a couple of cases I had to overwrite engines that people might want to use for other things (except for the dual-nozzle 1kN engine, which already has the exact same stats in the base RealEngines package as 2 other engines ). So as long as his tweaks keep them to the real-life performance specs/total weight, and the proper outer diameter, they should play nicely together without any issues Unfortunately, after doing the fresh install with all the currently latest versions of things again, something broke I'm suspecting that it is the latest version of MM that broke things again, but haven't tracked down the issues yet. So...a bit of a delay again...

Woopert, I've got a full package of mods for RSS/RO that will give what you need to assemble all of the various SLS options, minus the payloads (those are handled by others with the Taurus pod, the ICPS mod, ESA pack for the ATV-based SM, etc. and a few other options). It covers all of the new ARM parts, as well as the parts you need to make all 3 of the currently proposed booster options. I've also tweaked a few of the RealEngines aside from that - like for those that want to use proper thrusters for the Orion SM (repurposed/respecced one of the many 1kN engines in the RE pack) and alternative configs for some RCS modules. I'm about to do a full fresh install of the required RO mods, required mod packs for the various base engines, and the "latest" RealEngines, to ensure that my modded parts and the corrections to RealEngines that I've made will work on a totally fresh install and that I've not missed anything, and then I'll be sending it to Nathan for distribution/testing as desired - it's still not totally polished, and I expect there will be some problems that I've not gotten to test out yet, but I'm going to be away on a sailboat delivery for the next couple weeks so I wanted to get at least something out there before I took off