SSU Development Thread (2.0 to 3.0)

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

 

[Urwumpe]

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.

Without D, there is also better performance, since the D makes the texture stored uncompressed and in a format for easier painting in different memory than usual textures. On some GPU implementations, the dynamic textures are even stored in normal RAM and transfered into the GPU for every frame.

That is why I want to limit the amount of dynamic textures in SSU to the minimum necessary.

 

[GLS]

The code is pretty much ready for the TAA, just missing the positions, the masses and the meshes.

 

[Urwumpe]

The code is pretty much ready for the TAA, just missing the positions, the masses and the meshes.

How did you include it into the mission file?

 

[GLS]

How did you include it into the mission file?

Yes. I also added the STS-76 launch scenario to see it in action.... or just to see it as it just sits there :lol:. I'm just fine tuning the aft position of the External Airlock, and then I'll move to update the manual with the new parameters. If anybody has there's anything extra to add there (license, thanks, etc), just say.

BTW: I noticed that bottom of the External Airlock is way below the bottom of the PLB.

 

[Urwumpe]

Yes. I also added the STS-76 launch scenario to see it in action.... or just to see it as it just sits there :lol:.

Actually I meant... which parameters do I need to support in the Mission Editor? :lol:

 

[Donamy]

Yes. I also added the STS-76 launch scenario to see it in action.... or just to see it as it just sits there :lol:. I'm just fine tuning the aft position of the External Airlock, and then I'll move to update the manual with the new parameters. If anybody has there's anything extra to add there (license, thanks, etc), just say.

BTW: I noticed that bottom of the External Airlock is way below the bottom of the PLB.

Looks ok to me.

 

[GLS]

Actually I meant... which parameters do I need to support in the Mission Editor? :lol:

Oh, that. "ODSZpos" was removed, the new ones are "UseTAA" (default=false) to enable the TAA, at what I call the forward position (between the bulkhead and the ExAL), and "AftTAA" (default=false) to place it aft of the ExAL. When the meshes arrive the code and manual will be updated.

Looks ok to me.

But that is not the ExAL that I have...

 

[Urwumpe]

Oh, that. "ODSZpos" was removed, the new ones are "UseTAA" (default=false) to enable the TAA, at what I call the forward position (between the bulkhead and the ExAL), and "AftTAA" (default=false) to place it aft of the ExAL. When the meshes arrive the code and manual will be updated.


But that is not the ExAL that I have...

How do you tell that a forward TAA and no ODS is used?

I still think that even a solution like "PLBIVASystems=TAA,ODS,TAA,Spacehab" would be easier to understand for all involved.

 

[GLS]

How do you tell that a forward TAA and no ODS is used?

I still think that even a solution like "PLBIVASystems=TAA,ODS,TAA,Spacehab" would be easier to understand for all involved.

UseTAA=TRUE
UseODS=FALSE
UseExtAL=TRUE (if you want the external airlock)

 

[Donamy]

UseTAA=TRUE
UseODS=FALSE
UseExtAL=TRUE (if you want the external airlock)

A couple of issues with this.

Where the hatches go, change according to where the Adapter is placed, also the fabric cover, over the hatch.

 

[GLS]

A couple of issues with this.

Where the hatches go, change according to where the Adapter is placed, also the fabric cover, over the hatch.

There's always 3 hatches, right? And only the top one is used for EVA, so AFAIK there's only one cover which is always there. The other 2 hatches are always connected to something. The only issue I see is having a cover on the airlock hatch (internal or external), as it might be, or not, connected to something.