ChrisF0001

That's great, thank you!

Hi, So, I have a weird problem. In a very long running save, just 'upgraded' from KSP 1.7, and now using KSP 1.8 / GC 2.5.0.1 as it comes from CKAN with the USI stuff - I have a space station with an orbital workshop on it. And when I dock a dockable DIY kit to it (built successfully by the same station in the assembly line)... nothing appears in the Workshop Window. Just the 'Recycler' and 'Close' buttons, and the Workforce label. I do have three five-star engineers in there, and the kit is, as far as I can tell, docked by the construction port (albeit a few parts away from the workshop). In a sandbox test game with the same set of mods, a test ship launched with an orbital workshop -> docking port -> Dockable DIY kit all bolted together in the VAB works correctly. Has anyone seen anything like this before?...

Indeed, and had I noticed in time I might have been able to account for it. I guess I was living under a rock or something. These things happen... ^_^;

Is that the workaround of removing the KSPWheelDustEffects module? I had the impression that was to resolve a performance issue rather than the lockup on load. Still, I am certainly content to wait for the moment, as a software engineer myself I am quite aware of how bugs are... particularly bugs introduced from elsewhere!

Well... With a part name change some things have broken anyway. Some panels have moved, some have rotated, a couple are much bigger, and I see a bunch of manual-hyperediting in my future. Hopefully easier than the thing with KIS was though!

Just to confirm - reading the last bit of this thread after getting the freeze-on-load with 1.8, I understand that currently MechJeb and KF won't co-exist right now, but there might be a fix at some point? (My current ongoing save won't really survive without either!)

Thanks, hopefully that means there are indeed drop-in replacements!

And, suddenly I understand why a bunch of parts were apparently hidden in the VAB... I guess I should have been paying more attention. Was this deprecation for balance reasons?...

I think your understanding is correct, I just haven't set any of those things up for public sharing at this time. ^_^; I probably should... Still, if I can recreate the issue with only stock / USI parts I shall attempt to take the next steps. Since it does seem part-dependent it's rather speculative at this point, and I've been able to 'work around' using... slightly underhanded means for the time being!

I can reproduce it, although annoyingly it seems to be dependent on what the attachment point is attached to. A test craft of: <thing> : [BZ-52 Radial Attachment Point] : [Construction port] : [Construction port] : [MKS MiniTruss] (with probe core) ...works correctly when <thing> is, say, a fuel tank. But when <thing> is 'Hexa-Girder Modular Truss S1' from Near Future Structural (as in the real case): ...[LOG 19:01:03.455] Looking at node bottom [LOG 19:01:03.455] Returning BZ-52 Radial Attachment Point [ERR 19:01:03.455] A joint can't connect the body to itself. [EXC 19:01:03.456] NullReferenceException: Object reference not set to an instance of an object ...And then it collapses. (I have no particularly convenient way to upload more logs at this exact moment, but there are more tests I have yet to try...)

Hi, back yet again with another weird problem... I have a case where two connected construction ports won't compress. Or rather, I click 'Compress parts', and: there's no 'explosion' or sound, the smaller assembly moves into basically the right place, one port (on the larger assembly) flies off into space, the other port remains attached but embedded in the mesh, and it's hard to tell whether the assemblies are actually connected at all (they superficially appear to be, but switching vessels reveals them not to be). It's... odd. I don't yet know the exact trigger conditions, although I suspect it has to do with sticking construction ports on radial attachment nodes (but sometimes, that works...). There are a lot of experiments still to do. But, has anyone else seen anything like this?

So I've discovered a Confusing Thing that I wonder if anyone else has seen - regarding Orbital Logistics. This is KSP 1.7.3 and MKS 1.2.0.0. I have a bunch of bases and stations around Mun, and I thought it would be a great idea to build a ship that was basically a Tundra Pioneer+Logistics module with a monoprop engine on it, so that I could dock it with things and transfer resources to it. I built this thing in orbit with GlobalConstruction, launched, sent it somewhere, and made a transfer. Presently it failed with "The target logistics module could not be found on the destination vessel.". I observed that other transfers still worked, and after some poking around in the save file I observed that the new ship, in fact the new module, had a duplicate ModuleId in the ModuleOrbitalLogistics module of the... module. It was in fact a duplicate of the P+L module on the station that built the ship. Manually editing the quicksave file to give the new module a new GUID allowed transfers to work correctly. Presumably keeping an eye out for this in the future will allow it to be corrected, but am I trying to do something weird here? Is this a known phenomenon with multiple logistics modules on a single vessel? I do recall that I launched it with the 'start docked after construction' feature that seems to have appeared recently (or at least since the last time I built something in orbit)...

Thanks, it hadn't occurred to me that "R" might help with the ground-interaction rather than just attaching. I'll see how it goes!

