Space Shuttle

[Thorsten]

Reading through Richard's answer, it seems I completely misunderstood the question

[Thorsten]

I've now added the routines for the Ku-antenna pointing. Till I have done SM OPS 201 (antenna) where the details can be configured, it will track TDRS-3 at the moment (regardless of whether there's currently line of sight). It's actually neat, you can maneuver around and see how the antenna moves to re-acquire the forward link from the satellite.

[wlbragg]

@Richard, your example assigns 3 different values (0-2) to one property. Can the bindings be written to assign a different value to 3 different properties instead or do I need to use the one property in another function or a switch statement to take care of the three other properties?

IE:

Code: Select all

<animation>
toggle up = prop1=1, prop2=0 prop3=0
toggle mid = prop2=1, prop1=0 prop3=0
toggle down = prop3=1, prop1=0 prop2=0
</animation>

instead of

Code: Select all

<animation>
toggle up = prop0=0
toggle mid = prop0=1
toggle down = prop0=2
</animation>

<switch or FCS or Nasal>
if prop0=0 {prop1=1, prop2=0 prop3=0}
if prop0=1 {prop2=1, prop1=0 prop3=0}
if prop0=2 {prop3=1, prop1=0 prop2=0}
</switch or FCS or Nasal>


[wlbragg]

For now I set it up with a switch statement in Systems/adi.xml

Code: Select all

    <animation>
        <type>knob</type>
        <object-name>F6SW-1-7</object-name>
        <property>/fdm/jsbsim/systems/adi/toggle-switch</property>
        <factor>-35</factor>
        <offset-deg>35</offset-deg>
        <center>
            <x-m>-12.38974</x-m>
            <y-m>-0.5833</y-m>
            <z-m>-0.71387</z-m>
        </center>
        <axis>
            <x>0</x>
            <y>1</y>
            <z>0</z>
        </axis>
        <action>
            <binding>
                <command>property-adjust</command>
                <property>/fdm/jsbsim/systems/adi/toggle-switch</property>
                <factor>1</factor>
                <min>0</min>
                <max>2</max>
                <wrap>false</wrap>
            </binding>
        </action>
    </animation>

Code: Select all

<switch name="/fdm/jsbsim/systems/ap/orbital-dap-inertial">
   <default value="0"/>
   <test logic="AND" value="1">
      /fdm/jsbsim/systems/adi/toggle-switch EQ 2
   </test>
</switch>

<switch name="/fdm/jsbsim/systems/ap/orbital-dap-lvlh">
   <default value="0"/>
   <test logic="AND" value="1">
      /fdm/jsbsim/systems/adi/toggle-switch EQ 1
   </test>
</switch>

<switch name="/fdm/jsbsim/systems/ap/orbital-dap-free">
   <default value="0"/>
   <test logic="AND" value="1">
      /fdm/jsbsim/systems/adi/toggle-switch EQ 0
   </test>
</switch>

[wlbragg]

Should the keys on the pilot and commander keypads have a tooltip associated with them? I'm not sure they don't just get in the way.

[Thorsten]

I'm personally not a fan of tooltips at all, but as I have just switched them off, my opinion shouldn't matter.

Can the bindings be written to assign a different value to 3 different properties instead

You can assign multiple bindings - that's how the radio-buttons in flight_controls.xml are done:

Code: Select all

   <radio>
      <row>2</row>
      <col>1</col>
      <label>+X</label>
      <halign>left</halign>
      <name>sense-X</name>
      <property>/fdm/jsbsim/systems/fcs/sense-X</property>
      <live>true</live>
      <binding>
         <command>property-assign</command>
         <property>/fdm/jsbsim/systems/fcs/sense-minus-X</property>
         <value>0</value>
      </binding>
      <binding>
         <command>property-assign</command>
         <property>/fdm/jsbsim/systems/fcs/sense-minus-Z</property>
         <value>0</value>
      </binding>
      <binding>
         <command>property-assign</command>
         <property>/fdm/jsbsim/systems/fcs/sense-X</property>
         <value>1</value>
      </binding>
    </radio>   

(I do hope I understood the question correctly this time).

Btw - do you want responses primarily via the ticket system, or do you create them for reference only? It's nice that we have the system, but we should also agree on how to use it at some point, I guess

[wlbragg]

The more I think about it, the way I did the switch is probably the best, it's the least amount of code for sure.

do you want responses primarily via the ticket system

The ticket system has its advantages for sure. If everyone agrees then yes, I think we should use it.

I like it because it is an extension of my memory that wont fail me.
If you add items as you go it does have a tendency to help focus your tasks
It is way easier to find recorded information than looking back over the forum posts because it is organised and categorized.

Right now I am using it for things I don't want to forget, but the first one I entered had a question that got answered promptly .

[Hooray]

My main concern is to figure out just what needs to be instanced how in Richard's display framework to generalize it - seems I misunderstood how this works, it appears more complicated than I guessed.

I've been through the Nasal now and I've got a plan for turning it all into an object that we can instantiate multiple versions of (one for each screen) - I'm still not totally up to speed with the way it's all going to work; so the first step is to change the Nasal so we can have what we've got now on multiple screens and then figure out the next step..

I know you are having a hard time believing this, but the design will evolve "automagically" once you start using a dedicated Canvas dialog with an embedded keypad/screen, because that will allow you to easily develop/test independent instances of your code without any hard-coded assumptions - and also without being restricted by instruments being texture/UV mapped or not.

[Thorsten]

The keypad / IDP / GPC relationship code is done (and partially tested) - the remaining re-structuring is about instancing the MDU code itself, i.e. generating n identical displays, each driving a different canvas attached to a different location, which can be referenced by array index from the IDP code.

