Performance Evaluation, Scoring & Penalties

[Hooray]

Subject: Tutorials/Missions/Adventures: requests for features

1.- normal landing. Use power and flaps at your discretion
2.- Idle landing. If you use power 30 seconds before landing, this landing scores 200 points. Use flaps at your discretion.
3.- Idle landing without flaps. If you use power or flaps 30 seconds before landing, this landing scores 200 points.
4.- Obstable landing. There is a rope 50m before the zero line and 2m above the ground. Your approach must be above this rope. If you touch the rope, this landing scores 400 points.

Your final score will be the addition of all your partial scores.

A performance evaluation is another thing that could greatly benefit from simple canvas-based animation showing scores/penalties.
We probably need to add a simple scoring system so that people can implement their own bonus/penalty triggers.
Some of the more common ideas discussed elsewhere include: autopilot usage, exceeding certain limits(.nas), time & speed.

Also, anything that involves airliners will typically be involve W&B (fuel efficiency) - i.e. see all the "economy" discussions we've here regarding fuel efficiency.
If that is something that is to be supported, it would make sense to directly support only aircraft having at least an early-production status, including a configured and working W&B dialog (as per gui.nas).

Regarding post-flight evaluation, this will either involve sampling data points at run-time via timers, or hooking into the history/replay subsystems. Personally, I'd suggest to focus on those aircraft that already come with a working flight recorder configuration. That should limit the number of supported aircraft quite significantly, while also reducing the amount of frustration for users wanting to play with this using incomplete/unfinished aircraft

Basically, I am saying that it will be less work to ensure that mature aircraft use/provide things like 1) checklists, 2) the w&b dialog and 3) the flight recorder system, than working around all those aircraft that are nowhere close to supporting either of these features but still want to support "missions" - especially given that an aircraft-based tutorial/mission system would greatly benefit from these features being properly set up by the aircraft developer in the first place.

Overall, this should also help improve consistency while reducing the chance for disappointment and frustration among new users (keeping in mind that missions are going to appeal particularly to non-contributors, i.e. users looking for gameplay)

[ludomotico]

I'm not sure what the flight recorder provides, but I feel the data in a flight recorder could be too "raw" to implement a performance evaluator easily. Tutorials already include targets and we can build on top of these targets. They include properties /sim/tutorials/targets/NAME/distance-m and /sim/tutorials/targets/NAME/eta-min. They could include easily additional properties such as "radius", "reached" and "time-reached", the two latter properties automatically filled by the system. Missions would be more flexible if these targets are dynamic or movable from nasal space.

Some way to manage a list of high scores, or a "history of scores" to have some track of the evolution of the pilot may be adequate. A second iteration could include an online list of high scores. Personally, I'm not interested in world-wide high score lists but they may be fun for some users.

In multiplayer missions, some way to share individual scores between the participants must be devised. Probably, using the already implemented chat system.

At this moment, I believe preventing cheating is unimportant. I just put the issue on the table in case someone thinks otherwise.

[Hooray]

I'm not sure what the flight recorder provides, but I feel the data in a flight recorder could be too "raw" to implement a performance evaluator easily

it will be too raw/low-level for the things you mentioned, but anything that involves "economy"-models (fuel efficiency, flight envelopes, aircraft configuration) will probably need to sample the exact the same data anyway.

In multiplayer missions, some way to share individual scores between the participants must be devised. Probably, using the already implemented chat system.
At this moment, I believe preventing cheating is unimportant. I just put the issue on the table in case someone thinks otherwise.

agreed, it doesn't make sense to focus on cheating prevention for a system that is based on "open" concepts like scripting and XML/properties, anybody with just a little Nasal/FG knowledge would be able to circumvent such a system within a few seconds.