Board index FlightGear Development Aircraft

DHC-6 Twin Otter development

Questions and discussion about creating aircraft. Flight dynamics, 3d models, cockpits, systems, animation, textures.

Re: DHC-6 Twin Otter development

Postby legoboyvdlp » Wed Jan 02, 2019 11:34 pm

Hi,
If you want fixes to be available to all users through the launcher and flightgear.org downloads (and FGMEMBERS will pull the changes from fgadon) then the best way is to write to the flightgear-devel mailing list and ask for the maintainer to add your changes.
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: DHC-6 Twin Otter development

Postby mathieugouin » Fri Jan 04, 2019 3:57 am

Thanks I did that. Waiting for an answer...
Mathieu
mathieugouin
 
Posts: 36
Joined: Thu Jan 06, 2011 4:37 am
Location: CYHU
Callsign: MGOUIN
Version: V2018.1.1
OS: Lubuntu 18.04

Re: DHC-6 Twin Otter development

Postby bugman » Fri Jan 04, 2019 2:23 pm

As mentioned on the list, please see the FGAddon wiki article. Have a look at the section:


As for the FGMEMBERS fork, please note the official FlightGear statement on FGMEMBERS.

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: DHC-6 Twin Otter development

Postby mathieugouin » Sat Jan 05, 2019 3:48 pm

Hello,

I have corrected as best as I thought the following list of issues: https://github.com/mathieugouin/dhc6/is ... s%3Aclosed

They are pushed in https://github.com/mathieugouin/dhc6

Could anyone with sufficient knowledge of the DHC-6 code performs a sanity check and integrate the fixes?

I read the statement related to the FGMEMBERS and hopefully this will not be considered a "hostile fork"... I just wanted to easily make my changes available to be re-integrated in the code base, if you guys decide they are worth it.

If there is anything, let me know and thanks in advance!
Mathieu
Mathieu
mathieugouin
 
Posts: 36
Joined: Thu Jan 06, 2011 4:37 am
Location: CYHU
Callsign: MGOUIN
Version: V2018.1.1
OS: Lubuntu 18.04

Re: DHC-6 Twin Otter development

Postby tdammers » Sun Jan 06, 2019 3:14 pm

I don't know about the rest of the folks here, but personally, I think the whole "hostile fork" narrative is nonsense, and so I prefer to ignore it and just happily do my thing. It's free software, do with it what you want. In any case, I'll take a look at your changes, and if I like them and upstream doesn't want them, then I'll still merge them into my fork.
tdammers
 
Posts: 391
Joined: Wed Dec 13, 2017 11:35 am
Callsign: NL256
IRC name: nl256

Re: DHC-6 Twin Otter development

Postby bugman » Mon Jan 07, 2019 9:51 am

People are directed to the FGMEMBERS statement when they have questions about it. This is standard, and it is the official position of the FlightGear project. What is important is to read the FGAddon wiki article. Specifically all of the details explaining how to develop and improve aircraft in a collaborative fashion. Let me quote the first part of the Aircraft development section:

Contact the original aircraft authors

The first step for developing and advancing the aircraft of the official FlightGear hangar, or from one of the private hangars for that matter, is to make contact with the original aircraft author(s). Their names can be found within the *-set.xml file, within the <authors> XML tag. Often the contact email address will be listed in a README file or some other text file in the base aircraft directory. If not, contact can sometimes be established via the FlightGear development mailing list. Contacting the original authors is important to see if the aircraft is currently being actively developed, and if you can join in as part of the development team.


The FGAddon article is also translated into a number of languages. Here are the equivalent Aircraft development sections:


Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: DHC-6 Twin Otter development

Postby bugman » Mon Jan 07, 2019 11:40 am

You can also find author and other information about this recently updated aircraft on its wiki page:

Image

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: DHC-6 Twin Otter development

Postby Octal450 » Mon Jan 07, 2019 6:24 pm

Nonsense, you don't need FGAddon to collaborate. I do all my projects in my GitHub and collaboration is easy.

It really doesn't matter where you do it, as long as everyone is using the same platform (ie, GitHub vs gitlab, or git vs svn) it's extremely easy to collab.

Kind Regards,
Josh
Skillset: JSBsim Flight Dynamics, Systems, Canvas, Autoflight/Control, Instrumentation, Animations
Aircraft: A320-family, MD-11, MD-80, Contribs in a few others

Octal450's GitHub|Launcher Catalog
|Airbus Dev Discord|Octal450 Hangar Dev Discord
User avatar
Octal450
 
Posts: 5583
Joined: Tue Oct 06, 2015 1:51 pm
Location: Huntsville, AL
Callsign: WTF411
Version: next
OS: Windows 11

Re: DHC-6 Twin Otter development

Postby bugman » Mon Jan 07, 2019 7:49 pm

I am talking about the FGAddon wiki article where it explains how to collaborate. Sure you can start your own githib/gitlab/bb/sf/savannah/etc. git project as you wish. But if you never bother contacting the original authors, you may never find out about any active, or ready to be reactivated, development teams (IDG included).

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: DHC-6 Twin Otter development

Postby wlbragg » Mon Jan 07, 2019 7:58 pm

Josh, you know I would never argue with you without reason.

Nonsense, you don't need FGAddon to collaborate. I do all my projects in my GitHub and collaboration is easy.


I've been following this thread and I didn't get this out of any of the comments.

