SSU Development Thread (2.0 to 3.0)

[GLS]

Have you updated your video drivers recently? Maybe that broke a few things.

Nop. Can't tell about the F9 and O1/O2/O3 panels because I don't know if they had problems before, but the C3 covers only got like that when you did your magic to correct the D3D9 issues last week or so. But I went back and it's the same, so it looks like a coincidence.

 

[Urwumpe]

What level should they be at? This is a photo of a real orbiter PB guard cover. Notice how it is very transparent except for the metal frame.

Maybe reduce it to the metal frame and then leave this as 100% opaque. The 100% transparent parts can be ignored.

 

[DaveS]

Maybe reduce it to the metal frame and then leave this as 100% opaque. The 100% transparent parts can be ignored.

The current ones that we have now doesn't have the metal frames. It's just essentially the glass and nothing else. So that's why things are the way it is.

 

[Urwumpe]

The current ones that we have now doesn't have the metal frames. It's just essentially the glass and nothing else. So that's why things are the way it is.

Yes, and even if it looks like intended to you - to the casual player it will look like a bug.

 

[DaveS]

Yes, and even if it looks like intended to you - to the casual player it will look like a bug.

So what is your proposed course of action? The metal frames aren't just there.

 

[Urwumpe]

So what is your proposed course of action? The metal frames aren't just there.

Change mesh, use only the metal frames?

Otherwise, we will not only get into trouble with the users, but also with the rendering engines. If the transparent covers are not the last mesh groups in the rendering pipeline, they will cause rendering errors - that is why it is better to be careful with transparency.

 

[DaveS]

Change mesh, use only the metal frames?

Otherwise, we will not only get into trouble with the users, but also with the rendering engines. If the transparent covers are not the last mesh groups in the rendering pipeline, they will cause rendering errors - that is why it is better to be careful with transparency.

The big question is: Do we really want to mess with the VC now? It has more individual components than the Crawler, Pad and Space Shuttle Vehicle (Orbiter, ET and SRBs) combined.

---------- Post added at 07:13 PM ---------- Previous post was at 07:07 PM ----------

Nop. Can't tell about the F9 and O1/O2/O3 panels because I don't know if they had problems before, but the C3 covers only got like that when you did your magic to correct the D3D9 issues last week or so. But I went back and it's the same, so it looks like a coincidence.

I noticed that you have geometry instancing enabled. You might want to disable it as it is known that SSU and D3D9Client's geometry instancing aren't playing nice together. With it enabled, I was able tor reproduce your problems with panel F8. Disabling it, F8 went back to being good again.

 

[Urwumpe]

The big question is: Do we really want to mess with the VC now? It has more individual components than the Crawler, Pad and Space Shuttle Vehicle (Orbiter, ET and SRBs) combined.

If we don't now, we should do it right after release. The VC is no constant.

 

[DaveS]

If we don't now, we should do it right after release. The VC is no constant.

I just remember that we had quite the discussion a while ago about this very thing and it was decided to hold off on the VC until after the release.

 

[GLS]

I noticed that you have geometry instancing enabled. You might want to disable it as it is known that SSU and D3D9Client's geometry instancing aren't playing nice together. With it enabled, I was able tor reproduce your problems with panel F8. Disabling it, F8 went back to being good again.

Holy cow that worked! It's all good now, the overhead panels, the C3 covers and the rotary switches in panel F9! Thanks!!!:thumbup:
We should probably mention this in the manual right? Speaking of which, any news about the "editable version" of the outdated pdf manual? My schedule is getting tighter each week, but I think I can write some stuff for the manual.

---------- Post added 03-15-15 at 07:01 PM ---------- Previous post was 03-14-15 at 07:47 PM ----------

DaveS, could you check the position of the SILTS pod? It is too forward at the moment.

 

[DaveS]

Holy cow that worked! It's all good now, the overhead panels, the C3 covers and the rotary switches in panel F9! Thanks!!!:thumbup:
We should probably mention this in the manual right? Speaking of which, any news about the "editable version" of the outdated pdf manual? My schedule is getting tighter each week, but I think I can write some stuff for the manual.

---------- Post added 03-15-15 at 07:01 PM ---------- Previous post was 03-14-15 at 07:47 PM ----------

DaveS, could you check the position of the SILTS pod? It is too forward at the moment.

I'll check it. And on the note of ticket#62(Reentry plasma mesh/texture in wrong position), I checked it and it looks like it needs to be redone rather than realigned to fit the new orbiter.

 

[GLS]

Is it a start from scratch job, or a (simple) resize?

 

[DaveS]

Realigned SILTS pod has been checked it.

---------- Post added at 08:17 PM ---------- Previous post was at 08:14 PM ----------

Is it a start from scratch job, or a (simple) resize?

From the scratch. The new orbiter is just to different in the shape for it align properly.

 

[GLS]

