Release Tuesday!
SSV v1.16 is out!
https://github.com/GLS-SSV/SSV/releases/tag/v1.16
Highlights of the changes for this version are an initial version of the CRT tone/mission/"whatever they were called" timers, which in conjunction with a new option to force x1.0 time acceleration when a C&W alarm is triggered, allows the user to set a MET and accelerate forward (don't go full bananas) until that MET, upon which the SM alarm will be triggered and bring time acceleration back to x1.0.
In addition, the Launch tab in Mission Editor has now been improved, allowing the OMS Assist parameters to be easily set in there. Plus, there are now parameters for the new IY vector targeting, which thanks to the ascent guidance improvements by
@indy91, allows for precise orbital plane targeting. Please read the manual (section 7.2.4) for an overview of the options available.
For the future, work for v2.0 is still going on at full speed, the control segment architecture is mostly done, with only a few issues remaining, and much cleanup. Programs can now be scheduled and canceled in a more realistic way, which hopefully should result in less hacks in the future. E.g., the OMS engines were fired by scheduling the "OMS FIRE SEQUENCE" program, which would immediately issue the commands to open the required valves, and at the end of the burn it would close them, and cancel itself. Things like these are now "easy" to do.
Building on that, I've started with the SM OPS control segment, its executive and hybrid dispatcher, which is a mechanism to handle the call to functions in the correct order at the correct time. It will need some massaging to allow for the PAM function in the future, but so far the changes seem easy. The PLB software was already written +/- correctly, so I just have to call it in the new way. Also want to tweak the way bus I/O is commanded, integrating it more with whatever software is currently running. All this will break some ground for the GNC, which is still full of unknowns in the program and function orchestration side of things.
One big item up in the air is the BFS. Up until now there was a hack to show some BFS displays with limited data, but that is likely no longer possible. Given that during ascent and entry, the SM functions were effectively performed by the BFS (there was no memory or CPU for that in the PASS), and as data flow gets less and less "hacked", the lack of the BFS becomes more noticeable. I'm not sure how much effort it would take to add another GPC for the BFS, and have it just perform display functions: like in reality, it would need to spy on buses, but based on content and not timing, plus manage the CRTs with the other GPCs. I think I'll let this one sit for a while, think some more, and decide later on whether it should be done sooner or later.