Board index FlightGear Development Aircraft Cockpit development

The always great C172p cockpit improvement!!

Discussion about creating 2d and 3d cockpits.

Re: The always great C172p cockpit improvement!!

Postby HHS » Thu Dec 02, 2010 8:38 pm

horacio wrote:
isix wrote:HHS, I´m curious, can you talk more about this affirmation, please :

Me too are interested in to understand better this sentence.


Just read through this: http://wiki.flightgear.org/index.php/Howto:_Improve_Framerates -->3D Models:
Contrary to what many people believe, the impact of high vertex-count models on framerate is fairly minimal. In addition, for graphics hardware built after 2004 and intended for games (example: Nvidia GeForce 6 series), textures are close to, or completely, free.

I used a very long time a GeForce 5200- even at its time the cheapest one. 15-25 fps was normal for me. But even with a 760000 vertice-count model I had no decrease in fps. But of course the model-size in kb or Mb will be much bigger, and that will give problems on mp. This can be solved with an own, cheaper AI-model, which will be called up over mp.
Up, up and away
User avatar
HHS
Retired
 
Posts: 3624
Joined: Thu Jul 19, 2007 8:09 am
Version: GIT

Re: The always great C172p cockpit improvement!!

Postby horacio » Thu Dec 02, 2010 11:26 pm

HHS wrote:Just read through this: http://wiki.flightgear.org/index.php/Ho ... Framerates -->3D Models:


I have just read it some hours before you posted it. I thought you were meaning something else, because you said "There is the advantage of FlightGear".... when I was precisely talking about advantage from FS over FG... so there is no advantage of anyone. Both are in same status of performance.

HHS wrote:The 3d-work of the panel was done by me, just using a lot of pictures from the net as reference. Unfortunately I found a manual with image of this panel very much later....I didn't have access to the real aircraft, so a lot was just guessing. I planned to go on, but after I found out that touching a Default Aircraft in FGFS is a bad thing, I stopped and concentrated on my own work.


I haven't commented on this, but if so, you did a great job!!! I like a lot your panel. It has needed not change at all. I only have re texture it.

But... why you said that touching a default aircraft in FG is bad? so you said there is something bad in my work? It's important for me to know. You have a lot of extra experience to me.

I've thought that precisely default aircraft was the first on the list to be at top status of development (in this case, graphically). They are the first face on the air that every new user look in FG, right?. That is part of my criticism to organization in FG. I always think that first things are... first. Everything else is after. All default aircraft in FG most be finished at its best posibilities of development, before leave free way to develop other ones. Have you seen how many cockpit are on top status on Thorsten rating proposal? only 4, and only 2 of them are on default 2.0 package.
HORACIO CONTRERAS
El Hangar de Horacio
... ¿y dónde está el Teniente Bello?
_____________________________________________________________________________
Vive FlightGear! Have you a Ñ on your keyboard? Spain-LatinAmerica FlightGear community!
User avatar
horacio
 
Posts: 145
Joined: Wed Sep 29, 2010 5:06 am
Location: SCVM, Chile
Callsign: CC-HCR
Version: 2
OS: Windows 7

Re: The always great C172p cockpit improvement!!

Postby adrian » Mon Dec 06, 2010 4:09 pm

Touching default aircraft is not bad, it's actually very good as long as it's an improvement :)
Excellent work on the Cessna, keep it up!
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 2:15 pm

Re: The always great C172p cockpit improvement!!

Postby horacio » Thu Dec 09, 2010 1:16 am

Thanks a lot, Yoyo.

Looking at the fact that will cannot do any consistent progress on the C172P until after new year, I offer as an in advance christmas gift, a first release for my work.

Changes at the moment:

* Complete re texture of panel, and some parts of cockpit and chassis.
* All instruments contained on "c172P/Instruments" for its further modifications.
* Glass effect on main frontal window.
* 2 new views added: Co-pilot and Passenger.

For to do:

* Re texture of all instruments.
* Correct some still unfinished mapping on actual cockpit textures, and complete still missing ones.
* New better resolution and pretty design of default livery.

The link to download, as always at my hangar:
http://www.grafikavirtual.com/fgfs/?sec=aviones.php

Once again, as happened with the Bo-105, I have already contact to David Megginson, but still no answer. It seems to be a constant...??? I hope don't. Not because its my work, but I think that FG deserves a cockpit like mine on its default aircraft....

