Space Shuttle Ultra 4.0 PRESS TO MECO

[Urwumpe]

None really. This was to answer GLS's question how the DM/PMA-1 APAS was controlled:

Ah OK, I was already getting a bit confused. Any hint on the role of the switching unit? Was it just for different electrical connections? Mechanically, ODS and APAS are almost equal.

Also, can you check in a text file with the reference coordinates for the Centaur CISS animations? I thought you already had posted them, but I did not find them and looking into the mesh failed this weekend.

Also about the 5.0 ... do we stay on beta repository or do we release specifically for Orbiter 2016?

 

[DaveS]

Ah OK, I was already getting a bit confused. Any hint on the role of the switching unit? Was it just for different electrical connections? Mechanically, ODS and APAS are almost equal.

I'm not sure. The procurement document isn't entirely clear.

Also, can you check in a text file with the reference coordinates for the Centaur CISS animations? I thought you already had posted them, but I did not find them and looking into the mesh failed this weekend.

The bellow positions have not changed. They remain at the same positions as before.

Also about the 5.0 ... do we stay on beta repository or do we release specifically for Orbiter 2016?

Can't we just rename the branch or does this cause issues?

 

[Urwumpe]

The bellow positions have not changed. They remain at the same positions as before.

Sure? so it is really just a different detail and the mesh does not have minimal differences? Even larger rounding errors can be annoying.

Can't we just rename the branch or does this cause issues?

Well, the branch name is the less of my problems. I meant which OrbiterSDK we use as reference.

We started our beta-branch with the beta releases of Orbiter 2016, but now there is a final release (before the patch).

My suggestion would be to keep the Beta branch and update it while Orbiter is updated, but move the trunk to Orbiter 2016 as released. And then move the current 4.0 release tasks into a ssu-4.0 branch as soon as we have finished implementing the new features and only need to stabilize it.

 

[DaveS]

Sure? so it is really just a different detail and the mesh does not have minimal differences? Even larger rounding errors can be annoying.

I'm certain. The only real difference is that the old bellows had conical ends while the current bellows consist of a single cylindrical segment.

 

[Urwumpe]

I'm certain. The only real difference is that the old bellows had conical ends while the current bellows consist of a single cylindrical segment.

No problem. I wanted to create a custom kind of animation for them anyway, remember? A kind of a primitive skeleton animation.

 

[GLS]

My suggestion would be to keep the Beta branch and update it while Orbiter is updated, but move the trunk to Orbiter 2016 as released. And then move the current 4.0 release tasks into a ssu-4.0 branch as soon as we have finished implementing the new features and only need to stabilize it.

Why???? What's wrong with getting SSU 4.0 for 2010 out the door ASAP, and then end 2010 support by merging the beta branch to the trunk and going for SSU 5.0? If one wants to work on both 2010 and 2016, as I am, 2 SSU working copies with the different Orbiter instalations are needed, so I see very little point in playing around with branches and trunks to end up in the same place. IMO the way to go is forward, and that starts with getting 4.0 out in the wild.

About the CISS animations, one of them doesn't have the correct coordinates, the other is perfect. The elbows are "wired" to rotate half of the angle between the pipes, to bridge the gap between them, but they don't bend like an accordion.

About the APDS stuff, could I get a look at "Figure 140-A" please? Anyway, it looks like people who want to have their DM or PMA-1 addons dock correctly will need to interact with us... somehow. Probably won't change things now, but it's good to have an idea of how it was done.

 

[Urwumpe]

Why???? What's wrong with getting SSU 4.0 for 2010 out the door ASAP, and then end 2010 support by merging the beta branch to the trunk and going for SSU 5.0? If one wants to work on both 2010 and 2016, as I am, 2 SSU working copies with the different Orbiter instalations are needed, so I see very little point in playing around with branches and trunks to end up in the same place. IMO the way to go is forward, and that starts with getting 4.0 out in the wild.

