DME improvements

[FGDATA]

Hi Yurik

OrangTiger from the forums reported:

I have a new Problem with the Tu-154b now and it might be similar to the one with the COMM Radio. This time it's the DME, which is not working. The DME has three settings DME1-RSBN-DME2. In Mode >RSBN it shows the distance to the selected RSBN Reciever and this one works. But in Modes DME 1 >and 2 it should show the distance to the VOR-DME selected in NAV Radio 1 and 2, but it only shows a >red line across the instrument as if the VOR is not in range, but it's definitly is. I thought maybe there is a fix for this problem, like the one with the COMM Radio. If not I will post the >Problem in the Forum, or do you know someone, who could help me with that?

And then he edited the instruments.nas file as a suggested fix

This pull request adds his suggestions for evaluation

Thanks IH-COL

[kroki]

Hi there,

If I understand the patch correctly then seems to be wrong: it ties DME to VOR, whereas in Tu-154B2 (unlike many other ACs) those are separate devices. Two DME receivers have their own power switches and their own frequency settings, separate from those of VOR receivers (look for "DME" signs in the middle of overhead panel).

[DestroyFX]

The DME is fine.

On this plane it's not tied to the VOR receiver with is a good thing as you can see two other DME distance while using a different VOR :)

[FGDATA]

Thanks for the info Mathieu. I will revert the changes, then

IH-COL

On Mon, Aug 17, 2015 at 2:02 PM, Mathieu Bélanger notifications@github.com wrote:

The DME is fine.

On this plane it's not tied to the VOR receiver with is a good thing as you can see two other DME distance while using a different VOR :)

— Reply to this email directly or view it on GitHub https://github.com/yuriknsk/tu154b/pull/22#issuecomment-131960407.

[FGDATA]

Hi. This pull request now only intend to keep the repos synced. There will be no change on the codebase anymore.

Thanks to Kroki and DestroyFX for their critical review.

IH-COL

[kroki]

IH-COL, FYI (if you haven't seen the other thread): Yurik said he is on vacation and will be able to merge in about 3 weeks from now.

Just curious: I kinda understand why you may want to periodically null-merge this repo to FGData (though I'm not quite sure, perhaps it's time for me to re-read the ProGit book). But I'm even less sure why you request periodic null-merges the other way. When you have a spare moment could you please drop a message or a link here for elaboration? Thanks in advance :)

[FGDATA]

Hi Kroki yes I read about Yurik returning soon

About the pull requests

When a pull request comes with zero changes, all it is trying to do is sync the repos. In human terms it means that every repo is an identical copy of each other; including to the commit log lists. Example, in this case, my master branch has the DME test by OrangeTiger, which later was fully reverted, making my master have 3 additional commits, yet zero changes over the final code.

By syncing, It facilitates further merges from other forks/branches as fast-forwards. A fast forward is a merge that just rebases the new commits and make identical repos without creating additional merge commits. And in Github, the forks say "this branch is even with the repo master branch" as an example. This is the best guarantee that the content is really identical (no need to diff the contents to verify, per example)

If the repo contains, as an example no changes or differences, but it contains additional commits, which are typically, but not limited to, not fast forward merges, then github reports, as an example, "this branch is 3 commits ahead of the repo master branch". Sometimes this solely reffers to the merge commits. Other times it does imply that code is really different.

---

https://github.com/FGMEMBERS/tu154b

A more inclusive commit list is also convenient in the sense that it tracks all possible historical attempts and it is great to revise (with different methods) the code history. So adding commits such as the DME attempt that gets eventually reverted, while not affecting the code base, it does provide additional valuable test/assestment information that will be there for future developers.

Besides, due to all FGMEMBERS repositories to be used in FGDATA next with submodules, force updates in the master branch is an absolute no-no, since it can break the clones of other users. So I cannot sync by just deleting commits. I need to sync by pulling requests which, like in this case could be finally an empty commit.

Finally, other merges coming from the FGMEMBERS that can be empty are SVN syncs. Basically, you may/may not be aware, but FGMEMBERS repo fetch automatically the FGADDon corresponding repository in a weekly basis. This to track changes made by people isolated in that development sandbox. Example, let's say James Turner add some one liner to the code. We don't worry about it, because my script will bring that code to the Github area, and then pull requesting from FGMEMBERS will update the upstream repo (like yurik's). [advantages of being synced are huge].

But let's assume that last commits to SVN where just updating the SVN to be identical to the content in github. (Soitanen has done it like in d93e7646963a03ae9bc7aaf47fb8eca67cbed035). So when the SVN gets merged to FGMEMBERS there will be a commit coming from SVN --soitanen's SVN commit, then a merge commit that will be empty, due to the fact that the code is identical!. When I try to sync, you guys will see in such case that a pull request comes empty -- no changes in the code!, but it will bring commits made on SVN, and it will contain the whole SVN history log as well.

I hope it clarifies,

Best, IAHM-COL

[kroki]

Hi IAHM-COL,

Thanks for detailed elaboration. Now I see that there was a mistake in my question. By null-merge I meant not simply a merge that resolves in zero changes, but a merge that ignores changes in the source branch. I.e. if we have repos R1 and R2 that are merged, and then you make a commit A to R1 that you do not want to propagate to R2 you do a null merge from R1 to R2 with git merge --strategy=ours. Then the repos appear to be synched, yet R2 won't ever have the commit A. So I wondered what are the changes in FGData's repo that should not propagate to Yurik's.

So this pull request is not a null-merge (it doesn't ignore upstream changes, it just happens that cumulative change is void), and I looked through your previous requests and now see that none of them was a null-merge either, which makes my question irrelevant.

Thanks again!