SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[STS]

It would be nicer if we could also support rudder pedals. Is there a successor to the FBW plugin around? I have rudder pedals available for testing because of DCS:A-10C...

I reopen the earlier debate about why not a joystick axis (and/or some axis of another device, as standalone rudder pedals like Urwumpe or many simmers may have). If I understand correctly, an equivalent to a keypress would be to depress the pedal fully to one side or to the other.


Having this knowledge that the rudder can be moved by keystrokes, I made a successfull landing at edwards from the Edwards Entry test scenario, with some mistakes by my end during final approach, but safely made it to the runway, as I could manage the lost energy better.


Will continue testing.

 

[EstebanDF]

I reopen the earlier debate about why not a joystick axis (and/or some axis of another device, as standalone rudder pedals like Urwumpe or many simmers may have). If I understand correctly, an equivalent to a keypress would be to depress the pedal fully to one side or to the other.


Having this knowledge that the rudder can be moved by keystrokes, I made a successfull landing at edwards from the Edwards Entry test scenario, with some mistakes by my end during final approach, but safely made it to the runway, as I could manage the lost energy better.


Will continue testing.

Hi STS,

I've also noticed that if you manually work the rudders with the keyboard, then they self re-center so I assume the auto coordinated flight works.

you can also check the rudder manual and automatic actuation on the monitor down the hud.. Edit: The keyboard actuation is not immediate, like it will go to the extreme, the rudder actuation is rather slow.

 

[STS]

Hi STS,

I've also noticed that if you manually work the rudders with the keyboard, then they self re-center so I assume the auto coordinated flight works.

you can also check the rudder manual and automatic actuation on the monitor down the hud.. Edit: The keyboard actuation is not immediate, like it will go to the extreme, the rudder actuation is rather slow.

Yep, by using the SPI display I was able to manage the rudder with the keys, as shown, enabling me to manage energy better, as explained on the earlier post.

 

[ThBaron]

Texture of Shuttle front

I was interested in the current progress of SSU and downloaded the nightly build SSU_nightly_v5.0r3253.zip of 05/13/20. Is the texture issue on the front part of the shuttles because of the current status of the textures or do I have a wrong configuration? I use D3D9 Client R4.4 forOrbiter2016 (r1306). Thanks!
Screenshot https://drive.google.com/file/d/1aEH3FGM2xmex_SR4-yvXzUoUYa4wFOOB/view

 

[Urwumpe]

I was interested in the current progress of SSU and downloaded the nightly build SSU_nightly_v5.0r3253.zip of 05/13/20. Is the texture issue on the front part of the shuttles because of the current status of the textures or do I have a wrong configuration? I use D3D9 Client R4.4 forOrbiter2016 (r1306). Thanks!
Screenshot https://drive.google.com/file/d/1aEH3FGM2xmex_SR4-yvXzUoUYa4wFOOB/view

The first one, current status of the meshes vs the textures.



Seems to be part of this huge list: https://sourceforge.net/p/shuttleultra/tickets/177/


I already flagged it as "Needs refinement", I'll split it this huge collection of issues into individual tickets when I have more time for paperwork, so we can better track what is broken and what needs to be fixed.

 

[DaveS]

To detail the issue, the problem is that the orbiter mesh is currently mapped to Wolf's High Resolution Photorealistic Textures, which have things in slightly different locations than our current orbiter textures. I believe Wolf is awaiting the official 5.0 release to finish his textures, so for the time being, it is "will live with it" kind-of issue.

 

[Wolf]

I was interested in the current progress of SSU and downloaded the nightly build SSU_nightly_v5.0r3253.zip of 05/13/20. Is the texture issue on the front part of the shuttles because of the current status of the textures or do I have a wrong configuration? I use D3D9 Client R4.4 forOrbiter2016 (r1306). Thanks!
Screenshot https://drive.google.com/file/d/1aEH3FGM2xmex_SR4-yvXzUoUYa4wFOOB/view

Has SSU V5.0 been released? Where is this v5.0r3253 available?
BTW I tried to update SSU via SVN tool last week but it failed to recompile and now all the scenarios cause CTD...

 

[Urwumpe]

