Streamline startup process

[mferrie]

Instead of downloading all the scripts on the archive to the ship (wasting memory), why not have the startup script download just the appropriate library files based on the mission? The user will need to specify which library files to download.

[mathuin]

I actually do this with a copy of boot.ks which I call boot_small.ks. It has a line like this: SET FLS TO LIST("launch_asc.ks", "lib_parts.ks", ..., "warp.ks"). and I use it for missions that only need a subset of RAMP's functionality.

That being said, it's sometimes hard to know which files depend on which without searching for run statements. For missions which only need certain files temporarily and which are guaranteed to be in radio contact, I can see deleting no-longer-needed files and copying the next files up. But that sounds annoying.

[xeger]

My original space-saving plan for RAMP was to compile all other scripts during the invocation of boot.ks, copy the compiled bytecode to the ship's primary volume, and then run the compiled version of mission. When I tried to do this, I encountered a major setback: compiling was fundamentally broken; user functions defined in compiled scripts did not get added to the global namespace.

Moreover, always running compiled code made the edit-and-test loop very painful, although I solved that by having two files: boot.ks that is meant to be used to write scripts in Kerbin orbit and just runs everything uncompiled, and boot_mission.ks which prepares for a Real Mission.

Given the compilation-related bugs, I abandoned that plan and nowadays I just make sure that my ships have enough disk space store the whole collection of RAMP scripts.

Hopefully you're aware that you can use the component-tweak UI in the VAB to add disk space to your KOS cores up to a certain amount -- it adds a bit of cost to the ship, but even the entry-level KOS processor has enough max space to hold RAMP, and in the end I decided I'd rather spend my time building scripts than optimizing for size.

I think @fellipec has his own ideas about the direction we should take for boot, and since he's been the primary contributor for a few months, I'm going to defer to him. I suggest that we not let things get too complicated, though. Maybe it's worth seeing if compilation ever got fixed?

If we decide we want to allow piecemeal install of RAMP, I'd suggest the following:
a) by design, the lib_xxx scripts depend on nothing (they are meant as libraries that can be used independently) .. it should be easy to validate this is still so, since none of them should RUN anything.
b) For every case of a non-lib script that runs another script, we would need to extract the relevant functionality into some lib script, so that we end up with no non-lib script calling any other non-lib script.
c) The user who wants a piecemeal install would still be responsible for copying just the top-level scripts he wants, plus the libs that those depend on.

You can see that it gets complex pretty quickly, and a piecemeal install will never be easy to work with...

[fellipec]

I had that dilemma when I start sending crafts away and losing connection with KSC.
Them I wrote the boot file that I bundled with RAMP, as a way to ensure I will not lose the mission because of a connection problem.
Immediately I found most of the parts from kOS had not enough memory. I thought a lot about the issue. If I copy just the libraries and few scripts for the mission I need, I realize that I'm already copying most part of the programs anyway. And that would add a complexity already discussed.
Then I start to compile the programs, like the original @xeger plan and found no issues. That was nice but RAMP was still big. Finally, I gave up, made a module manager file and increased the memory size of all kOS computers.
I thought of writing some script that deletes unnecessary files and copies new ones on the fly, like @mathuin suggestion, but in my opinion that may lead to more problems, like deleting wrong files maybe from the archive, or losing some burn window because of communications blackouts and a missing file. I prefer to keep it simple and just buff the memory of the parts.

[xeger]

