Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 37,655
- Reaction score
- 2,376
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
I just thought about something, but that would be perfectly low priority right now, so I wouldn't mind if GLS and you complain about the distraction. It is just an idea to experiment with something.
From that point, things could be further fleshed out:
I am not 100% sure about the effort needed. I suspect it could be broken down into 3-4 bigger programming tasks and each task would take about a weekend.
Why I am talking about that: in January 2018, we have the 10th anniversary of our project. We can't get it completed until then at the current slow, but steady pace. But maybe we can have some of the bigger goals of the project realized, like for example allowing a turn-around between missions and flying multiple missions in sequence.
- Question: Does DaveS have a good mesh of the OPF?
- Idea: Test a turn around of a orbiter in the OPF from one mission configuration to another.
- Concept: For simplicity in the experiment, just do a three stage main process there:
- Access needed tasks in the OPF by comparing new mission file with current status of the orbiter. Assume no failures yet.
- Execute tasks without special ordering right now, even if it looks unrealistic. Assume unrealistic times for each task, but each task should have a non-zero time to execute. All tasks are assumed to be of the same generic type, without specialization. Use a pool of executing agents in the OPF to represent limited resources of technicians.
- Finalize: Declare orbiter as "ready for transport", stop the transition to the next mission process.
- The whole process can stop here for the experiment.
- Communication with the orbiter should happen via an implementation neutral "user model" of the internal subsystems, so we don't need to recompile the SSU_OPF.DLL every time the orbiter changes. The definition how to utilize such a user model should be placed into libUltra.
From that point, things could be further fleshed out:
- We could let the player use the planned ground vehicles to transport the orbiter to the VAB and do an unrealistic integration there, as already planned.
- We could make the tasks and the execution model more realistic, for example, by automatically creating PERT models internally.
- We could include failures into the accessing tasks.
I am not 100% sure about the effort needed. I suspect it could be broken down into 3-4 bigger programming tasks and each task would take about a weekend.
Why I am talking about that: in January 2018, we have the 10th anniversary of our project. We can't get it completed until then at the current slow, but steady pace. But maybe we can have some of the bigger goals of the project realized, like for example allowing a turn-around between missions and flying multiple missions in sequence.
