SSU Development Thread (2.0 to 3.0)

Status
Not open for further replies.
One question there....

Does anybody see a problem using .NET Framework 4.6 already for an experimental project or should the more common 4.5.2 be used?

I have no problem right now using 4.6 on a Visual Studio 2013, but I suspect not everybody has also a Visual Studio 2015 in parallel for testing.
 
I've been looking at how to add this TAA, and we could do away with the ODSZPos mission option, which defines the position of the External Airlock along the payload bay, and choose that parameter internally, according to whether or not the TAA is used (forward of the airlock). Any problems with this?
Another thing: could there be 2 TAAs used (one on each side)? Or shall we allow only one?
Only one is my vote. The reason for the TAA is to add contingency EVA capability when the normal EVA egress/ingress hatch is blocked. So it only flew on missions that used a Spacelab/SpaceHAB module where they transfer tunnel was connected to the airlock.

---------- Post added at 11:59 PM ---------- Previous post was at 11:58 PM ----------

One question there....

Does anybody see a problem using .NET Framework 4.6 already for an experimental project or should the more common 4.5.2 be used?

I have no problem right now using 4.6 on a Visual Studio 2013, but I suspect not everybody has also a Visual Studio 2015 in parallel for testing.
I recommend using 4.5.2.
 
I've been looking at how to add this TAA, and we could do away with the ODSZPos mission option, which defines the position of the External Airlock along the payload bay, and choose that parameter internally, according to whether or not the TAA is used (forward of the airlock). Any problems with this?
Another thing: could there be 2 TAAs used (one on each side)? Or shall we allow only one?

No problem for me there... maybe we can define the payloads attached to the mid deck hatch as sequence in the mission file?

Maybe under the name "CabinExtension0=TAA".
 
One question there....

Does anybody see a problem using .NET Framework 4.6 already for an experimental project or should the more common 4.5.2 be used?

I have no problem right now using 4.6 on a Visual Studio 2013, but I suspect not everybody has also a Visual Studio 2015 in parallel for testing.

As I don't even know .NET 0.1, so my opinnion can't really count. Does either of them run in vs2010?
 
As I don't even know .NET 0.1, so my opinnion can't really count. Does either of them run in vs2010?

Not that I know for sure, but VS2010 did already support .NET 4.0

Shall I commit it as it is and allow you to check? Right now its just some XAML prototyping to find the UI design language that I want.

And yes, don't expect too much on .NET from my side as well. Learning by doing!
 
No problem for me there... maybe we can define the payloads attached to the mid deck hatch as sequence in the mission file?

Maybe under the name "CabinExtension0=TAA".

As in:
CabinExtension0=TAA
CabinExtension1=ExtAirlock
CabinExtension2=Tunnel
CabinExtension3=Spacelab
?
If so, it would be usefull when we have all those things (and stuff to do in them). For now I was thinking of "ForwardTTA=TRUE"/"AftTTA=TRUE" or maybe "UseTTA=TRUE"/"ForwardTTA=TRUE".
 
As in:
CabinExtension0=TAA
CabinExtension1=ExtAirlock
CabinExtension2=Tunnel
CabinExtension3=Spacelab
?

Exactly that - not sure if we really need more options there. The placement of the elements can't vary, we just have the problem that we can't easily include new payloads in that way.
 
Not that I know for sure, but VS2010 did already support .NET 4.0

Shall I commit it as it is and allow you to check? Right now its just some XAML prototyping to find the UI design language that I want.

And yes, don't expect too much on .NET from my side as well. Learning by doing!

Did some searching and VS2010 doesn't work with .NET > 4. So for now I can't do anything, 4.5 or 4.6.
 
Did some searching and VS2010 doesn't work with .NET > 4. So for now I can't do anything, 4.5 or 4.6.

Well, 2010 is a long while ago...

I don't think I can recommend going below 4.5, since 4.5 adds the asynchronous processing API that .NET badly lacked compared to Java then and which is necessary. Also I used the Ribbon API for building the application, which is again 4.5+.
 
Well, 2010 is a long while ago...

I don't think I can recommend going below 4.5, since 4.5 adds the asynchronous processing API that .NET badly lacked compared to Java then and which is necessary. Also I used the Ribbon API for building the application, which is again 4.5+.

