Kerbal Construction Time/StageRecovery Dev Thread

[SpacedInvader]

I've narrowed it down to an issue with MechJeb. I'll have to try a newer version when I get home from work tonight to see if the problem persists.

[severedsolo]

I'm runnning mechjeb, none of the others

[ericwdhs]

I also have considered doing something like this, as I'm not a big fan of people building rockets in the VAB or planes in the SPH. I had also considered dropping the rate of whichever building isn't used (choose VAB or SPH at game start, set that one to 1BP/s and the other to 0.5BP/s). Other people have expressed that they like being able to build vessels wherever they want, and once you are sufficiently upgraded using the SPH for rockets isn't as practical. I haven't decided if I'm going to change anything yet or not. If people really want to go out of their way to build things in the "wrong" building, I don't know if I should stop them.

The unified queue is a good solution though, but from a gameplay aspect I like upgrading the two buildings separately. If anyone else has an opinion on this, let me know. It's easy enough, imo, to just limit yourself from building in the wrong building.

Instead of unifying the queue or penalizing use of both buildings, could you have incentives/penalties tied to the actual type of craft? It would make sense considering the buildings are supposed to be specialized. I'm not familiar with KSP's internals, but it seems like it should be as easy as the coding equivalent of: "If the ship launches with thrust down, it's a rocket. It will take twice as long to build in the SPH. If the ship launches with thrust horizontal, it's a plane. It will take twice as long to build in the VAB." Personally, I'd prefer a penalty more on the order of 5 or 10 times as long, but twice is good for easing up gameplay.

Edited June 28, 2014 by ericwdhs

[SpacedInvader]

Instead of unifying the queue or penalizing use of both buildings, could you have incentives/penalties tied to the actual type of craft? It would make sense considering the buildings are supposed to be specialized. I'm not familiar with KSP's internals, but it seems like it should be as easy as the coding equivalent of: "If the ship launches with thrust down, it's a rocket. It will take twice as long to build in the SPH. If the ship launches with thrust horizontal, it's a plane. It will take twice as long to build in the VAB." Personally, I'd prefer a penalty more on the order of 5 or 10 times as long, but twice is good for easing up gameplay.

How would you account for VTOLs then? I honestly don't see what's wrong with the current situation outside of code efficiency. If people want to waste points upgrading the SPH to build rockets instead of upgrading the VAB, then I say let them. The end game result is always going to be highly upgraded version of both anyway...

[ericwdhs]

How would you account for VTOLs then? I honestly don't see what's wrong with the current situation outside of code efficiency. If people want to waste points upgrading the SPH to build rockets instead of upgrading the VAB, then I say let them. The end game result is always going to be highly upgraded version of both anyway...

VTOLs would follow the same rules. It just wouldn't be as elegant. If what you actually set to build is tweaked to vertical thrust, assume it's better off launching from the launchpad. If it's tweaked to horizontal thrust, assume it's better off on the runway. Make that clear to the user and you should have no problems. Even if the user does split points half SPH, half VAB, they should get what they want eventually. It'll just take longer overall, and that's perfectly fine since developing VTOL craft takes more time and effort in the real world anyway.

That all said, I only replied because magico said he's "not a big fan of people building rockets in the VAB or planes in the SPH" (I assume VAB and SPH are supposed to be switched.) I agree with him there, but I think the proposed solution of unifying the queue doesn't actually do anything to solve that. It would only remove the distinction between SPH and VAB, and that's a step backward. Then again, I haven't gotten more than few minutes into testing this mod (just saw it today), so I'm may have missed the obvious or woefully misinterpreted some stuff about how the mod works. I'm also assuming there's an easy way to read a craft's thrust direction, the one given by the Center of Thrust icon in the editor. I really don't know how feasible my "solution" to this one concern is.

[TurielD]

Guto8797 was reporting the same bug a few pages back. If you can get me a log I can see if anything is being reported there that might explain the problem. Hopefully that bug actually has an error associated with it in the log...

Unfortunately nubby question: How do I save a log of game events?

[severedsolo]

Camera Sim Error happened again: https://www.dropbox.com/s/ivrtklna104p7ty/output_log.txt

Don't know if it helps, but it kicked in when I reverted to editor after already running a simulation once (I used the KSP menu, not KCTs)

[magico13]

Instead of unifying the queue or penalizing use of both buildings, could you have incentives/penalties tied to the actual type of craft?

That's a pretty cool way of handling it (and I definitely switched VAB and SPH in that quote, derp). For simplicity's sake what I've done in my dev version is drop the initial build rates to 0.1 and given the user 15 upgrades. I may need to increase that number though, since it isn't quite enough to reach 1BP/s in either facility (0.85BP/s actually, 0.1 in the other). I like the early game flexibility this provides, as the user has more options at first and there's more buildup required to reach the comparatively high rates of late game. Also it's way simpler to code

