bcqJC

This is hopefully the last update on the spawn issue for a while. Unless I encounter any game-breaking issue, I'll stay put with the current state of mods I have. Installed the latest Tweakscale update yesterday - TS 2.4.4.5. Also EVS 2.2. The spawning issue is gone. I've switched over to a default config for WorldStabilizer to see if I can get rid of the CFG customizations. My OPT Humpback SSTO now launches without hiccups. I don't know which of those 2 updates fixed the issue. Things are stable so far. Looking forward to some gameplay this weekend.

An update to the spawn issue... Note, I'm running 1.11 with a lot of mods - 100+. I got tired of using VesselMover to spawn my OPT Humpback ssto with the troublesome cargo ramp; and individually boarding kerbals onto it. So I tried (and failed a lot) ways to get around the problem. Here's the workaround/solution that I finally settled on. WorldStabilizer stays as before. But this time, give it more time to do its thing by bumping up stabilizationTicks to 500 (from 100); groundingTicks to 250 (from 6); maxUpMovement to 25.0 (from 2.0); displayMessage to True (from false). The settings are in WorldStabilizer.cfg. By doing this, WS ran for about 10 seconds on my laptop before I got the "World has been stabilized" message. On the Humpback ssto, give WS some discrete targets to use as reference points when it moves the craft up/down on spawning. I used a couple of M-2x2 Structural panels as the targets. These are attached to docking ports that are offset so that the structural panel is level with the landing gear. Make it so that those targets are easily discarded - I set the docking ports to decouple by staging. Basically, when the craft spawns, it should rest on the landing gear and the structural panels. On launching the craft from Editor, give WS a second to get its bearings. As long as everything is above or flush with the runway, hit stage to decouple the structural panels before WS can finish. The ssto will calmly settle on the runway. Here's a screenshot of my ssto in the Editor to showing the placement of the structural panels. They look larger because I'm using Tweakscale to bump up the size to 200%. I don't know whether this will work for all cases. YMMV. As you can see, I'm using KerbalFoundries for my landing gear. I don't know whether that is the reason why I ended up having to use the structural panels. KF landing gear don't have colliders while stock landing gear have. I did not spend time to try out the stock landing gear because I'm not a fan of them anyway.

