Some potentially great ideas

[milleyvanilli]

I have potentially interesting connected ideas worth for consideration. For the record, I have personally tried Microsoft Flight Simulator X, X-Plane 11, including Flight Unlimited 3 and Fly2K back in earlier times.

What seems to be missing in all these flight sims is a way to make it more real by adding a procedure to check your fuel grade and perhaps oil, thereby make sure your flight is safe and worth making the trip. For example, the fuel grade would have to be the proper grade, which the game physics could show on an a chart revealing what’s required. Morever, you could check to see if there is water in the aircraft's fuel (i.e. from a prior flight). You could also check for cracks and dents on your wing, so that your flight will be safe.

Your job in all of this, of course, would be to inspect these things as a pilot before your flight from the checklists. Things that would need fixing could be fixed by a local virtual mechanic. I’m sure the time for these types of fixes in the physics of the game would depend on the nature of the part that is damaged.

All these things could be options that you would setup as “more realism” in the sim.

Would others be interested in features like these? Would this be great for the flight gear community? If there are no developers available for this, I would be interested in contributing if any developer had a suggestion on what material I would need to learn game physics and mechanics, since my knowledge is only within the realm of C and C++.

[bigstones]

I thought of something similar (but less sophisticated) while watching a video of a pre-flight check. Some aircraft have clickable things that are not in the cockpit - in particular, a PA-28 was modeled with a luggage door. So I think you could do a lot that way, it should be all XML and Nasal, AFAIK, and it should be possible to make it as a reusable framework. Regarding modeling more physics stuff I don't know however (actually, I never touched aircraft modeling either.)

[stuart]

Hi Guys,

I think you can do the virtual inspection item with a combination of
1) aircraft animation/modeling to model opening oil panels, dents in wings
2) the "walker" so you can navigate around the aircraft
3) Either a XML-based tutorial, or possibly just a checklist for the user to follow
4) perhaps some Nasal coding to glue the elements together, though most of that would be insite the tutorial
5) (Optionally) extending the existing failure modeling to control the chance of encountering some of the problems.

So, all the pieces are there, it just needs someone to glue them together .

The virtual mechanic isn't really required if your aim is to teach people how to perform a pre-flight: you can simply have the user indicate which items make the aircraft unfit to fly and score them on their accuracy.

-Stuart

[Hooray]

Hi & welcome,

You'll probably want to check out:
http://wiki.flightgear.org/Aircraft_Checklists
http://wiki.flightgear.org/A_Failure_Ma ... FlightGear
http://wiki.flightgear.org/FlightGear_M ... Adventures

Like Stuart says, we have most of the building blocks for this, it's just a matter of integrating things accordingly.

BTW: I suggest to check out this article: http://wiki.flightgear.org/Implementing ... FlightGear

[Jabberwocky]

Reality is all good and nice, but for normal not so professionals who fly for fun, please consider next to the autostart menu item an autorepair item. Please, please, please ...

[Hooray]

I would be interested in contributing if any developer had a suggestion on what material I would need to learn game physics and mechanics, since my knowledge is only within the realm of C and C++.

Stuart's list is fairly exhaustive, with C and C++ knowledge you are basically over-qualified, we have an integrated scripting language, analogous to JavaScript in your browser, which can be used to implement these -and many other- features.

Something like an interactive "pre-flight check" would be ideally based on Stuart's checklist system, using DFaber's Walker - all tied together using the tutorial/missions subsystem, all of these are 100% scripted, i.e. no C/C++ involved.

[HJ1AN]

To add on to this, I have another suggestion to plane modelers. Have some of the switches and knobs randomly set on or off before startup, so that as part of the checklist to ensure the switches are where you want it before startup. Ie, the previous pilot may have left the throttle pushed in or a light switched on, cowl left open, etc. for example.

Also have an option or part of autostart to reset them automatically.

[Hooray]

That would also be best done by using Stuart's aircraft checklists - i.e. a Nasal script could randomly set up some initial state, but it should definitely not be implemented through just aircraft-specific Nasal scripts (or even just XML files) - buttons & switches is exactly what checklists deal with, so it would be better to introduce a flag that allows certain button states to be randomized during start-up.
It's probably less than 50 lines of Nasal code to extend the checklist code accordingly, and all aircraft would benefit from it - as long as people adopt checklists.

[Michat]

It's a good idea. I like it.

[milleyvanilli]

Bigstones, it’s good that you pointed that out, since my intent in the post was relative to adding procedures that make it seem more real. I do know XML is great for providing labels and descriptions of these things, similar to what in older days would be flat database text files.

