So there is actually a bug, because those blocks and "flavors" are not in currently, although filled in via mission config?
Yeah... the pad vessels got changed but I never got to work with that so it was never updated. Also, not all mission file parameters are defined in the pdf manual, but only those used by the vessels.
Looking at the pad parameters, we have LC-39A, B and SLC-6 to choose from. Maybe the best option is to add a "LaunchPadType" parameter, with the pad type/year... now a structured file makes sense :lol:
In other words, STS-3 mission scenario output vs. STS-3 predefined scenario is a unit test.
Maybe not that formal but yes, the output scenario should match the scenario we already have (not necessarily in vessel order, or specific subsystem values), i.e., it should be equivalent.
Would this be another parameter currently missing from the available controls/mission-parameters?
The scenario starting points would be a predefined list and it would be only an on-screen parameter option used for the generation of the scenario file. Each option might have it's own subset of options.
Do you mean parsing SC3 or stock Orbiter configuration files, or is there an additional SSU-specific vessel-description format?
Something like what the create vessel option of the ScenarioEditor does, show a list to the user. Then there should be an option to attach it to attachment xyz or put it in orbit (RPOS, etc, parameters via textbox input?), as well as the mentioned vessel specific parameter textbox.
Another additional parameter like the time-to-launch options?
Maybe grouping starting points into "launch", "orbit", "entry" is a good idea... maybe not. :idk:
In the end there should be several starting points: T-9m, T-1m, pre-OMS-2, EI-5m, TAEM, etc..., but for starters, just having 2 launch ones is a huge step forward.
---------- Post added at 05:42 PM ---------- Previous post was at 05:37 PM ----------
After some code reading, I think there is not much missing, actually. The overall work-flow is working, what is missing to pass the STS-3 test is:
- some position values are zero
- subsystems
- SWT, SRB and Pallet vessels
- MFDs
The overall code structure is decent (perhaps not perfect, but what is perfect, anyway?), so there is "only" a content problem, no system problem.
As such, the implementer should have knowledge of SSU, really. C# knowledge is less of a concern IMHO.
Like I said, some parts are done, others aren't... :shifty:
What confuses me a bit is the roadmap. It looked like a scenario manipulation tool in the thread at first, not like a scenario creation tool. Currently it is the later.
There was some indecision at first about what it should do, and scenario editing was, and is, a bit over the top. Mission file editing is already complex enough, so there's that and then scenario generation at specific points.
---------- Post added 11-11-19 at 03:03 PM ---------- Previous post was 11-10-19 at 05:42 PM ----------
Initial cleanup work in the SRBs is done!
Next I'll have to correct some textures, as they were mapped backwards for some reason, and upon correction of that I noticed that the black triangles are wrong.
A few more "pieces of the puzzle" fell into place while I was going around the FWC meshes. First, the fwd dome joint area looked weird, and that is because the fwd segment was longer that it should be, so in barreled into the fwd skirt. Second, because the ET attachment segment has the diameter of the composite parts, instead of the actual metal parts, it "forces" the aft SRB/ET struts into a different place, so that's why things also don't fit in that area.
The FWC joints and diameters, plus the OFT textures, will be fixed in the next round thru those 30 meshes.