SSU Development thread (4.0 to 5.0)

Gingin

New member
Joined
Feb 5, 2015
Messages
255
Reaction score
0
Points
0
Location
City of Light
All the best for the fork thing.
Thanks for your work, I really had and still have a lot of fun with SSU.
A rendez vous every week :)
Entry thing and drag predicator is really an impressive work.
 

DaveS

Space Shuttle Ultra Project co-developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
8,786
Reaction score
38
Points
123
Instead of starting a fresh project, maybe I should be the one to leave as I'm the cause of all these mesh issues. Right now, there's nothing for me to do any way so as I can't provide any coding to the project and coding is what is limiting the project. How long have we been waiting a freaking DPS anyway? 12 or so years? I still remember promises of a final DPS implementation back in 2009 while the actual real shuttle was still flying and here we are in 2020, and nothing yet!

And the ODS/Airlock was last touched mesh-wise back in August 2015. If you don't believe me, check the SVN log for ODS.msh. As there's no hard requirement for nicer meshes or textures I think I should just be on my own, creating high detail stuff for myself, just like I was was David413's Shuttle Fleet was still a thing.

That way everyone gets what they want. I'll just be another third-party rather than a first party supplier.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
35,590
Reaction score
97
Points
138
Location
Langendernbach
Its a sad point in the project, but well, it may be we all deserved it.

No idea how it will go on. My new notebook arrived last week, but I still have to install all the development tools (But I got NASSP running out of the box a day after it arrived).

Maybe I'll do the same there. Just fork off on a git repository and just do all the DPS and AI crew nonsense that I wanted to implement but was never really able to do with the broken notebook.

But I don't feel like I will release anything except the code. We are at a point now, where somebody else should be the hero. I have grown old. With mere 41. SSU needs a maintainer.

And then, I would rather start with the backend again and fix all those testability and architecture issues that added to the lava cake that made it harder to implement new features into SSU. No pressure to make something visible to the end user sounds like a good thing, also it should keep the inbox empty.
 

Face

Addon Developer
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,115
Reaction score
57
Points
73
Location
Vienna
But because I really want an "advanced" shuttle simulation to be available for Orbiter, I will fork SSU and continue on my own (after I come up with a new name :facepalm:).
Wouldn't it make more sense to just create a branch and do everything you want there? The term "fork" is more appropriate for hard separation of teams these days, where you put up your own infrastructure (repo/build-server/test-suites) and have your own management (roadmap, decision-making process).

Don't get me wrong, but I don't have the impression that there is a lot of both in SSU, anyway. If you feel like there should be (why else fork?), why not set the course yourself?
 

Wolf

Donator
Donator
Joined
Feb 10, 2008
Messages
1,082
Reaction score
1
Points
38
Location
Milan
I tried, and I ringing the bell long before that.

I am very sorry to hear that but I totally understand your motives. I remember posting a question about potential priorities for SSU long time ago since I had the impression that efforts were somehow going dispersed.
I really hope that one way or the other this project will survive and its developement continue. And ring the bell when the mesh are done so that maybe I can work again on the Hi-res textures :thumbup:
 

DaveS

Space Shuttle Ultra Project co-developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
8,786
Reaction score
38
Points
123
So where do we stand on further development or is the project over? I really think that the project should move on but in an coding aspect only. The visual elements (the meshes and textures) should become secondary. Think of what Dr. Schweiger did with Orbiter, he split the physics from the visuals creating the Orbiter Visual Project (OVP) which has given us the wonderful D3D9Client.

SSU would still have a basic set of visual elements but any further development to them beyond the absolutely necessary would essentially become add-ons. This way they would never become the pacing element or be put in the critical path ever again. I really think this would work and would really push the project forward.
 

GLS

Addon Developer
Addon Developer
Joined
Mar 22, 2008
Messages
3,951
Reaction score
67
Points
73
So where do we stand on further development or is the project over? I really think that the project should move on but in an coding aspect only. The visual elements (the meshes and textures) should become secondary. Think of what Dr. Schweiger did with Orbiter, he split the physics from the visuals creating the Orbiter Visual Project (OVP) which has given us the wonderful D3D9Client.