The why is simple:

1. We need to support a potential Orbiter 2016P1 as well soon.
2. We need to maintain the trunk on a defined Orbiter 2016 version later.
3. We still need to be able to do a 4.1 patch if needed.

Orbiter 2016 is a huge change to 2010P1 with many problems that we are slowly getting aware off. I will not slam the door to 2010 before we can do a stable 2016 release.

BTW: For keeping the number of Orbiter installations low, I already resorted to develop my own add-ons outside the OrbiterSDK folder and just deploy them into the Orbiter installation that I want to test. Works fine. Next iteration will be doing the deployment/undeployment with CMake , instead of do this with special batch files.

 

[GLS]

The why is simple:

1. We need to support a potential Orbiter 2016P1 as well soon.
2. We need to maintain the trunk on a defined Orbiter 2016 version later.
3. We still need to be able to do a 4.1 patch if needed.

Orbiter 2016 is a huge change to 2010P1 with many problems that we are slowly getting aware off. I will not slam the door to 2010 before we can do a stable 2016 release.

That's all still very much possible to do. When 4.0 comes out, a tag will be created that, if needed, can be used to create a new branch to fix whatever is needed there. Also, we can (and should) wait a couple of weeks with the trunk at 2010 to more easily fix bugs in 4.0.
IMO our main development line is still for Orbiter2010 (i.e. 4.0), so that is the one that should be in the trunk. Yes, that means we're a bit "behind the times", but that's by back in April I said let's release 4.0 that already has some new things and bug fixes, and then all move on to 2016. By doing it we will not be "slamming the door" on 2010, we will just focus on something else (2016), like I'm sure was done for Orbiter 2006. We can always go back and release an update to SSU for Orbiter 2006, we just need an installation for that. :2cents:

 

[DaveS]

About the APDS stuff, could I get a look at "Figure 140-A" please? Anyway, it looks like people who want to have their DM or PMA-1 addons dock correctly will need to interact with us... somehow. Probably won't change things now, but it's good to have an idea of how it was done.

 

[Urwumpe]

That's all still very much possible to do. When 4.0 comes out, a tag will be created that,

A tag is a read-only branch. Yes, we can create a new branch from it. But that is a completely different semantic and it is a lot of tough work more. Remember: Always merge branches in ONE direction. When you branch from trunk to a branch, you can either merge the trunk from the branch or the branch from trunk, but not both at the same time.

The usual pattern:

1. You create a release branch from trunk to finalize the release while already working in new features.
2. On release, you tag the revision in the release branch.
3. Should a patch be needed for the 4.0 release, you resume at the production branch and tag the patch release.

This is all a best practice regarding any VS (it is the same for git) to avoid conflicts and human errors.



You can of course work without release branches and do the release work in the trunk. But this means feature branches. Currently we have very few feature branches, you don't want the effort of maintaining many feature branches with a centralized VS.

 

[GLS]

Well, it seems like this ODS attachment thing will not work. For testing I added APAS attachments to the ProjectAlpha_ISS vessel and took the PMA2 mesh from ISS A2Z, made a simple cfg vessel for it, and docked it in front the of PMA2 port of ProjectAlphaISS (so I could have more than 1 port, 1 vessel and +/- accurate APAS target). When the PMA2 vessel is attached to SSU*, it undocks from the ProjectAlpha_ISS :facepalm:.

*) I'm using these limits to attach: <0.1m on all axis and <5º on all directions

 

[DaveS]

Well, it seems like this ODS attachment thing will not work. For testing I added APAS attachments to the ProjectAlpha_ISS vessel and took the PMA2 mesh from ISS A2Z, made a simple cfg vessel for it, and docked it in front the of PMA2 port of ProjectAlphaISS (so I could have more than 1 port, 1 vessel and +/- accurate APAS target). When the PMA2 vessel is attached to SSU*, it undocks from the ProjectAlpha_ISS :facepalm:

You say attached, don't you mean docked? Being attached is not the same a being docked. They're completely separate from each other, not once do their paths intersect. So if the PMA is attached while the orbiter docked, Orbiter only sees the SSU orbiter vessel as far as docking is concerned.

 

[GLS]

You say attached, don't you mean docked? Being attached is not the same a being docked. They're completely separate from each other, not once do their paths intersect. So if the PMA is attached while the orbiter docked, Orbiter only sees the SSU orbiter vessel as far as docking is concerned.

I do know that being attached is not the same as being docked... give me a little credit here .
The idea behind these ODS changes is that initially we would attach the target vessel (capture), and then retract the ring so we can dock the vessels. The attachment is needed so we can bring the vessels together during ring retraction, because moving a docking port doesn't work (apparently... I haven't tested it).

 

[DaveS]

I do know that being attached is not the same as being docked... give me a little credit here .
The idea behind these ODS changes is that initially we would attach the target vessel (capture), and then retract the ring so we can dock the vessels. The attachment is needed so we can bring the vessels together during ring retraction, because moving a docking port doesn't work (apparently... I haven't tested it).

So what is the problem to be clear? You mentioned undocking, shouldn't we be in the docking port phase then?

Edit:
I read the post again and correct me if I'm wrong, the problem is that the PMA undocks from ISS when it is attached to orbiter? Then that could be a Orbiter core problem and not one on our end.

 

[GLS]

So what is the problem to be clear? You mentioned undocking, shouldn't we be in the docking port phase then?

Edit:
I read the post again and correct me if I'm wrong, the problem is that the PMA undocks from ISS when it is attached to orbiter? Then that could be a Orbiter core problem and not one on our end.

I'd say it's more like an Orbiter short-coming. When vessel A is docked to vessel B, and we in vessel C attach to vessel A, vessel B undocks from vessel A. If A was attached to B, I think it they would not separate (not tested). But still, we don't want to dock to the ISS and have the Soyuz/etc flying away.
Anyway, even if Martin changes things on his end and this "issue" goes away, it won't matter for SSU 4.0, so unless someone has another (quick) way to do this, we'll have to leave this out of this release.

 

[DaveS]

I'd say it's more like an Orbiter short-coming. When vessel A is docked to vessel B, and we in vessel C attach to vessel A, vessel B undocks from vessel A. If A was attached to B, I think it they would not separate (not tested). But still, we don't want to dock to the ISS and have the Soyuz/etc flying away.
Anyway, even if Martin changes things on his end and this "issue" goes away, it won't matter for SSU 4.0, so unless someone has another (quick) way to do this, we'll have to leave this out of this release.

Yes, it looks that way, that we have to leave the ODS out of 4.0.

 

[GLS]

I just committed the ODS changes I made, the code is commented out so previous functionality remains, but the corrections I made to the panel are "active" (no more "INTERP SEALED").

In other news, I was thinking about hiding the forward bulkhead and docking lights mesh when they are not used... but as they are part of the "forward bulkhead stuff" group I'm going to have to separate those vertices and put them in a new group.

BTW, to who can edit posts, task 90 and 120 can be removed of the 1º post (ticket 90 can be closed IMO).

---------- Post added at 01:29 PM ---------- Previous post was at 01:12 PM ----------

In other news, I was thinking about hiding the forward bulkhead and docking lights mesh when they are not used... but as they are part of the "forward bulkhead stuff" group I'm going to have to separate those vertices and put them in a new group.

On second thought, maybe playing with 8000 vertices and triangles by hand isn't such a good idea :facepalm:. I'll leave this one for the graphics department to do when time is available.

 

[Urwumpe]

Switched 90 and 120 to DONE

 

[Donamy]

You can't dock to an attached vessel.

 

[Urwumpe]

You can't dock to an attached vessel.

Exactly, you need to detach first.