Looking for aircraft with 'paper cut' bugs

[wkitty42]

@clrCoda, the history of that wiki page should show when (and who) removed that information...

[Johan G]

The question is why it was removed and if it should have.

Have the functionality been removed in the latest stable version? In that case it perhaps would have been better to add a {{note}} template about that it was removed from the newer versions of FlightGear.

[clrCoda]

I assume this happened in a change to controls.nas. I'm not quite familure with looking at sourceforge for the file and dialing controls.nas back to a version when all of the keyboard commands still worked for a comparison.

I wrongly assumed that additions to keyboard.xml for the flightrecorder caused this. Nothing that was added for the flightrecorder is an issue here, as far as I can tell.

Left and right arrows, and on the keypad, keys 4 and 6 respectively used to drive the autopilot heading hold value when heading hold was selected. Altitude values controlled by up and down arrows keys 8 and 2. Speed values by page up and down. These are the things that don't seem to work any longer on planes that are associated with the Generic A/P.

I found my 2.0 copies of controls.nas and keboard.xml, and when I have time I will compare those with the newest versions to see if I can find where the discrepancy is. It's either controls.nas definitions or a change in property names -- speculation at this point.

--Ray

[Johan G]

I'm not quite familure with looking at sourceforge for the file and dialing controls.nas back to a version when all of the keyboard commands still worked for a comparison.

You can find controls.nas here, and by clicking the link History in the upper right corner of the code box you can see the commit log and commit messages.

I am no way near sure, but one of the candidates could be commit 9856fdd4, that was meant as a bug fix for bug #748. One on the comments to the bug report mentions that the fix breaks aircraft using the generic autopilot. It is an old commit, from 30 June 2012. The comment also links to the topic Autopilot adjustment 2.8.0.5.

It seems we are straying a bit from the topic though.

[clrCoda]

@Johan G

Can we move posts from here downward in this current thread:
http://forum.flightgear.org/posting.php?mode=reply&f=24&t=27090#pr254122
to the end of this conversation at
Paper Cut Bugs?

In any case, thank you very much for what you said. Yes, this problem has been years in the making
I believe you found the source. If I'm reading the description on that patch correctly the patch-er is confusing what ever problem he is thinking of with the functionality of the keyboard when generic autopilot functions are selected.

Personally, I don't quite see the issue in terms where the Generic A/P functionality has to be sacrificed for what ever it was that person was trying to fix.

In any case I hope it worked for the one plane they were working on, even tho they broke hundreds of others. I'm certain someone will read that as inflammatory and "set me straight" but really it's just a question of why was it done, because it's just that far over my head without full context.

Thanks
--Ray

[Johan G]

It seems we are straying a bit from the topic though.

@Johan G

Can we move posts from here downward in this current thread:
http://forum.flightgear.org/posting.php?mode=reply&f=24&t=27090#pr254122
to the end of this conversation at
Paper Cut Bugs?

Done! Good idea. Thanks.

[clrCoda]

Hi Bugman!

Johan G has found precisely where and when this problem of keyboard A/P control was lost.
Relevant link with all the links of relevant info in one place.
http://forum.flightgear.org/viewtopic.php?f=4&t=26183&p=254227&hilit=A%2FP+keys#p254227

In those texts a keyboard.xml addition is specified and I installed it and it works to toggle the passive mode.

I can't help but think that the bravo should have toggled passive mode with a flight director switch, rather than have some one make a commitment that broke the original functionality of the A/P keys forcing all every other plane in flightgear using the G-A/P to install a keyboard.xml hack.

I think we either install the keyboard.xml hack and fix all planes and maybe make a point of mentioning the new alt-insert and alt-delete keys into the in-sim menu>help>common keys....

Or we fix the real problem which is to return the commit that broke everything just to fix the bravo and fix the bravo with a switch that switches the passive mode, such as a hooking passive mode to the flight director where I think it belongs.