SSU would still have a basic set of visual elements but any further development to them beyond the absolutely necessary would essentially become add-ons. This way they would never become the pacing element or be put in the critical path ever again. I really think this would work and would really push the project forward.
If that question is aimed to me, I said my peace in my last post.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
35,590
Reaction score
97
Points
138
Location
Langendernbach
So where do we stand on further development or is the project over? I really think that the project should move on but in an coding aspect only.

In that case, it is effectively over, since we have too few C++ developers.



And since we have the problem every other year, it is no new problem. We need to try something else. But don't ask me how. I have no idea yet, that we did not try in the past.

Maybe we need a reasonable storyline first again, before we again get lost in detail?
 

DaveS

Space Shuttle Ultra Project co-developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
8,786
Reaction score
38
Points
123
I think the main problem is that none of us have any managerial skills whatsoever so things tend to derail often because of it. We'd really need someone at the top that would coordinate things, essentially serving as final arbiter on what goes in. Right now we don't have that at all and none of us really want to take on that role.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
35,590
Reaction score
97
Points
138
Location
Langendernbach
I think the main problem is that none of us have any managerial skills whatsoever so things tend to derail often because of it. We'd really need someone at the top that would coordinate things, essentially serving as final arbiter on what goes in. Right now we don't have that at all and none of us really want to take on that role.

I tend to agree, but again, this is a free time project. I am returning doing the PO/Software Architect/Systems Engineer job at work after getting one half of the PLM services here running well, I know what this management task means, but I don't want to do that after work as well.

Anything with more authority than a Product Owner would fail. And we would need a commitment. And more than one developer. Which currently looks bad.

Also, this manager should not be involved in development. If we take the scrum values as any kind of reference here:



  1. Commitment: Team members individually commit to achieving their team goals, each and every sprint.
  2. Courage: Team members know they have the courage to work through conflict and challenges together so that they can do the right thing.
  3. Focus: Team members focus exclusively on their team goals and the sprint backlog; there should be no work done other than through their backlog.
  4. Openness: Team members and their stakeholders agree to be transparent about their work and any challenges they face.
  5. Respect: Team members respect each other to be technically capable and to work with good intent.
Sorry, but we lack 1,2,3 and 4. But I am convinced that 5 is still fine.

Maybe I will return finishing some of the DPS/OI/AI things I started while the rest of you agree about any kind of management structure and project manifest in the mean time.

But I feel like the best for SSU would be a complete change in generation, we should search for our successors. I have job and family now, I can't invest much time into SSU. It would be more realistic for me to stay out of any core team as emeritus and just do small patches or develop missions.



Maybe things change when I finally have my BSc degree, I am just a few formalities and months away from finally writing my thesis at work.
 

STS

Member
Joined
Feb 1, 2009
Messages
349
Reaction score
3
Points
18
Location
Vigo
Website
orbisondas.es
Hello team.


It´s very sad to read the last pages of this thread. If you need any help to continue the development of SSU, count me in.


I am very new to C++ development, but I have experience on the field of programming. I would need some kind of masterclass about how to develop for SSU (and well, also, for Orbiter), I would be very happy to help. I live close to GLS, and have the same timezone as Urwumpe, so maybe we could make some TS/DS meetups? I say this because of the timezone issue, if we want to speak on a syncronized manner.



As you know I have a community that I am trying to resurrect now, and we are very interested in SSU. We are, I think, very good betatester as we do full missions (well, without most of the prelaunch, if we are being strictly realistic...).



I have some guys there that could also provide help to the graphics department.


Please make me know how we can help.
 

jarmonik

Addon Developer
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,108
Reaction score
64
Points
48
Website
users.kymp.net
When I was debugging some SSU related MFD problem I noticed a font quality being pretty bad. It would seem that DX7 is running with better font quality than DX9, so, how do you draw for an example the "FLIGHT INSTRUMENT MENU" Tex ? We use GDI::TextOut() and the results are not good.


Also, I made an experiment to push the MFD render size from 512px up-to 1024px (current max of Orbiter) and the results are much better. I have attached a hacked version of D3D9Client that will enlarge the CRT MFD to 1024 resolution.


To test it, the MFD resolution from "Extra" tab must be set to 1024. But be warned that many other things wont render correctly since all Sketchpad outputs are enlarged. Binary is for Orbiter Beta, backup the original file first.
 

Attachments

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
35,590
Reaction score
97
Points
138
Location
Langendernbach
I think for the Flight Instrument Menu, we use Sketchpad Textout, while for the CRT screens, we prerender the font in a suitable size on an internal texture and use BitBlt there.

