SSU Development Thread (2.0 to 3.0)

[dseagrav]

Oh, I thought it expected to be run on its own anyway because you modified Earth.cfg

 

[GLS]

The MPS issue from the "ITEM 27" thread is basically the result of it not saving the state... and as it can't really be done in hours, so I recommend putting a warning in the manual stating that scenario saving is not supported in MM102, 103 and 104.
Going back to the external airlock: can't a hatch be put on top of it? There's one on the TAA, is it possible to "clone" it?

 

[Urwumpe]

Oh, I thought it expected to be run on its own anyway because you modified Earth.cfg

We have a lot of infrastructure around it, as expected, but the general plan is to have a rather open add-on there, e.g. that you can use it in your own scenarios, make your own missions for SSU and develop your own payloads for SSU. It is different there in contrast to NASSP, which is already limited in its flexibility by the historic spacecraft that it simulates.

The proposal for a workbench/mission editor for SSU is designed right now so far, that you can even design your own space shuttle program, for example for alternative history add-ons. The Layer 8 factors there would then be kept away from the run-time version (the scenarios in Orbiter) inside the workbench.

---------- Post added at 01:13 PM ---------- Previous post was at 01:08 PM ----------

The MPS issue from the "ITEM 27" thread is basically the result of it not saving the state... and as it can't really be done in hours, so I recommend putting a warning in the manual stating that scenario saving is not supported in MM102, 103 and 104.

How much work is really missing there? I would consider it personally as a show stopper to release, since the problems there might also be symptom for problems in future stages. The MPS is an active factor until we leave MM 106, which means about 55 minutes of the scenario. That is not long, but long enough to consider saving between the OMS maneuvers a normal action.

 

[GLS]

How much work is really missing there? I would consider it personally as a show stopper to release, since the problems there might also be symptom for problems in future stages. The MPS is an active factor until we leave MM 106, which means about 55 minutes of the scenario. That is not long, but long enough to consider saving between the OMS maneuvers a normal action.

Saving the state in the GPC sw classes is easy. Then there's the MPS manifold propellant resources to deal with (and then testing).
For the user, the MPS pretty much ends with turning off the SSME controllers, EIUs and putting the He Isol vlvs in GPC, and if I recall that's in MM105 (maybe 104). There's a vacuum inerting at the beginning of MM106 but it is automatic. So I'd say the save "gap" is about 20-30 minutes. It's a shame really, but it goes back to the "no need for save capability during launch" thing. But now, having the mission editor to keep users away from manually editing scenario files, I'll add save capability from pad all the way up, and the extra scenario parameters will be "hidden" from the user.

 

[Urwumpe]

But now, having the mission editor to keep users away from manually editing scenario files, I'll add save capability from pad all the way up, and the extra scenario parameters will be "hidden" from the user.

Remember that its still a long way until the Mission Editor will be ready for the end-user.

But in general, about editing the scenario files of SSU, I would recommend the following policy:

ACHTUNG!
ALLES TURISTEN UND NONTEKNISCHEN LOOKENPEEPERS!
DAS KOMPUTERMASCHINE IST NICHT FÜR DER GEFINGERPOKEN UND MITTENGRABEN! ODERWISE IST EASY TO SCHNAPPEN DER SPRINGENWERK, BLOWENFUSEN UND POPPENCORKEN MIT SPITZENSPARKEN.
IST NICHT FÜR GEWERKEN BEI DUMMKOPFEN. DER RUBBERNECKEN SIGHTSEEREN KEEPEN DAS COTTONPICKEN HÄNDER IN DAS POCKETS MUSS.
ZO RELAXEN UND WATSCHEN DER BLINKENLICHTEN.

 

[GLS]

Yes I know it will not be ready overnight but, to me at least, that is the main target of this next development cycle. I think this is gotten so big that even us devs are having difficulties editing scenarios (and the mission files will go the same way).
That warning looks so scary even google translate can't translate :rofl:.

 

[Urwumpe]

Yes I know it will not be ready overnight but, to me at least, that is the main target of this next development cycle. I think this is gotten so big that even us devs are having difficulties editing scenarios (and the mission files will go the same way).

