quickstart tutorial should mention how to boot

[Dunbaratu]

At the bottom of the quickstart tutorial it should really mention, much like it talks about how to write a program in a file, how to make a boot file. I was watching a twitch streamer today who went through the tutorial and still didn't know boot files were a thing.

I think it's a basic enough need (boot files) that it should be mentioned early on, during quickstart rather than having to find it later in the docs.

[Dunbaratu]

Come to think of it - searching the docs page for the word "boot" finds nothing about the general description of how to boot - it should be made into a new a separate page when describing how the CPU works, and the quickstart should link to that page.

[Dunbaratu]

Checklist - remember to cover these things when writing the boot page:

[ ] The sequence of events that happens when a boot file is set and you launch a vessel - create local boot folder, copy from archive boot to local boot, then run from local boot.
[ ] The importance of the wait until ship:unpacked check and why it's needed.[ ] That editing the archive boot doesn't change the local boot because it's a local copy.
[ ] That you can dynamically change the boot file in flight with core:bootfilename.
[ ] The list of options to pick for booting is only refreshed when first entering the VAB/SPH. If you add a new file to 0:/boot/ while in the VAB/SPH you need to reload the VAB/SPH scene for it to appear in the list.
[ ] That the CPU reboots every time you load it into the scene, therefore boot files are also run when you switch to a vessel from the tracking station. boot files need to be written to be aware of this possibility (status=prelaunch check)

---

Edit - additional things I'm adding to the checklist because of what commenters said below:

[ ] That boot files must have .ks extension or they won't appear in the boot list.
[ ] That revert to launch does not reload the boot file from disk - it uses the one that was copied the first time. (Refer to the list of actions depicted in the first bullet point above, and point out which spot in that list is being reverted to - it's reverting to a point AFTER the file got copied.)
[ ] That the boot file happens every time you turn the power back on after turning it off.
[ ] That the "reboot" command exists.

[nuggreat]

I have seen some people have issues with boot scripts where they where not displayed in the VAB/SPH boot file options because they where do not have the .ks extension on the file they are trying to set as the boot file easy enough to miss in the docs but it has still come up a time or two.

Also something that should be noted is that reverting to launch will not cause the boot file to be reloaded from disk it will still be the same from from when you first pressed "launch". This is important because if the boot file was changed the only time kOS will load a different boot file is a completely fresh launch of the craft. There are ways around this in code but that can run into this issue (found here)

If you attempt to run the same program twice from within another script, the previously compiled version will be executed without attempting to recompile even if the original source script has been modified. However once the program has finished executing and returns to the main terminal input, the memory containing the programs is released. This means that every time that a script file is run from the terminal it is recompiled, even if the script file has not changed.

which is an easy problem to miss or forget about.

[mgalyean]

Techniques for power cycling / rebooting might be covered also. One Discord member mentioned putting a reboot of all kOS cores into the ABORT action group I tried it and it works really well. Related because it reboots.

[mgalyean]

Could "wait until ship:unpacked" just be parser-side boilerplate that gets automatically run first any time a boot script is run? If it needs to be done every time, why not just make it part of the process that loads the boot script?

[nuggreat]

The WAIT UNTIL SHIP:UNPACKED does not need to be run in every script though it is important for boot files that go strait into trying to do stuff on a rocket (throttle, steering, staging, ect). Also there are even scripts out there that would have problems if kOS started forcing WAIT UNTIL SHIP:UNPACKED as part of the parse step.

[nuggreat]

Wouldn't work as then you would get inconstant results from when you press the "launch" button in the VAB/SPH compared to a revert to launch because the file is only loaded when the vessel is launched and not loaded on a revert. And I don't think there exists a way to easily flag a vessel when it is first created nor would I want such functionality as launch being a unique case can cause problems. Thus it is better to explain why one should do something in one case which allows them to understand and thus apply to other cases should they need it as apposed to simply doing it automatically in the background.

[mgalyean]

Does STATUS = PRELAUNCH whether a fresh launch or reverting?

[nuggreat]

I had forgotten about prelaunch, would have to test to see if it properly resets on a revert. But even then I would be reluctant to rely on it as there are all kinds of strange and wonderful bugs in parts of the API. For instance did you know it is possible to have a status of "landed" despite the fact your craft is not on the ground at all.

[mgalyean]

Yes, in fact I have seen that status in KER when I was definitely not landed. Double take on that one

[mgalyean]

Well I learned here that I need to audit my boot scripts. I didn't know they fired whenever the core bearing ship loaded in a scene. Harmless with most of what I've got so far I think. But I need to look at the self-destructing debris widget I built very closely, lol

[Dunbaratu]

@mgalyean - There's a known bug (still not fixed) in KSP where if you bust an extendable solar panel so pieces of it lay on the ground, then take off again, the game will think you're still landed. (So it won't let you save the game or leave the scene since it thinks you are "moving across terrain" rather than flying.) The bug is caused by the fact that the bits of broken solar panel on the ground still count as being part of the vessel, so it thinks "part of the vessel is touching the ground".

[Dunbaratu]

@nuggreat , @mgalyean - I have added additional points to the checklist in the above comment because of your comments. Thank you.