Has anyone encountered an issue where the Rover Autopilot / Stability Mode sometimes just goes a bit... wrong? (As in, I turn it on and the rover immediately tries to flip over its own nose.) This is KSP 1.7.3 and MechJeb 2.8.4.0, though I'm almost sure it started happening sometime in KSP 1.6.1. I vaguely remember reading somewhere it might have something to do with misaligned reaction wheels - or possibly with things built off Kerbin? (Certainly the design tested 'okay' right outside KSC, but the same rover built on Mun using GlobalConstruction sure does like being upside-down...)

So I have an annoying question... When you grab a thing in EVA, you can press B / N to move it up and down before dropping it - but you only seem to get a limited number of 'nudges' before it just stops. Is there any way (such as settings file hackery) to increase that maximum offset? (I'm trying to rebuild a base after the Great Detachment Mess of '19, and some parts still clip into the ground even after the maximum amount of B-pressing. I'm having to carefully balance them on top of other things then grab said other thing from underneath them in the hope that they settle gently to the surface, it's quite incredibly tedious...)

Ah, I see, thanks. I had not fully grasped the MKS side of things. My theory about 1.1 -> 1.2 -> 1.3 was to get the automatic upgrade to happen, since I have a couple of probes far out of reach of any engineers and it seemed perhaps safer than editing the save file directly - but if KAS 1.3 will support KSP 1.7, that might be a viable way forward...

So let me just check to see if I can formulate a plan here... Starting with KSP 1.6.1 / KAS 1.1: Do whatever manual upgrade missions I can to replace legacy parts Disconnect any remaining struts / flex-o-tubes Update KAS to 1.2 and follow the legacy update pipeline sequence Update KSP to 1.7 and KAS to 1.3 Reconnect flex-o-tubes Profit? Sorry for the continuous questions!

Is there any word on the future of MKS Flex-o-tubes? I'm a little confused as to how functional the pre-KAS-1.2 legacy DLL is in KSP 1.7 at all...

I think I worked around it with this MM patch: @PART[AES_RCS] { !MODULE[ModuleRCS] {} EFFECTS { running { AUDIO_MULTI_POOL { channel = Ship clip = sound_rocket_mini volume = 0.0 0.0 volume = 0.02 0.1 volume = 0.5 0.1 volume = 1.0 0.1 pitch = 0.0 0.75 pitch = 1.0 1.5 loop = true } MODEL_MULTI_PARTICLE { modelName = Squad/FX/Monoprop_small transformName = RCSTransform emission = 0.0 0.0 emission = 0.1 0.0 emission = 1.0 1.0 speed = 0.0 0.8 speed = 1.0 1.0 localRotation = -90, 0, 0 } } } MODULE { name = ModuleRCSFX stagingEnabled = False thrusterTransformName = RCSTransform thrusterPower = 0.25 resourceName = MonoPropellant resourceFlowMode = STAGE_PRIORITY_FLOW runningEffectName = running atmosphereCurve { key = 0 240 key = 1 100 key = 4 0.001 } } } ...It's been a while though, so I can make no guarantees! ...In fact, since I can't remember which versions of KSP and USI caused this, you may need to do something different. In any case, find the effects module from a thruster that's working, patch it over the affected one like so, and hopefully it will work!

Hmm, that's not ideal - I guess I'll be avoiding 1.7 for a while on that basis at least, then. Thanks for the patch, as well - that might make some sort of update path possible in the end... I don't suppose you happen to know if the upgrade pipeline also processes .craft files?

All I want is the Portable Strut - everything else has more-or-less a drop-in replacement and can be worked around, but nothing replaces that functionality (the hook / cable pair is neither symmetrical nor anywhere near long enough!). I was hoping the KAS.dll in the old LEGACY folder would work, but if that can't work with 1.7... I guess I can't update either KAS or KSP itself unless I start a new game. Which is a shame. (Seriously, I must be using dozens of those things!) Aren't the Flex-O-Tubes in MKS based on the same plugin? Would they stop working with the update?

So, is there any way to *stop* the 'Upgrade from Legacy' sequence from happening? (I still have delusions of keeping the LEGACY files around and preserving some unsupported parts...)

I believe the critical thing is that you must have a Pioneer Module (presumably powered / crewed...). That has a command called 'Check colony rewards', which when used gives you the science / funds / reputation that's been generated since the last time you did it. How that's calculated, though, I have little idea...

I don't have any Ag Support Modules yet, but I have noticed that when making T-Credits the module often can't see LFO that's physically far away, even if it's on the same base / station. It's not clear to me whether specific parts are blocking the flow, but ever since I spotted this I now build logistics modules with little tanks / redi-paks directly stuck to the module itself to sort it out...

I believe it's always been that way, just like it used to be with the stock External Command Seat. In the past those couldn't be launched with crew either. I have been known to put the AES Pod on the front of an Akita-based rover if I *really* needed a Kerbal there at launch - or indeed attach the pod + Kerbal to the back of the rover with a tiny decoupler if I really wanted to test the seat itself...