Morse

Hanging during the loading screen might be it. Looks the same based on the description. Unfortunately I moved away from my computer and can't just PR the fix. I'll be back only in a month.

Ok, there is this line in the logs: [ERR 12:08:17.224] ADDON BINDER: Cannot resolve assembly: PreciseManeuver.Unity, Culture=neutral, PublicKeyToken=null That means something is wrong with the unity assembly. I guess some rebuilding is required. But then again, it works for some people, so maybe there is some other problem. The bad news is, that to fix it I need a proper dev environment, which I won't have for some time (I just moved to another country).

I never launched 1.12, so no idea how this works there. Also, I'm not sure I'll have time for an update in the next ~couple of months. But I can look into logs, maybe there is something simple there.

I was actually waiting for this to surface. I had the same error. But my version of AA is modified, so I was not sure whether it was just me. The problem is that the fix is non-trivial, it involves the GimbalRearranger. The idea for loaders is that the StartLoad() finishes quickly, and just starts a coroutine that does the heavy lifting. The coroutine should also yield regularly, so that the screen does not freeze. GimbalRearranger just does everything synchronously in the main thread, which, apparently, unity have an issue with. If the method takes too long - everything hangs forever. The trick is to know how long is "too long". My guess is that it has something to do with the framerate. Long story short, StartLoad() should StartCoroutine(), everything else should go inside that coroutine, yield return null should be inside the loops in coroutines to not stutter the framerate.

Can you look through your mods and try to find out which one might cause this? Only the ones that have an icon in modpanel are interesting.

Logs please. https://forum.kerbalspaceprogram.com/index.php?/topic/163863-how-to-get-support/ Both here or GitHub are good, but I usually notice GitHub quicker.

No specific formulae. The speed that is needed for the circular orbit is found from the centripetal acceleration: g = v^2 / r. Then I just rotate the speed vector to be coplanar with the maneuver current speed vector, and subtract the current speed. You can find the code here https://github.com/radistmorse/KSPPreciseManeuver/blob/master/src/NodeManager.cs#L300

Love this, yet I have a problem with the cockpits. They are very large but not very heavy. Since the engines are located in the back most of the times, it makes it very difficult to make a proper weight balance without clipping. I understand that the cockpit must be big to have a proper aerodynamic form, but maybe it can be smaller on the inside? I propose to combine the cockpit with the service bay: carve some space from inside it to be able to place something heavy in there without clipping. Just like you already did for the crew compartment.

Ok, I may have found an error. I can't test it myself since I don't have KSP installed, but try to replace the dll with this one: https://drive.google.com/file/d/1slOZNTpA62T8LZW2aH32yil8JJ1A93ro/view?usp=sharing If it works I'll put it in a new release

First of all, I'll need the logs to look into any issues. Second of all, if you think that errors correlate with the previously-hidden mods, maybe delete the mod config (the xml files inside the mod folder) and try to setup everything anew.

Is the update needed? I never launched 1.9, so I don't really know, but no bugreports so far.

That's gonna be hard, since while the vessel is off-rails it basically constantly changes its orbit. The "orbit" itself is just a prediction, which is strictly followed only when the vessel is on-rails. As soon as physics kicks in - all bets are off where exactly the vessel will fly.

I just want to point out that all the VS solutions come with a set of unique GUIDs, which will end up to your dll. It is always a good idea to keep the GUIDs unique, even though I never heard of any actual issues of several dlls having the same GUID. Still, if you start your mod based on someone else's sources, you should probably re-generate all the GUIDs. Also, don't forget about the license, which should remain compatible.