To detail the issue, the problem is that the orbiter mesh is currently mapped to Wolf's High Resolution Photorealistic Textures, which have things in slightly different locations than our current orbiter textures. I believe Wolf is awaiting the official 5.0 release to finish his textures, so for the time being, it is "will live with it" kind-of issue.

I don't think that is a good idea. Additionally to various gaps and other issues, this makes it also impossible to test SSU out of the box. And I don't think these textures are a required dependency. They should be considered optional. This way, we can test SSU without depending on a specific version of the textures.


So, no living with it. Fixing it.

 

[DaveS]

I don't think that is a good idea. Additionally to various gaps and other issues, this makes it also impossible to test SSU out of the box. And I don't think these textures are a required dependency. They should be considered optional. This way, we can test SSU without depending on a specific version of the textures.


So, no living with it. Fixing it.

The plan was use those textures as our new OOB textures, replacing the ones we've have since the beginning, which are based on the default Atlantis textures. They've been edited to hell and back in 13 years, not really looking any good or being that particularity accurate for that matter as well. So the plan was to get rid of them and use something that was custom created for SSU, instead of trying to shoe-horn ill-fitting textures to a mesh that barely have any connection to the textures it was trying to fit.


But due to various issues, this hasn't happened so far.

 

[Urwumpe]

The plan was use those textures as our new OOB textures, replacing the ones we've have since the beginning, which are based on the default Atlantis textures. They've been edited to hell and back in 13 years, not really looking any good or being that particularity accurate for that matter as well. So the plan was to get rid of them and use something that was custom created for SSU, instead of trying to shoe-horn ill-fitting textures to a mesh that barely have any connection to the textures it was trying to fit.


But due to various issues, this hasn't happened so far.

Right now, things have become worse. Not better. Where is it custom fitted? What kind of quality assurance is it?

 

[ThBaron]

Where is this v5.0r3253 available?

see https://www.orbiter-forum.com/showthread.php?p=605980&postcount=2913

 

[Urwumpe]

Has SSU V5.0 been released? Where is this v5.0r3253 available?
BTW I tried to update SSU via SVN tool last week but it failed to recompile and now all the scenarios cause CTD...

Which repository did you use? I created the "nightly-build" package from the Orbiter-Forum repository.

 

[DaveS]

Has SSU V5.0 been released? Where is this v5.0r3253 available?
BTW I tried to update SSU via SVN tool last week but it failed to recompile and now all the scenarios cause CTD...

Could you post the error messages? The trunk should be build just fine.

 

[Wolf]

Which repository did you use? I created the "nightly-build" package from the Orbiter-Forum repository.

I used this svn://orbiter-radio.co.uk/shuttleultra/trunk


Guess it's wrong. So which one should I use for the SVN update?

 

[Wolf]

Could you post the error messages? The trunk should be build just fine.

Basically the whole thing failed (19 items out of 16)

 

[Urwumpe]

Basically the whole thing failed (19 items out of 16)

View attachment 17156

Yes, you are still compiling on the old VC++, I used the Visual Studio 2019 Community.



I plan switching to CMake after finishing the first step to move the animation definitions into JSON files, then the requirement to use the same VS version and toolchain should be gone.

 

[DaveS]

Urwumpe: Would it be OK for me to check in a set of modified VS2017 project files that can actually build? You checked in a set of the same files a while back that doesn't build OOB, but I modified them again so that they do build OOB.

 

[Urwumpe]

Urwumpe: Would it be OK for me to check in a set of modified VS2017 project files that can actually build? You checked in a set of the same files a while back that doesn't build OOB, but I modified them again so that they do build OOB.

If you are planning to do the development....



What is the problem using VC 2019?

 

[DaveS]

If you are planning to do the development....



What is the problem using VC 2019?

There's no problem. It just that we do have separate solutions/project files for each VS version going all the way back to VS2005 and you altered the VS2017 files to not work VS2017 anymore. Feel free to create VS2019 appropriate files and check those in, that way we don't end up with a broken build chain.
The fixed VS2017 files have been checked in, so the sources should build properly with VS2017 again.

 

[Wolf]

So any suggestion on how I can repair my SSU?