Start on archive yields "power starved" when powered up with no KSC connection.

[ghost]

The expected behavior is for it to actually turn on, and just require you to switch to the local volume to run anything. Instead, it just gives the very unhelpful "power starved" message, even if there's plenty of power. (Edit: This is while there is a Kerbal in the command pod, so I do have local control of the ship.)

Note that an already powered on computer which loses connection works fine, and can still run scripts from the local volume. It's apparently only if it runs out of power, or has the power turned off, that it stops working.

Ship tested was: 1x Mk1 command pod 1x CX-4181 Scriptable Control System 1x SP-L 1x6 Photovoltaic Panels 1x Comms DTS-M1

Mods used: KSP version 1.0.5 kOS version 0.18.2 RemoteTech version v1.6.9 ModuleManager version 2.6.17 (pulled in by ckan as a dependency) HyperEdit version 1.4.2.0 (for quickly getting the craft into orbit to test)

[ghost]

Just a quick update to confirm that the issue still exists in kOS 0.20.0. As a minor note on reproducing the issue, I did have to restart KSP after enabling "Start on archive".

The ship was the same as last time: 1x Mk1 command pod 1x CX-4181 Scriptable Control System 1x SP-L 1x6 Photovoltaic Panels 1x Comms DTS-M1

The mods used where: KSP version 1.1.2 kOS version 0.20.0 RemoteTech version v1.6.11 ModuleManager version 2.6.24 (pulled in by ckan as a dependency) HyperEdit version 1.5.0 (for quickly getting the craft into orbit to test)

[hvacengi]

I am unable to reproduce this with the current development build and the current pre-release of remote tech. In order to work on this, we will more than likely need a copy of your log file and possibly a save file to do further testing. I was unable to replicate the issue with or without a kerbal in the command pod. It also didn't happen if I used a probe core without an omni-antenna built in (I edited it out of the MM patch).

Just by reading your description and the parts, my first guess is an issue with not having a probe core on board. If you don't have a probe, there is no RT Signal Processing Unit, which prevents it from processing signals. Essentially, any time that you want to do something that would require a signal back to KSC you need to have a probe core, or another signal processing part, on the vessel.

On the separate note, I would file this as an error message issue rather than a bug. Having "start on archive" enabled and then starting a processor without a connection should be the same thing as turning on a computer without a boot drive: it complains about having no boot device and doesn't still load the OS. Running kOS like that should also throw an error and fail to boot, but the reason should be made clear to the user. But @tomekpiotrowski has been the driving force between the RT integration recently, he might have other thoughts.

[ghost]

Here's the log (it's too big for pastebin, sorry.): https://drive.google.com/open?id=0B4ps98pMWaZnMVJYS0VCdEZ1LTA

And here's the save: https://drive.google.com/open?id=0B4ps98pMWaZnUGg4d0o3QTRFRXc

Just load the quicksave, and tell the kOS part to power on. It will say "power starved" even though there's enough power. If you right-click the antenna and activate it (it's already targeted at KSC), the kOS part will successfully power on.

[hvacengi]

All I needed was one look at the log and I can see what the issue is. The reason that you're getting a "power starved" message is that the exception is being thrown during the electricity calculation, so it never sets the power state to READY. I also know why I don't get there error on my local copy as well: the range check is skipped when the vessel is in the "PRELAUNCH" status, so testing from the launch pad would not provide the same results.

We definitely need to fix the error itself, since it's throwing an exception without catching it. But exactly what we should do is still a question. Options include:

• Throw an exception that displays the "volume out of range" error on the screen, break execution, and lock out control (My personal preference)
• Throw an exception, display the error on the screen, but then default to the local volume
• Simply default to the local volume as a fail over.
• Outright disallow the use of "start on archive" if RT is installed and enabled.

[ghost]

Locking out control sounds fairly reasonable, but the "start on archive" option will probably need to be fixed if you all decide to go with that. Currently, if you change the "start on archive" setting, you have to actually switch scenes in order for the new setting to take effect. Power cycling the kOS part isn't enough to get it to register the new setting.

[hvacengi]

I want to summarize the conversation that @Dunbaratu, @tomekpiotrowski, and I had in the developers slack:

• This error should not completely break the game, and it should allow the user to access the terminal without a scene change
• It would be nice to be able to store the "current" directory so that upon reboot you don't default back to the system setting (though this presents other challenges)
• The combination of "start on archive" and RemoteTech should be valid, and should not be locked out from user selection.
• The update/fix will log the exception to the terminal, however it will not lock out local input. If you have a kerbal in a command pod, you will be able to switch to 1. however any attempt to access files on the archive will still throw an exception.
• The crucial part of this fix is that the exception thrown during ProcessElectricity is prevented, and future exceptions are also caught.

[Dunbaratu]

On second thought, storing the "current" directory and restoring it on reboot is probably not a good idea, as it means boot scripts can't be written to assume they know how the system will be when it boots. While I dislike the fact that scene switching causes a reboot, as long as it does cause a reboot, we should treat that reboot as a true full reset of the state of everything (including current volume). "The RAM is wiped, and the program is wiped, but for some strange reason it still remembers $PWD." seems really inconsistent.