I hope you enjoy it, and make any helpful comment before it is completely finished.

Best regards
HORACIO
HORACIO CONTRERAS
El Hangar de Horacio
... ¿y dónde está el Teniente Bello?
_____________________________________________________________________________
Vive FlightGear! Have you a Ñ on your keyboard? Spain-LatinAmerica FlightGear community!
User avatar
horacio
 
Posts: 145
Joined: Wed Sep 29, 2010 5:06 am
Location: SCVM, Chile
Callsign: CC-HCR
Version: 2
OS: Windows 7

Re: The always great C172p cockpit improvement!!

Postby Avionyx » Thu Dec 09, 2010 8:24 am

Thanks a lot Horacio!

Got this downloading now and looking forward to doing a flight later, I will be sure to post some screenshots in the media forum this afternoon.

Really absolutely beautiful work, thanks once more.

Alex
Avionyx
 
Posts: 439
Joined: Mon Jan 11, 2010 3:07 pm
Location: EGKA
Callsign: G-AVYX
Version: GIT
OS: Arch

Re: The always great C172p cockpit improvement!!

Postby wrg » Thu Dec 09, 2010 8:56 am

Unfortunately in your model snow from a cabin isn't visible through a windshield
http://www.mediafire.com/?ac9zbtae7247884
scenery of Russia updated 20 Jul 2015 https://github.com/soitanen/Project-Russia
wrg
 
Posts: 79
Joined: Mon Dec 06, 2010 11:46 am
Location: ULLI Saint-Petersburg
Callsign: R-wrg
IRC name: fibs
Version: 2018.4.0
OS: Debian GNU/Linux

Re: The always great C172p cockpit improvement!!

Postby stuart » Thu Dec 09, 2010 9:19 am

Hi Horacio,

I'm the current maintainer of the c172p. Thanks very much for your work on it.

horacio wrote:Thanks a lot, Yoyo.

Looking at the fact that will cannot do any consistent progress on the C172P until after new year, I offer as an in advance christmas gift, a first release for my work.

Changes at the moment:

* Complete re texture of panel, and some parts of cockpit and chassis.
* All instruments contained on "c172P/Instruments" for its further modifications.
* Glass effect on main frontal window.
* 2 new views added: Co-pilot and Passenger.


This sounds good, with the exception of putting all the instruments in c172p/Instruments. Where possible, we put instruments in Aircraft/Instruments-3D/, so they can be used by lots of different aircraft. Is there a particular reason you've moved them?

Can I also check that you are using the latest version of the c172p - the one that is in git? I've made some improvements to the model myself since the last release, so you should work with the latest development version.

horacio wrote:Once again, as happened with the Bo-105, I have already contact to David Megginson, but still no answer. It seems to be a constant...??? I hope don't. Not because its my work, but I think that FG deserves a cockpit like mine on its default aircraft....


I am the current maintainer of the c172p. If you could use GIT and generate a merge request, I'll take a look at integrating your changes

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1491
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: The always great C172p cockpit improvement!!

Postby horacio » Thu Dec 09, 2010 12:20 pm

wrg wrote:Unfortunately in your model snow from a cabin isn't visible through a windshield
http://www.mediafire.com/?ac9zbtae7247884


Uh, right!! I have already notice the same issue with blades animation and dust on the ground on BO-105, which I added glass effect too. I think it's problem of incompatibility of transparencies due to normals in aircrfat model and PNGs used for snow, blades or whathever (I supose will happen the same with rain, I will check). I think will need to remove those effects, at least while there were no possibility to see any external animation that include transparencies of PNGs at the moment.

The only great doubt I have (and if someone could know the reason) is that on BO the glass effect is applied to all windows, but the issue to don't see animations only happen in frontal window. Through lateral ones it's still possible to see those effects. Any ideas....???????????

stuart wrote:I'm the current maintainer of the c172p. Thanks very much for your work on it....

...This sounds good, with the exception of putting all the instruments in c172p/Instruments. Where possible, we put instruments in Aircraft/Instruments-3D/, so they can be used by lots of different aircraft. Is there a particular reason you've moved them?