It seems like @fellipec and I came to the same conclusion: KISS. :-) One final comment: sometimes I dream about making RAMP modular *and concurrent*, i.e. it installs different parts of itself onto different kOS cores. In the past, the single threaded run loop prevented this from being exciting (max 200 instructions per physics tick_ but I believe kOS has genuine threads now, and an async interface between itself and the physics loop... so, some very neat things should be possible now. If we want to explore "minified" boot scripts, that is the direction I would probably follow: for instance, write a `boot_ascent` script that *just* handles launch/ascent, and put it onto a core that is attached to the ascent stage.... then have a "boot_orbit" stage that deals with circularization and maneuvers ... and so forth.

…

On Fri, Jan 26, 2018 at 2:12 AM Luiz Fellipe Carneiro < ***@***.***> wrote: I had that dilemma when I start sending crafts away and losing connection with KSC. Them I wrote the boot file that I bundled with RAMP, as a way to ensure I will not lose the mission because of a connection problem. Immediately I found most of the parts from kOS had not enough memory. I thought a lot about the issue. If I copy just the libraries and few scripts for the mission I need, I realize that I'm already copying most part of the programs anyway. And that would add a complexity already discussed. Then I start to compile the programs, like the original @xeger <https://github.com/xeger> plan and found no issues. That was nice but RAMP was still big. Finally, I gave up, made a module manager file and increased the memory size of all kOS computers. I thought of writing some script that deletes unnecessary files and copies new ones on the fly, like @mathuin <https://github.com/mathuin> suggestion, but in my opinion that may lead to more problems, like deleting wrong files maybe from the archive, or losing some burn window because of communications blackouts and a missing file. I prefer to keep it simple and just buff the memory of the parts. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#26 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEemBzdJj0fLk7tf9kgfSC4Ue6Wj0jmks5tOaUMgaJpZM4RfCSS> .

[mathuin]

Thank you for bringing up the idea of supporting multiple cores!

While I haven't considered per-stage cores, I have spent the past few days working on a mission that deploys several relay satellites into geosynchronous orbit using a resonant orbit. I have four cores -- one for each probe and one for the lifter. It works -- and it was a challenge and a lot of fun to write.

My first suggestion is that having a start script that includes the core's name tag if present would be very very helpful when loading individual cores - 0:/start/Vessel Name - Core Name.ks as an example.

My second suggestion is that boot_mission.ks be modified to upload the appropriate start file and parse it for run commands and functions, then upload those files if they're necessary and parse them for dependencies, and so on. This idea is less awesome now that I understand that variables and expressions can be used in runpath() and runoncepath() but I only learned that just now. 😵 For those sticking to the old-school run command, it would allow them to upload only what they need which is crucial when space is at a premium.

These suggestions may be outside the scope of the project, but I thought they were worth mentioning.

[xeger]

I had some other thoughts last night while working on the bootloader -- nothing comprehensive yet, and I owe some people reviews of their maneuver changes, but the kernel of the idea was:

1. Take the existing file-copy logic and extract it into an install.ks that can be called by boot or others. Make it take an optional parameter which is a list of file patterns to copy. Perhaps copy all lib_ scripts since they are typically used in multiple places.

2. Move responsibility for copying from the bootloader into the startup script. The startup script is essentially the "mission" script, we would be adding to it the responsibility of also installing the files required for that mission.

3. Adopt @mathuin's idea of core-specific startup scripts (if they exist) so that different cores can have different missions.

This would give people the ability to do multicore and write missions that use less of RAMP. However, I fear that we have a basic issue: RAMP has gotten really big; even the lib_ scripts may be so large as a collection that they can't fit onto one of the basic beginning-of-game cores! By giving people all of these fancy install and optimization features, I'm afraid we're compensating for RAMP being bloated, at the cost of making it more complex for newcomers to understand.

I'm afraid I don't have a solution for the larger problem yet!

[mathuin]

I run with the ModuleManager patch listed in the boot README, and the CX-4181 can still hold all of RAMP. File optimization is really only required for the KR-2042b in my limited experience. That being said, I do not know if the compilation code has stabilized, nor do I know whether compiled versions of scripts include all their dependencies. :-(

Is it worth making a separate issue for multi-core topics? Actually developing missions with multiple cores has brought up a few ideas I'd be happy to explore, like the core-specific startup script.

[xeger]

That's a good idea; multicore probably deserves to be spun off into its own topic.