There might be other planes other than the bravo with the problem. 777 is a possible other plane that needs a passive switch correction.

Your thoughts?

Thanks,
Ray

[bugman]

Or we fix the real problem which is to return the commit that broke everything just to fix the bravo and fix the bravo with a switch that switches the passive mode, such as a hooking passive mode to the flight director where I think it belongs.

Hi,

This is clearly the correct way to go. For the core of the project, hacks are to be avoided as these always come back to bite you later on (temporary hacks are sometimes needed, but they always cause future pain). Do you see another way to solve bug #748? If we do have a different way to solve this bug, I'd recommend writing a summary of the problem, it's history, and its solution to the mailing list, using as many links as possible for reference. Then fixing bug #748 and reverting the bad commit can happen as back-to-back commits, fixing the A/P keyboard bug

Regards,
Edward

[clrCoda]

I've spoken to a few about this problem and I also got a nice surprise PM from someone no longer posting to forum ( voluntarily, hehe, not banned ) that had also worked on this problem.

I tend to think that what happened here was aircraft modelers (bravo possibly others ) that happened to have the wrong impression of what the flight director is and what the lines it makes in the PFD are for.

Yes, I shall do as you suggest.

[clrCoda]

I'm sorry that this appears to be taking me longer that we might have hoped.

Current reasonable excuse for delay is that some of the information I require to build the accurate history is at gitorious and according to them for the last week or more :

Gitorious.org is migrating all the repositories to Internet Archive.
The repositories will soon be available for read-only access, with original clone URLs preserved.

One glareing thing is that in the history of the problem there was introduced a bit of code to toggle the passive-mode of the flight director for those people that would have liked to return keyboard controls to aircraft using generic A/P that lost those controls after the commit to fix the problem with the Bravo.

I've not yet read the thinking that decided that the toggle should be forced on all of the generic a/p planes rather than to be entered into only the Bravo as the on/off switch -- for which the passive-mode property seems to be being used in the Bravo.

That is, the keyboard hack should have gone into Bravo and the commit that forces Gen-A/P planes to use the keyboard hack instead should have never happened.

Proving this with-out a shadow of a doubt is my intention. This should return the full control of the keyboard back to FlightGear as we all once enjoyed just a few years ago.



This has been a "why-the-heck-is-this-taking-so-long" update. Please tune to your regularly scheduled program.

--Ray

[clrCoda]

Please follow this train of thought experiment for a moment. Tell me if I'm wrong but...

There seems to be a way to solve this without bothering or worrying about having to
inspect any of the planes involved, and that they can remain coded as they are and
not have to be changed in any way.

This approach seems to take the entire history of what others involved had said and
offered previously, bundles all that together as positive incremental changes to the
situation, but that had not truly rippled out to the full extent of the reach of what
was effected in the bigger picture.

Leave everything as is and consider adding the following:

1) a "FlightDirector" check box to the Generic Autopilot Dialog and all that entails
like adding a passive-mode toggle to the generic autopilot.
2) a new key to keyboard.xml to toggle this passive-mode.
3) a new line entered into the in sim Menu>Help>Common Aircraft Keys that says something
like "Toggle Key Options" with an asterisk next to it and next to all of the effected
lines in that dialog that represent the effected keys controlled by the toggle.


Why I think this is a slightly better solution than another is:

This works for all planes as they are currently coded.
I have no tally of how many planes besides the bravo would be effected by reverting
current commits.

Were the 3 things enumerated above added, I don't have a care how a plane uses the
passive-mode property. The stunning thing is, if the keyboard isn't doing what
I want it to in the Bravo or in any thing coded like it, or even if it were a
generic a/p plane, then hitting the one toggle fixes that situation immediately
for all planes.