Remember this? "Make sure your seatbacks and tray tables are in their fully upright and locked positions." (I never thought I'd miss those words until now)... In 1.11, you can add this. "Make sure your landing gear is stowed and the SAS is OFF." Landing gear and water don't mix apparently. Must be the spring and dampener logic trying to bounce the craft on water. And keep them stowed. SAS is trying to keep the craft level but the water is bouncing it around. Eventually, SAS will over-compensate enough to bounce your craft off the water high enough that it breaks into pieces when it lands/crashes back on the water. So... "Make sure your landing gear is stowed and the SAS is OFF."

Yes, at least for me, WorldStabilizer is still needed because of my insistence on using the OPT Humpback parts. Also, it is still needed when restoring saved games and launching craft that don't have any of the kraken inducing parts.

@Lisias, thank you for figuring this out and sharing it. Because Vessel Mover only allows the selection of 1 crew when spawning a craft, I now follow a 2 stage sequence when launching. I created a "bus" to carry the crew complement and launch it from Editor. Then, when Flight scene kicks in, and WorldStabilizer has done its stuff (I enabled the message to be displayed in the WS cfg file), I use VesselMover to spawn my spaceplane with a pilot. I then proceed to board the crew. Extra steps, but there's a bit of realism in it. And it allows me to still fly my craft that still uses the Humpback Cargo Ramp. Thank you, @JadeOfMaar, for keeping OPT updated.

You're right. TCA has since been fixed to address that issue. It fixes this by letting you assign a "Mode" to the engine when its "Role" is set to Maneuver only. So with your setup, your JE1 Turbofan must be assigned its own engine group - e.g. G2. Its "Role" set to Maneuver instead of Manual Control. Once you set it to Role=Manuever, Mode becomes available. Set Mode to Rotation and Translation. With engine group 1, G1, leave them at Thrust and Maneuver. Hint: once you get the hang of crusing around and stopping, try experimenting with setting them to Thrust only. In TCA parlance, Thrust means the engine is focused on providing lift, keeping your craft hovering. Maneuver is directed in the horizontal, either for moving laterally or rotating, moving your craft around. It would also be nice to put some RCS thrusters on your craft so that it can easily rotate and translate rather than relying on tilting the entire craft to redirect thrust. You might need some mods that provide you with RCS thrusters that share the same fuel with your engines. Once you've set it up that way, "cruising" around will be possible using TCA. Don't forget to set your maximum horizontal speed to get your craft moving in cruise mode. And remember that Stop means ALL STOP. Your craft will refuse to budge. If you want to nudge your aircraft around, Stop, then once stopped, toggle Stop off. But if you want to use Manual Control for horizontal engines instead... A note when setting Role=Manual Control. TCA uses Thrust Limiter to control engine output. To do this, TCA will set the throttle for that engine to 100% (Full Throttle) then fiddle with the Thrust Limiter to control engine output. For manual control engines, always set the their Thrust Limiter to zero in the editor or in the TCA Engine Profile. You don't want your horizontal engines in full burn when you turn on TCA. To control the manually controlled engines, bring up the TCA window, click on Engines Control, and toggle Show Manual Engines. It would be nice to be able to assign manual engines to a custom Axis Control Group - hint,hint @allista

That happens if the craft you're trying to assemble fits the assembly space.

I use the SimpleLogistics mod to allow craft share resources. Craft with larger tanks automatically top up craft with smaller tanks.

In my opinion, a working craft is not going to help you much. Even if you have a "working craft", you won't be able to enjoy it much without knowing how to control it. So below are some guiding principles on how to build and control a working craft. Just like anything to be learned, it's a pain.

For me, it works on KSP 1.10.1. VM is version 1.9.0. There is an issue though (which I've had since KSP 1.9 but I just considered it a minor one)... When spawning a vessel in any other body, VM freezes after loading the craft. Until I found out the workaround, I thought that the game itself froze. The workaround is to select the spawned craft by pressing "]" (switch to next vessel). If that doesn't work, try previous vessel. Actually, I was already using EasyVesselSwitch for dealing with groups of kerbals so for me, I just ALT-LMB click the spawned vessel to select it.

@allista, Thank you for pointing out the use of AutoThrottle. All this time, I've used TCA with Hover, FollowTerrain, and AutoThrottle on. And then just plugged-in numbers for altitude (I play sandbox so I have all the goodies from the get-go). I didn't know what I was missing. By being forced to use AutoThrottle, I learned other stuff like IndependentThrottle and how it works together with mapping engine throttle to CustomAxisGroups. I "fly" my craft now instead of just typing numbers to control my craft. Thanks!

Maybe it's just me... I installed the latest versions of TCA, Hangar, GC, CC and the separate AT_Utils download. With TCA, I can no longer input the desired altitude to hover using the keyboard. My keyboard has a numeric keypad. Input using both the keypad and the keyboard doesn't work. The -10/+10 buttons work, so I have a workaround, even if it takes a fair bit of clicks to get to something like 360 meters altitude. Here's the logs... https://www.dropbox.com/s/kf7a7t0twg7kgja/2020-07-23.zip?dl=0 Thanks.

btw, the anti-gravs do have a visible effect.

I'm also on KSP 1.10. However, I don't have the anti-grav texture issue above. I have the following mod versions: KerbalFoundries-2.4.8.18.zip (Feb 2020) TexturesUnlimited-1.5.10.25.zip (May 2020) KSPWheel-0.16.14.33.zip (May 2020) Last May, when updates to TU and KSPWheel came out, I deleted the TU and KSPWheel folders and replaced them with the latest versions. That's probably why I don't have issues in KSP 1.10.

Some good came out from the bug. Now that I've been forced to use sub-assemblies, I found out that instead of creating tanker ships, I can cram my SSTO Hangar with a bunch of cargo container sub-assemblies and haul lots of material. I still need a pair of external CC tanks that are partitioned to carry all types of resources, in order to facilate transfers/unloading of material since I can't transfer stuff directly to/from hangar cargo. When the external tanks are emptied, I just refill them from the hangar cargo using the "Transfer resource" function of the hangar. And once all the cargo sub-assemblies are empty, I can launch them so that nearby Workshops can recycle them. Less part count = smoother gameplay. If I want additional crew space, I can put a docking port inside the hangar and attach a crew module in the empty space ;) I know that's already abusing Hangar. But please, pleeease, don't kill that feature.

For me, the current layout where all the info is in 1 line/row is ok. The layout above splits that 1 line into 2 - 1st for type and the 2nd for the resource. The 3rd resource in the example, Material Kits, shows the "Edit Tank Volume" function which took me some tries to figure out how to complete. Didn't realize that I had to press ENTER to exit it. So adding a Done button in the UI is helpful. You can get rid of the fill percentage. At least with me, when I edit the tank, I have the PAW up, so I can see the fill percentage there. I assume the other numbers in the 2nd line are the fill units and mass. Those don't matter to me when I'm deciding to partition a tank. But they may be useful for others who demand precision. So maybe making some of the numbers optional even via a config file that can be edited offline, would be nice, so that I have the option to get rid of some of the numbers and end up with things being displayed in 1 line. As a note, one of the reasons I use CC is to spead out batteries and the mass associated with them. Since the batteries count towards dry mass, CC allows me to spread them out and fix the CoM of the ship when dry, without resorting to using separate parts for ballast. The current UI lets me do that without being cluttered. Maybe make the Type dropdown in the middle section, where the resource details are, compact. For example, instead of showing the whole "Liquid Chemicals", just show an abbreviation "LqC". Then when clicked to display the dropdown, show the abbreviation and description "LqC - Liquid Chemicals" - same goes for other types. That way, you have more room to play with in the 1st line of the details. We're more interested in the actual resource anyway. That's assuming you can have a dropdown list that is wider than the field being populated. It does mean that preset names have to be limited. Separate ask... Can you make it such that tanks can also be configurable in flight when empty? Give a cost to the conversion, similar to how Asteroid hatches can be reconfigured given resources are available. But with CC tanks, make it such that it can only be reconfigured when (docked) with a Workshop and some qualified engineers.

@allista, I just had a chance to use version 3.6.0.1 in KSP 1.10 and encountered an issue. I can't add ships to the hangar in the Editor. When I try to add ships, nothing happens when I click on Load after I select a ship. The good news is there is a workaround. Subassemblies load fine. Probably because you provided your own window to load them up instead of using the stock window like in loading ships. Here are the logs... https://www.dropbox.com/s/sgpkqeowglkmjck/log20200707.zip?dl=0

The videos in https://www.youtube.com/user/allistau pretty much covers the how-tos. From your screenshot, I see that the DockableKitContainer is docked using the wrong end. The stripes on the side of the kit serve a purpose. They tell you which end is which. Note that one end of the stripe has a D in a triangle. That's the "Construction Dock" end - or "Dock", for short. Which means the other end is the "Transport Dock" end. So when moving it around, your SpaceCrane should be docked to the Transport end. In your screenshot, it is docked to the Construction end. So if you flip the Kit around so that the Construction end - the one with a D - is docked to your Workshop, then the Kit should be ready for construction, assuming that the kit has been assembled.

Radial Hangar also works fine in 1.10. So at least for me, Hangar is good for 1.10.

@allista... I'm running 1.10. Just paid a visit to my Mun base made from a VTOL Hangar. No explosions, no krakens. TCA has some Nullrefs in the log but it's not spam level. I did crash and exploded on the 1st try to land but that was me messing around with the Collision Prevention System. So far, Hangar is OK with 1.10. Will try deploying some satellites using my radial hangar equipped SSTOs later.

I first encounted the use of __LOCAL from the Tweakscale forums. Yes, I'm aware of the MM documentation. However, over the course of chasing issues in my install across several releases, I noticed the pattern in the logs (KSP and Player) that the patches in __LOCAL are applied last. MM does several passes to apply CFGs. For each pass, stuff in __LOCAL are always executed last. They are logged that way for me so I just assumed that it's the same for everyone. Try it next time you try to patch something and look at the logs.

Haven't put in some 1.10 play time. I found an issue while launching 1.10. The affected part is Hangar\Parts\SmallHangar\Hangar1, module ModuleDeployableSolarPanel. To get past 1.10 hanging during startup, I created the following patch in GameData\__LOCAL - so that it is executed last and is separate from the mod folder. @PART[Hangar1] { !MODULE[ModuleDeployableSolarPanel] { } } The patch gets rid of ModuleDeployableSolarPanel from the part. SimpleLogistics is also similarly affected and I posted there as well. I don't use Ground Hangars in my games so getting rid of the offending module in 1 part is not an issue for me.

Narrowed the issue down to a single PART/MODULE - PART[DeployedSolarPanel], MODULE[ModuleDeployableSolarPanel]. Instead of renaming the CFGs, I created a new CFG in GameData/__LOCAL. From what I understand, the __LOCAL folder is where MM expects user-created patches and executes them last. I don't want to mess with the files in the mod folder because I just manually install mods (I always delete the old mod folder and drop-in the up-to-date one). However, even though I placed the patch in __LOCAL, and it's supposed to run last, because DeployableScience.cfg adds the ModuleDeployableSolarPanel a 2nd time using the LAST directive, I had to use the FINAL directive in my local fix. I know how the mod authors are against using FINAL. Let me emphasize that this is a user-created patch in __LOCAL. I called the patch 110SimpleLogistics.cfg. Patch follows... I don't use the affected part so I don't know how the patch affects it. I just want to get past firing up 1.10. I'll play around in the weekend to see if my saved games still work.

If you're able - maybe you have a save game - try the toggle dock but this time, display the autostruts first (Alt-F12/Physics/Display autostuts) before toggling dock. Observe how the autostruts change during the docking process. I suspect that all the bouncing and possible whipping around is caused by the re-rooting and repositioning of the CoM when the ships are docked. If so, you can mitigate this by changing the autostruts of each ship such that no part is autostrut to root. Also try to eliminate any autostrut to heaviest. When the 2 ships are docked and you start moving resources around, the combined CoM of the 2 ships will move and anything autostrut to heaviest will move too. Another way is to eliminate the need to dock. Try out SimpleLogistics. It allows 2 or more ships to share resources.

After I saw the GC requirements for my Munbase in the Editor (2.6M Sp + 2.6M MK), I decided to take some shortcuts since I already have a working harvesting and manufacturing facility in the RockArch crater where I will situate the base - I used VesselMover to spawn my base on the Mun Some pics...