SSU Development Thread (3.0 to 4.0)

[GLS]

I thought we wanted to move the trunk to 2016 anyway to reduce the conflicts

We could do that, but then the trunk could become unusable for a while. If the branch is kept updated with the trunk changes, the merge probably won't hurt much.

 

[Urwumpe]

We could do that, but then the trunk could become unusable for a while. If the branch is kept updated with the trunk changes, the merge probably won't hurt much.

OK, so I just misunderstood the state of the branch wrong - I thought it just needed some upgrades.

---------- Post added at 08:28 PM ---------- Previous post was at 07:48 PM ----------

The SSU_TEST_MFD can take a moment... had a very long day at work today, thanks to another layer 8 problem.

I hope I can get the majority of it done until the weekend.

 

[GLS]

I was looking around the ASE/IUS, working on the umbilical animation, and noticed that bay 13 has the 2 bottom holes uncovered. No problems on the top ones.

 

[DaveS]

I was looking around the ASE/IUS, working on the umbilical animation, and noticed that bay 13 has the 2 bottom holes uncovered. No problems on the top ones.

Checked in a fix.

 

[GLS]

Given that the upper stages are (mostly) for "escape velocity" missions, I'm wondering if we should add a C3 energy output to the HUD?

 

[DaveS]

Given that the upper stages are (mostly) for "escape velocity" missions, I'm wondering if we should add a C3 energy output to the HUD?

That would be nice. Although the IUS is really meant for GEO missions as it was primarily an Air Force program. That's why NASA went with the Centaur, it being a NASA program. Also it being a liquid stage it's a bit easier on the spacecraft thanks to a more gentle ignition.

 

[Urwumpe]

Could we specify missions for the upper stages?

Either directly inside the upper stages, or in a control center vessel. The second solution would be better if we create upper stages dynamically during a scenario of multiple SSU missions, but it would not be needed for the current kind of missions.

It would also have the advantage, that we could bundle the responsibility for mission control functions into one vessel DLL.

 

[GLS]

I just committed some changes to control the number of IUS antennas and RCS tanks. Can't find definitive information about Centaur options, so I did nothing in there. Added the C3 energy display for Earth, so eventually it disappears from the HUD as one leaves the home planet. Also changed the material settings of the payload adapters, as the Centaur one was black when in Earth's shadow and didn't match the rest of the nearby meshes.

Could we specify missions for the upper stages?

Either directly inside the upper stages, or in a control center vessel. The second solution would be better if we create upper stages dynamically during a scenario of multiple SSU missions, but it would not be needed for the current kind of missions.

It would also have the advantage, that we could bundle the responsibility for mission control functions into one vessel DLL.

That would be nice... but then we would have to (as our american friends say) "go the full 9 yards". We would need upper stage guidance, launch window computation, etc..., and it seems to me like there are more important things to be done.

 

[Urwumpe]

That would be nice... but then we would have to (as our american friends say) "go the full 9 yards". We would need upper stage guidance, launch window computation, etc..., and it seems to me like there are more important things to be done.

Of course. But then, you know, the full 9 yards always begin with the first one. Is it really that far away? We could expect a lot of the complicated data to be calculated in advance by better tools than we could ever program.

 

[GLS]

Of course. But then, you know, the full 9 yards always begin with the first one. Is it really that far away? We could expect a lot of the complicated data to be calculated in advance by better tools than we could ever program.

I think step 1 would be "hit MECO targets", and we can't do that with reliability :facepalm:.

 

[Urwumpe]

I think step 1 would be "hit MECO targets", and we can't do that with reliability :facepalm:.

We are too busy with ascent tweaks IMHO, we also have other mission phases to cover. Maybe in the next QA phase, we work it out closer.

 

[GLS]

We are too busy with ascent tweaks IMHO, we also have other mission phases to cover. Maybe in the next QA phase, we work it out closer.

Even taking the aborts out of the equation (which is somewhat advanced), I'd say ascent guidance is one of the areas where we lack "tweaks" :lol:. It needs a fix on the PEG algorithm that currently only uses the constant thrust mode, so it doesn't take into account the 3g limit (that's why TMECO is 7:50 or so for most of the ascent). Then, the pitch control needs fixing near MECO, as the c.g. changes and guidance causes it to change too much and control of the flight path angle goes down the drain. Then there's the sideways guidance that currently targets plane inclination only, but leaves out plane location (LAN). Also, there's no manual control except throttles.
Bottom line, I'm all for adding more capability and detail, but embarking on new big endeavors when the orbiter doesn't have "basics" like EPS/PRSD stuff and there's also tons of re-writing to be done in the vc, doesn't seem right.

 

[Urwumpe]

Bottom line, I'm all for adding more capability and detail, but embarking on new big endeavors when the orbiter doesn't have "basics" like EPS/PRSD stuff and there's also tons of re-writing to be done in the vc, doesn't seem right.

Actually - those are what I mean as well:

• EPS
• TCS
• GNC (relative navigation is still considered harmful)
• Communications (We need somebody to help us better during RDVZ)
• Crew! (The player can't do it all at once)

about in that order.

 

[DaveS]

[*]Crew! (The player can't do it all at once)

Well, the Project Apollo team got something like that with their Checklist MFD. Maybe we could check with them and see if their license allow for their code to be used with SSU. Obviously the code would have to be modified/adapted to work with SSU but it would be great start.

 

[GLS]

We could breakdown the checklists by crewmember/seat, and then leave to the user the tasks of the current vc positon and automatically do the rest.

 

[Urwumpe]

Well, the Project Apollo team got something like that with their Checklist MFD. Maybe we could check with them and see if their license allow for their code to be used with SSU. Obviously the code would have to be modified/adapted to work with SSU but it would be great start.

The idea is good, but their MFD is hardly functional, even for the single kind of mission Project Apollo currently supports. I think it would be better doing our own attempt at it and only learn from Project Apollo experiences there.

Also the Space Shuttle checklists had been vastly improved in formal design compared to Apollo, we have way better input material available then they have.

And AFAIR, it still means that the player would have to be at different places all at once during many operations. It would be better we could take away more simple tasks from the player and leave the big mission to him.

 

[GLS]

Any corrections needed before I put this in the manual and never have to change it again? :compbash2:

 

[Urwumpe]

Any corrections needed before I put this in the manual and never have to change it again? :compbash2:

I can't see issues there. :thumbup:

---------- Post added at 09:45 AM ---------- Previous post was at 09:43 AM ----------

Missed your post before.

We could breakdown the checklists by crewmember/seat, and then leave to the user the tasks of the current vc positon and automatically do the rest.

I would not do that, because of a very simple reason: Astronauts switch their workstations, but never their role. A CDR always stays CDR, even if he is at the aft work station.

I would prefer letting the player stay commander of the mission, maybe later also allow the other roles. Switching roles makes little sense during a mission, but maybe there is a reason for allowing that in the case we have EVAs to perform. Switching roles between missions makes more sense, since we might also need player influence during the mission preparation.

 

[GLS]

I've now added those diagrams to the manual.
If anyone has any ideas for changes or additions to the manual, please make them or post them here and I'll make them for you, as I don't think I can write more text this year... wned:

 

[Urwumpe]

I've now added those diagrams to the manual.
If anyone has any ideas for changes or additions to the manual, please make them or post them here and I'll make them for you, as I don't think I can write more text this year... wned:

I would direct this question to the players who NEED the manual.