First of all, thanks a lot for to answer. About instruments...have you ever seen my BO-105 cockpit development? I have modified every single instrument on it, resizing, adding some brights and shadows, socket textures, and specially, because modified all the original main images, adding better contrast, better resolution and adding glass reflection effect on them. So, the same as will do on the C172, I preffer to leave untouched original FG instruments to don't affect all the other aircrafts that share those instruments with C172, and only make modifications to that which will be used on the current model.

About GIT, I don't use it by some reasons. 1st, I'm still almost new on FG, and I'm still learning a lot of things, so cannot do everything together and at the same time. I think right now would be good time to begining using it. But 2nd important one, at least as far as I know, by downloading GIT you need a lot of space (near 2 GB??) only for aircrafts, due to have included every airplane which is currently developed and accepted to GIT. So, I don't have that space (I'm musical producer and need really a lot of space due to great weight of audio files, and I'm currently on top of space) , and I don't want all those aircrafts that will never use, and even see on screen.

Perhaps I'm sin of ignorance, but I still cannot find enough clarifying information about what GIT is, and olny for what I read here and there, I don't see it as a good option of development and for developers, and sounds me as a really uncomfortable tool, and I'm totally averse to download and install anything that don't convinces me to use.

Perhaps you can give me good reason to use it, and convince me to do that. :wink:

HORACIO
HORACIO CONTRERAS
El Hangar de Horacio
... ¿y dónde está el Teniente Bello?
_____________________________________________________________________________
Vive FlightGear! Have you a Ñ on your keyboard? Spain-LatinAmerica FlightGear community!
User avatar
horacio
 
Posts: 145
Joined: Wed Sep 29, 2010 5:06 am
Location: SCVM, Chile
Callsign: CC-HCR
Version: 2
OS: Windows 7

Re: The always great C172p cockpit improvement!!

Postby f-ojac » Thu Dec 09, 2010 5:07 pm

Hi Horacio,

Very very nice work, as the one you did on the Bo105. I hope they both find their way into FG sometimes, I think FG deserves it, especially for default aircrafts/helos.

Concerning GIT, sure it would be easier if you could you it. However, You certainly don't need to download ALL aircrafts to work on one or two of them. Maybe you should see what has been done on other aircrafts : they use a separate git directory and - AFAI understood, put merge requests when everything is ok.

Keep on!
Hosting terrasync, World Scenery, TGWeb on my own private server. Click here to donate and help to make the service last.
f-ojac
 
Posts: 1285
Joined: Fri Mar 07, 2008 9:50 am
Version: GIT
OS: GNU/Linux

Re: The always great C172p cockpit improvement!!

Postby boeing 787-8 » Thu Dec 09, 2010 5:15 pm

Fantastic :shock:
I Don´t know where we will take all of this, but I assure you it will be fun. (Orville Wright, 1903).

Welcome to my blog! http://fgfsliveries.blogspot.com
User avatar
boeing 787-8
 
Posts: 252
Joined: Tue Aug 17, 2010 10:06 am
Location: Granada (LEGR) (Spain)
Callsign: EC-BOE
Version: 2
OS: Windows XP PRO SP3

Re: The always great C172p cockpit improvement!!

Postby hvengel » Thu Dec 09, 2010 5:40 pm

horacio wrote:
stuart wrote:I'm the current maintainer of the c172p. Thanks very much for your work on it....

...This sounds good, with the exception of putting all the instruments in c172p/Instruments. Where possible, we put instruments in Aircraft/Instruments-3D/, so they can be used by lots of different aircraft. Is there a particular reason you've moved them?


...

About GIT, I don't use it by some reasons. 1st, I'm still almost new on FG, and I'm still learning a lot of things, so cannot do everything together and at the same time. I think right now would be good time to begining using it. But 2nd important one, at least as far as I know, by downloading GIT you need a lot of space (near 2 GB??) only for aircrafts, due to have included every airplane which is currently developed and accepted to GIT. So, I don't have that space (I'm musical producer and need really a lot of space due to great weight of audio files, and I'm currently on top of space) , and I don't want all those aircrafts that will never use, and even see on screen.

Perhaps I'm sin of ignorance, but I still cannot find enough clarifying information about what GIT is, and olny for what I read here and there, I don't see it as a good option of development and for developers, and sounds me as a really uncomfortable tool, and I'm totally averse to download and install anything that don't convinces me to use.

Perhaps you can give me good reason to use it, and convince me to do that. :wink:

