SSU Development Thread (2.0 to 3.0)

[GLS]

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.

 

[Urwumpe]

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.

 

[DaveS]

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.

 

[fort]

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 ) ?

 

[Urwumpe]

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.

 

[DaveS]

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.

 

[GLS]

Hello,



Asphalt.dds ( Vandenberg ) ?

Hi!
That is a problem with the Vandenberg addon, not with SSU.

 

[fort]

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 ).

 

[Urwumpe]

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?

 

[GLS]

Still a good question:

Do we support this:

VandenbergAFB - 2006

or that Vandenberg now:

Vandenberg Air Force Base v.2.5


Would it make sense for us to attempt going the Edwards AFB way there?

We need (and use parts of) VandenbergAFB - 2006

---------- Post added at 12:39 PM ---------- Previous post was at 12:37 PM ----------

Yes. And easy to solve: alsphalt is in many others addons ( and maybe Orbiter itself under another name ).

If I remember well, it's a problem with a texture path in a mesh. As the file in question is part of SSU, we can't fix it.

 

[DaveS]

Still a good question:

Do we support this:

VandenbergAFB - 2006

or that Vandenberg now:

Vandenberg Air Force Base v.2.5


Would it make sense for us to attempt going the Edwards AFB way there?

Usonian's Vandenberg 2006 is the one that we full authorization to use and modify as we see fit. We don't have the same for any EDW/WSSH.

 

[Urwumpe]

Usonian's Vandenberg 2006 is the one that we full authorization to use and modify as we see fit. We don't have the same for any EDW/WSSH.

Oh, I thought it was EDW that we had included.

Then... we could include it into SSU, maintain it with us and modify it as we see fit? Did Usonian agree to maintain it under the GPL (with full credits of course?)

EDIT: Since EDW is much more important for us than VAFB, wouldn't it make sense to include our own?

 

[DaveS]

Oh, I thought it was EDW that we had included.

Then... we could include it into SSU, maintain it with us and modify it as we see fit? Did Usonian agree to maintain it under the GPL (with full credits of course?)

EDW is included, it's mine and uses NASA Landsat imagery for the surf-tiles. Vandenberg is Usonian's Vandenberg AFB 2006. And yes, he created his Vandenberg AFB as an SDK, as an base add-on for others to add stuff to. All the launch complexes are static, just blocks. Others can add the actual launch complexes like we have done with SLC-6.

 

[GLS]

Oh, I thought it was EDW that we had included.

Then... we could include it into SSU, maintain it with us and modify it as we see fit? Did Usonian agree to maintain it under the GPL (with full credits of course?)

EDIT: Since EDW is much more important for us than VAFB, wouldn't it make sense to include our own?

As we have to credit Usonian anyway (AKAIK we don't - someone please do a credit list and I'll added to the manual), we might just as well put everything needed inside SSU, and remove the addon dependency and fix that little texture bug. I've put this forward a while back, and it was decided to keep things as they are.

 

[fort]

and fix that little texture bug. I've put this forward a while back, and it was decided to keep things as they are.

VandenbergAFB-2006

>Meshes folder:

VAFBasphalt.msh
TEXTURES 1
asphalt.dds

VAFBterminal.msh
TEXTURES 1
concrete.dds

VAFBtaxiway.msh
TEXTURES 1
concrete.dds

>Textures folder:

VAFBconcrete.dds
VAFBasphalt.dds

>Vandenberg.cfg:

MESH
FILE VandenbergAFB\VAFBtaxiway
............................................
TEX VAFBconcrete
............................................
END
MESH
FILE VandenbergAFB\VAFBterminal
........................................
TEX VAFBconcrete
............................................
END
MESH
FILE VandenbergAFB\VAFBasphalt
.........................................
TEX VAFBasphalt
............................................
END


My Orbiter log was asking for an asphalt.dds, that is the reason why...

EDIT:

Sorry, that is my fault; I did' not see that it was necessary to edit the Base cfg with the VAFB's textures.

 

[Donamy]

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.

Hello!!,... I'm standing right here. :tiphat:

I will be releasing scenarios with the mission addons I do, and the plan is to reference SSU, of course.:thumbup:

 

[Urwumpe]

Hello!!,... I'm standing right here. :tiphat:

I will be releasing scenarios with the mission addons I do, and the plan is to reference SSU, of course.:thumbup:

Sorry, I did not want to let it appear like I address you in third person :lol:

Then its OK for you to be responsible for the distribution of the SSRMS with your add-on and we remove it from our file lists?

---------- Post added at 02:32 PM ---------- Previous post was at 02:28 PM ----------

EDW is included, it's mine and uses NASA Landsat imagery for the surf-tiles. Vandenberg is Usonian's Vandenberg AFB 2006. And yes, he created his Vandenberg AFB as an SDK, as an base add-on for others to add stuff to. All the launch complexes are static, just blocks. Others can add the actual launch complexes like we have done with SLC-6.

Well, as long as we don't get collisions there with the other Vandenberg add-ons, its fine for me.

But we still need to know how things are licensed to us so we are doing everything as correct as possible and include the necessary licenses in the manual.

And do the credits, of course.

 

[DaveS]

Well, as long as we don't get collisions there with the other Vandenberg add-ons, its fine for me.

But we still need to know how things are licensed to us so we are doing everything as correct as possible and include the necessary licenses in the manual.

And do the credits, of course.

This is from the Vandenberg AFB 2006 manual:

OPEN LICENSE
You are free to include and distribute all or part
of VandenbergAFB within other add-ons for use
with Orbiter Space Flight Simulator. Credit the
author and advise users of changes made as
you deem appropriate.
The provisions of Orbiter Space Flight Simulator
Copyright and Disclaimer notices, 06 May 2006,
shall apply to VandenbergAFB and its author

 

[Urwumpe]

This is from the Vandenberg AFB 2006 manual:

Then we include this open license into an appendix of the manual. We are not permitted to GPL it because of it (we would need to ask Usonian there), but we can dual-license it safely.

 

[DaveS]

Then we include this open license into an appendix of the manual. We are not permitted to GPL it because of it (we would need to ask Usonian there), but we can dual-license it safely.

So are we going to include it in our main package or are we just going to include the actual zip file?