The fact that it's available on CKAN doesn't mean that it is supported. Yes, you may try to install it through CKAN (and I'm sure most people do), and it will probably work. But if it doesn't, or of the release is not updated on CKAN, you'll have to find someone else to solve these problems.

This is not right. It should call for v180_ModuleControlSurfaceFixed.OnUpgrade instead. Is there a line "[UpgradeScriptFix] Successfully replaced the v180 upgrade scripts." somewhere in the beginning of the log? For me it happens right after the main menu loading, like this [LOG 19:53:42.059] [HighLogic]: =========================== Scene Change : From LOADING to MAINMENU ===================== [LOG 19:53:43.147] [AddonLoader]: Instantiating addon 'ContractDefs' from assembly 'KSP' [LOG 19:53:43.174] [AddonLoader]: Instantiating addon 'UpgradeScriptFix' from assembly 'KSPUpgradeScriptFix' [LOG 19:53:43.188] [ReflectionUtil]: Found 20 types with UpgradeModule attribute in 62 assemblies. [LOG 19:53:43.197] [UpgradeScriptFix] Successfully replaced the v180 upgrade scripts, fixed 1 + 1 scripts. And if not, are there some exceptions from KSPUpgradeScriptFix.UpgradeScriptFix.Awake? How did you install the mod? Is there a file KSPUpgradeScriptFix.dll somewhere?

That is very expected, since trajectories uses different bin files for different versions. If you are feeling adventurous, you can rename Trajectories18.bin into Trajectories19.bin, and see what happens.

You don't need to bundle the models themselves to use them in your mod. They are already in the game. That being said, you should probably pay attention to the re-stock mod and take some extra steps to make your mod compatible with it.

Hi @HyperFun. I see a lot of files inside your mod, for which you are not the author. While you can use the content from other mods inside your compilation, you should list all the mods and all the authors from which you took. Also, you must be sure that your license is compatible. You can't just slap "do whatever you want" (which is basically CC-0) to other people's work. Some files that you use are from squad. First of all, you are not allowed to use them in your mod. Second of all, you don't need to. If you want to modify the default configuration you should use module manager for that. Speaking of which, I see that your mod depends on MM, Kopernicus, TweakScale, BDArmory and probably lots of other mods. You should list all them in the OP, if you want people to be able to use your mod. Also, your mod adds a lot more than what you have listed. Even if you want to make some things "secret", you should still list them. You could use spoiler container for that.

In Unity game in most of the cases all the game logic is stored in the Assembly-CSharp.dll file. It has nothing to do with debug. For debug you need to attach to the running process to observe it step-by-step. This is just looking at the sources. And I wouldn't recommend looking at KSP sources for educational purposes. They are terrible.

Used for a bit @Devoblue's version of mod for 1.8. Right after some crash got a bunch of those: [EXC 18:00:16.606] NullReferenceException FerramAerospaceResearch.FARAeroComponents.FARVesselAero.SimulateAeroProperties (UnityEngine.Vector3& aeroForce, UnityEngine.Vector3& aeroTorque, UnityEngine.Vector3 velocityWorldVector, System.Double altitude) (at <6338ca968c7c4c8a971a01d858e759df>:0) FerramAerospaceResearch.FARAPI.CalculateVesselAeroForces (Vessel vessel, UnityEngine.Vector3& aeroForce, UnityEngine.Vector3& aeroTorque, UnityEngine.Vector3 velocityWorldVector, System.Double altitude) (at <6338ca968c7c4c8a971a01d858e759df>:0) System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0) Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation. System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0) System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0) Trajectories.FARModel.ComputeForces_Model (Vector3d airVelocity, System.Double altitude) (at <d900c2c6cc8646f093c1ac4037e93254>:0) Trajectories.VesselAerodynamicModel.ComputeForces (System.Double altitude, Vector3d airVelocity, Vector3d vup, System.Double angleOfAttack) (at <d900c2c6cc8646f093c1ac4037e93254>:0) Trajectories.VesselAerodynamicModel.GetForces (CelestialBody body, Vector3d bodySpacePosition, Vector3d airVelocity, System.Double angleOfAttack) (at <d900c2c6cc8646f093c1ac4037e93254>:0) Trajectories.Trajectory+<>c__DisplayClass51_0.<AddPatch>b__0 (Vector3d position, Vector3d velocity) (at <d900c2c6cc8646f093c1ac4037e93254>:0) Trajectories.Trajectory.RK4Step (Trajectories.Trajectory+SimulationState state, System.Func`3[T1,T2,TResult] accelerationFunc, System.Double dt, Vector3d& accel) (at <d900c2c6cc8646f093c1ac4037e93254>:0) Trajectories.Trajectory+<AddPatch>d__51.MoveNext () (at <d900c2c6cc8646f093c1ac4037e93254>:0) Trajectories.Trajectory+<ComputeTrajectoryIncrement>d__42.MoveNext () (at <d900c2c6cc8646f093c1ac4037e93254>:0) Trajectories.Trajectory.ComputeTrajectory (Vessel vessel, Trajectories.DescentProfile profile) (at <d900c2c6cc8646f093c1ac4037e93254>:0) Trajectories.Trajectory.Update () (at <d900c2c6cc8646f093c1ac4037e93254>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) Not sure if it is FAR fault or trajectories'

Ignoring by name would be cludgy. The ModuleControlSurface that is included with this engine has some very specific set of parameters ctrlSurfaceArea = 0 ignorePitch = true ignoreYaw = true ignoreRoll = true I guess either ctrlSurfaceArea = 0 or the fact that all the controls are ignored will be enough to understand that this is not the part you are looking for . You could safely ignore those.

There are some problems yet with SyncModuleControlSurface aside from update scripts. Right now, I noticed that some engines from Mk2 expansion mod do not work properly. There is this VTOL engine that uses ModuleControlSurface to turn itself into vertical position using the "deploy" action. And it doesn't work properly. The deployment happens fast, much faster than it should be, and the retraction happens instantly. I looked at the code of the vanilla ModuleControlSurface.CtrlSurfaceUpdate, and I see that it differs substantially from what you have. What was the original purpose of this module? Is it still needed? I tried disabling the GimbalRearranger, and it still worked (and fixed the issue with the VTOL deployment). Maybe it was meant to fix the KSP problems that are long gone? Also, why do you use the custom module loader. Isn't it the purpose of the module manager?

Yes, I'll have to deal with that. But nobody even noticed that for several years, so I guess it's not that big of a problem.

No. But there are almost no changes since 1.5.2, you can use that.

Nothing unusual there. But anyway, I just published a new version. At least it shouldn't crash anymore.