Would need to take a look again there, have the sources on my other notebook.
 

DaveS

Space Shuttle Ultra Project co-developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
8,786
Reaction score
38
Points
123
When I was debugging some SSU related MFD problem I noticed a font quality being pretty bad. It would seem that DX7 is running with better font quality than DX9, so, how do you draw for an example the "FLIGHT INSTRUMENT MENU" Tex ? We use GDI::TextOut() and the results are not good.


Also, I made an experiment to push the MFD render size from 512px up-to 1024px (current max of Orbiter) and the results are much better. I have attached a hacked version of D3D9Client that will enlarge the CRT MFD to 1024 resolution.


To test it, the MFD resolution from "Extra" tab must be set to 1024. But be warned that many other things wont render correctly since all Sketchpad outputs are enlarged. Binary is for Orbiter Beta, backup the original file first.
No issues here, except for the one you noted (every Sketchpad output is enlarged). MFDs does look better and are more readable. Added bonus is that 1024x1024 is the resolution of the actual Shuttle MDUs, so that's nice.
 

DaveS

Space Shuttle Ultra Project co-developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
8,786
Reaction score
38
Points
123
So I have been in contacted Donamy about SSU's current implementation of the RMS and I have gotten confirmation that the EE in Candarm2 does not suffer from the same singularity attachment point slippage that the Candarm in SSU does. I really think that a fix for this and the save/load bug I recently discovered should make its way into the next SSU release as it makes executing certain missions impossible, like STS-31 which saw the EE go through several singularities to have the telescope oriented a certain way for the crew and ground controllers in the Space Telescope Operations Control Center (STOCC pronounced "stock") to observe the Hi-gain antennas and solar arrays as they were being deployed and unfurled.

Speaking of it, does anyone have an up to date list of meshes that still needs to be cleansed of their hidden triangles?
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
35,590
Reaction score
97
Points
138
Location
Langendernbach
So I have been in contacted Donamy about SSU's current implementation of the RMS and I have gotten confirmation that the EE in Candarm2 does not suffer from the same singularity attachment point slippage that the Candarm in SSU does.

This only happens while in singularity?
 

DaveS

Space Shuttle Ultra Project co-developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
8,786
Reaction score
38
Points
123
This only happens while in singularity?
As far as both I, Donamy and jgrillo2002 who has apparently duplicated it in the shuttle fleet add-on (https://www.orbiter-forum.com/project.php?issueid=1324), yes. The EE attachment point slips causing it to visually move away from where the EE is with any attached payloads, such as HST. Another thing that would be nice to have would be the COARSE/VERN rate indicator which is the MIN TB on A8U, it shows ON when the RMS is in the VERN rate mode and OFF when in the COARSE rate mode.
 
Last edited:

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
35,590
Reaction score
97
Points
138
Location
Langendernbach
As far as both I, Donamy and jgrillo2002 who has apparently duplicated it in the shuttle fleet add-on (https://www.orbiter-forum.com/project.php?issueid=1324), yes. The EE attachment point slips causing it to visually move away from where the EE is with any attached payloads, such as HST. Another thing that would be nice to have would be the COARSE/VERN rate indicator which is the MIN TB on A8U, it shows ON when the RMS is in the VERN rate mode and OFF when in the COARSE rate mode.

Can you get me some example angles to replicate it? I am still busy with setting up the workspace, just managed to compile something, not sure what it is.

---------- Post added at 21:44 ---------- Previous post was at 21:38 ----------

And can you put "Support 1024 x 1024 MFD resolution" to our TODO list? Where are we currently tracking the issues?
 

DaveS

Space Shuttle Ultra Project co-developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
8,786
Reaction score
38
Points
123
Can you get me some example angles to replicate it? I am still busy with setting up the workspace, just managed to compile something, not sure what it is.
Well, the easiest approach is to load up the attached scenario Then press Ctrl-A to switch over control to the RMS. Then using the numpad controls yaw the EE past the singularity at Y/YAW +270.0 (Numpad 6) and back to +0.0 (Numpad 4). Now just repeat this for a few minutes. Now the EE and the MPLM should have diverged attitudes and there's no way the EE should still have a firm grapple of the MPLM.
 

Attachments

Top