Space Shuttle

[amalahama]

What do you have in mind to do next, Thorsten?

There's still six DPS pages which seem meaningful to support (PDRS support and the environment system), there's the MEDS config page,... In terms of guidance, the crown jewel of the collection: proper RTLS support (even under AP?), that's a really challenging regime. Some contingency abort guidance. Tank leakage simulation and appropriate procedures.
.

Proper HUD symbology for terminal phase would be a nice feature as well

Regards!

[wlbragg]

If I wanted to breakout the individual panels into each having their own .xml file (12000+ lines of code is getting to be a bit much, ), how do I call that file from the main cockpit.xml model file? Is there any effects related downside (or any other for that matter) in doing that?

If this is doable, should any effect definitions stay with the "moved" panels into the new file and thus a new effect definition or leave the definition in the main cockpit.xml model file?

If leaving the effect definition in the main model file, does the order the satellite file gets called need to be prior to its effect being called?

[Hooray]

normally, using the include directive - there shouldn't be any overhead in doing so, it'll just recursively call the same XML parser to build the XML tree - however, I would not suggest doing this manually, there are excellent XML tools available which can help automate 99% of these tasks.

[wlbragg]

I don't suppose you could be a little more specific? I see the "include" directive being used in the set-xml but I couldn't get that to work, Could just be my incorrect usage. I would really appreciate a working example.

Does it have to be used from the set file or can it be used in the model file that the set file calls?
Does it need a identifying tag around it?

Code: Select all

<model>
    <path>Aircraft/SpaceShuttle/Models/SpaceShuttle.xml</path>
    <Panel-R1 include="panel-R1.xml"/>
</model>

--or--

<model>
    <path>Aircraft/SpaceShuttle/Models/SpaceShuttle.xml</path>
</model>
 <Panel-R1 include="panel-R1.xml"/>

--or--

<model>
    <path>Aircraft/SpaceShuttle/Models/SpaceShuttle.xml</path>
</model>
<R1>
    <Panel-R1 include="panel-R1.xml"/>
</R1>


The above examples all being called from the -set.xml file.

I would simply test all the possible combinations but this would take hours of booting and re-booting.

however, I would not suggest doing this manually, there are excellent XML tools available which can help automate 99% of these tasks

Could you elaborate on that also, I know of no way to do this automatically, I was just going to cut and paste code blocks to new files. It's not really that labor intensive, we're only talking about 10 files or so that need to be created. From that point on we can create a new file for every new panel being developed.

[Hooray]

