Back to download page.

warnings regarding / commentary and such upon my latest (2014-Nov) acceleration script

Warnings

• This is not meant to be run unless you're experimenting along with me.
• It is not meant to work with any of my other .nas files (yet). I have no idea what the interaction would be.
• I'm releasing this now for anyone who is following my work because this version is much cleaner than anything before it. This will almost certainly be the way I do my next set of .nas files, when I re-integrate this new version.
• There are plenty of print statements and no verbose variable / switch yet. (Your console will be cluttered.)

The Code

New Features

• This should work even on the first entry into FG.
• You see the max immediately as it happens, even on reply.
• You get a "final" max after my definition of the plane settling: throttles to idle, wow (both rear wheels), and Z-accel < 33.16 fps/s for two whole seconds. (More specifically, 4 samples over 2 seconds.)

Known Bug

There is a scenario where the frame listener never gets cleared. The script showed maxZ then a final max Z and then I think the plane went off the runway, so WOW went up and down, then I saw "34" and the frame listener "hung" and kept printing hits. I'm not going to chase this now (2014/11/12).

More Commentary

This is close to a minimal definition of the acceleration "score" feature. It's ~122 lines, and I hope it will get smaller. I've tried to re-research and re-think the problem from the beginning.

The initial trigger is only WOW (weight on wheels) for the two rear (sets of) wheels. I very vaguely remember my in-my-head logic as to why I needed all the elevation stuff and timers and whatnot, but I feel a bit silly now that I've seen this version work.

Future Work / self-critique

A very active member of the FG forums asked that I write a Nasal tutorial. Standard software practice also highly recommends documentation.

Code should be evaluated at least two ways--whether it works from the outside and the innards (the code itself). My code has pretty much worked for 19 months, but the innards have not been so pretty. I've observed for many years that it's really hard to document code with less-than-great innards. You start documenting and then realize how difficult the effort is because you're having to explain stuff that's messier than it needs to be. I'm getting to the point where I will have code worthy of documenting.

This version is much cleaner, but I suppose I should add some closures. Nasal does support closures.

Also, yes, I am very familiar with the concept of version control systems and I have used them extensively. That's on the agenda, too. For one, I only know for sure of one other person who has ever run my scripts. I'm not arrogant enough to post to GitHub with two users. I can run my own Git server, and I've experimented with it. I'm getting there.

Version Note

Looks like I will label the first experimental version as:
print("accel - Kwynn.com - experimental - v11.0.0a - 2014/11/12 10:01pm EST");

Apparently I'm feeling paranoid today:
SHA256(accel_experimental_2014_1112_2201.nas)= 634939814666812e61aefb83ea92f7801615f53aa7fe8cd530cb642d60ea03ce
MD5(accel_experimental_2014_1112_2201.nas)= ac04ea614424d38a018b85b6291eb7de

The hashes / checksums are with Linux EOFs.

Page History

Created 2014/11/12, updating 10:24pm and will continue for a little while.