jkadarn

Members
  • Content Count

    4
  • Joined

  • Last visited

Community Reputation

0 Neutral

About jkadarn

  • Rank
    Newbie
  1. I had the same bug and managed to reproduced it with only FAR (0.14.3.2) installed. See: http://forum.kerbalspaceprogram.com/threads/20451-0-25-Ferram-Aerospace-Research-v0-14-3-2-10-21-14?p=1547265&viewfull=1#post1547265
  2. I tried to make a custom install stanza, but I'm not sure what's the best way to do it. ^^ The path in the archive is: KerbalAlarmClock_3.0.4.0/GameData/TriggerTech/KerbalAlarmClock Is there a way to avoid a version-dependent "install_to" directive in this case? "install": [ { "file" : "KerbalAlarmClock_3.0.4.0/GameData/TriggerTech", "install_to" : "GameData" } ]
  3. Hello! It seems that Kerbal Alarm Clock is installed in <ksp>/GameData/KerbalAlarmClock/ but it should be <ksp>/GameData/TriggerTech/KerbalAlarmClock/ I guess the structure of the 7z archive is the problem here. I'm not sure how the metadata file should be modified to handle this...
  4. I also encounter this issue quite frequently, on Kerbal 0.25, win32, with only Module Manager 2.5.1 & FAR 0.14.3.2. On my computer, the warp duration needed to get this bug seems to be around 5~10mn (real time), no matter the speed or the location (landed on Kerbin, LKO, GKO) I wasn't able to reproduce it on linux (either 32 or 64 bits), but that was on another computer. I couldn't reproduce the bug with the previous version of FAR (0.14.3.1).