Unfortunately nubby question: How do I save a log of game events?

Nothing special you need to do, just find the Kerbal Space Program folder on your computer, go into the KSP_DATA folder and find output_log.txt. Simple as that

Camera Sim Error happened again: https://www.dropbox.com/s/ivrtklna104p7ty/output_log.txt

Don't know if it helps, but it kicked in when I reverted to editor after already running a simulation once (I used the KSP menu, not KCTs)

I'll take a look but I'm afraid that the log won't have anything too useful. I'm going to compare mechjeb versions to see if there's anything corresponding there.

[SpacedInvader]

So updating to the newest dev build of MechJeb *seems* to have fixed the locked view issue.

[magico13]

I'll take a look but I'm afraid that the log won't have anything too useful. I'm going to compare mechjeb versions to see if there's anything corresponding there.

Well, this time the log actually contained an error that would explain the camera lockup, but unfortunately not a reason for why it happened. I'll keep looking to see if I can figure something out though.

NullReferenceException: Object reference not set to an instance of an object
  at FlightCamera.GetAutoModeForVessel (.Vessel v) [0x00000] in <filename unknown>:0 

  at FlightCamera.setMode (Modes m) [0x00000] in <filename unknown>:0 

  at FlightCamera.setModeImmediate (Modes m) [0x00000] in <filename unknown>:0 

  at MapView.exitMapView () [0x00000] in <filename unknown>:0 

  at MapView.ExitMapView () [0x00000] in <filename unknown>:0 

  at FlightUIModeController.SetMode (FlightUIMode mode) [0x00000] in <filename unknown>:0 

  at FlightUIModeController.Start () [0x00000] in <filename unknown>:0 

So updating to the newest dev build of MechJeb *seems* to have fixed the locked view issue.

Ok, keep me posted. It's starting to look like there are multiple sources of this bug, as they usually don't have anything in the log file.

[SpacedInvader]

So I've stumbled across a new bug. Sometimes when switching vehicles, a whole slew of functionality ceases to function properly. Here's how it manifests:

- Revert buttons and space center button in the escape menu stop working.

- Quicksave stops working

- Switch vessels stops working

- All vessel icons and orbits in the map view are gone

The only way to get everything back is to restart the game and even then, jumping back to the situation you just got stuck in can cause the whole thing to start over again. I'm not 100% sure KCT is entirely at fault, but when I had a look at the logs after this happened, there were a lot of null reference exceptions attached to KCT and then removing KCT from my GameData folder fixed the issue.

EDIT: Trying to replicate it again so I can deliver the logs

Edited July 2, 2014 by SpacedInvader

[SpacedInvader]

Ok, here's the KSP and the Output logs zipped. Looks like something super nasty happened as there are actually something like 1.1 million lines in the output log relating to null reference exceptions. That being said, I'm not 100% sure KCT has anything to do with it, but the behavior most certainly stops with KCT taken out of GameData.

https://drive.google.com/file/d/0BzPO9eXfO6xGazR0SnhYSEE2MjQ/edit?usp=sharing

[montyben101]

Will this work on an already started save? also will it work with mods?

[SpacedInvader]

Will this work on an already started save? also will it work with mods?

Yes and yes

[montyben101]

Sorry but im still confused as to what "build points" are? do you spend them to make ships build faster and then earn more from..... somthing?

[SpacedInvader]

Sorry but im still confused as to what "build points" are? do you spend them to make ships build faster and then earn more from..... somthing?

Ships cost a certain amount of build points based on how complex they are (which parts and how many). Your KCT will build those ships at a rate of x build points per second (pretty sure its per second), with the default being 1bp/s. You can upgrade your KCT to build ships faster or more at the same time.

[montyben101]

Ok i think i get it now, ships cost build points and then after they are complete the build points are returned to be used again on a different craft?

[JeffreyCor]

Build points are how much "work" it takes to make the ship. They aren't a resource so don't get "spent" but are completed by how fast each of your assembly line works, which is akin to how advance your construction facility is. Simple examples would be a basic ship being 1000 built points (BP) on a construction like that can manufacture at 1 built point per second (BP/s) would take 1000 seconds to complete. That same ship on a line that can produce at 2BP/s would take 500 seconds to finish. Similarly, a complex ship could require say 10,000BP which makes the prospect of upgrading assembly lines attractive. This is what the upgrade points are utilized for (as well as other neat things )

[montyben101]

Ah i get it now thanks

[magico13]

Ok, here's the KSP and the Output logs zipped. Looks like something super nasty happened as there are actually something like 1.1 million lines in the output log relating to null reference exceptions. That being said, I'm not 100% sure KCT has anything to do with it, but the behavior most certainly stops with KCT taken out of GameData.

