Jump to content

Morse

Members
  • Posts

    246
  • Joined

  • Last visited

Reputation

269 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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).
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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
  7. 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.
  8. 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
  9. 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.
  10. Is the update needed? I never launched 1.9, so I don't really know, but no bugreports so far.
  11. 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.
  12. 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.
  13. 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.
  14. 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?
  15. 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.
×
×
  • Create New...