SSU Development Thread (2.0 to 3.0)

[Urwumpe]

Yes, there are some changes. I have the "SSU" scenarios updated (in the mps branch for now) and I'll provide "canned" versions of the scenario blocks in question, so anyone can go there and copy what they need.

Are these scenario changes incompatible to older ones or can we already include them in scenarios, should the MPS functions need more work?

 

[DaveS]

It looks like it uses the same fabric covering.

Yes, but the SpaceHAB textures are specifically tailored fit only the SpaceHAB module. I need one that fits the EDO pallet.

 

[GLS]

Are these scenario changes incompatible to older ones or can we already include them in scenarios, should the MPS functions need more work?

In terms of MPS, the scenarios currently in the trunk are old and (probably) won't work, and the ones in the mps branch are the standard (minus the ET update I'm finishing). I also did change the OMS assist mission file configuration to have the correct ON/OFF and duration values.

 

[Urwumpe]

In terms of MPS, the scenarios currently in the trunk are old and (probably) won't work, and the ones in the mps branch are the standard (minus the ET update I'm finishing). I also did change the OMS assist mission file configuration to have the correct ON/OFF and duration values.

Thats not so much a problem, the question rather is: Does not make sense to already take the scenario blocks for the new MPS into the release, even if you might not be ready in time. We could then simply do the release process as planned, and later start a new release branch with your MPS. This is especially important should we do scenario creation tools along the way - we don't need to wait for the MPS to already include what is final.

 

[GLS]

Thats not so much a problem, the question rather is: Does not make sense to already take the scenario blocks for the new MPS into the release, even if you might not be ready in time. We could then simply do the release process as planned, and later start a new release branch with your MPS. This is especially important should we do scenario creation tools along the way - we don't need to wait for the MPS to already include what is final.

Not sure I'm following you... you want to release what's on the trunk now and in a later release have the mps branch stuff? If that's the case I've no problem with that. At best I'll need 2-3 days to "finish" this... but there's always something to do. :lol:

 

[SiameseCat]

Not sure I'm following you... you want to release what's on the trunk now and in a later release have the mps branch stuff? If that's the case I've no problem with that. At best I'll need 2-3 days to "finish" this... but there's always something to do. :lol:

What Urwumpe's suggesting (I think) is to update the scenarios in the trunk to handle the changes in the mps branch, but do the release without including the mps branch. Then, once the mps branch code is added to the trunk, the existing scenarios can be used without further changes.

 

[Urwumpe]

What Urwumpe's suggesting (I think) is to update the scenarios in the trunk to handle the changes in the mps branch, but do the release without including the mps branch. Then, once the mps branch code is added to the trunk, the existing scenarios can be used without further changes.

If it makes sense. But if we are speaking of just 2-3 days, we can simply perform a longer code review and start the release work later.

 

[GLS]

OK, just uploaded the new stuff! Please play with it, especially everything that isn't launch, because I want to be sure I didn't break anything. Also, could someone check if I added libUltra correctly to the Atlantis_Tank project? It works but I'm not 100% sure it's done the right way.
Now I will put "outside" documentation together and hopefully upload it later today.

A (quick) request: could anyone at our "graphics department" do a little edge smoothing in the SSMEstream.dds texture? I think it should be somewhat ragged, but currently we can notice the edges of the texture and it doesn't look super.

---------- Post added at 01:22 PM ---------- Previous post was at 12:31 PM ----------

I'm looking at the "Doc/Space Shuttle Ultra" folder and wondering if we shouldn't differentiate between "public documentation" and "developer documentation". The public docs would consist of help files and whatever is need to the user, and that is what goes in the releases. The dev docs would have more "technical" stuff and the doxygen output and would stay somewhere in the svn.
Good or bad this idea?

 

[Donamy]

I'd like to see a decent orbiter released ASAP.

 

[DaveS]

I'd like to see a decent orbiter released ASAP.

As an SSU mesh developer, I think you might be interested in this: https://dl.dropboxusercontent.com/u/24122088/Orbiter payload bay.zip

With this you can ensure proper fitting of your payloads in AC3D. AC3D file and texture in dds included.

 

[Donamy]

I do have one that I've been using, but a full orbiter mesh is needed for the release version. The one available now is distorted (see above post for pic). Also, the one available won't import to AC3D, so I couldn't fix it.

 

[DaveS]

I do have one that I've been using, but a full orbiter mesh is needed for the release version. The one available now is distorted (see above post for pic). Also, the one available won't import to AC3D, so I couldn't fix it.

