SSU Development Thread (3.0 to 4.0)

[Urwumpe]

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.

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

Added a new 5.0 milestone there, via "Edit milestones". I also made it default, so any new ticket goes to 5.0 in first place.

 

[GLS]

I just went to the code page in sourceforge and got the following message:

Empty Repository
It looks like this Subversion repository doesn't have any files in it. Let's commit your project code now.

Their twitter has the following info:

SF.net Operations ‏@sfnet_ops 2h2 hours ago
#SourceForge project web will temporarily be down for planned maintenance.

Hope its nothing more than that....

 

[Urwumpe]

If its down for ever, we go somewhere else ...



...or I have to invest my little salary into getting a development server for us....

 

[GLS]

Another update:
SF.net Operations ‏@sfnet_ops 3m3 minutes ago
#SourceForge is experiencing issues. The ops team is investigating.

 

[kuddel]

...had the same issues while updating OVP, but it seemed to be up again!

 

[GLS]

"We're sorry -- the Sourceforge site is currently in Disaster Recovery mode"

deja vu all over again :facepalm:

 

[DaveS]

Maybe we should initiate talks with the O-F admin staff about setting up a SSU SVN repository here.

 

[GLS]

Maybe we should initiate talks with the O-F admin staff about setting up a SSU SVN repository here.

Let's see what happens. The last commit was about 1.5 days ago, so unless they really messed up the backups, this time we should not loose anything. Currently I can go a few days without it, as I still have tons of work to do on the PFDs and the second font, but it's never good to see the word "disaster" in the status of something. :uhh:

 

[Urwumpe]

Let's see what happens. The last commit was about 1.5 days ago, so unless they really messed up the backups, this time we should not loose anything. Currently I can go a few days without it, as I still have tons of work to do on the PFDs and the second font, but it's never good to see the word "disaster" in the status of something. :uhh:

The project has survived now for 9 years and various disasters (including me), that kind of stuff is just a minor challenge for us.

---------- Post added at 11:51 AM ---------- Previous post was at 10:57 AM ----------

Maybe we should initiate talks with the O-F admin staff about setting up a SSU SVN repository here.

We should then move away from SVN and turn towards git. git simply comes closer to what our workflow in reality is now, with various single developer branches and experiments and one main line of development.

In the worst case, you remind me on the 10th birthday of SSU and I look at how to fund a combined git + Jenkins server for us. But there are a lot of don'ts for me:

I don't want to make it depend on me personally for the next 10 years
I don't want to be overly depending on donations there
I don't want to have a machine stand at home and require me to administrate it

A quick search gets me about 20€ per month for a suitably sized windows 2008 server... a bit expensive for our current standards. Maybe we can get a better offer there, if I look more carefully.

 

[GLS]

Latest update

SF.net Operations ‏@sfnet_ops 1h1 hour ago
#SourceForge is still experiencing issues, we are working hard to address the problems.

The meltdown came a bit early this year... must be el niño.

 

[DaveS]

And we're back:

SF.net Operations ‏@sfnet_ops 3min ago
#SourceForge is back to full capacity.

---------- Post added at 09:19 PM ---------- Previous post was at 07:44 PM ----------

Some issues building the SSU sources against the Orbiter 2016 RC1 SDK. I have deleted the gcAPI_dbg.lib file and rebuilt the sources countless times now with no change.