The display driver itself is a non-trivial handful, because it displays both display-specific and Shuttle-wide data, so some updates may only affect a particular screen, others will affect all screens regardless of from where they have been entered.

It's actually a fairly complex system - take a look into section 2.6 of the crew manual to get the idea of how it all ties together.

[wlbragg]

@Richard, I have no idea if you will know the answer to this question but I need to ask. I am starting to animate some of the switches in the Shuttle. The first one I did was the Commander's ADI switch. Next I decided I might as well go ahead and do the Pilot's ADI switch. Two things I noticed. The Commander's switch was one solid object including the pedestal, the Pilot's was many faces and still part of the Fwd_Equipment_Knobs object which is literally half the ship. One was on a texture (text legend) panel, the other was not. Can you shed some light on this for me and maybe guide me on steps you were planning on taking down the road to deal with this?

To remind you, it appears that you somehow may have already converted many switches to stand alone objects and named them, does that sound familiar?

[wlbragg]

I finally found a picture of the Flap, Speed Brake and AP button lights in action.

[Hooray]

Regarding code like this: http://sourceforge.net/p/fgspaceshuttle ... p_main.nas

Code: Select all

device.MEDS_menu_title.setText("      MAIN MENU");


Note that you can also set font/formatting related attributes using dedicated properties, i.e. you don't need to prepend/append whitespaces for such purposes.

For details, refer to api.nas and the text class: http://sourceforge.net/p/flightgear/fgd ... as/api.nas
which is where you can find the setAlignment method:

Code: Select all

# Set alignment
  #
  #  @param align String, one of:
  #   left-top
  #   left-center
  #   left-bottom
  #   center-top
  #   center-center
  #   center-bottom
  #   right-top
  #   right-center
  #   right-bottom
  #   left-baseline
  #   center-baseline
  #   right-baseline
  #   left-bottom-baseline
  #   center-bottom-baseline
  #   right-bottom-baseline
  #
  setAlignment: func(align)


Equally, layouting can be accomplished using the vbox/hbox layouts - which in turn can be used to create table (row/column) layouts: http://wiki.flightgear.org/Canvas_Layout_System
Overall, using the corresponding Canvas/OSG level helpers for this should be more Canvas friendly.

If you find anything missing, it would be better to let us know what it is - in fact, Gijs added missing features with just a handful lines of code: http://wiki.flightgear.org/Canvas_Devel ... osgText.29

Equally, it would be a good idea to stop using the low-level settimer() API and use maketimer() instead, or at least introduce a wrapper for settimer() using the maketimer() API

[Thorsten]

Note that you can also set font/formatting related attributes using dedicated properties, i.e. you don't need to prepend/append whitespaces for such purposes.

Well, we usually have an SVG placeholder of a given length in the display (that's how the real thing is specified in the DPS dictionary, you'll find entries like XXXXS all over the place which tell you there can be a four character string with a possible symbol in the end, and passing properly formated strings to replace the placeholder seems to be what the Shuttle avionics does - it does in fact *not* center or otherwise align the strings on the screen.

Equally, layouting can be accomplished using the vbox/hbox layouts - which in turn can be used to create table (row/column) layouts

Then I'd have to place every character in the correct table position to get the layout. Have you actually tried it?

The DPS screens are old-style CRT displays from 1980 - 50 columns, 28 rows. Each character is on a given col/row, and we're almost literally using this information to make the displays - each label is pretty much at the specified position. I don't want a standard table layout, I want the original layout in the DPS dictionary - and Richard's SVG placement masks are a doable workflow for that.

I invite you to actually code one display (take SM SYS SUMM 1 for instance) any way you prefer to get a first-hand idea of what it involves.

[Richard]

@Richard, I have no idea if you will know the answer to this question but I need to ask. I am starting to animate some of the switches in the Shuttle. The first one I did was the Commander's ADI switch. Next I decided I might as well go ahead and do the Pilot's ADI switch. Two things I noticed. The Commander's switch was one solid object including the pedestal, the Pilot's was many faces and still part of the Fwd_Equipment_Knobs object which is literally half the ship. One was on a texture (text legend) panel, the other was not. Can you shed some light on this for me and maybe guide me on steps you were planning on taking down the road to deal with this?

To remind you, it appears that you somehow may have already converted many switches to stand alone objects and named them, does that sound familiar?

Originally all of the switches were like that; just part of a huge mesh. I started to separate them out by panel; which is probably why the cdr side is done.

Workflow for this is something like, edit mode, select face/vertex, CTRL-L (select linked), possibly extend selection to include anything that isn't missed, then CTRL-P (reparent), do this for all switches then go back into object mode move them into the appropriate group and rename them all following the convention.

When you're next editing the mesh would you rename the MDU buttons for the centre and pilot ; naming is MFDC1_B1 to MFDC1_B6, MFDC2_B1 to _B6, MFDC3_B1 to _B6 , MFDC4_B1 to _B6 , MFDC5_B1 to _B6 , MFDR1_B1 to _B6 , MFDR2_B1 to _B6 . obviously the C1 follows the canvas screen of the same number. These are all bound in the xml so then all the buttons should work.

[Thorsten]

And... works...

This has SPEC 2, MEDS PFD, SPEC 20 and OPS 201 selected on different screens. As far as I could test, the screens all respond properly dependent on which IDP is selected and what major function is selected for the IDP and on edge keys (you just probably won't get the logic if you haven't read the manual... it is confusing).





Here's a night shot with SM and GNC functions mixed.



I see all displays with some rendering error if I look under a shallow angle in daylight. They look all okay at night and under more then, say, 30 deg - I'll look into this next.

So we could do with the keyboard to IDP switches and the IDO major function switches on the central console now I'll implement the major function selection for the virtual keyboard in the mean time.