SSU Development Thread (2.0 to 3.0)

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

 

[Urwumpe]

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

I would say, by that license, we can include it into the main package without problems. We just need to make sure that we are not incorrectly applying our own license to the property of others.

Usonian might not feel too bad about it being GPL, if he ever pondered about that, but I don't want us to cheat any contributor.

EDIT: We already had the discussion about one year ago, as I had found. I think I will do a short test soon, if keeping Vandenberg tiles out reduces the size of SSU significant, but I doubt it.

 

[GLS]

I would say, by that license, we can include it into the main package without problems. We just need to make sure that we are not incorrectly applying our own license to the property of others.

Usonian might not feel too bad about it being GPL, if he ever pondered about that, but I don't want us to cheat any contributor.

EDIT: We already had the discussion about one year ago, as I had found. I think I will do a short test soon, if keeping Vandenberg tiles out reduces the size of SSU significant, but I doubt it.

Speaking of tiles, I'm in the process of re-adding some tiles that were deleted by mistake. They were though to be of Ellington Field but some were of Gander and Shannon. It's about 21MB extra, but as they are TAL sites I think it's a plus. I'm adding them to the AerojetDAP list so they can be used.
One big chunk (80MB) is for a single PDF. We could move all the extra documentation to a SF download page, as it doesn't need versioning, and just keep the manual with a link for the extra documentation page.

 

[Urwumpe]

Speaking of tiles, I'm in the process of re-adding some tiles that were deleted by mistake. They were though to be of Ellington Field but some were of Gander and Shannon. It's about 21MB extra, but as they are TAL sites I think it's a plus. I'm adding them to the AerojetDAP list so they can be used.

Yes, good point. I hope that with Orbiter 201x, the need for us to provide tile sets will vanish completely. In the mean time... could we maybe produce a version of SSU and its bases without any tiles? We would need different cfg files then, but maybe we could do this with a configuration tool to upgrade the bases.

One big chunk (80MB) is for a single PDF. We could move all the extra documentation to a SF download page, as it doesn't need versioning, and just keep the manual with a link for the extra documentation page.

Sounds like a good idea, could save us some bandwidth.

 

[GLS]

Yes, good point. I hope that with Orbiter 201x, the need for us to provide tile sets will vanish completely. In the mean time... could we maybe produce a version of SSU and its bases without any tiles? We would need different cfg files then, but maybe we could do this with a configuration tool to upgrade the bases.

I think that would be more trouble than good. As it is we can barely keep track of one configuration, and with the new Orbiter (hopefully) around the corner, it probably become unneeded.

Sounds like a good idea, could save us some bandwidth.

Then somebody with full access to SF will have to do it, as I can't.

 

[Urwumpe]

Then somebody with full access to SF will have to do it, as I can't.

Which access is missing? Can't you use SFTP?

 

[GLS]

So, the Gander and Shannon tiles are out again. There's just too much distortion caused by the angle at which to photo was taken. When checking the runway lengths to add them to the AerojetDAP, it becomes obvious that some have maybe a 50% error in length.
At this point I'm inclined to just remove the bases completely, as the runways are wrong, and I've little patience to fix that ATM.

Which access is missing? Can't you use SFTP?

What is that?

---------- Post added at 05:38 PM ---------- Previous post was at 05:08 PM ----------

For now I removed the tile references from the base files. There's 4 full days until the release, so I'll probably get around to fixing the runways.

Change of subject. All 3 ET meshes have the "main" texture with the D flag, but I don't see the need for it, and testing without that flag shows no problems. Can I remove those flags?

 

[Urwumpe]

What is that?

A SSH encrypted version of FTP. I use that for uploading the releases to SF.

https://en.wikipedia.org/wiki/SSH_File_Transfer_Protocol

 

[DaveS]

So, the Gander and Shannon tiles are out again. There's just too much distortion caused by the angle at which to photo was taken. When checking the runway lengths to add them to the AerojetDAP, it becomes obvious that some have maybe a 50% error in length.
At this point I'm inclined to just remove the bases completely, as the runways are wrong, and I've little patience to fix that ATM.


What is that?

---------- Post added at 05:38 PM ---------- Previous post was at 05:08 PM ----------

For now I removed the tile references from the base files. There's 4 full days until the release, so I'll probably get around to fixing the runways.

Change of subject. All 3 ET meshes have the "main" texture with the D flag, but I don't see the need for it, and testing without that flag shows no problems. Can I remove those flags?

If there's no adverse effects, then you can remove them. I believe The D flag is set for dynamic rendering of textures. This is from the 3Dmodel.pdf document that comes with the OSDK:

If a texture is to be dynamically updated during the simulation (e.g. instrument panels in
virtual cockpits), the texture name should be followed by the flag ‘D’. Orbiter will
decompress these textures to allow more efficient dynamic updates.

I don't know how true that is anymore considering the document was lasted updated in June 2006.

 

[GLS]

A SSH encrypted version of FTP. I use that for uploading the releases to SF.

https://en.wikipedia.org/wiki/SSH_File_Transfer_Protocol

AFAIK, the only things I have access to are the tickets and the repository.

Anyway, here's tiles that could be moved to an "Extra Documentation" download page in SF:
>> MEDS.pdf
>> 125852main_ius93f2.pdf
>> everything in the folder Tech Notes? (except the Pad Xenon lights position files which probably should be moved up one directory)
>> don't know what to do with Flightdeck Panel Locator.svg and the architecture folder

Also there's a refman.pdf from 2008... if anyone could update that, it would be nice to see how (poorly) documented our code is :lol:.

---------- Post added at 06:33 PM ---------- Previous post was at 06:13 PM ----------

If there's no adverse effects, then you can remove them. I believe The D flag is set for dynamic rendering of textures.

I think it probably uses less memory without the D. I'm sure there's some benefit to not having the D, otherwise the thing would be on by default, and we wouldn't need to add it.