Restoring c172p historical commit logs #218
Conversation
Reflect those changes here.
Expanded chamber of pitot tube.
Add VHF antennas to top of fuselage. Better propeller disks when spinning fast. Took green tint out of pitot tube.
- added untextured seats - moved the panel back to the proper position - changed viewpoint and field of view
- yokes - carb heat - throttle - mixture - flap switch - trim wheel Moved the pilot seat back slightly. Use LOD more aggressively, so that all the interior detail is skipped when the viewer is distant.
throttle, and mixture knob.
activated with the mouse, but they do respond to the following properties: /controls/lights/taxi /controls/lights/landing /controls/pitot-heat /controls/lights/navigation /controls/lights/beacon /controls/lights/strobes
nav light; enlarged beacon.
the bleed-through problem -- it occurs only when the texture has an alpha component. It's not a good, long-term solution, though.
Make the plane much sloppier at high alpha and/or with the flaps extended. In slow flight, there's much more lateral instability now, and adverse yaw is more obvious at the start of a turn using only ailerons.
I added some hot spots to the default c172p-3d.
subdirectories in yet another step towards making aircraft more self contained rather than potentially spread out.
I added some more hotspots to Davids c172p since he already had done all the animation. Also I tried making the throttle and mixture knobs into hotspots even when they are moving adding extra hotspots for them. Also you can click on the trim wheel to trim now. I added a directory for the labels for the white toggle switches, but there is probably better way to do the labels then I came up with. There is a short readme file which gives the path for the new directory.
|
Please, if I sounded rude, please, it was not my intention. |
|
sure Ludomo. Likewise No es mi intencion -ni interes- ser rudo. Os digo, que estoy completamente de acuerdo con todo lo que dices, excepto con no mezclar este contenido. Como habeis verificado no tiene ningun efecto en el tama~o del contenido en Kb, ni tampoco en cambiar el contenido del repositorio. Solamente introduce los "commit" antes de la separacion de este proyecto. La unica diferencia entre tu opinion y la mia es que, como conclusion esta peticion no es aprobada por ti. En mi opinion la aprobacion no deberia ser tan compleja. Entiendo que dices que si alguien mas en tu lista de colaboradores piensa distinto a ti no os importaria que ese otro hiciera el "merge". Lo que os digo finalmente es que tal postura realmente hace muy dificil para todo colaborador del proyecto venir a contradecir lo que tu ya habeis decidido (siendo todavia tu repositorio) |
|
This is not "my" repository. Someone had to create a repository and it was me because, at that time, I seemed to be the most skilled in using git. Some months later, I'm totally surpassed by other contributors. Please, this is not "my" repository and I know perfectly I can't take any decision on my own! Israel, esto es ahora más filosófico que otra cosa. En la universidad, tengo que recordar constantemente a mis estudiantes que se fijen en el futuro, en acabar los proyectos, que se pongan metas y que lleguen a ellas. La meta de este proyecto es que quede todo perfecto. Todos sabemos de dónde viene y realmente no veo que haya ningún beneficio en poder conocer el estado de la c172p en el año 2002. Sobre todo porque ese estado se puede conocer en FGDATA. Prefiero que no se pierda el poco tiempo que tenemos todos en hacer esfuerzos que no mejoren el proyecto. En realidad aceptar tus cambios es tan fácil como pulsar el botón verde que tengo aquí abajo, pero realmente estoy convencido de que no debo sentar el precedente de aceptar cosas que solo nos hacen "perder tiempo" a todos. En cualquier caso, lo digo completamente en serio: esta es mi filosofía y mi opinión y realmente no me importa que alguien tenga otra y pulse el dichoso botón verde :) |
|
The way these commits are added back into the repository is completely useless. If you do The "best" way would be to try to rebase all of our commits on top of the old commits, but that will change all the commit IDs and will be very invasive as well. But I don't think we should go that way. It's maybe a bit unfortunate that the old commits are not present, but I rather not mess with all our commits. |
|
I will as you say onox be completely against a rebase. |
|
So this is all prior to c172p-detailed? Maybe a few more contributors can weigh in. I have less say in this than Juanvvc, who along with gsagostinho I feel are the rightful owners of this repo. At any rate, Israel, which ever way this goes, please know we appreciate the thought and effort involved to create the data, it's not a bad idea in a perfect strategy. |
|
You can still find the history in FGData via |
|
intriguingly you can still check the file log and the file blame. I just tested example but, if choosing the proper revision The length of each output (with pretty=oneline) for the head revision: 1 clearly, if the information is in the repository it can be obtained. |
|
@wlbragg Yes. all this commit does is add historical commits for everything happening before ludomo and Gilbert started this work. In principle the history should have preceeded them. For one side: I found difficult now to trust valuable historical data over FGData. For the other, that historical commits really belong here too, and they acknowledge all those contributors before us. (note as an example the readme file do not acknowledge them explicitly, not the tree contains an inclusive "AUTHORS.txt"). This strategy cleans that in one simple step. Ludomo has a Philosophical difference of opinion about this. And yes, I agree with you, he and Gilbert are ultimately the "Parents" of this project. I think ONOX, you and I agree more of beign --to say the least-- nice to have the commits there. But again, the solution is not technically perfect, as ONOX outlies. It is just the best of all possible options I know of. And I said before, accepting the merge has no practical "harming" consequences. It only does a bit of good, where it can. |
|
Also, I found important to note that Ludomo first reaction was this is inconvenient over repo size bloating away. |
|
Had you seen also that I am looking forward to send another pull request that includes a "restoreName" to get the aircraft to work as "c172p" ? I am sooo looking forward to get these merges completed, but I feel in a way my help is totally not-appreciated here :( |
|
Your help is totally appreciated if you fix any of the 60 open issues! It is just I really don't want to "waste" time to fix something that is not an issue now, and it won't be an issue in the future because past history is perfectly preserved in FGDATA. It is our history what is in danger, not the history of the original c172p :) My current role as "curator of the project" (I don't want to say "manager", I'm looking for a term less formal) makes me kindly push you to use your time and skills in any open issue by not accepting this merge. |
|
ok. you are the boss Ludomo I deleted the "previous" history now, to allow me to send the pull request for aircraft renaming Best, So this discussion is over and this is the new topic |
|
Can I politely ask this to be merged? |
|
First of all, the answer was/is no. Second, Github says the PR cannot be reopened because "the master branch was force-pushed or recreated." |
|
the second argument is no problem. The answer of WHO was no ? |
|
However, could you create a new branch (--orphan branch I think) with just the old commits? (from " Updated with animations, more detail, and new panel." to "c172p: define CG envelope") |
|
To quote @Juanvvc:
|
|
That is not a NO answer. Read well ONOX |
|
No need to start shouting. |
|
I can create an orphan branch but that is totally unnecesary. I need the history to be restored over the detailed instead. Unless this is technically impossible, which is not my perspective . Shouting? via text? |
|
i'm confused at why israel _needs_ this history restored... what is the real need or purpose? it doesn't provide anything beneficial to the project that i can see... i certainly hope that this doesn't blow up like what happened on the dev list 😞 |
|
Israel, I know your intentions are good and that you believe you are doing something beneficial, and also that you believe you are seeing something that none of us are, but you must realize that this discussion is turning into one of "those" discussions. Look, ludomotico already told you very politely that this is not a current issue and that we won't bother with it right now and that if you'd like to help you can have a look on our current opened issues (which you are welcome to help us with!), but then you started a discussion with both onox and wlbragg (in different PRs but about the same thing). You are doing us no favour by continuing with these discussions... look, even if you think you are right, in the end you are causing these annoying discussions here, and you are the one that can easily make them stop. So far we had zero problems in this project concerning people being pushy and the whole development has been so smooth, so please consider if it's really relevant to press on with these discussions when clearly nobody else is up for it. Very likely the only thing you will manage to achieve is to start having problematic relations to all these already mentioned developers here, and that will make it even more difficult for you to convince anyone that you are right. So I kindly ask you to reconsider this, please. |
|
Am I the one being pushy Gilberto?
Which is exactly whats going on here, too. Look. When I find an issue I can fix, I will gladly do it, and I will not need to be kindly pushed to it. The second petition will change nothing in your code, but will place back historical data. I am not thinking I am right about this. I am sure. The only technical "con" has been repository size bloating. Which already got demonstrated this is not really an issue (unless you worry for less than 10Kb of data). Because I am sitting myself downstream of this repository (over FGMEMBERs) and the c172p of FGDATA is going to be replaced by this version, I would largely apprecciate these historical commits merge to be accepted. And if there is a technicality that I am not seeing why this is not acceptable, I will like to know that. But that this is not accepted based that is not Ludomo's priority --and he is trying to push me in one direction not another: that's a more complex explanation in my book. Besides, he did not say: "No" I really hope this clarifies the current status of this request. |
|
@gilbertohasnofb @Juanvvc Is it ok if I force push to restore the original master? (without IAHM-COL's commits) |
This merge does no change to current code, but restores all previous contributions to the c172p project. The FG hallmark aircraft.
(this merge goes for all three active branches)