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

[DaveS]

Can't test with the beta, currently testing against the released Orbiter 2016.

What problems do you have getting the Orbiter beta up and running? I had no problems at all. Just create an empty Orbiter 2016 beta folder, perform an SVN Checkout in it with the URL svn://svn.orbiter-forum.com/orbiter/


Then, once the checkout is complete, just copy the contents of it into your main Orbiter 2016 folder and you have upgraded to the latest Orbiter beta version which currently is 190823.

 

[Urwumpe]

What problems do you have getting the Orbiter beta up and running?.

No, I just don't want to.



I want to test SSU against what everybody uses, not a beta that a minority of the more development oriented people try.

---------- Post added at 00:30 ---------- Previous post was at 00:25 ----------

BTW, we seem to have MaxQ earlier and slightly lower than it should be.

80.879794 (SpaceShuttleUltra) {STS-101} [KPI] :   48.9 s MAXQ = 673.3 lb/ft^2

Just testing the idea there. A proper implementation could likely consist of a list of simple event triggers that are recorded during a mission phase.

 

[DaveS]

BTW, we seem to have MaxQ earlier and slightly lower than it should be.

80.879794 (SpaceShuttleUltra) {STS-101} [KPI] :   48.9 s MAXQ = 673.3 lb/ft^2

Just testing the idea there. A proper implementation could likely consist of a list of simple event triggers that are recorded during a mission phase.

Well, we are launching light on most flights as we don't have payloads for them. You could test with STS-107 as all the payloads are all there with their historical masses.

 

[Urwumpe]

Well, we are launching light on most flights as we don't have payloads for them. You could test with STS-107 as all the payloads are all there with their historical masses.

OK, I just used the existing Launch test scenario for STS-101. maybe we should ballast it for comparison to the historic expectations.



I also did some corrections to the STS-120 launch parameters, we aim for a too high MECO in most flights, it should be 52 NM according to the statistics as performance upgrade.

 

[DaveS]

I want to test SSU against what everybody uses, not a beta that a minority of the more development oriented people try.

Could you try the attached archive? It is built against the latest D3D9Client sources for the regular Orbiter 2016 version. It should have the same absolute animations as jarmonik's beta archive, but for the Orbiter 2016 release.

 

[Urwumpe]

Looks much better with it. Also the anomaly with the inverse kinematics calculations of the EE attitude is gone now.

As you can see, the rounding errors are all gone now:

29.665536 RMS EE: +33.4 +77.3 -84.4 -94.0 +16.2 +54.5 -> (-0.000052, -1.000000, 0.000537) [1.000000] * (-0.000358, -0.000537, -1.000000) [1.000000] = 0.000000
122.210726 RMS EE: +33.4 +77.3 -84.4 -94.0 +16.2 +54.5 -> (-0.000204, -1.000000, 0.000526) [1.000000] * (-0.000362, -0.000526, -1.000000) [1.000000] = 0.000000

 

[Donamy]

How do I find which SSU version I'm using ?

---------- Post added at 01:42 AM ---------- Previous post was at 01:37 AM ----------

I found a 110324.zip in modules. It's the only one.

 

[DaveS]

How do I find which SSU version I'm using ?

AFAIK, there's no way currently unless you're using SVN.

---------- Post added at 03:45 AM ---------- Previous post was at 03:43 AM ----------

I found a 110324.zip in modules. It's the only one.

I'm not sure what that is but it isn't one of ours.

 

[Urwumpe]

If you can all agree, that the current version is looking useful, I would say, from checking the tickets, that I should continue with the RCS instead of putting too much time into the DPS now.

---------- Post added at 11:40 ---------- Previous post was at 11:21 ----------

@DaveS : Can you research for the EDO pallet dry mass, as requested in the ticket #199? We can then derive a new ticket for fixing the values in our implementation.

---------- Post added at 11:41 ---------- Previous post was at 11:40 ----------

And does anybody want to do the Product Owner job for SSU and maintain our product backlog? I just started grooming it a bit, but I am also developer right now, I don't want to get into an conflict of interests there.

 

[STS]

And does anybody want to do the Product Owner job for SSU and maintain our product backlog? I just started grooming it a bit, but I am also developer right now, I don't want to get into an conflict of interests there.

Well, I only know the concept of Product Owner theoretically, but as I (talking in the name of my simgroup) am a power user of SSU, and we do full missions that require to test everything on SSU, and report to you issues or suggest improvements, I think that I am a good candidate to take the role of PO.


Do we have a product backlock already? If we do, I understand that it is the current roadmap.

 

[Urwumpe]

Well, I only know the concept of Product Owner theoretically, but as I (talking in the name of my simgroup) am a power user of SSU, and we do full missions that require to test everything on SSU, and report to you issues or suggest improvements, I think that I am a good candidate to take the role of PO.


Do we have a product backlock already? If we do, I understand that it is the current roadmap.

It is the listing of tickets and milestones on Sourceforge, do you already have an account? It isn't exactly the fastest ticket system, but it still seems to be the norm here.

https://sourceforge.net/p/shuttleultra/tickets/

---------- Post added at 12:39 ---------- Previous post was at 12:03 ----------

I uploaded a new "nightly" (rather noonly) build of SSU to Sourceforge so everyone has a recent version available for testing. I won't make it the new default download until we have the 5.0 milestone done, instead I will replace the build from time to time.


It should be available for download in some minutes.

 

[STS]

I just created an account on SF.



It´s turryboeing

---------- Post added at 12:45 PM ---------- Previous post was at 12:43 PM ----------

Later i´ll takee a look at what tickets we have now, and maybe create new ones for the issues I reported here regarding DAP Config and RCS fuel usage.

 

[Urwumpe]

I just created an account on SF.



It´s turryboeing


Later i´ll takee a look at what tickets we have now, and maybe create new ones for the issues I reported here regarding DAP Config and RCS fuel usage.

Can one of our SourceForge Project administrators include him to the project and give him the rights to maintain the list of tickets?


I am in second row now.


BTW, can somebody remove GLS_SSU from the administrators, now that he is doing his own fork?



Maybe give him the lowest project member level, but don't remove him from the project. After all, he was a major contributor to SSU and I sure would have no problems seeing him back again one day.

---------- Post added at 13:00 ---------- Previous post was at 12:58 ----------

You can find the nightly test package now on:

https://sourceforge.net/projects/sh...eultra/5.0/SSU_nightly_v5.0r3253.zip/download

---------- Post added at 13:18 ---------- Previous post was at 13:00 ----------

Another request from a feeble beggar to the administrators: Can you check if we can separate the bug ticket list from the feature list and maintain two lists of ticket trackers? That could make the work way more organized. Thank you.

Just look at how it is done for Project Apollo, but I would replace "Support Requests" by "Documentation", so we have a dedicated tracker for project documentation, tutorials and other media (Like Video Tutorials)

Also, SourceForge improved a lot since the last time I developed for SSU, the links to other artifacts in the wiki works great now, like using [#123] for refering to Ticket 123 in our current system.

 

[GLS]

BTW, can somebody remove GLS_SSU from the administrators, now that he is doing his own fork?

I removed myself earlier today.

Maybe give him the lowest project member level, but don't remove him from the project. After all, he was a major contributor to SSU and I sure would have no problems seeing him back again one day.

Never say never, but things would have to be different in the graphics side of the house.

---------- Post added at 12:35 PM ---------- Previous post was at 12:35 PM ----------

BTW: I should also remove myself from moderator of this sub-forum.

---------- Post added at 12:40 PM ---------- Previous post was at 12:35 PM ----------

BTW: I should also remove myself from moderator of this sub-forum.

Can't seem to do that on my own... I'll PM a boss for it.
/offtopic

 

[Urwumpe]

Never say never, but things would have to be different in the graphics side of the house.

I know.



We'll have to handle this procedural problem anyway.

---------- Post added at 14:43 ---------- Previous post was at 13:43 ----------

Any good ideas how to do the accounting for the consumable masses?

I don't want to have over 30 propellant resources for SSU to track every smaller tank. Since those are mostly smaller masses and not always ejected outside while consumed, would it make sense to define a "misc. Liquids" mass?

In that case, we could focus the propellant mass line in the scenario file for the ~8 big resources and theoretically even omit this resource, if we set its current and maximum mass after loading the scenario from the individual tank contents.


The suggestioned logical propellant resource structure would then look like this:

const unsigned short PROPID_OMS_L = 0;
const unsigned short PROPID_OMS_R = 1;
const unsigned short PROPID_ARCS_L = 2;
const unsigned short PROPID_ARCS_R = 3;
const unsigned short PROPID_FRCS = 4;
//APU fuel
const unsigned short PROPID_HTP = 5;
//Contents of the ET plus residuals in the orbiter aft
const unsigned short PROPID_MPS = 6;
const unsigned short PROPID_SRB_L = 7;
const unsigned short PROPID_SRB_R = 8;
const unsigned short PROPID_SRB_HTP_L = 9;
const unsigned short PROPID_SRB_HTP_R = 10;
//Mass consumed by crew members and dumped overboard
const unsigned short PROPID_MISC = 11;

I included a second pair of propellant resources for the propellants consumed by the SRB APUs while the SRBs are part of the stack. Theoretically, we could even merge those into one resource, but the SRBs likely still need two resources.

 

[DaveS]

@DaveS : Can you research for the EDO pallet dry mass, as requested in the ticket #199? We can then derive a new ticket for fixing the values in our implementation.

Done. I posted a reply to the ticket.

 

[Urwumpe]

Got the suggested model for the propellant resources down to 8 - any criticism there?

const unsigned short PROPID_AFTPOD = 0;
const unsigned short PROPID_FRCS = 1;
//APU fuel
const unsigned short PROPID_HYDRAZINE = 2;
const unsigned short PROPID_WSB = 3;
//Contents of the ET plus residuals in the orbiter aft
const unsigned short PROPID_MPS = 4;
const unsigned short PROPID_SRB_L = 5;
const unsigned short PROPID_SRB_R = 6;
const unsigned short PROPID_SRB_HYRAZINE = 7;
//misc. liquid and gases that might be dumped overboard
const unsigned short PROPID_MISC = 8;

I now merged the two OMS pods into one logical propellant resource, the individual tank masses for the MMH and N2O4 tanks will then be tracked by the individual tanks and valves. The idea: Both masses must be tanked symmetrically anyway during launch and can only vary during the mission. OMS propellant can feed into ARCS manifolds, so it is simpler if both use the same propellant resource anyway.

I still kept hydrazine and water spray boiler water separated - not sure if this could also be merged into one resource. But its not possible to use hydrazine for cooling the hydraulics...

 

[Donamy]

Well, I only know the concept of Product Owner theoretically, but as I (talking in the name of my simgroup) am a power user of SSU, and we do full missions that require to test everything on SSU, and report to you issues or suggest improvements, I think that I am a good candidate to take the role of PO.


Do we have a product backlock already? If we do, I understand that it is the current roadmap.

Is the problem with the RMS fixed for you ?

 

[Urwumpe]

DaveS: If I provide a means to define the animation parameters of Panel O8 in a JSON file, could you fill out the needed animation data for the switches in it?

The VC elements are pretty easy to delegate into a JSON file, since they have only few animation parameters.

 

[DaveS]

DaveS: If I provide a means to define the animation parameters of Panel O8 in a JSON file, could you fill out the needed animation data for the switches in it?

The VC elements are pretty easy to delegate into a JSON file, since they have only few animation parameters.

That shouldn't be a problem assuming things are better defined than with the ODS! That thing's a mess. Could we use the aft FD panels first so that they can move farther back to their proper positions relative to the Xo576 bulkhead?