The PLB should be enough to size the payloads correctly. That PLB model is directly from the new orbiter so there's no difference between the AC3D version and the Orbiter version.

 

[Donamy]

You are not understanding what I'm saying. I would like to have,( as I'm sure many others would also) an Orbiter mesh that actually looks good when I'm using orbiter.

 

[DaveS]

You are not understanding what I'm saying. I would like to have,( as I'm sure many others would also) an Orbiter mesh that actually looks good when I'm using orbiter.

Got it. That will be part of the next release. The code first needs to be properly reviewed for any discrepancies and significant faults. Once that is done, everything will be packed up and released.

 

[GLS]

Just found there's another doc folder in the "middle" of the code, so disregard my previous documentation related post. :facepalm:

 

[GLS]

Just commited a little "annex" to AscentGuidance in the form of the PASS "ASCENT TRAJ". :yes:
It's pretty much just a new function, so no modifications were made, keeping in line with the current "freeze".

---------- Post added 09-02-14 at 12:19 AM ---------- Previous post was 09-01-14 at 11:42 PM ----------

2 quick questions:
1) while we don't have the BFS, could we differentiate the PASS/BFS displays using the BFS CRT switches in panel C3?
2) should I have a go at the ENTRY TRAJ (and BFS ASCENT TRAJ, if the stuff above works), or it's better to wait?

 

[Donamy]

When can we expect, the next release that would fix the mesh problems ? I will hold off on making payloads until then, just incase the next release breaks them.

 

[GLS]

New question (in addition to the ones above): any ETA on merging the mps branch?

 

[GLS]

In case anybody cares I've compilled a list of (most substantial) changes done in the mps branch:

#added PASS "ASCENT TRAJ" to AscentGuidance, with some code from CRTMFD and some new stuff (EO VIs, SERC status, SEP INHs) but still incomplete
#uploading some "technical" documentation about MPS/SSME, and a discrete bundle listing (also in pdf to be easier to browse)
#added 2 new scenarios about the "Death Star" flights (and mission files)
#moved ET propellant instance to Atlantis_Tank class and replaced it by and mps manifold propellant instance, which feeds the SSMEs and is constantly "replenished" by the ET instance
#updated launch scenarios to have the ET propellant level value in the ET vessel block (using 99.6% on all as that is the average load)
#added level and ullage pressure sensors to the ET and MPS manifold
#added low level sensor arm command to ascent guidance
#changed low level logic in SSME_Operations to have correct implementation
#ET ullage mass now simulated
#added Flow Control Valves and control logic (HACK instead of using a DSC, control logic is for now in SSME_Operations class)
#connected LH2 Ullage Press switch in panel R2 to control GH2 FCVs
#in Sensor class, added capability to add an error in the sensor reading, expressed as percentage of full scale input
#changed the names of source and header files "BLOCK_II" to "SSME_BLOCK_II"
#changed the velocity added to the ET at separation from -1 m/s to 0 m/s, because there are no springs pushing just aerodynamics and thrusters
#added logic in SSME SOP to detect command path and channel fail
#added SSME channel fail check in RSLS
#reworked unused ATVC class (running just 1 instance instead of 4 for now)
#added ATVC_SOP class that receives gimbal commands (just SSME for now)
#LCC, RSLS and MPS Dump now gimbal the SSMEs and ATVC SOP gimbal them for drag chute deploy
#added SERC
#fixed little logic bug in OMS dump/assist, so the dump now stops when "MECO Confirmed" flag is set
#changed the position of the SSME light to be a little behind the nozzles instead of between them
#corrected pre-launch position of flight controller power switches
#created ETSepSequence and TransitionDAP (still bare bones) classes, and moved some code from AscentGuidance to there, and also copied some code from OrbitDAP, and improved ET sep
#created SRBSepSequence and SRB sep is now triggered in the correct way
#in GetSRBChamberPressure, changed the 1000 factor to 530, so it outputs values close to SRB pressure (in psia) at around MET+120sec, in order for SRB SEP to occur +/- at the normal time
#corrected wrong lights turning on at MECO Confirmed in Orbital DAP
#body flap lights in panels F2 and F4 now turn off at mps dump end (had to add an OPS 2 check to PCT in OrbitalDAP)
#added MPS LH2 and LO2 feedline relief vents, valves, command and logic
#changed OMS assist implementation in mission files, Mission and AscentGuidance classes to use the real implementation: "on/off" and "duration" I-load values (start is always MM103 + 10sec)
#changed the minimum GetSSMEThrustLevel output required to have the SSMELight on, so at MECO it doesn't turn off "harshly", but instead fades more consistently with the thrust
#changed SRB light from 1 to 2 sources, and also added them to Atlantis_SRB class so they still show post sep (not sure if pre/post sep positions match)
#small change in SSME_SOP, so that on a data path failure PC goes to 0
#updated launch scenarios to show MFDs in a more "standard configuration"
#changed order of SRB plume creation (srb_contrail is now the first added instead of the last). looks much better specially from head on. (the position of srb_contrail probably needs a little tweaking)
#corrected event timer not counting up after counting down to 0
#added functionality to SRB SEP and ET SEP switches and push buttons in panel C3
#added fine count throttle down
#added EO recognition and correspondent update to 1º stage throttle table and fine count throttle value
#corrected slow OAA retract and extend movements and added emergency extend
#improved visuals for SSME ignition and shutdown
#reworked RSLS_old::Abort() to include more safing operations
#added RSLS abort check to SSULCC, so it extends the OAA in case of abort
#corrected the "FUEL P" value on the APU/HYD display of the CRTMFD by changing the value returned from APU.cpp
#added atmospheric pressure to OMS PC display in CRTMFD
#updated/corrected the launch scenarios so that panels F2 and F4 have the correct lights on
#added LOX F/D vent for vacuum inerting
#redid most of the code in MPSDump.cpp so the proper commands are issued, dump is started when needed and manual control exists
#added logging to MPS Dump events
#in SSULCC.cpp and RSLS_old.cpp fixed a tiny bug in the "event" logic, that caused the event to occur twice in the unlikely event the step time was equal to the event time
#changed Atlantis::GetSRBChamberPressure to return 0 instead of -1 after SRB SEP
#improving "power distribution" in the EIUs (still not enough info)
#adding "throttle to 100" cmd to RSLS (again little info)
#tweaked the ET GOX vents (looked too long)
#changed the pre-launch "T-HH:MM:SS" output to oapiDebugString() to also display tenths of seconds
#modified the SSME throttle commands in AscentGuidance, and added AGT (Adaptive Guidance Throttling) (not perfect due to lack of info)
#added the post-MECO LH2 dump
#added the SSME S/D PBs functionality
#added the SSME S/D limit switch functionality
#added a bunch of valves to the MPS
#improved the functionality of SSME controller and its software
#added SSME_Operations class to contain GPC control logic of the SSMEs
#added IO_control class to interface panel switches and GPC commands to valves
#added the MPS/SSME Helium System, and made the associated switches on panel R2 functional
#added various MPS/SSME HeSys and MPS manifold parameters to the OMS/MPS display on CRTMFD
#added code to SSULCC to "fill" the Helium system
#removed some unused MPS variables from the Atlantis class
#added a bunch of asserts
#documented several files with doxygen stuff

