SSU Development Thread (2.0 to 3.0)

[SiameseCat]

In reality the current display "key" in the menu is highlighted white. In our setup the menu is being written in the MDU and the CRTMFD is the one that decides which display is up. So we would need to have the CRTMFD communicate to the MDU which display is up, so it could do the highlighting. I tried but didn't succeed... feel free to give it a go.

Is there a reason why we're doing it this way? Now that all the displays have been moved to the MDU, it seems like it would make more sense for the MDU to do everything, and just use CRTMFD to indicate when a button is pushed.

Does anyone know what the mass of the ODS and airlock is? I'm working on defining subsystem masses, but I haven't been able to find mass values for these components.

 

[DaveS]

Does anyone know what the mass of the ODS and airlock is? I'm working on defining subsystem masses, but I haven't been able to find mass values for these components.

That is the one thing I haven't managed track down. However, according to EVA tools and equipment reference book, the mass of the internal airlock is 825 lbs (373.725 kg). According to the STS-71 press kit, the "Orbiter Docking System" which is more described as the Ext A/L+ODS "weighs more than 3,500 lbs" (1585.5 kg). How that breaks down between the actual Ext A/L and the ODS I don't know.

 

[GLS]

Added a new ticket (#80) regarding old meshes that we might have. If some of those meshes are for future work, they probably should be in a branch or something, otherwise we're probably putting them in the release.
Once this cleanup is done we should also do the same for the textures.

 

[Urwumpe]

Anybody interested in making a shell script for automatically creating a zip archive of all SSU release files from the checked out installation? It is the next thing on my TODO list here, but I won't get to SSU for the next 14 days.

 

[GLS]

Anybody interested in making a shell script for automatically creating a zip archive of all SSU release files from the checked out installation? It is the next thing on my TODO list here, but I won't get to SSU for the next 14 days.

I'll also in the "no SSU" mode for the next 9 days or so... :thumbsdown:

 

[Urwumpe]

I'll also in the "no SSU" mode for the next 9 days or so... :thumbsdown:

I don't know who invented exam seasons, but when I meet this guy... :lol:

 

[kuddel]

Anybody interested in making a shell script for automatically creating a zip archive of all SSU release files from the checked out installation? It is the next thing on my TODO list here, but I won't get to SSU for the next 14 days.

You might take this (which I've done for D3D9Client) as a starting point...

/Kuddel

 

[DaveS]

While troubleshooting the reason why I have so much problems getting the LH2/LOX dump ducts on the CISS to fit the payload bay properly, I discovered that the PLB is too deep. However, there's a quick fix procedure for this.

1. Select all the PLB items (vent filters, PLB itself, lights, sills and ring frames
2. Scale the items from the bottom up until the dimensions read W 5.33 H 2.67 H 18.48

The key is H 2.67 as that's the real depth of the PLB as measured from the sills longerons. The bottom of the aft wing box (which has Bays 12 and 13) is 105" (2.667 m) from the sill longerons. For the facts: The Z-axis coordinate of the bottom of the wing box is Zo305. Currently the bottom sits at Zo315.748.

 

[DaveS]

I think I have stumbled onto a bug that makes my life as the project's pad rat a bit harder. The possible bug is that whatever you do, the GOX venting from the SSMEs just won't stop and stay that way when you exist and reload the scenario.

It seems like there's something that keeps refilling whatever propellant tanks that those "thrusters" use when ever the scenario is reloaded and the vehicle is in launch config (Orbiter, ET and SRBs).

 

[GLS]

I think I have stumbled onto a bug that makes my life as the project's pad rat a bit harder. The possible bug is that whatever you do, the GOX venting from the SSMEs just won't stop and stay that way when you exist and reload the scenario.

It seems like there's something that keeps refilling whatever propellant tanks that those "thrusters" use when ever the scenario is reloaded and the vehicle is in launch config (Orbiter, ET and SRBs).

In a perfect world those vents would be controlled by the SSME model, based on whether there's LOX at the inlet and the position of the IMSL PAV (that depends on the IMSL solenoid or the GSE N2 PAV if I remember well...). IMO, as currently we don't really have a LPS to do tanking, there's little point in having a launch scenario in which the ET isn't full (although I want that someday). I think there needs to be some more work in the DPS and GPC side of things, before we create the LPS. That will open the door to countdowns and all of that.
In the meantime we could probably cheat the system and temporarily have a key to turn the vents on, and a line in the scenario file that turns the vents off at the start. That way one could start a scenario with the vents off, and when time comes just hit the key and turn it back on (don't see the point of the key being able to turn it off).
Please create a ticket so this doesn't "fall thru the cracks", and I'll look at it next week or so.

 

[DaveS]

IMO, as currently we don't really have a LPS to do tanking, there's little point in having a launch scenario in which the ET isn't full (although I want that someday).

Well, I need it for future pad work. In order to test everything, I sometimes need to engage time acceleration and this wrecks havoc with the frame due to the MPS/GVA venting.

 

[GLS]

Fortunately Martin thought of that . Just go to the "Visual effects" tab and uncheck the Particle streams checkbox, and those pesky particle streams won't do any more harm.:lol:

 

[GLS]

So, I finally got the time to look at something that was "bothering" me for some time now: this code structure

if (!bFoundData || !_strnicmp( pszBuffer, "GPrime", 6 ))
	{
		// default
		// set GPrime
	}
	else if (!_strnicmp( pszBuffer, "G", 1 ))
	{
		// set G
	}

This is from the Centaur and I copied the "structure" from the ET type selection in Atlantis_Tank.cpp. This works very well for the cases where the config file has one of the strings we're searching, and also for when it doesn't have a string at all. But in the cases when it does not have any of the strings we're looking for (because the user might have edited the config file for whatever reason), it does not run any of the code inside those ifs (not good).

Came up with this "structure" for the Centaur:

if ((bFoundData == true) && (_strnicmp( pszBuffer, "G", 2 ) == 0))
	{
		// set G
	}
	else
	{
		// default
		// set GPrime
	}

Notice the 2 in the _strnicmp argument, so it also checks the NULL at the end, otherwise the function would find it even when pszBuffer was "GPrime" (or "G-something-else").

Just posting this here so everyone can check it before put it in the repository. If it's OK then I'll change the ET code as well.

 

[Urwumpe]

Why "bFoundData == true" ? That's redundant code.

 

[GLS]

Why "bFoundData == true" ? That's redundant code.

Just checked it and you're +/- right... without it we're testing an uninitialized string... that might be anything, including "G" or "GPrime", right?
Because of that, admittedly 1-in-1000000000000 change, and also because this only runs once during loading and it's probably not more than a dozen cycles for the CPU, I'd keep this check as I think it does more good than harm.

 

[Urwumpe]

Just checked it and you're +/- right... without it we're testing an uninitialized string... that might be anything, including "G" or "GPrime", right?
Because of that, admittedly 1-in-1000000000000 change, and also because this only runs once during loading and it's probably not more than a dozen cycles for the CPU, I'd keep this check as I think it does more good than harm.

Actually "bFoundData" alone already evaluates as true or false, "the == true" is not necessary.

Not sure about the semantics of bFoundData... would Need to check this after the exams.

 

[GLS]

Actually "bFoundData" alone already evaluates as true or false, "the == true" is not necessary.

Oh, that! That's just an habit of mine to write the whole expression :lol:

 

[GLS]

I have some free time now, so I'm back to the list of the tickets I find critical to fix before the release:
49 (Orbiter dry mass) (SiameseCat is working this one)
62 (Reentry plasma mesh/texture in wrong position)
63 (Switch covers (and their appearance in D3D9))
67 (Aft MDU is distorted)
77 (All MPS vents/dumps are in wrong position)

The one I could do something about is 77, but I need the coordinates for the vents.
Other than that, and if there isn't anything I can do for anyone, I'll be trying to draw the "8-ball" (very little chance it will be ready for this release).

 

[kocmolyf]

...I'll be trying to draw the "8-ball" (very little chance it will be ready for this release).

I finally figured out all the math for this tonight (for the LR1). If you haven't already tried it (and you're using 2D drawing tools), let me warn you that it is maddening. Send me a message if you get stuck.

 

[GLS]

I finally figured out all the math for this tonight (for the LR1). If you haven't already tried it (and you're using 2D drawing tools), let me warn you that it is maddening. Send me a message if you get stuck.

The math isn't concerning me (at least for now). My main concern is: "is it possible to do an ADI that looks like the one in the shuttle, using GDI?" Looks like it's possible, but there's still much work to do before that question gets a definitive answer.