Something that has been "bothering" me for some time now is the star tracker doors. Something is not right with them as they are showing up thru the fuselage. Did some code browsing to see what the story was, and to see how to operate them, and found that the doors are not controllable as the MechActuator class doesn't have an input and might also not be finished. So, as they don't work, I changed their initial position to closed.
While I was fooling around with that, I also found a problem with the panel O6 switch covers: the hinge is on the "top" of the cover and it should be on the "bottom". I don't know if they are just hinging at the wrong place or if the StandardSwitchCover only considers covers opening "up". I'm tempted to create a ticket for this one, because I don't see this being fixed soon as it looks like panel O6 is not controlling anything ATM.

 

[SiameseCat]

I've checked in a fairly major update of the SSU manual. Most of the changes are related to technical details, but I've also added an Installation Instructions section.

 

[Urwumpe]

Something that has been "bothering" me for some time now is the star tracker doors. Something is not right with them as they are showing up thru the fuselage. Did some code browsing to see what the story was, and to see how to operate them, and found that the doors are not controllable as the MechActuator class doesn't have an input and might also not be finished. So, as they don't work, I changed their initial position to closed.

MechActuator is supposed to be implementation of the standard dual AC motor actuator used in the Space Shuttle. I remember that I am to blame for creating the class in the component model.

It was supposed to combine two ACMotor objects and turn their motion into the animation. The AC motors where supposed to be controlled by the MCAs by getting different combinations of AC currents, so that the switches for the MCAs make any sense. The MCAs get feedback from the MechActuator class about reaching soft stop microswitches in the animation.

Since there are quite a few such mechanic actuators of the same construction in the Space Shuttle, I thought that it makes sense to use a component model there. Especially since you could affect the animation then by either messing around with the MCA switches, the power supplies or the control logic itself.

 

[GLS]

I've checked in a fairly major update of the SSU manual. Most of the changes are related to technical details, but I've also added an Installation Instructions section.

Thanks a bunch for the updated manual! :thumbup:
Now, this is not complaining, but I have compiled a "nitpicking list" (I would do all of this, but after 2 attempts at installing TeX editors, I've given up on that format... :compbash

page 4
> The spacecraft3 reference is not needed.
> Should mention the need to activate/enable CRTMFD.
> I know it probably doesn't look good, and it might not make sense, but could the URLs be shown? If the document is printed there's no way to know the link.
> About the lines to be added, the readme file (SSU Readme First.txt) mentions a few more... who's wrong?

page 8/9
> Is it possible to put the 2 images in the same page? Maybe by cropping some white space off the edges of the images?

page 10
> RMS grapple/release keys don't work here, but key 8 works.

page 11
> In the ascent phase: "MECO is commanded" should be replaced by "A manual MECO is commanded".
> At the top of the 2 column: "The table below" should be "Table 2", and maybe with a link to it?

page 13
> The image description should say something like "attachment locations on the Orbiter with (right) and without (left) ODS".
> About the text below the image: aren't bridgerails shown now? We just don't have the horn-like "guide things", right?

page 16
> At the end of the text: shouldn't the OMS/MPS etc, have a chapter for them? Something like "MEDS displays", after the DPS displays. If so, please inform so I can give a hand in the writing.

page 17
> Should add the phrase "Currently no item entries are supported" to the ENTRY TRAJ chapter.
> Correction to the HORIZ SIT chapter: "Only ITEMs 41, 3, 4, 6, 8 and 39 are supported. ITEM 41 selects the landing site, ITEMs 3 and 4 switch between the primary and secondary runway (not necessarily the same physical runway), ITEM 6 switches between a straight-in and overhead approach, ITEM 8 switches the aim point between nominal and close, and ITEM 39 switches between nominal, short and ELS (Emergency Landing Site) speedbrake configurations for final approach. These parameters all affect the entry autopilot, so they should be set as early as possible, preferably before Entry Interface (EI)."

page 18
> The table is outdated, "Landing Sites currently available in SSU" file has current list.

general
> There should be one (or more) empty lines after the TOCs.
> Question: the "Version 1.XX Rev. B" refers to the manual or the SSU "code"?

 

[DaveS]

> About the text below the image: aren't bridgerails shown now? We just don't have the horn-like "guide things", right?

Yes, we do have the actual bridge rails, but not yet the Payload Retention Latch Assemblies (PRLAs). There are two types of PRLAs, passive and active. Passive PRLAs are used for non-deployable payloads while active PRLAs are used for deployable payloads. The alignment guides are optional on the active PRLAs.

Passive PRLA:

Active PRLA:

 

[Zach121k]

So I have a question.
I have a HQ wav of the Hydrogen Burners and wanted it to play when they went off. Being very familiar with code, I decided to go into the SDK files... I soon realized that this was a lot. Any ideas on how I can do this?

 

[GLS]

So I have a question.
I have a HQ wav of the Hydrogen Burners and wanted it to play when they went off. Being very familiar with code, I decided to go into the SDK files... I soon realized that this was a lot. Any ideas on how I can do this?

Hi there!
I did a quick check of the code and a few tests and found that while in focus to "vessel 1", one can't hear the sounds produced by "vessel 2" . So, although the long-throw igniter sound would be a very good addition, because it would be produced in the MLP it would not be audible when in focus to the shuttle. This seems to be a OrbiterSound limitation.