HORACIO


Actually GIT is a huge help for developers. It's main purpose it to help developers work together and to help manage change and it does this very well. For example it you had used GIT your changes would be very easy to integrate into fgdata. Instead by not using GIT it will be more work to get your work integrated (not impossible just more work). But you are correct that fgdata is large and there is definitely a learning curve to source code management processes and to GIT. For those with a programming background these are, at most, small issues but for non-programmers learning GIT and source code management processes is a significant undertaking. In the end if you want to maximize the impact of your work you will want to use GIT.

I have been working on improving the p51d (IE. the jsbsim version) and have had two very large change sets integrated into the fgdata main line. I used GIT and the process of getting these changes into FG has been very easy because of GIT. By the way I would love for you to do the same sort of thing for the p51d-jsbsim cockpit. If you are interested please let me know.
hvengel
Retired
 
Posts: 1128
Joined: Sun Dec 24, 2006 4:35 am
Location: Minden Nevada

Re: The always great C172p cockpit improvement!!

Postby horacio » Fri Dec 10, 2010 1:50 am

hvengel wrote:By the way I would love for you to do the same sort of thing for the p51d-jsbsim cockpit. If you are interested please let me know.


Of course I could be interested. I would love to see every single cockpit in FG in such a similar status of development. I think that more than external graphics, this is one of the first impression of shortcomings the first time in FG in comparison to other good graphically developed flight simulators.

It's just that I already have a little list of planes to do: finish my own work on BO-105 and C172, following by B777-200ER, and after help for already external requests as the Dromader (by El Flauta) and AH-1 by Jack.

If no other do any cockpit work on p15d before this, you can be sure I could be ready to work on it.

hvengel wrote:Actually GIT is a huge help for developers. It's main purpose it to help developers work together and to help manage change and it does this very well. For example it you had used GIT your changes would be very easy to integrate into fgdata. Instead by not using GIT it will be more work to get your work integrated (not impossible just more work). But you are correct that fgdata is large and there is definitely a learning curve to source code management processes and to GIT. For those with a programming background these are, at most, small issues but for non-programmers learning GIT and source code management processes is a significant undertaking. In the end if you want to maximize the impact of your work you will want to use GIT.


After reading your post and olivier.jacq's one, I have read all the topics specially dedicated to GIT on Support section. I think now I have a good understanding on what about it. Ithought that the answer posted by richter in one of them is the better I was ever looking for:

richter wrote:When people talk about the "GIT version" and "building from GIT" and "put it in GIT", they are referring simply to the development version of FlightGear, which differs from the release version. Git is just the software that manages/hosts the source code on a server and allows users to download the latest development version.

And I for one wish everyone would just call it the development version (as does practically every other software project), instead of the pointlessly confusing "GIT"! A year ago the development version was called "CVS" and people were confused as to "what's CVS?", and in another five years I bet the project will migrate to some newer version control system and people will be asking "What's Snarfle? Is is some special version? It it a program I have to install?"


That's the reason why many new users, like me, are so confused in what about GIT is, and have wrong impressions of it. Besides this, I have read the little list of drawbacks detailed by Groucho:

Groucho wrote: * There is no officicial support. If something does not run as expected, you are on your own
* The code does not come as binary setup, you will have to build and make it run on your own. However some people are providing nightly builds for most platforms
* There is no guarantee, that everything fits together. Changes are frequent and might break things which were running last week
* You propably loose compatibility with the released binary

On the plus side: You get the bleeding shiny features lots of people are talking about but which are not officially available yet.
How to use the development version can be found in the FlightGear wiki.

To summarize: If you are primarily out for flying, stay with the released binaries and wait for releases. That way you can be sure to be on the safe side of flying and always have a running version.


Therefore, as the same is so simple to understand, the same is so simple to make a desicion about to using it or don't. I'm first a user, and after a developer. I'm on FG because love to fly, and in its absence, to simulate flying. I like to start my PC, run FGrun and to fly. I'm not ready yet to do constantly changes or need to apply new changes from GIT to fly, or to see something working yestarday and today don't. I have already enough deficiencies on my small and not powerful PC to having new problems to solve every time.