Hitting the toggle corrects the bravo and planes coded like it, and hitting the toggle
again corrects all the other planes. We make no reversions to commits.
We extend the flexibility to allow for planes to be coded like generic and like
the bravo class.
We keep everything, all the reasonable good answers that have developed in the
'thread' so far and add just a tiny bit more for a bit of a correction.

These corrections are devised from suggestions made by people that have considered
this problem in the past. Only I have had the benefit of time and to collect these
ideas and re-represent them here.

Adding the text suggested to "Common Aircraft Keys" makes the newly added key
obvious to all users instantly.

Adding the FD box to the generic a/p dialog makes it mouseable.
Makes it instantly understandable.
If the box is selected in a generic autopilot plane then the passive-mode is
obviously set and unset if unchecked.

Previously it was suggested to add the keys alt-delete to unset and alt-insert to set,
but I'd like to suggest that this be reduced to just alt-insert as a toggle and that
that should be make to toggle the passive-mode, and the new FD box in the Generic A/P
dialog. (alt-delete is free but delete is thrust revers and skyop also has a ctrl-delete
as thrust reverse arm. alt-insert doesn't have any other association that I have found.)

The effect of hitting this new key in a Generic A/P plane or a Bravo A/P like plane is
that if the keyboard is not doing what you expect it to, hit the toggle and try again.

One new key not currently being used. One line of text in a dialog added and a character
added to any other effected key in that dialog ( '*' ).
One action taken by a user that has the one-size-fits-all effect, and we don't have to
lose anything we have gained. -- I think. You?

--Ray

post edit: "insert" is rudder left.

[clrCoda]

I forgot to mention that the other suggestion for this is to just add the toggle to any plane like the Bravo to toggle the Flight Director passive-mode, and revert the commit that broke the keyboard years ago, and worry about any other plane that was like the bravo that now needs to be fixed.

Possibly the best over all solution, but potentially the most upsetting for untold, undisclosed aircraft.

--Ray

[bugman]

I'm sorry that this appears to be taking me longer that we might have hoped.

Current reasonable excuse for delay is that some of the information I require to build the accurate history is at gitorious and according to them for the last week or more :

Gitorious.org is migrating all the repositories to Internet Archive.
The repositories will soon be available for read-only access, with original clone URLs preserved.

We all have -plenty- of time For this, I remember that someone has made a mirror of fgdata-old on one of the servers providing part of FlightGear's infrastructure (Martin maybe), but unfortunately I cannot find the link in the mailing list messages. You could ask on the list. I don't know how long it will take for fgdata-old to appear in the Internet Archive, it's a non-profit organisation and things move slowly. But using this secondary source for FlightGear's history would be useful.

I forgot to mention that the other suggestion for this is to just add the toggle to any plane like the Bravo to toggle the Flight Director passive-mode, and revert the commit that broke the keyboard years ago, and worry about any other plane that was like the bravo that now needs to be fixed.

Possibly the best over all solution, but potentially the most upsetting for untold, undisclosed aircraft.

I think that this would be the most acceptable solution, as it is the most correct. We have the control to fix any aircraft in the instable, in-development /trunk/ of the official aircraft hangar that are currently 'hacked' to work with commit 9856fdd4521b7ee29ff87d504476e231a2123612. And the active developers in the private hangars will be able to follow and quickly adapt to the proper and clean solution.

Regards,
Edward

[clrCoda]

Does Immatriculation, or rather those parts of aircraft that put our callsign on dash boards, on tails, and underwing still need to be only 6 characters.

I recall getting the DHC6-300 to show my entire callsign, but have forgotten how i accomplished this. Trying to get the AirCrane to do so and just changing the For loop in the immat.nas count from 6 to 7 doesn't seem to be enough. There is something else that needs to happen, and I've completely forgotten what that is.

If we can now show 7 characters then the limit of 6 might could be considered a bug unless MP is the problem, but I see 7 character labels in MP servers every day.

I believe this could be considered a paper cut bug and effects many planes.

[MIG29pilot]

Paper cut flying machines, you say?