Jump to content

0level

Members
  • Posts

    7
  • Joined

  • Last visited

Reputation

0 Neutral

Profile Information

  • About me
    Bottle Rocketeer

Recent Profile Visitors

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

  1. Same here on Win10 64 bit. It really happens often and reloading the scene is a rather annoying "workaround". I use a couple of mods (some affecting the nodes) but it seems to happen in vanilla, as well. The bug is already listed here: http://bugs.kerbalspaceprogram.com/issues/8212 I really hope that this one gets a fix, soon!
  2. Hi Ferram, I just wanted to thank you for the latest dll (Jan 17: https://github.com/ferram4/Kerbal-Joint-Reinforcement/blob/master/GameData/KerbalJointReinforcement/Plugin/KerbalJointReinforcement.dll). It fixed the problem with undocking for me. Without your fix the guys would still be stuck in LKO. Cheers, 0level
  3. Hi, I have an issue when deactivating a cam (NavCam). It does not seem to matter whether I am actually using it (looking through it) or not. The normal view is messed up. I was using an action for deactivating it so I thought Action Groups Extended was the issue but Diazo (the author) double checked and said that the error occurred in Hullcam VDS (see thread here: http://forum.kerbalspaceprogram.com/threads/74195-0-90-%28Jan31-15%29-Action-Groups-Extended-250-Action-Groups-in-flight-editing-Now-kOS-Support%21/page74). It would be great if Hullcam could switch back to the normal view when deactivating a cam (when no others are active) or if there would be an action bindable to 'exit hullcam view'. The AGX mod caught the exception - maybe its helpful: [LOG 21:56:15.288] AGX RTQueue Fail&Recover 1 System.TypeLoadException: Could not load type 'System.Func`2' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. at MuMechModuleHullCamera.DeactivateCameraAction (.KSPActionParam ap) [0x00000] in <filename unknown>:0 at BaseAction.Invoke (.KSPActionParam param) [0x00000] in <filename unknown>:0 at ActionGroupsExtended.AGXFlight.ActivateActionGroupActivation (Int32 group, Boolean force, Boolean forceDir) [0x00000] in <filename unknown>:0 at ActionGroupsExtended.AGXFlight.CheckRTQueue () [0x00000] in <filename unknown>:0 EDIT: I did not see Agathorn report a few posts back. So this is merely a repost. Cheers, 0level
  4. Hi Diazo, yes, I use Hullcam VDS and you are right. That seems to be the problem - I did not recognize the exact timing the error occured. Your fix (1.30b) worked around the fatal consequences ot the problem just fine! Thank you so much. I will ask the author of Hullcam VDS about the remaining issue or switch to another cam mod. Cheers, 0level
  5. Hi Diazo, sorry, my work-life had the best of me, yesterday. As promised I will send you the complete log file as a pm in a few secs. I got the following error message 104282 times: [LOG 00:23:39.257] AGX RTQueue Fail 1 System.TypeLoadException: Could not load type 'System.Func`2' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. at MuMechModuleHullCamera.DeactivateCameraAction (.KSPActionParam ap) [0x00000] in <filename unknown>:0 at BaseAction.Invoke (.KSPActionParam param) [0x00000] in <filename unknown>:0 at ActionGroupsExtended.AGXFlight.ActivateActionGroupActivation (Int32 group, Boolean force, Boolean forceDir) [0x00000] in <filename unknown>:0 Busy litte beaver... This is what it looks like in-game: I hope it helps to track down that nasty bug. Good hunting! 0level
  6. Hey, thanks for the quick reply. I will gladly do so when I get home and squeeze it in. Hopefully this evening (gmt +1). Cheers.
  7. Hi Diazo, I am using your great(!) mod together with Actions Everywhere and RemoteTech (besides a lot of others). I built a service craft with a grabbing unit locally controlled by Jebediah to catch some (pre-RemoteTech) satellites. After launch the actions are queued although they are issued locally. I tried bypassing them which works at first until I clamp to something in which case the bypass seems to be overridden (although the gui still displays the message). The queue shows all triggered actions followed by increasing negative numbers and they're never fired. After entering this state bypassing via the gui button does not seem to work any more; the stack is still filled. Triggering parts directly works, though. In a locally controlled craft the queue should not be used, right? Am I missing something here? I updated to 1.30a today and did not test this before. RT is v1.6.2. Cheers, 0level
×
×
  • Create New...