1>gcAPI.lib(gcAPI.obj) : error LNK2038: mismatch detected for '_MSC_VER': value '1900' doesn't match value '1600' in ASE_IUS.obj
1>gcAPI.lib(gcAPI.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in ASE_IUS.obj
1>     Creating library Debug\Atlantis\SpaceShuttleUltra.lib and object Debug\Atlantis\SpaceShuttleUltra.exp
1>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
1>gcAPI.lib(gcAPI.obj) : error LNK2019: unresolved external symbol __ftoui3 referenced in function "unsigned long __cdecl gcColor(union oapi::FVECTOR4 const *)" (?gcColor@@YAKPBTFVECTOR4@oapi@@@Z)
1>..\..\Modules\SpaceShuttleUltra.dll : fatal error LNK1120: 1 unresolved externals

 

[GLS]

Some issues building the SSU sources against the Orbiter 2016 RC1 SDK. I have deleted the gcAPI_dbg.lib file and rebuilt the sources countless times now with no change.

1>gcAPI.lib(gcAPI.obj) : error LNK2038: mismatch detected for '_MSC_VER': value '1900' doesn't match value '1600' in ASE_IUS.obj
1>gcAPI.lib(gcAPI.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in ASE_IUS.obj
1>     Creating library Debug\Atlantis\SpaceShuttleUltra.lib and object Debug\Atlantis\SpaceShuttleUltra.exp
1>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
1>gcAPI.lib(gcAPI.obj) : error LNK2019: unresolved external symbol __ftoui3 referenced in function "unsigned long __cdecl gcColor(union oapi::FVECTOR4 const *)" (?gcColor@@YAKPBTFVECTOR4@oapi@@@Z)
1>..\..\Modules\SpaceShuttleUltra.dll : fatal error LNK1120: 1 unresolved externals

I got that sometime ago... the D3D9 library doesn't like vs2010 because it was built with a more recent vs version. That time Jarmonik built one on vs2005 or something and it worked.

 

[DaveS]

Could we add a annotation that states the flight controller mode? I mean the Rotation/Translation mode. Current we have no indication which mode is the active one.

 

[GLS]

Could we add a annotation that states the flight controller mode? I mean the Rotation/Translation mode. Current we have no indication which mode is the active one.

Yeah, we could always add some kind of screen output for that, with the option to show and hide it. Right now I'm starting the A/E PFD over on the beta branch... it will probably take a week or more, but after that I can come up with something.
(Another thing we could do is have the THCs and RHCs move on user command, but it probably will be a 99% waste of time and effort as most of the times we're not looking at the THC or RHC to see it move...)

Any ETA for SSU 4.0? Orbiter2010 is about to become "obsolete"...

 

[GLS]

I closed the OBSS texture ticket, as it's +/- fixed.... but this problem might actually be caused by the "flat surface" at the end of the OBSS being at the wrong angle, i.e, it's tilted outboard too much. Looking at the previous relation between the black bars and the surface, it seems that it was correct. and it was the "flat surface" that was tilted the wrong way. ATM I don't have time to take a deeper look into this

 

[DaveS]

I closed the OBSS texture ticket, as it's +/- fixed.... but this problem might actually be caused by the "flat surface" at the end of the OBSS being at the wrong angle, i.e, it's tilted outboard too much. Looking at the previous relation between the black bars and the surface, it seems that it was correct. and it was the "flat surface" that was tilted the wrong way. ATM I don't have time to take a deeper look into this

After checking with various photos, it appears that you are correct. The End Effector of the OBSS is flat when it is in the deployed position in the MPMs. I have now fixed this and checked in the fixed version.

 

[GLS]

Meltdown 2:
SF.net Operations ‏@sfnet_ops 5m5 minutes ago
#SourceForge is experiencing issues. The ops team is investigating.

---------- Post added at 09:29 PM ---------- Previous post was at 06:46 PM ----------

Meltdown 2:
SF.net Operations ‏@sfnet_ops 5m5 minutes ago
#SourceForge is experiencing issues. The ops team is investigating.

... and back to normal.

 

[DaveS]

Where do we stand on getting the radar altimeters implemented? We need them as currently all our TAEM, HAC and A&L GN is expecting a flat even Earth. With 2016 this is no longer true. So this throws everything off as shown in this screenshot (note the altitude tape on the A/E PFD, 2326 ft):

 

[GLS]

Yes, we need the RAs for SSU 5.0. I'm thinking about making the class and having the data ready for use, but until the new GPCs are done that data won't be used.
In addition to a radar, we'll also need the ADPs and the landing site altitude for NAV.

---------- Post added at 09:59 PM ---------- Previous post was at 01:59 AM ----------

I was looking at issue with the RMS coordinates (and I'm giving up for now as it will probably take me a couple of weeks to learn enough RMS to be able to fix it) and found that the EE camera and light are tilted a bit too much outboard. According to the diagrams it should be "on top" of the RMS when it's deployed. Can't find images to back the diagram up. Other than that, I can only say the RMS attitude numbers seem really messed up, which makes me think we're using the wrong referential. On the positions, some axis match well some times... There's a 2 inch error on the X-axis in the cradled position, so some of this is probably due to wrong measurements being used. I'm not going to touch anything for now as I still don't quite know what I'd be doing.

On more pressing matters: what is missing on SSU 4.0, so we can release and all move to the new Orbiter? Is the new ET mesh(es) ready to go? What about these?

 

[DaveS]

The RMS EE/light is not " on-top" when the RMS is deployed. This is set of of images of the RMS from the Shuttle Orbiter/Cargo Standard Interfaces document: