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

[GLS]

Yes. I suspect this illegal entry comes straight from FCOS and not a single piece of application code has a chance to react. The table of the item entries is loaded from magnetic tape AFAIR.

I just finished a list of SPECs and a list of DISPs (we had something like 1.5 lists before), and separated the displays by OPS/MM, MF for PASS and BFS, with the intent of getting a head start for when the new hardware become available.
I'll have to test before I commit, but before that I have to catch some ZZZZZs...

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

Committed the fix for the ITEM issue (it had to go in the IDP because that's where the display ID is currently saved...), and also the new lists of SPECs and DISPs. Nothing should have changed, but because of our current "PASS/BFS/GNC/SM hybrid" GPC, some displays will still show blank when they shouldn't be showing at all (PASS GNC SYS SUMM 2 in OPS 1 for example). Anyway, if anything changed for worst let me know.

On a more general subject: one thing I'm "concerned" about is the number of conflicts that will show up when cleaning up, both the 2 RCS systems, and the 1.5 GPCs we have in the trunk (I assume both the RCS(/OMS) and the new DPS will have their own branches because the trunk doesn't look good in those areas).
When those branches are created, should we clean up the new stuff from the trunk and just have the old stuff in there, and maybe clean the old stuff from the branches leaving just the new in-development stuff? Or will it be easier to clean up off stuff when we merge those branches back to the trunk? Or should a cleanup be done in the trunk before the branch?

Also, IMO we should take the opportunity to make the new RCS have the real thrusters (and do away with our simplified system and over-complicated implementation), using the new GPC capabilities to have the advanced control needed. We should also work the OMS ("chemistry" and "control" parts) at the same time, allowing the interconnects to be implemented.
This brings us an opportunity to "fix" another issue which is propellant vessel order. Currently we have the ET/MPS manifold and SRBs resources being the first created on the pad and not created while the vehicle is in orbit (duh!), which makes the order of the remaining propellant resources change from the launch config to the orbit config.
IMO, first the ET/MPS and SRBs should be the last to be created to solve the order issue (and eventually the SRBs should move to the SRBs). Second, we should only have propellant resources for things that are connected to thrusters, so APUs and such should manage their mass using the subsystem mass logic. Third, could some sort of wrapper be created to manage a "single propellant resource meaning 2 tanks feeding a thruster"? It would be useful for the RCS, OMS and MPS, but getting it to work with OMS/RCS interconnects and MPS vents might not be easy...

(yes, that's probably too much text... :uhh

 

[Wolf]

So "Illegal Entry", triggered from the GPCs, it is (even though we currently have the SPEC and DISP numbers defined in the IDP...)

Are we supposed to get the illegal entry message also when the SYS SUMMARY (1 or 2) displays are showing?

 

[Urwumpe]

First of all: Generally yes, sounds good.

Second: I think its good having a "chemistry" kind of package, handling constants and functions for the propellants, like density by temperature.

Third: Everything that is vented to the outside should be implemented as propellant resource for simplicity and for not confusing other add-ons about constant weight changes. We should only change dry mass, when this changes. So, APU fuel and APU/FE boiler water is of course a propellant for us. Same for helium for the pneumatics. Or Ammonia for the Boilers.

But the waste water opens another interesting question:

I am not sure how to define "Urine" as resource. THIS is really a point where we create propellant from dry mass (astronauts). One way would be defining everything an astronaut consumes as propellant mass. This way, we could for example also handle atmosphere leaking into space by correct operation or malfunction. But I suspect it would make SSU a mess to maintain. Some compromise between performance, least surprise and less bugs has to be found.

 

[GLS]

Are we supposed to get the illegal entry message also when the SYS SUMMARY (1 or 2) displays are showing?

All 4 SYS SUMMs are DISPs, so yes, if you try to input an ITEM you will get the "Illegal Entry" message.

---------- Post added at 04:57 PM ---------- Previous post was at 04:33 PM ----------

First of all: Generally yes, sounds good.

Second: I think its good having a "chemistry" kind of package, handling constants and functions for the propellants, like density by temperature.

Third: Everything that is vented to the outside should be implemented as propellant resource for simplicity and for not confusing other add-ons about constant weight changes. We should only change dry mass, when this changes. So, APU fuel and APU/FE boiler water is of course a propellant for us. Same for helium for the pneumatics. Or Ammonia for the Boilers.

But the waste water opens another interesting question:

I am not sure how to define "Urine" as resource. THIS is really a point where we create propellant from dry mass (astronauts). One way would be defining everything an astronaut consumes as propellant mass. This way, we could for example also handle atmosphere leaking into space by correct operation or malfunction. But I suspect it would make SSU a mess to maintain. Some compromise between performance, least surprise and less bugs has to be found.

Having it all be propellant resources does make us only have to handle one case when playing with c.g. positions in the future, but that would mean we would have a truck load of propellant resources...

On the RCS and DPS branch front: anything I can do?

 

[Wolf]

All 4 SYS SUMMs are DISPs, so yes, if you try to input an ITEM you will get the "Illegal Entry" message.

Since this doesn't happen on my end I am afraid I did something wrong with SVN update.
Can you confirm the pic below shows rev 2758 (and previous ones) have been updated correctly?

Maybe checkmarks should be green instead?

Thanks

 

[GLS]

Quick list:
L OMS (Fu/Ox)
L OMS He2
L OMS N2
R OMS (Fu/Ox)
R OMS He2
R OMS N2
K OMS (Fu/Ox)
K OMS He2
F RCS (Fu/Ox)
F RCS He2 Fu
F RCS He2 Ox
L RCS (Fu/Ox)
L RCS He2 Fu
L RCS He2 Ox
R RCS (Fu/Ox)
R RCS He2 Fu
R RCS He2 Ox
APU-1 Fu
APU-2 Fu
APU-3 Fu
APU H2O
WSB-1 H2O
WSB-2 H2O
WSB-3 H2O
MPS (LO2/LH2)
MPS-1 He2
MPS-2 He2
MPS-3 He2
MPS-P He2
ECLSS-1 N2
ECLSS-2 N2
ECLSS H2O 1
ECLSS H2O 2
ECLSS H2O 3
ECLSS H2O 4
Waste H2O
PRSD-1 O2
PRSD-1 H2
PRSD-2 O2
PRSD-2 H2
PRSD-3 O2
PRSD-3 H2
PRSD-4 O2
PRSD-4 H2
PRSD-5 O2
PRSD-5 H2
PRSD-6 O2
PRSD-6 H2
PRSD-7 O2
PRSD-7 H2
PRSD-8 O2
PRSD-8 H2
PRSD-9 O2
PRSD-9 H2
PRSD-10 O2
PRSD-10 H2
PRSD-11 O2
PRSD-11 H2
PRSD-12 O2
PRSD-12 H2
PRSD-13 O2
PRSD-13 H2

The entries with parenthesis could actually be 2, depending on how we handle them.
On the urine issue, we could say that it is actually water from the potable tank that "magically" appears in the waste tank. Solid waste mass probably needs no handling as we can assume the hydration level of the food to be the same pre and post digestion. Also, Shuttle flights are short enough for us to not worry about astronaut weight loss. (I just realized SSU is so advanced that we are actually discussing these subjects :lol

Still to include (if they should) are the cooling loop fluids and the hydraulic fluid. Also, I'm not sure if the OMS kit would have 2 or 4 prop tanks.

---------- Post added at 05:31 PM ---------- Previous post was at 05:27 PM ----------

Since this doesn't happen on my end I am afraid I did something wrong with SVN update.
Can you confirm the pic below shows rev 2758 (and previous ones) have been updated correctly?
View attachment 15547
Maybe checkmarks should be green instead?

Thanks

If you didn't edit the files yourself, updating should not cause any issues.
What are you inputting that should cause the error?
And a potentially stupid question: did you compile after updating?

 

[Wolf]

If you didn't edit the files yourself, updating should not cause any issues.
What are you inputting that should cause the error?
And a potentially stupid question: did you compile after updating?

Stupid answer: NO, didn't compile :blush:
so I guess I need to do that with VS everytime I do an SVN update?... problem is when I launch VS it says the 30 days free trial period is expired. I thought VS Community 2017 was free..

 

[GLS]

Stupid answer: NO, didn't compile :blush:
so I guess I need to do that with VS everytime I do an SVN update?... problem is when I launch VS it says the 30 days free trial period is expired. I thought VS Community 2017 was free..

You only need to compile if the code was changed. You can check the log and see if the update changed files in the "Orbitersdk/Space Shuttle Ultra" folder. If only meshes or textures were changed, then you don't need to compile.

On VS2017, you need to register it... M$ :facepalm: It asks for an e-mail (not sure if it has to be a micro$oft account) and maybe a password, but it looks to be a one time thing and then it doesn't bother you again.

 

[DaveS]

On VS registration: This dates back at least to VC++ 2010 and I have never had any issues despite having it installed on multiple PCs throughout the years.

 

[Urwumpe]

What about registering a single resource for every class of resource, instead of having a logical propellant resource for every tank and system? Generally, I think its easier to let Orbiter keep track of the masses than if we need to do it. But I see the limits of the scenario file syntax coming if we have too many propellant resources.

For example, we could define Helium as one propellant resource, keep track of the individual tanks internally and just treat it like we have a large ball of Helium inside the spacecraft, that is ejected by multiple thrusters.

---------- Post added at 23:36 ---------- Previous post was at 23:33 ----------

And well, we have no ECLSS yet, but thinking about it: Water is not just potable water getting turned dirty, but also food and oxygen getting digested. A substancial amount of water should be released by the crew as sweat. Its a pretty complex topic. But yes, its time to think about at least the coarse design decisions now. How do we want our ECLSS in the future?

 

[GLS]

What about registering a single resource for every class of resource, instead of having a logical propellant resource for every tank and system? Generally, I think its easier to let Orbiter keep track of the masses than if we need to do it. But I see the limits of the scenario file syntax coming if we have too many propellant resources.

For example, we could define Helium as one propellant resource, keep track of the individual tanks internally and just treat it like we have a large ball of Helium inside the spacecraft, that is ejected by multiple thrusters.

A problem with "one large ball of something" is that on top of the propellant resource ratio being saved, we'll need to save the mass that each system uses. Topping an APU fuel tank would need 2 parameters changed. Keeping things separate is probably better.
About a potential limit for the number of propellant resources in a scenario, let me run a few tests.

And well, we have no ECLSS yet, but thinking about it: Water is not just potable water getting turned dirty, but also food and oxygen getting digested. A substancial amount of water should be released by the crew as sweat. Its a pretty complex topic. But yes, its time to think about at least the coarse design decisions now. How do we want our ECLSS in the future?

It's the egg and the chicken story: we want an ECLSS that can keep people alive, but we need people to make it. :lol:

---------- Post added 12-29-17 at 12:09 AM ---------- Previous post was 12-28-17 at 11:19 PM ----------

100 propellant resources, creating a scenario line over 1000 chars long: no issues. We only need to get the SSU Workbench to handle it. :shrug:

 

[Urwumpe]

100 propellant resources, creating a scenario line over 1000 chars long: no issues. We only need to get the SSU Workbench to handle it. :shrug:

OK, then my fear of exceeding the size of the Orbiter line buffer was not justified. Yet. :lol:

But we should get a table in some document then, which propellant resource index relates to which tank, so Workbench and SSU operate on the same knowledge.

 

[GLS]

OK, then my fear of exceeding the size of the Orbiter line buffer was not justified. Yet. :lol:

I could try a "test-to-failure" to see how what is the limit, but I don't think we'll even get to 100.

But we should get a table in some document then, which propellant resource index relates to which tank, so Workbench and SSU operate on the same knowledge.

I could create an spredsheet with the list above, which would be easy to edit. A ticket to keep this "visible" would probably be a good idea, as we still need to figure out if we have 1 or 2 propellant resources for the thrusters, and then we still need to update (at least) the RCS so we can separate the aft RCS tank(s) from the OMS tanks.

 

[Urwumpe]

I could create an spredsheet with the list above, which would be easy to edit. A ticket to keep this "visible" would probably be a good idea, as we still need to figure out if we have 1 or 2 propellant resources for the thrusters, and then we still need to update (at least) the RCS so we can separate the aft RCS tank(s) from the OMS tanks.

I would say two for the aft RCS and two for the OMS would be accurate enough, they should be separated if possible.

 

[GLS]

I would say two for the aft RCS and two for the OMS would be accurate enough, they should be separated if possible.

Separating those is very possible (and needed), my question is should the fuel and the oxidizer be separated, and if so how/where do we connect the thruster. Having one propellant resource should work, we just need to keep track of 2 masses. If we really want to cut down on parameters, keeping a ratio instead won't work, but a difference might: we would allow firings as long as (fabs( dif ) != totmass), and we would subtract the fuel usage from dif and add the oxidizer usage to dif. But keeping 2 masses is probably easier.
Another check needed is enough pressure in the tanks, but that's why we have subsystem classes.

 

[Urwumpe]

I don't think it makes sense in an Orbiter API sense - a thruster needs both chemical components to work, they are one resource. And we need pressure, temperature and mass anyway in each tank to define the behavior downstream - for example what happens during an interconnect.

 

[GLS]

Committed propellant resource list and created ticket.

 

[GLS]

In relation to ticket 147, is this good enough for me to continue and make the rest?

Beware: making this will not be as cheap in FPS as a regular animation, but it shouldn't prohibitively expensive... it runs on my +/- low-end laptop, and in the end it will only cost when the tilt table is in motion, so... :shrug:

 

[DaveS]

Looks OK to me based on that screenshot. What is the FPS loss on your machine when the animation is in progress?

 

[GLS]

Looks OK to me based on that screenshot. What is the FPS loss on your machine when the animation is in progress?

I have not clue... maybe 10%?
Anyway, there's also this bug that causes the bellows to vanish if their original location isn't in view.