core:bootfilename fails when it mentions volume number.

[Dunbaratu]

Make a boot file called "1:/runme.ks" (to verify it's on the local volume):

// runme.ks
print "If you see this, it's proof that runme.ks has run.".

• Works -> set core:bootfilename to "runme.ks". reboot.
• Works -> set core:bootfilename to "/runme.ks". reboot.
• Fails -> set core:bootfilename to "1:/runme.ks". reboot.

Explicitly mentioning the "1:" volume number makes it do nothing on boot.

It may make sense to say the boot filename should be local (i.e. that "0:/runme.ks" shouldn't work, maybe.) But it shouldn't fail just because the correct local volume was explicitly mentioned instead of merely implied.

(This was discovered because of some posts in the kOS thread of the Kerbal Space Program forums.)

[hvacengi]

I disagree that volume identifiers should be considered acceptable if they happen to align with the "start on disk". I think it would be better to explicitly enforce that the string must be a relative path instead of global. The issue is due to how we manage the "start on" disk. Because that is handled at the game settings level, the boot location may change between two different flights of the same vessel. Which would make it so that either "1" or "0" is valid depending on settings. So, if we want to maintain that the boot file must be located on the start up disk we really need to ensure that volume information is not stored in the boot file name. We probably also need some additional documentation to explain the restriction, and to specifically clarify that the relative root is the start up volume, not the current volume or directory.

If we want to suggest that vessels are allowed to boot from different disks, that's another discussion entirely. I personally prefer that boot files need to be on the start up volume.

I do think that a component of this discussion should/will be addressed when I fix #2121, since we will have more verbose identification of which file the system is attempting to boot from and why it may have failed.

[Dunbaratu]

Actually, fixing #2121 would completely remove any need to demand the boot cannot include an explicit volume identifier. Because if the failure to find the boot file was described at runtime, then say trying to boot from "0:/myarchivefile.ks" when the archive can't be seen would generate an error message at boot time explaining what happened.
The claim that the setting "start on archive" describes where the boot file must be is incorrect. It describes where the cd(...) is at the time. The only reason the boot file has to be there is because we demand the boot file be relative. Saying the boot file must be relative because it must be relative to the current directory at boot time is a circular argument. In fact, allowing a script that sets core:bootfilename to explicitly mention the volume would make the script MORE portable across different player settings, not less portable, by making it possible to have the same behaviour either way.

[hvacengi]

It may be more portable to allow global paths, but I'm not sure that I like the idea still. I'll acknowledge however is that my primary bias that I personally don't like being able to start on and boot from the archive when a communication system is enabled. Given that PXE allows you to do a network boot, I really shouldn't let that bias dominate.

[Dunbaratu]

One of these days I'd like to see us incorporate the signal delay into file operations. Right now we don't. (If you type copypath("0:/foo","1:/bar"). at the interactive prompt to a remote probe with lightspeed delay, the wait you get is coming entirely from sending the command and not from copying the file. If a program did the same command, it would happen immediately.)
The reason booting from archive is unrealistic with signal delay enabled is because of this, not because the boot from archive itself should be banned. If copying or running files from a distant archive obeyed signal delay, then booting from archive for a distant probe wouldn't feel like as much of a cheat as it would be as impractically slow as it should be.

I think enforcing the no-boot-from-archive is actually trying to fix the problem by attacking one symptom of it instead of by attacking the actual cause of it.

[bigmcr]

This should be mentioned on the documentation for BOOTFILENAME. I've dealt with this for several months now, and it has been a pain. After a reboot, I've had to type "RUNPATH(CORE:BOOTFILENAME)." in order to get my code up and running, and I've never (before now) figured out why it wasn't running that command automatically.
If someone can point me toward how to change the documentation, I can do it.