If I am not reading wrong on topics I've quoted, then I said it again: I find that GIT is not a good and a easy choice for development. I still cannot understand why that way of development. Like who likes: FG should be distributed in defined working teams, with defined goals to reach by each team, and every new user or developer that want to join to contributions on FG, adheres to one of those teams, and work in that area, and every time to time official releases includes every new improvement previously developed by each team. Nobody needs wheather development, when testing cockpit textures development. So, why to see every new development on GIT, to may test your own ones? Better works in the world are doing by teams (many hands working together), not by single persons working alone. But still better works are done when every single team may work without interferences of the other ones, and if wheater development interferes on my work, then I cannot work properly on graphic cockpit development. That's my opinion.

At least for a while I will not move to GIT, so I kindly request to any kind user of GIT that would want put a merge request for my works (both BO-105 and C172P), I would be thankful. If not, both of them are available on my hangar to anybody want them.

Thanks to every possitive posts and congratulations.

HORACIO
HORACIO CONTRERAS
El Hangar de Horacio
... ¿y dónde está el Teniente Bello?
_____________________________________________________________________________
Vive FlightGear! Have you a Ñ on your keyboard? Spain-LatinAmerica FlightGear community!
User avatar
horacio
 
Posts: 145
Joined: Wed Sep 29, 2010 5:06 am
Location: SCVM, Chile
Callsign: CC-HCR
Version: 2
OS: Windows 7

Re: The always great C172p cockpit improvement!!

Postby stuart » Fri Dec 10, 2010 11:40 am

horacio wrote:If I am not reading wrong on topics I've quoted, then I said it again: I find that GIT is not a good and a easy choice for development. I still cannot understand why that way of development. Like who likes: FG should be distributed in defined working teams, with defined goals to reach by each team, and every new user or developer that want to join to contributions on FG, adheres to one of those teams, and work in that area, and every time to time official releases includes every new improvement previously developed by each team.


Leaving aside the organization aspect of this, there is an interdependence between the source code of the simulator and the aircraft themselves that makes it important to keep up to date. v1.9.1 aircraft generally do not work with v2.0.0.

The existing situation of having a single GIT repository evolved from the early stages of the project when there were only a few aircraft. There is work underway at present to allow the aircraft to be split from the rest of the data to resolve this.

However, there are some advantages to a single repository, particularly if making changes that need to affect a large number of aircraft. For example, we recently retired a very old implementation of the HUD. By having a single repository it was very straightforward to determine which aircraft were affected and fix them.

horacio wrote:Nobody needs wheather development, when testing cockpit textures development. So, why to see every new development on GIT, to may test your own ones? Better works in the world are doing by teams (many hands working together), not by single persons working alone. But still better works are done when every single team may work without interferences of the other ones, and if wheater development interferes on my work, then I cannot work properly on graphic cockpit development. That's my opinion.


While you might not need weather development for re-texturing, changes to the FDM model, or the generic systems modelling do affect aircraft and need to be considered. Otherwise when the next release comes out, you may discover that your plane won't fly!

It is therefore important that aircraft developers keep close to the development version of the software, by using GIT.

Note also that if there are multiple people working on the same aircraft (as is the case with the c172p), you need some way to coordinate their changes. GIT provides a sensible way to do this.

horacio wrote:At least for a while I will not move to GIT, so I kindly request to any kind user of GIT that would want put a merge request for my works (both BO-105 and C172P), I would be thankful. If not, both of them are available on my hangar to anybody want them.


If I have time (unlikely with a 12 week baby to look after), I may merge your c172p changes into GIT. I don't know enough about the BO-105 to merge them successfully.

You should realize that this is going to take significantly longer for me to do than it would if you were using GIT as I'll have to manually merge your changes with any others that have taken place since the last release. There is a high likelihood that I won't have time to do so before the next release (currently due at the end of the year).

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1491
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: The always great C172p cockpit improvement!!

Postby hvengel » Fri Dec 10, 2010 7:22 pm

stuart wrote:
horacio wrote:If I am not reading wrong on topics I've quoted, then I said it again: I find that GIT is not a good and a easy choice for development. I still cannot understand why that way of development. Like who likes: FG should be distributed in defined working teams, with defined goals to reach by each team, and every new user or developer that want to join to contributions on FG, adheres to one of those teams, and work in that area, and every time to time official releases includes every new improvement previously developed by each team.