As you know the only default aircraft that is packaged with FG is "currently" a collaboration of folks preferring GitHub. It is then ported manually to the FG repository fgdata when a new release is on the horizon. The J3Cub as well as others I work on are done the same way with the exception that I also use a svn link to SourceForge fgaddon to transfer updates when ready. Because of my lack of knowledge I have to manually transfer updated files from my local git repo to my local svn repo first.
I don't exactly know how the Shuttle is set up but I do know I am using a local git repo to push to a svn-git repo on SourceForge when I do work on it.
Thorsten is the one who takes care of the magic of getting the releases to fgaddon.

So your statement is correct, but the implied tone behind it is something I don't understand. I have noticed as of late that fgmembers is not being updated as it once was. I know this for fact because I noticed changes I have made to numerous aircraft are not being forwarded into fgmembers in a timely fashion if at all. There may be good cause that I am not aware of but it is what I have noticed none the less.

Something else that I am extremely frustrated with is when I see aircraft changes to fgmemeber forks that never make it into fgaddon duplicate aircraft, as there was never any agreement on how to make that happen.
Simple fact of the matter is the way in which fgmembers was originated and managed, without comprise on both sides. It left a fractured society and is now responsible for many aircraft updates not getting into fgaddon. Fgaddon is the defacto repository managed by the FG organization and I think it should have the most up to date aircraft available, period.
Other, non-hostile, hangers don't try to duplicate aircraft repositories controlled by the FG organization. I say "controlled" loosely as the organization is only interested in a central repository overseen by the organization to allow for all aircraft to continue at least the basic updates to be able to run with new versions of the simulator.
Other non-hostile hangers don't work on aircraft that are also provided in fgmembers without periodically making their contributions back into fgaddon.
Other, non-hostile, hangers don't have a separate website with a section solely for the purpose of denigrating members in good standing of the FG organization. They try to work with the rest of the organization VS fighting with it.

I like the idea of a central location where you could go to get every GPL aircraft ever made, but that is a huge task to keep it organized and not competing with what the FG organization is trying to achieve. In the case of fgmembers its concept, while admiral, turned into a political "hostile" fork which in my opinion left a fractured, worse off infrastructure to everyones cause.

It is nothing but confusion for me and I know how it originated and how it works. I can only imagine the confusion of a new user of FG that comes along.

It's a fact, a couple people with less standing in the organization disagreed with several people, with maybe a little better standing in the organization, and refused to cooperate with a consensus and decided to do their own thing without regard to the negative side effects it could have on the organization as a whole.

Sad thing really! I wish it had turned out differently.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: DHC-6 Twin Otter development

Postby wkitty42 » Mon Jan 07, 2019 8:48 pm

wlbragg wrote in Mon Jan 07, 2019 7:58 pm:Something else that I am extremely frustrated with is when I see aircraft changes to fgmemeber forks that never make it into fgaddon duplicate aircraft, as there was never any agreement on how to make that happen.

but there is a way that has already been set and is used all the time... see above ;)
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: DHC-6 Twin Otter development

Postby wlbragg » Mon Jan 07, 2019 8:58 pm

The fact is it is not being done in many cases. Probably mostly with developers that don't know (a problem in my opinion) or don't care (is what it is)!
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: DHC-6 Twin Otter development

Postby wlbragg » Mon Jan 07, 2019 9:30 pm

I apologize to the DHC-6 developers, past, present and future for derailing this thread. Maybe a moderator could clean it up if it goes any farther.

My reason for a reply was out of continuing frustration that the infrastructure isn't perfect and the division is so deep. It's hard enough to get volunteer work and new development going without a fractured society.

I've always believed communication could solve most issues, but in this case it just seems to continue pushing the division.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: DHC-6 Twin Otter development

Postby Richard » Tue Jan 08, 2019 1:04 am

wlbragg wrote in Mon Jan 07, 2019 7:58 pm:Josh, you know I would never argue with you without reason.

Nonsense, you don't need FGAddon to collaborate. I do all my projects in my GitHub and collaboration is easy.




In my opinion Josh is right in what he said; possibly it would be better to have added "provided that you collaborate your changes back to FGAddon when they're ready"

The Shuttle is a good example of how to effectively use another repository to collaborate in a way that works with FGAddon. The master for the Shuttle is a git repository where all the work is done by various contributors and then it gets merged into FGAddon when it is decided that a release is ready; so FGAddon is always the definitive release version. I do the same for the F-15 and F-14 and so do lots of other developers/teams.

The problem to avoid is modifying forked repositories that aren't the master as this will lead to lost work from FGAddon.
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: DHC-6 Twin Otter development

Postby Thorsten » Tue Jan 08, 2019 7:45 am

As fond as I am of debating fundamental issues, I think that misses the point here.

mathieugouin wants to contribute to FGAddon. He's been asking on the mailing list and in the right thread. The step that should have happened by now is that the maintainer (dg-505 if I read the thread right) should have chimed in and told us what works best.

Unfortunately that hasn't happened, and I don't know offhand why.

Of course people aren't always around (the forum says he was last seen June 2018) and we don't require them to.

So the thing that needs to be happening now is that we strike a reasonable balance between respecting the plans of the maintainer and preserving the enthusiasm of a new collaborator.

May I suggest the following procedure:

* mathieugouin tries to contact DG-505 via the forum email function directly
* if there is no response after a reasonable time, someone else with commit rights takes a look at the patches and merges them [1]
* if they are in good shape, we aim at giving mathieugouin commit rights to FGAddon 'soon'

[1] Since I believe that is what needs to happen, I'll take it on my conscience to do it, though I have plenty of stuff to do and would not be unhappy if there's another volunteer
Last edited by Thorsten on Tue Jan 08, 2019 9:54 am, edited 1 time in total.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

PreviousNext

Return to Aircraft

Who is online

Users browsing this forum: No registered users and 14 guests