Hooray, thank you for those resources. I could tap into those if these are features that enough users would like to see. I also see what you mean about JavaScript being a proper tool for this, being connected with the web browser. I do have much knowledge of this language that I learned outside of my schooling.

Jabberwocky, that is also a good title to call it if you are wanting to focus less on the repair and more on learning dynamics of flight. This is why mechanics would be an optional feature to users for realism.

H1JAN, that’s an excellent suggestion! I didn’t think of that one. This is what I’m getting around about in this post. Again, these would be options adding “more realism” into the game, the way I see it. I see perhaps a “Randomized switches” option. Also, this could be from basic to advanced, meaning that basic defines common knobs that could be set from a prior flight and advanced would be additional randomized knobs.

Anything that adds to realism, I believe, is a great thing. This is exactly why I love flight sims. The more real they make it, the more it feels like you’re really there!

On a side note, has anyone that have played Microsoft Flight Simulator series of products find the private test instructor irritating in X? She seemed to be much more strict in X compared to back in 2000. The tests were a lot harder in X, in my opinion.

Finally, I would say if you are interested in great pilot training, I recommend anyone checking out the one in Flight Unlimited 3. That seemed to have the most realistic training I have ever experienced for virtual simulation, including the present day Flight Simulator X and X-Plane 10! I learned much more in that flight sim in particular. All the other sims just seem to be better on aesthetics in comparison.

[Hooray]

you misunderstood: I only mentioned JavaScript running in a browser to illustrate how FlightGear scripting through Nasal works inside FlightGear, without requiring any C/C++ experience/tools/build environment, and without having to rebuild FG from source. Basically, "Nasal" is to FlightGear what JavaScript is to your Browser - an extension mechanism through scripting.

http://wiki.flightgear.org/What_is_Nasal
http://wiki.flightgear.org/Nasal_for_C% ... rogrammers

[milleyvanilli]

Thank you Hooray. I did misunderstand and saying so with my apologies! I see now what you mean.

What about 3D math? Would I need to learn that to be effective with any Flight Gear scripting? I am only up to a college algebra level in those regards.

[bigstones]

I do know XML is great for providing labels and descriptions of these things, similar to what in older days would be flat database text files.

XML in FG has a particular "meaning" actually. Many [sub]systems (like the checklist) are configurable through XML files (http://wiki.flightgear.org/Xml) whose general structure is well defined, so actually I wasn't speaking of XML in a general way. However a lot of much more authoritative and complete suggestions than mine were given already (...please be aware of my post count.)

(@Hooray: would it be correct to say that the DOM is to JavaScript what the Property Tree is to Nasal?)

[Hooray]

nope, not at all - what you describe here, should not require any advanced maths or physics for months (or even years) to come - but even if you should want to add some more fancy maths/physics, we have several contributors who'll usually love to help with interesting math/physics problems. In fact, most long-term contributors have some form of background in either maths, physics, aerodynamics/engineering or computer science - but ultimately, spare time is more of a bottleneck than skills/expertise - that especially applies to people who are really just about to get started contributing, and who are not interested in doing common number-crunching stuff (weather, aerodynamics/FDM, 3D rendering, GIS etc)
There are some contributors around here who are extremely accomplished, but who have never contributed in any way through code, maths, physics or engineering - in fact, that even applies to some core developers whose professional background would match such more technical areas, but who still prefer to contribute to completely different areas, such as e.g. texturing, 3D modeling, scripting, FDM tuning.

Before you start working on anything, I'd suggest to spend 1-2 weekends looking through the links that we've posted, that should save you quite time and get you on the right track.

Regarding the DOM/Property Tree analogy: PropertyList-encoded XML files are mapped to a/the "property tree" data structure, which is what is commonly used to tie together different subsystems and features - typically, such XML files are not manually processed, they are "transparently" processed by FlightGear, loaded and mapped into a Property Tree, that can be manipulated/modified using either C/C++ code, or FlightGear scripting (through Nasal). There are several subsystems that implement a full API on top of the property tree, such as the AI traffic system, but also Canvas - basically, setting certain properties (e.g. via setprop), triggers certain code (through listener callbacks) - with arguments and return values passed through the property tree, which in turn allows arbitrary 3D models to be placed, but also AI traffic to be created / controlled, as well as OpenGL textures to be created and modified and run-time, which is what we use to implement HUDs, GUIs, instruments, MFD avionics, and even liveries or scenery textures (VGDS).

PS: Post count itself is not a useful figure to put some context around what people say - we've got some fairly active "posters" who are still mostly "users", while we have some forum members who have a fairly low post count, but who are accomplished contributors, if not even developers.

[Philosopher]

Thomas of corse applies there! (I seriously didn't know he was so smart when I first encountered his handle here)