https://drive.google.com/file/d/0BzPO9eXfO6xGazR0SnhYSEE2MjQ/edit?usp=sharing

Looking through the logs there are a large number of Null Reference Exceptions starting with the second flight. KCT mentions some errors with the Crew Selection GUI (which I've already fixed in the latest version, but which don't have any real effect). The NRE's mentioned are with the PersistentEmitterManager.FixedUpdate(), which seems to be a KSP function. Then it appears as if you reverted several times, with the same errors, then only in the last two flight attempts does it mention anything with KCT (with the OnDestroy event, but specifically with trying to get the active vessel (I may need to add a check for if FlightGlobals is null, but it shouldn't be during a flight). It all seems to be spurred on from an initial error when going from the Space Center to Flight, but nothing mentioned with KCT (though KCT initiates the change, so it's entirely possible it's at fault).

Is this only with a specific ship? Is it only with the second flight?

(I've found that even if KCT is never mentioned, there's a decent chance it is still at fault. There are so many weird bugs with KSP that can get called upon by seemingly normal things with KCT)

Ok i think i get it now, ships cost build points and then after they are complete the build points are returned to be used again on a different craft?

Not quite. Build Points are just a convenient way to describe the complexity/cost of the vessel. They aren't a "tangible" thing, per se. When a ship is being built it is done so at a rate of X Build Points per second (the default at this time is 1BP/s but can be upgraded). When the progress exceeds the number of Build Points that a ship is worth, the ship is finished. It should be pretty clear when you start playing with it. The total amount of time that a ship will take to complete (in seconds) is just the number of Build Points divided by the rate.

It's basically a unit of time, and prior to the upgrades update it was just the total time (since before upgrades there was only a single 1 BP/s rate per building). So just think of it like the total build time.

Edit: Ninja'd and with a response that was probably clearer than mine

Edited July 2, 2014 by magico13

[montyben101]

Right i just launched a craft and even though i selected crew only the commanding (root part) was filled with crew and not the crew container below?

(400th post!)

Edited July 2, 2014 by montyben101

[magico13]

Right i just launched a craft and even though i selected crew only the commanding (root part) was filled with crew and not the crew container below?

Using the launch button from the Build List I'm assuming? The Crew Select GUI has a ton of bugs that no one has ever reported that I'm working on fixing. It depends on the parts being ordered the same way in the file as in flight, which may not be the case (or the code is just messed up) as I've seen similar issues (it was trying to assign crew to the radiators...). The debug log would likely contain some text saying that KCT tried to assign crew to a part but it exceeded the crew capacity. I'll likely be rewriting that code for the next version. In the mean time, you may need to use Crew Manifest or Ship Manifest. I'd like to get that update out in a few days though, if not as soon as later today.

[montyben101]

We'll apart from said bugs this mod is amazing! It adds so much more to the game than just launch crafts whenever you want!

[SpacedInvader]

Looking through the logs there are a large number of Null Reference Exceptions starting with the second flight. KCT mentions some errors with the Crew Selection GUI (which I've already fixed in the latest version, but which don't have any real effect). The NRE's mentioned are with the PersistentEmitterManager.FixedUpdate(), which seems to be a KSP function. Then it appears as if you reverted several times, with the same errors, then only in the last two flight attempts does it mention anything with KCT (with the OnDestroy event, but specifically with trying to get the active vessel (I may need to add a check for if FlightGlobals is null, but it shouldn't be during a flight). It all seems to be spurred on from an initial error when going from the Space Center to Flight, but nothing mentioned with KCT (though KCT initiates the change, so it's entirely possible it's at fault).

Is this only with a specific ship? Is it only with the second flight?

(I've found that even if KCT is never mentioned, there's a decent chance it is still at fault. There are so many weird bugs with KSP that can get called upon by seemingly normal things with KCT)

In the specific case of these logs there should have only been one flight which was reverted twice, with the second one being the one where everything stopped working. I was trying to land on the Moon and my dV budget was a lot tighter than I should have allowed for so my descent stage kept running out of fuel at about 100m-200m and I was trying different profiles to try and get it down. Anyway, my thinking based on the nature of the failure (all of the buttons ceasing to function) that this *may* be related to KCT's disabling of the launch button. I haven't had a chance to look through your code at all, but are you managing the click event or are you disabling the button in a different manner?

As for KCT being at fault even though it might not be mentioned, I can believe that, though I definitely wouldn't rule out negative interactions with other mods. It seems that KCT does, however, have a bad habit of exacerbating issues with other mods that KSP might be able to ignore otherwise such as the camera issues with MechJeb.

EDIT: I guess I'll just have to avoid reverting as much as possible from now on.

[magico13]