Do whatever you have to do. I'll catch up... eventually.
 
This is a photo of the aft hatch on the External Airlock but it applies to the TAA hatches as well:

D_hatch_dimensions.jpg

The "D" measurement wouldn't be 0.614m, would it ?
 
Fixed a few problems found while playing with the latest nightly. Urwumpe, when creating the zip file, didn't you get a missing files warning? There where 2 files in the list that didn't exist (it has been fixed).
A thing we need to discuss is the SSRMS. Currently the release list has scenarios and other stuff, but no dlls.... or everything goes, or nothing goes.
 
Fixed a few problems found while playing with the latest nightly. Urwumpe, when creating the zip file, didn't you get a missing files warning? There where 2 files in the list that didn't exist (it has been fixed).

Not that I remember, but I also use the 7z flavor instead of the Winrar version.

A thing we need to discuss is the SSRMS. Currently the release list has scenarios and other stuff, but no dlls.... or everything goes, or nothing goes.

All or nothing... but do we still need to publish the SSRMS or can we refer to an external add-on for that? After all, we also don't include the ISS in our release right now.
 
Not that I remember, but I also use the 7z flavor instead of the Winrar version.



All or nothing... but do we still need to publish the SSRMS or can we refer to an external add-on for that? After all, we also don't include the ISS in our release right now.
No and the SSRMS is already published on OHM as a separate add-on complete with its own documentation. So I think we should consider a completely separate add-on not really connected to SSU.
 
Hello,

Urwumpe, when creating the zip file, didn't you get a missing files warning? There where 2 files in the list that didn't exist (it has been fixed).

Asphalt.dds ( Vandenberg ) ?
 
Last edited:
No and the SSRMS is already published on OHM as a separate add-on complete with its own documentation. So I think we should consider a completely separate add-on not really connected to SSU.

Maybe we should talk to Donamy there, since his ISS add-on was possibly the primary user of this. Maybe we can get a better solution there.

My suggestion, how this could go in the future:


  1. SSUWorkbench (AKA Mission Editor + Dev Tools) is getting more attention after release, so its possible for Donamy to provide SSU scenarios, which can be distributed by him for his ISS. I have some ideas there, including using the SSU meshes for visualization.
  2. We on the other hand focus stronger on the Non-ISS-Missions.
  3. Should a bigger payload ever get so complex that it could distract us from the STS, we encourage spawning an open-source payload project independent of us.
    1. Only exception there would be payloads that require a deep integration into SSU, like Spacelab/Spacehab.
  4. We try to limit us to providing an open and accessible way of including payloads into SSU, not the payloads themselves, payloads should only be included into SSU to present new features in a release.
 
The "D" measurement wouldn't be 0.614m, would it ?
This is what I have:

The tunnel adapter has an inside diameter of 1,600 m millimeters (63 inches) at the widest section and tapers in the cone area at end, to two 1,016 millimeter (40 inch) diameter D-shaped openings, 914 millimeters across. A 1,1016 millimeter (40 inch) diameter D-shaped opening, 914 millimeters (36 inches) across is located at the top of the tunnel adapter. Two pressure sealing hatches are located in the tunnel adapter, one at the upper area of the tunnel adapter and one at the aft end of the tunnel adapter. The tunnel adapter is constructed of 2219 aluminium and is a welded structure with 60 by 60 millimeter (2.4 by 2.4 inch) exposed structural ribs on the exterior surface and an external waffle skin stiffening.
 
Hi!
That is a problem with the Vandenberg addon, not with SSU.

Yes. And easy to solve: alsphalt is in many others addons ( and maybe Orbiter itself under another name ).
 
Hi!
That is a problem with the Vandenberg addon, not with SSU.

Still a good question:

Do we support this:

[ame="http://orbithangar.com/searchid.php?ID=2380"]VandenbergAFB - 2006[/ame]

or that Vandenberg now:

[ame="http://orbithangar.com/searchid.php?ID=5810"]Vandenberg Air Force Base v.2.5[/ame]


Would it make sense for us to attempt going the Edwards AFB way there?
 
Status
Not open for further replies.
Back
Top