SSU Development Thread (3.0 to 4.0)

[Urwumpe]

This below in a "changelog.txt" going in the doc/SSU folder, and a page in the manual at the end before the credits?

Yes - maybe I can do a small lua script this weekend, that turns a generic change log from Subversion into a formatted version for latex and a readme text file. Would that be a solution?

 

[GLS]

Yes - maybe I can do a small lua script this weekend, that turns a generic change log from Subversion into a formatted version for latex and a readme text file. Would that be a solution?

I don't think so, as it would output all changes, and I don't think we what to have "small" changes like "updated the manual" and such. That change log wasn't too hard to do by hand, so I don't see the need to automate it. For the manual I'll try to make it as simple as possible, so in the future it's just copy-paste a new change list and create the pdf.

Speaking of scripts, I think it was you that created the refman.pdf with the code documentation. I tried to get that script working to create a new pdf (the existing one is like from 2008) but it doesn't like me :facepalm:. Could you run that and create a new pdf, so we can see how little documented code we have? :lol:

 

[Urwumpe]

I don't think so, as it would output all changes, and I don't think we what to have "small" changes like "updated the manual" and such. That change log wasn't too hard to do by hand, so I don't see the need to automate it. For the manual I'll try to make it as simple as possible, so in the future it's just copy-paste a new change list and create the pdf.

Speaking of scripts, I think it was you that created the refman.pdf with the code documentation. I tried to get that script working to create a new pdf (the existing one is like from 2008) but it doesn't like me :facepalm:. Could you run that and create a new pdf, so we can see how little documented code we have? :lol:

Refman.pdf was created with doxygen, I doubt I have done some magic there. :lol:

Well, we could for example steal an idea, that other people use for agile development: They add a special code to their subversion comments, that is parsed by the build system and turned into a changelog and also automatically increments the version based on the change.

 

[GLS]

Refman.pdf was created with doxygen, I doubt I have done some magic there. :lol:

Yes I know it was done by/with doxygen, but I can't get that thing to spit out a pdf, and I tried both the "manual script" way and the GUI way... just html comes out :facepalm:. You got it to work once, so I'm putting this by your door. :lol:

Well, we could for example steal an idea, that other people use for agile development: They add a special code to their subversion comments, that is parsed by the build system and turned into a changelog and also automatically increments the version based on the change.

Yeah, but then someone messes the comments up and the whole thing fails to do what we want. We don't really release that often, and even if we did, this isn't in the critical path nor is it complex or critical, so I think there's no real need for automation here.
Right now I'm dealing with "real life stuff", but before the end of the day I'll have the change log section added to the manual.

---------- Post added at 09:03 PM ---------- Previous post was at 04:57 PM ----------

Change log added to the manual (available here).
Can we get this out the door by Tuesday?

 

[Urwumpe]

Yes I know it was done by/with doxygen, but I can't get that thing to spit out a pdf, and I tried both the "manual script" way and the GUI way... just html comes out :facepalm:. You got it to work once, so I'm putting this by your door. :lol:

Needed some klingon to get it work again on a new computer, but luckily, at least a MikTex installation was already available here. :lol:

The output file is now a lot larger than the old one (50 MB, over 2000 hyperlinked pages), but contains also a lot more diagrams and source files.

Just wait for sourceforge until the file appears in the References folder.

Tried initially to check it in, but the upload speed was at 4 kb/s, so I decided to leave this exercise to others and use SFTP for the large PDF file.


https://sourceforge.net/projects/sh...source code reference manual 4.0.pdf/download

 

[GLS]

Needed some klingon to get it work again on a new computer, but luckily, at least a MikTex installation was already available here. :lol:

The output file is now a lot larger than the old one (50 MB, over 2000 hyperlinked pages), but contains also a lot more diagrams and source files.

Just wait for sourceforge until the file appears in the References folder.

Tried initially to check it in, but the upload speed was at 4 kb/s, so I decided to leave this exercise to others and use SFTP for the large PDF file.


https://sourceforge.net/projects/sh...source code reference manual 4.0.pdf/download

Many thanks!
I'll commit it then.

 

[Urwumpe]

Many thanks!
I'll commit it then.

Not sure if needed, I'll just check in the modified Doxygen file, that should be enough for subversion, don't you think?

 

[GLS]

Actually I'll leave the file there, as in the process of finding the location of the old file I found that it was removed from version control and moved to the References folder in SF.

---------- Post added at 11:31 PM ---------- Previous post was at 11:29 PM ----------

Not sure if needed, I'll just check in the modified Doxygen file, that should be enough for subversion, don't you think?

Yes.

 

[GLS]

So I started the "MFD revolution" in the Orbiter2016 branch (should we create a SSU 4.0 to 5.0 thread for this?) by making a very very simple MFD for the Centaur vessel to display the info up to now shown in the HUD. It uses the 'T' key so it will not work with the keyboard as it collides with CRTMFD, but as when this is all done the CRTMFD will not be accessible from the Centaur (or anywhere else), this conflict will solve itself.
In the future we can have all kinds of pretty drawings in there, but for now I think just the numbers works fine.
IUS is next, and then the CRTMFD which will have to be done in parts: move the MFD into the vessel, change to sketchpad, add D3D9 goodies, move the subsystem displays into the MDU class (not in this particular order).

 