Leaving aside the organization aspect of this, there is an interdependence between the source code of the simulator and the aircraft themselves that makes it important to keep up to date. v1.9.1 aircraft generally do not work with v2.0.0.


In fact at least some models in GIT need recent GIT only features to work fully. The p51d-jsbsim is an example of this. In addition I recently had to make a number of changes in the FDM to sync things up with a recent JSBSim update to GIT. In many cases changes in GIT will not affect things like better cockpit textures and the other cockpit work being done by Horacio but the only way to be sure is to sync your system to GIT and test before requesting a GIT merge. In cases where the work is primarily cosmetic in nature you would likely not need to do GIT updates to other fg systems (simgear, fgfs...) very often. In fact I only do an update to the whole FG system when I am about to request a GIT merge so that I can do final testing to make sure things will work with the latest code. But I am also doing lots of FDM work and this is probably overkill for cosmetic work like cockpit texturing.

stuart wrote:The existing situation of having a single GIT repository evolved from the early stages of the project when there were only a few aircraft. There is work underway at present to allow the aircraft to be split from the rest of the data to resolve this.

However, there are some advantages to a single repository, particularly if making changes that need to affect a large number of aircraft. For example, we recently retired a very old implementation of the HUD. By having a single repository it was very straightforward to determine which aircraft were affected and fix them.


It appears that many users considering working on existing aircraft models have issues with the size of the fgdata GIT download as well as the learning curve for a new tool/process. An fgdata clone is huge and if you are working on a single aircraft it is clearly over kill. It would be nice to be able to make a GIT clone of a single aircraft directory tree since this would save huge amounts of space and download time. On my network connection (not very fast) it takes about 3 1/2 hours to get the first copy of fgdata. Of course updates are much faster as I updated my copy of fgdata yesterday and it took perhaps 5 minutes. My copy was about two weeks old when I updated it and there were about 1500 files changed during that time. In any case I am looking forward to having support for cloning individual aircraft directories. In part because it will make things easier for me but also because it will remove a major issue that is preventing some aircraft devs from using GIT.

stuart wrote:
horacio wrote:Nobody needs wheather development, when testing cockpit textures development. So, why to see every new development on GIT, to may test your own ones? Better works in the world are doing by teams (many hands working together), not by single persons working alone. But still better works are done when every single team may work without interferences of the other ones, and if wheater development interferes on my work, then I cannot work properly on graphic cockpit development. That's my opinion.


While you might not need weather development for re-texturing, changes to the FDM model, or the generic systems modelling do affect aircraft and need to be considered. Otherwise when the next release comes out, you may discover that your plane won't fly!

It is therefore important that aircraft developers keep close to the development version of the software, by using GIT.

Note also that if there are multiple people working on the same aircraft (as is the case with the c172p), you need some way to coordinate their changes. GIT provides a sensible way to do this.


The last point is very important. If you are working on any model that has someone else (or a team of people) working on it it is very important that everyone keep things in sync with each other. With a source code management tool like GIT this is easy to do since the tool does the work as long as each dev does his/her part. In fact this is one of the primary functions of a tool like GIT since this allows for teams (from very small to very large) to work together in very efficient ways.

stuart wrote:
horacio wrote:At least for a while I will not move to GIT, so I kindly request to any kind user of GIT that would want put a merge request for my works (both BO-105 and C172P), I would be thankful. If not, both of them are available on my hangar to anybody want them.


If I have time (unlikely with a 12 week baby to look after), I may merge your c172p changes into GIT. I don't know enough about the BO-105 to merge them successfully.

You should realize that this is going to take significantly longer for me to do than it would if you were using GIT as I'll have to manually merge your changes with any others that have taken place since the last release. There is a high likelihood that I won't have time to do so before the next release (currently due at the end of the year).

-Stuart


This reinforces my point. if Horacio's work were done in GIT against a recent GIT clone then Stuart could do a test merge (this would only take a few minutes) and test it (might take a few hours or a few minutes depending on what was changed). If the merge didn't cause any issue he could then merge this into the code main line. The whole process might take at most a few hours most of which would be to test the merge. In stead he will have to hand merge the changes and this will likely takes days of effort. Not impossible but way more work and perhaps way more error prone and it will also delay making this very nice work available as a standard part of FlightGear.