---------- Post added at 05:51 PM ---------- Previous post was at 01:13 PM ----------

As I'm sitting here doing nothing, I switched back to the trunk to see how things are there, and noticed that the star trackers have that effect Donamy mentioned a few days ago, and in the TAEM EDW landing scenario I notice a "shadow"/dark area on top of the wing (where the delta and the chine meet). And finally the EDO pallet is sticking out of the PLB in the STS 107 launch scenario. Problem at my end?

Also noticed the ET is white (looks like no texture) in some launches, and only at SRB sep does it get some color going (and that burned texture has the same bands of color in the LOX feedline that I get in the mps branch), and the long-throw igniters are off position. I'll try to correct both problems.

BTW orbiter textures look real nice in the trunk :thumbup:

About ticket #57 (Add SILTS pod option to mission files), what is needed exactly? Just the option in the mission file or do I have to do texture/mesh work? (no go on the graphics here )

 

[DaveS]

I notice a "shadow"/dark area on top of the wing (where the delta and the chine meet). And finally the EDO pallet is sticking out of the PLB in the STS 107 launch scenario. Problem at my end?

What dark area on the wing? Could you show a screenshot of this please?

Also noticed the ET is white (looks like no texture) in some launches, and only at SRB sep does it get some color going (and that burned texture has the same bands of color in the LOX feedline that I get in the mps branch), and the long-throw igniters are off position. I'll try to correct both problems.

Which ET are we talking about here? Or is it all of them? I get the proper textures on all of them.

About ticket #57 (Add SILTS pod option to mission files), what is needed exactly? Just the option in the mission file or do I have to do texture/mesh work? (no go on the graphics here )

Just the option. The mesh+texture already exists: SILTSpod.msh