[GLS]

Did some testing with a packaged SSU 4.0 and it seems to work well. The only bug I found was the "green cavities" are always uncovered. Other than that, I think only the CISS G animations need updating, and it's ready do meet the public.

 

[DaveS]

Did some testing with a packaged SSU 4.0 and it seems to work well. The only bug I found was the "green cavities" are always uncovered. Other than that, I think only the CISS G animations need updating, and it's ready do meet the public.

This has now been fixed.

 

[GLS]

DaveS, I noticed that you re-added the Orbiter_blank.dds texture to the Orbiter.msh file in r2429 (I noticed the texture not found messages while running Orbiter beta). Is that texture needed now? Because a few weeks back it was not needed and its entry in the mesh replaced with Atlantis_5thmod.dds.

 

[DaveS]

DaveS, I noticed that you re-added the Orbiter_blank.dds texture to the Orbiter.msh file in r2429 (I noticed the texture not found messages while running Orbiter beta). Is that texture needed now? Because a few weeks back it was not needed and its entry in the mesh replaced with Atlantis_5thmod.dds.

It's because the source model file still makes use of it. I haven't gotten around updating it so I missed that the file got checked in.

 

[DaveS]

The new SLWT mesh is finally ready for its big reveal. It's now properly sized, everything is per the SLWT System Definition Handbook. Don't mind that that the GH2 vent arm in the third image doesn't mate properly with the ET Carrier Assembly (ETCA) on the actual ET. This is due to that the FSS is off.

East Camera Site:

East side of the hard stand looking up:

300' level of the FSS looking down:

South side of the hard stand looking north towards the vehicle:

---------- Post added 07-09-16 at 08:25 PM ---------- Previous post was 07-08-16 at 11:22 PM ----------

I have checked in a mostly complete version of the new SLWT. Please do note use any LWT/SWT scenarios as the updated offsets breaks the alignment of those. I have included this note on line 2230 of Atlantis.cpp:

ahET = CreateAttachment(false, ET_OFFSET + ofs, _V(0, 1, 0), _V(0, 0, 1) , "SSU_ET"); // DaveS note: DIR and ROT vectors should be V(0.0, 0.999997,  0.00261802), _V(0.0, 0.00261802, 0.999997) but this causes the ET to move during 2nd stage and I'm not sure what to do about that. It's most likely related to CG calcs.

 

[Urwumpe]

I have checked in a mostly complete version of the new SLWT. Please do note use any LWT/SWT scenarios as the updated offsets breaks the alignment of those.

What alignment issues are now left to do?


And what is needed to be done for the other bases that we included in the SSU distribution to work in beta? Any experiences already?

 

[GLS]

What alignment issues are now left to do?


And what is needed to be done for the other bases that we included in the SSU distribution to work in beta? Any experiences already?

I think for SSU 5.0 we should swallow the Usonian's Vandenberg base. Due to the 3D terrain, some changes are required to Usonian's addon, and it would be easier if we distributed (and modified) the files we need. Other than that, only every runway surface needs work to flatten it :lol: :facepalm:. Edwards no longer has a runway, it has a rollercoaster....
And we'll need to compile runway end altitude values for use in AerojetDAP (and change that as well).

 

[DaveS]

What alignment issues are now left to do?

What do you mean? Do you mean if there's anything else that's mis-aligned? Well, in that case: Just both the pads as they were made for the old ET meshes.

And what is needed to be done for the other bases that we included in the SSU distribution to work in beta? Any experiences already?

Well, they do need to be converted to the 2016 base standards which I have no idea how to do. The documentation is non-existent. So those will have to wait until the documentation has been made available.

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

I think for SSU 5.0 we should swallow the Usonian's Vandenberg base. Due to the 3D terrain, some changes are required to Usonian's addon, and it would be easier if we distributed (and modified) the files we need. Other than that, only every runway surface needs work to flatten it :lol: :facepalm:. Edwards no longer has a runway, it has a rollercoaster....
And we'll need to compile runway end altitude values for use in AerojetDAP (and change that as well).

And the NWS needs to be updated as its way too sensitive as are the brakes.

 

[GLS]

And the NWS needs to be updated as its way too sensitive as are the brakes.

That's not base related.

 

[Urwumpe]

And the NWS needs to be updated as its way too sensitive as are the brakes.

Can you file a ticket for it, including describing how to test for proper behavior? There is no NWS related ticket open right now.

 

[GLS]

Can you file a ticket for it, including describing how to test for proper behavior? There is no NWS related ticket open right now.

I think our logic is applying too much sideways force, inducing such a sideslip that the vehicle starts rolling down the runway, or it starts sliding sideways if the touchdown coefficients are lowered.

---------- Post added at 08:50 PM ---------- Previous post was at 08:48 PM ----------

Speaking of tickets, I can't change the milestones there, so 3.2 means 5.0 (the first beta release)