There is a lot of FUD being spread about GIT in various FG related forums. Almost all of this is being done my non-developers and most of it is based on misconceptions or misunderstandings. There is clearly a difference in the use case between someone using GIT to build/have that latest code and someone who is doing development work (aircraft or coding does not matter). For the first use case GIT adds significant complexity for very little gain. For the later case a tool like GIT actually makes things simpler and greatly facilitates the work being done (after getting over the learning curve).

Hal
hvengel
Retired
 
Posts: 1128
Joined: Sun Dec 24, 2006 4:35 am
Location: Minden Nevada

Re: The always great C172p cockpit improvement!!

Postby horacio » Fri Dec 10, 2010 10:28 pm

First of all, I greatly appreciate the time and patience to answer and explain every point, by both of you, stuart and hvengel. And I understand each one of them, but even so I think that GIT is not an optimal working process. I would try to explain my idea the best way to be correctly understood.

I understand the fact that perhaps for a plane, ie. the FDM development, is not relevant for to work in parallel with cockpit texture development, but yes it is for other aircraft development which involved it. In this way, GIT is a good tool to continuosly check the last changes done by other users that may affect to my own development.

But precisely this tool (GIT) allows to follow an a non categorized and organized process of development to the basic plataform of simulation and peripherals as a whole pack. It's not an optimal process the fact named by hvengel, that after you finished all your changes in any area, when you want to test them... you need to download the last updated version to check if it works or don't. It have absolutely no sense at all. What if after 2 weeks of work, you find that none of your changes will work or will be compatible with last changes done by other users?

When I studied management and production, I learned about steps, stages and logical distribution of processes over time, previously scheduled on a Gant Chart. It NEVER can be done everything together at the same time, which is currently happening in FG. The basic step for to develop any peripherals in FG (aircrafts, sceneries, wheather, etc) is the plataform for simulation. A developer needs a basic floor which to work over. And this floor cannot being changing every new week. After a stage of development in the plataform of simulation is established, then it should not have any consistent changes after a long time, to allow other peripherals areas to follow its normal curve of development, until they search such a good level than needs a new stage over to work on. It cannot exists parrallel development on plataform the same as in peripherals. Or at least, it cannot exists the fact that peripherals developers are looking every new day the changes done by developers dedicated to plataform area. It don't allows them to concentrate and lead their work at its best point of development. This way of work leads to the old fashioned process of trial and error, which is not optimal in any case.

If all aircraft's FDM is part of basic plataform to correctly run simulation, then this is the first step that needs to be developed before touch any other area of development. And none other development should be accepted until this item is set to a standard level, established for EQUAL to all FG aircrafts.

To see development in a lot of areas is not equal to faster processes. Indeed, after a lot of years already existing FG, graphical development (in all areas) is still in a very basic status. This shows the failure of a job doing in all areas simultaneously. And that, without listing a lot of incompleted aricrafts, bugs inherited from one version to another whitout solution, and etc.

All previously explained are the reason why finally when a new developer get involved in FG development, begin to work on anything that comes in win, because he find that anything will be useful (which is right), but he is not seeing that some things have urgent need to be developed before others. Then we fall in the current way of work: everybody do something, but everybody needs to be wathcing to the work of all other to be sure his work is well done (GIT way of work).

Nobody can do a good job looking at 10 places at once. Is that anybody listened ever about production chain?. Do you think it exists because it's funny or because like the pope in Rome? No, because is the logical way of production of a product that requires different stages of development.

That's why I think that GIT is not a good option of development. For the actual way, yes, but for the optimal, don't.

I really appreciate your willingness, stuart, for to merge my work. You are not obliged, even by your word. If you have time, and if you find it's useful, then do it... and good for this. If don't, then ok anyway. I'm not working to GIT, I'm working because cannot fly pleasantly in a simply colored cockpit, and if other can enjoy my work... good for them.
HORACIO CONTRERAS
El Hangar de Horacio
... ¿y dónde está el Teniente Bello?
_____________________________________________________________________________
Vive FlightGear! Have you a Ñ on your keyboard? Spain-LatinAmerica FlightGear community!
User avatar
horacio
 
Posts: 145
Joined: Wed Sep 29, 2010 5:06 am
Location: SCVM, Chile
Callsign: CC-HCR
Version: 2
OS: Windows 7

PreviousNext

Return to Cockpit development

Who is online

Users browsing this forum: No registered users and 1 guest