Yeah, that will get inevitable. We have a pretty useful structure there, but that structure will not prevent complexity from striking. Especially since internal parameters in one subsystem might affect another in unexpected ways. Ensuring consistency will be one important job in the mission editor.

That warning looks so scary even google translate can't translate :rofl:.

Well, its just trying to sound German, not be German. :lol:

 

[DaveS]

Saving the state in the GPC sw classes is easy. Then there's the MPS manifold propellant resources to deal with (and then testing).
For the user, the MPS pretty much ends with turning off the SSME controllers, EIUs and putting the He Isol vlvs in GPC, and if I recall that's in MM105 (maybe 104). There's a vacuum inerting at the beginning of MM106 but it is automatic. So I'd say the save "gap" is about 20-30 minutes. It's a shame really, but it goes back to the "no need for save capability during launch" thing. But now, having the mission editor to keep users away from manually editing scenario files, I'll add save capability from pad all the way up, and the extra scenario parameters will be "hidden" from the user.

The MPS vacuum inerting requires two switch throws on R4, MPS H2 PRESS LINE VENT - OP, wait 60 sec, MPS H2 PRESS LINE VENT - GND.

 

[GLS]

The MPS vacuum inerting requires two switch throws on R4, MPS H2 PRESS LINE VENT - OP, wait 60 sec, MPS H2 PRESS LINE VENT - GND.

AFAIK, both MPS vacuum inertings (is this a word?) are fully automated. The procedure you're referring to is the GH2 pressurization line inerting.

 

[DaveS]

AFAIK, both MPS vacuum inertings (is this a word?) are fully automated. The procedure you're referring to is the GH2 pressurization line inerting.

Yes, you are correct. I re-read the MPS Workbook and both MPS inertings are fully automatic. The first one occurs at MPS DUMP COMPLETE+15 minutes and lasts for 2 minutes. The second occurs when the crew performs the OPS106 transition.

 

[Donamy]

The MPS issue from the "ITEM 27" thread is basically the result of it not saving the state... and as it can't really be done in hours, so I recommend putting a warning in the manual stating that scenario saving is not supported in MM102, 103 and 104.
Going back to the external airlock: can't a hatch be put on top of it? There's one on the TAA, is it possible to "clone" it?

Check your mail

 

[GLS]

Check your mail

They were committed.

 

[Urwumpe]

There is a minimal divergence between the ODS ring extension rods and their drive units visible at full extension, the coordinates would need a minimal tweaking, but I would not consider the incident a show stopper.

 

[DaveS]

They were committed.

Now we have this. From what I can tell, the ODS is in the right spot but the External Airlock itself isn't. And the height issue is still undealt with leading to hatch/tunnel misalignment.

---------- Post added at 09:30 PM ---------- Previous post was at 09:23 PM ----------

As a solution to the ODS camera view issue, how about binding its offset to the offset of the airlock itsefl? Currently we have it like this:

case VC_DOCKCAM: //Docking camera
		DisplayCameraLabel(VC_LBL_DOCKCAM);
		SetCameraOffset(_V(orbiter_ofs.x + 0.00175, orbiter_ofs.y - 1.03/*EXTERNAL_AIRLOCK_POS.y*/ + 1.15, orbiter_ofs.z + pMission->GetExternalAirlockZPos() - 0.3275));
		SetCameraDefaultDirection(_V(0.0, 1.0, 0.0), PI);
		SetCameraRotationRange(0, 0, 0, 0);
		oapiVCSetNeighbours(-1, -1, VC_PLBCAMFL, VC_AFTPILOT);

---------- Post added at 09:37 PM ---------- Previous post was at 09:30 PM ----------

And here's the reason why the view is so bad. The ODS doesn't fit the airlock, or the offset is bad.

 

[GLS]

Now we have this. From what I can tell, the ODS is in the right spot but the External Airlock itself isn't. And the height issue is still undealt with leading to hatch/tunnel misalignment.

---------- Post added at 09:30 PM ---------- Previous post was at 09:23 PM ----------

As a solution to the ODS camera view issue, how about binding its offset to the offset of the airlock itsefl? Currently we have it like this:

case VC_DOCKCAM: //Docking camera
		DisplayCameraLabel(VC_LBL_DOCKCAM);
		SetCameraOffset(_V(orbiter_ofs.x + 0.00175, orbiter_ofs.y - 1.03/*EXTERNAL_AIRLOCK_POS.y*/ + 1.15, orbiter_ofs.z + pMission->GetExternalAirlockZPos() - 0.3275));
		SetCameraDefaultDirection(_V(0.0, 1.0, 0.0), PI);
		SetCameraRotationRange(0, 0, 0, 0);
		oapiVCSetNeighbours(-1, -1, VC_PLBCAMFL, VC_AFTPILOT);

---------- Post added at 09:37 PM ---------- Previous post was at 09:30 PM ----------

And here's the reason why the view is so bad. The ODS doesn't fit the airlock, or the offset is bad.

You look carefully, can see that the ODS camera position always depends on the external airlock position (pMission->GetExternalAirlockZPos()).
As for the ODS/airlock relative positioning I think I left the numbers it they were before.
About the ODS camera issues you are having... I can't reproduce them. I've tried both graphics clients, both airlock positions, with and without ODS, with and without TAA. Is anybody else having this camera issue?

 

[DaveS]

You look carefully, can see that the ODS camera position always depends on the external airlock position (pMission->GetExternalAirlockZPos()).
As for the ODS/airlock relative positioning I think I left the numbers it they were before.
About the ODS camera issues you are having... I can't reproduce them. I've tried both graphics clients, both airlock positions, with and without ODS, with and without TAA. Is anybody else having this camera issue?

Could you try in D3D9Client.cfg setting NearClipPlaneMode to 1 and VCNearPlane to 0.01? This is to avoid clipping of meshes in VC mode.

---------- Post added at 09:54 PM ---------- Previous post was at 09:52 PM ----------

And this shows that the ODS is off-center relative to the airlock. The red cross-hair is the center of the airlock hatch.

 

[GLS]

Could you try in D3D9Client.cfg setting NearClipPlaneMode to 1 and VCNearPlane to 0.01? This is to avoid clipping of meshes in VC mode.

Now it shows! That +/- "fixes" the airlock VC position view... there's no more clipping, but the main VC mesh still shows....
BTW, just noticed (and corrected) that the ODS sight wires were missing from the ring animation.

---------- Post added at 11:59 PM ---------- Previous post was at 09:08 PM ----------

So, are we moving the non-SSU specific documentation out of svn (and the release package) and into a dedicated download folder in SF? I would do it, but I don't have enough access at SF to add downloads, so either I get promoted or somebody with access do it please.

 

[Urwumpe]

So, are we moving the non-SSU specific documentation out of svn (and the release package) and into a dedicated download folder in SF? I would do it, but I don't have enough access at SF to add downloads, so either I get promoted or somebody with access do it please.

I have done it now, I also moved the old source code documentation there.

You can find the files now here:

https://sourceforge.net/projects/shuttleultra/files/References/

---------- Post added at 11:35 AM ---------- Previous post was at 11:20 AM ----------

We should better add a readme to the folder, so there are no doubts that this is not our own documentation (except the old source code documentation), but NASA publications.

Any suggestion how to formulate this? After all, its not GPL documentation.

 

[GLS]

I have done it now, I also moved the old source code documentation there.

You can find the files now here:

https://sourceforge.net/projects/shuttleultra/files/References/

Thanks! That's a load off the release package. I've corrected the release file list and will update with the updated manual. Is this enough? "Additional documentation containing background information about the shuttle and its systems can be found here (http://sourceforge.net/projects/shuttleultra/files/References/)."

We should better add a readme to the folder, so there are no doubts that this is not our own documentation (except the old source code documentation), but NASA publications.

Any suggestion how to formulate this? After all, its not GPL documentation.

How about: "These files are not part of Space Shuttle Ultra, but are instead NASA publications. They are provided here as background information about the Space Shuttle."

 

[Urwumpe]

How about: "These files are not part of Space Shuttle Ultra, but are instead NASA publications. They are provided here as background information about the Space Shuttle."

Done