See the PropertyList docs on the wiki: as long as your XML files are PropertyList-encoded XML files, they should support the include directive (there's also some info in $FG_ROOT/Docs/README.xmlsyntax)

xmlstarlet is one of the tools that comes to mind to "refactor" XML files programmatically.

[wlbragg]

See the PropertyList docs on the wiki:

Thanks for the info Hooray.

Unfortunately, http://wiki.flightgear.org/PropertyList_XML_files isn't giving me the answer. Everything I try leaves the knob animation inoperable. There are too many variables as to what might be wrong with my "guess" as to the exact syntax or if maybe it is a path issue. I see the "include" directive being used in different ways with different xml data, none of which seem to be the specific use case I need.

I guess I'll have to wait until someone that has used it in this way can speak up and provide a more detailed or specific example.

[Richard]

Providing that the names in the geometry are unique I'm pretty sure you can just do

Code: Select all

    <model>
        <path>something-else.xml</path>
    </model>


where something-else.xml doesn't have an ac file. This might not work at all, and it might not work with effects - so give it a whirl and let us know.

[wlbragg]

Thanks Richard, that doesn't appear to work either. I actually get an error "cannot find the following objects for animation". I tried using it in Model/cockpit.xml and also in the -set.xml. I don't get the error when using it in -set.xml, but it still doesn't work.

Also, using various combinations of

Code: Select all

<something include="something.xml/>

I don't get the error but it doesn't work either.

So I guess I am asking how to do something that can't currently be done.

[Thorsten]

I don't know how it actually all works (I doubt anyone really does...) - some observations:

* <include> helps you only if you want to populate a specific subdirectory of the property tree

Code: Select all

    <failures include="component_condition.xml"/>


populates the failures/ subdir of the Shuttle tree for instance, but it never works to add anything to the root directory. Declaring animations in a subdirectory of the model xml doesn't work.

* there's probably a reason model within model xmls are not using <include> but <model>, and I suspect that one of the differences is that xml as such creates property tree structure, but models in addition create OSG nodes on the scenegraph.

Which is to say

Code: Select all

    <model>
        <path>cockpit.xml</path>
        <offsets>
            <x-m> 0 </x-m>
            <y-m> 0 </y-m>
            <z-m> 0 </z-m>
        </offsets>
    </model>


creates a scenegraph node 'cockpit' (or whatever the assigned name is, we should have the ability to name somehow) and effects can be assigned to that node and should automatically apply to all children (at least for animation, that really works - unfortunately the effect framework is really coded with its own conventions).

* Now trying to include xml misses the scenegraph node references a <model> tag creates, which is why I think this doesn't really work.

* The idea to have the effects, animations and other definitions for one ac model in one xml file isn't so bad - the problem in out specific case is that the whole cockpit mesh is one chunk, so it all grows very large.

I suspect if we had panel by panel *.ac files and just include them in the cockpit files via <model> tags (as airplanes usually do instruments...), it'd all be somewhat more manageable.

But a shortcut to 'just' include additional xml into the root level directory to simplify files doesn't exist in FG to my knowledge.

[wlbragg]

I suspect if we had panel by panel *.ac files and just include them in the cockpit files via <model> tags (as airplanes usually do instruments...), it'd all be somewhat more manageable.

Yeah, I thought about that but that has its own drawbacks with the effects too, although I don't think we're using any of the effect that create issues such as interior shadows. Bottom line, it's probably not worth the effort.
It's not to the point where it is unmanageable, I was just hoping it would be an easy thing to break it up. I'll continue doing it the way we have been and use comments to keep it reasonably organized.

[Thorsten]

Yeah, I thought about that but that has its own drawbacks with the effects too, although I don't think we're using any of the effect that create issues such as interior shadows

That's caused by translating/rotating things into place rather than having them absolutely positioned in the ac file, not by including a separate ac file. As long as the coordinate system of the cockpit is the same throughout all included files, it's fine.

[Thorsten]

After some blood, sweat and tears, the Shuttle now has an AP that delivers the powered RTLS flight to a reasonable MECO condition (this is lightyears beyond the usual control problem and your run of the mill PID - during the fuel dissipation stage, there is no real control authority, powered pitcharound operates close to the accelerations that break the Shuttle, effects of trajectory changes aren't really felt until 30 seconds later, the whole flight characteristics changes drastically as mass reduces and acceleration ramps up, the sign of the errors flip dynamically as the Shuttle changes from a heads-down to a heads-up attitude,... ) and can do the alpha recovery and Nz holding stages of the glide.

The latter basically drops the Shuttle with Mach 7+ from 350.000 ft into the lower atmosphere - it does a (vertically supersonic) freefall until it recovers around 90.000 ft and bounces back after a vicious phase of vertical acceleration as lift catches.

It's quite a unique experience to pilot this by hand (it is doable, but the workload is heavy) - the AP makes it a lot easier though.

It's still not all fine-tuned (I got delivered into a viable TAEM, but with lots of S-turns required) and the plunge actually gets into a region where actuator stall occurs and makes the controls unresponsive for a while, but the outline of this is there.

I dare say with its many successive stages of quite different nature it's with some margin the most complex AP operating anywhere in FG...

[wlbragg]

That's caused by translating/rotating things into place rather than having them absolutely positioned in the ac file, not by including a separate ac file.

I guess I never really understood that and it is really helpful to know this. So technically in the c172p's case, all the eternal .ac instruments it uses (the ones that are local anyway), could be positioned absolutely in their ac file and then be included in the shadow effect to get a better visual. It would be some work but might be worth it. It for sure would be worth understanding this on any new build and start out using this method so you can include the entire instrument panel in your effects, good to know.

the Shuttle now has an AP that delivers the powered RTLS flight to a reasonable MECO condition

I would guess eventually you might do some kind of write-up on how to use it (or already have)?
I need to spend a week going through your documentation and tutorials and really put this ship through its paces so I understand all of this, everything in FG it's just so time consuming, I could spend days on just one of these phases.

But it is really pleasing to know it is all there available for the experience once one is ready to commit the time to learn it. I can't convey how important your documentation is to me personally, thanks for all your hard work.

[Hooray]

at some point, it would probably be very cool if someone could record a few "fgtapes" so that our video capturing folks can more easily capture appropriate shuttle videos to post those on youtube, so that we can reuse them on the wiki (newsletter/tutorial and release announcements)

[Thorsten]

So technically in the c172p's case, all the eternal .ac instruments it uses (the ones that are local anyway), could be positioned absolutely in their ac file and then be included in the shadow effect to get a better visual.

That's my understanding, yes. Richard has I believe structured the F-15 that way and it works. Of course, that'd still leave the problems of translating/rotating hands on the gauges which might lead to inconsistencies, but they would seem to be manageable by using a flat, non-directional lighting for them.

I would guess eventually you might do some kind of write-up on how to use it (or already have)?

Eventually... It's the most complex flight pattern the Shuttle does. Of course it's easy to switch the AP on and let it be done automagically, but even what to monitor when to verify it's all working correctly is a handful.