The disabling of the launch button in the editor is performed by setting a control lock (visible in the debug menu if you have it display all the current locks). The code for that is InputLockManager.SetControlLock(ControlTypes.EDITOR_LAUNCH, "KCTLaunchLock"); and is the same thing that KSP does when you open the Load menu in the editor. Simulating from the editor is performed with this function: EditorLogic.fetch.launchVessel(); along with some additional locks (quicksave and quickload, along with vessel switching in the public version [removed in the new update]). Launching from the Build List is performed with these two functions (the first is part of the GUI [specifically the VAB storage], the second is contained within the KCT_BuildListVessel class):

                    if (GUILayout.Button("Launch", GUILayout.ExpandWidth(false)))
                    {
                        KCT_GameStates.launchedVessel = b;
                        if (ShipAssembly.CheckLaunchSiteClear(HighLogic.CurrentGame.flightState, "LaunchPad", false))
                        {
                            if (!IsCrewable(b.ExtractedParts))
                                b.Launch();
                            else
                            {
                                showBuildList = false;
                                centralWindowPosition.height = 1;
                                KCT_GameStates.launchedCrew.Clear();
                                partNames = KCT_GameStates.launchedVessel.GetPartNames();
                                parts = KCT_GameStates.launchedVessel.ExtractedParts;
                                pseudoParts = KCT_GameStates.launchedVessel.GetPseudoParts();
                                KCT_GameStates.launchedCrew = new List<CrewedPart>();
                                foreach (PseudoPart pp in pseudoParts)
                                    KCT_GameStates.launchedCrew.Add(new CrewedPart(pp.uid, new List<ProtoCrewMember>()));

                                showShipRoster = true;
                            }
                        }
                        else
                        {
                            showBuildList = false;
                            showClearLaunch = true;
                        }
                    }

public void Launch()
{
      KCT_GameStates.flightSimulated = false;
      string tempFile = KSPUtil.ApplicationRootPath + "saves/" + HighLogic.SaveFolder + "/Ships/temp.craft";
      shipNode.Save(tempFile);
      FlightDriver.StartWithNewLaunch(tempFile, flag, launchSite, new VesselCrewManifest()); //flag is the location of the flag as set by the editor, launchSite is either "launchpad" or "runway", the last thing is an empty crew list since the crew selection gui takes care of that
}

(All code here is from the development version. There are slight changes from the current public version, which is available on the main branch of the github page [this is all on the dev-branch])

AS you can see, I don't really ever understand all the issues with launching as of late since the functions I use are part of KSP. The one time I tried writing my own it never worked.

The buttons ceasing to function is likely KSP failing to execute the functions required for scene change (same thing happens when the persistence fails to save). The log shows 10 total changes to flight scenes, the first being fine but starting with the second there were issues. 8 of them are from flight to flight after the flight that had issues. Some of them are this short

 [HighLogic]: =========================== Scene Change : From FLIGHT to FLIGHT =====================

Tac.LifeSupportController[FFED6468][2541.58]: Game scene load requested: FLIGHT

NullReferenceException
  at (wrapper managed-to-native) UnityEngine.GameObject:get_transform ()
  at PersistentEmitterManager.OnSceneChange (GameScenes scene) [0x00000] in <filename unknown>:0 
  at EventData`1[GameScenes].Fire (GameScenes data) [0x00000] in <filename unknown>:0 
  at HighLogic.LoadScene (GameScenes scene) [0x00000] in <filename unknown>:0 
  at FlightDriver.RevertToLaunch () [0x00000] in <filename unknown>:0 
  at PauseMenu.drawRevertOptions () [0x00000] in <filename unknown>:0 
  at MultiOptionDialog.drawContent (Int32 id) [0x00000] in <filename unknown>:0 
  at UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) [0x00000] in <filename unknown>:0 
  at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0  

Though I am now seeing a change between this later one and the initial errors, as this one mentions an issue with reverting and the initial one references an error with FlightDriver.StartAndFocusVessel (but more specifically with the PersistentEmitterManager)

NullReferenceException
  at (wrapper managed-to-native) UnityEngine.GameObject:get_transform ()
  at PersistentEmitterManager.OnSceneChange (GameScenes scene) [0x00000] in <filename unknown>:0 
  at EventData`1[GameScenes].Fire (GameScenes data) [0x00000] in <filename unknown>:0 
  at HighLogic.LoadScene (GameScenes scene) [0x00000] in <filename unknown>:0 
  at FlightDriver.StartAndFocusVessel (.Game stateToLoad, Int32 vesselToFocusIdx) [0x00000] in <filename unknown>:0 
  at QuickSaveLoad.quickLoad (System.String filename, System.String folder) [0x00000] in <filename unknown>:0 
  at QuickSaveLoad.onHoldComplete () [0x00000] in <filename unknown>:0 

NullReferenceException
  at (wrapper managed-to-native) UnityEngine.GameObject:get_transform ()
  at PersistentEmitterManager.FixedUpdate () [0x00000] in <filename unknown>:0