Closed gilbertohasnofb closed 9 years ago
that's for the parking brake, right? :wink:
I can't hear flap sounds even when clicking on them
I can definitely hear a click sound when I click on the flaps lever, but you'll also hear the sound of the flaps itself. The sound of the flaps is positioned near the speaker in the top panel. Is that where it should come from? Or should it come from the left and right wings?
the dial sounds are too loud IMO. I'd make them barely audible when the engine is at high RPM.
I'll reduce the volume.
the masters switch sound (both ALT and BAT) are a bit buggy. light switches also got a bit buggy
I have no problems with the switches. If you toggle /sim/model/c172p/sound/click-master
to true, the sound will play, and when you toggle it to false and then to true again, you can re-play the sound again. The Nasal code will toggle the property to false after 0.1 seconds, which is the more than the duration of these click sounds. You would have to click faster than 10 times per second if you want to interrupt the sounds. You can try to toggle /sim/model/c172p/sound/click-parking
, which will play a sound that takes 1.6 seconds. If you toggle it to false the sound will simply stop, if you toggle it to true again, the sound will play from the beginning again. I can't hear any brokenness.
@gilbertohasnofb I've reduced the volume of the dial sounds.
I can definitely hear a click sound when I click on the flaps lever
You are correct, the sound is definitely there. As for the position, I really don't know.
I've reduced the volume of the dial sounds.
Much better IMO!
You would have to click faster than 10 times per second if you want to interrupt the sounds.
I hear some weird effect sometimes at a much slower rate than this. I tried to record it but the video is horrible. Anyway, see if you can hear it (turn up your volume as the video is very soft). At around 00:07 you can hear the first times the sound breaks, and at around 00:14 again. Link: https://www.youtube.com/watch?v=mm3bInvy_hc&feature=youtu.be
I can't hear any brokenness.
What about what I wrote that some switches (mainly light switches and sometimes the circuit breakers) do not make any sound? For me they make sound let's say 85-90% of the time, but sometimes they fail.
I can hear the clicks in the video, but I don't hear anything wrong with them :confused:
@onox Yeah, I was afraid of that. Unfortunately the program I use to record video is rubbish when it comes to recording sound. Let's just continue implementing this and in the meantime I will make some tests on my side and see if I find anything reliable on how to reproduce these things I mentioned, ok?
@wkitty42
that's for the parking brake, right?
Yep! Sorry for my EngRish :smile: I already corrected the Thanks
file.
@tigert Tuomas, which kind of sound does a trim wheel make? Would you be able to describe it?
@gilbertohasnofb I see you added a commit to the bug-238 branch you also added to the master branch? If you add it to the master branch, then there's no need to add the same commit to this feature branch. We only care about adding sounds in this branch.
@onox Yeah, it was my mistake and I realised as soon as I did it (you can note that I added it first to the bug-238 branch; I had forgotten which branch I was in, sorry). But since it was a harmless addition to that branch, I just left things as they were. Is that a problem? Sorry for the mess..
No, it's not a problem.
@gilbertohasnofb I have added the sounds for the radio stack, except the two comm/nav radio's and the transponder. Some issues with the radio stack:
Aircraft/Instruments-3d/kt76a/kt76a.xml
, Aircraft/Instruments-3d/kx165/kx165-1.xml
, and Aircraft/Instruments-3d/kx165/kx165-2.xml
, so I couldn't add sounds for them.We are currently using just the first 0.1 seconds of double-click2.wav
. The full sound is 0.25 seconds long. Using the full part doesn't make sense because you can keep a (mouse)button pressed.
Maybe the ADF, radio's, and AP instruments can be modified, so that buttons move from their 0.0 position to 1.2 and then back to 1.0 if you want to enable the button. (If that's how the buttons work) And move from 1.0 to 1.2 and then back to 0.0 if you want to disable it. In that case it might make sense to split double-click2.wav
into two parts.
Notes: Position comm1/nav1:
-0.3660 -0.12 -0.04
Position comm2/nav2:
-0.3660 -0.12 -0.09
Position transponder:
-0.3660 -0.12 -0.25
@gilbertohasnofb I also think that a different sound than scroll.wav
should be used for the trim wheel. The autopilot might move the trim wheel and then it looks like some dial is being moved. It sounds confusing :stuck_out_tongue_closed_eyes:
I think if you can add a new sound for the trim wheel scroll, then we can merge PR #265. The issues above require copy and modifying files from fgdata.
@gilbertohasnofb I think your commit actually caused the branch to not be automatically be merge-able. However, I have done some interactive rebasing to squash some commits and simply removed your particular commit in the process.
@onox I will try to add a new sound for the trim wheel by tonight.
About the nav radios and transponder, why don't we copy them into our project then? Together that's only 439 kb more.
As for my last erroneous commit on this branch, my apologies again. Glad to hear it's mergeable right now.
@onox Okay, so I have prepared the new sound for the trim tab, but I am having a problem with our branch. I still didn't even try to add nor commit nor push this time. I simply did a git pull on the master branch (all fine), then when I did a git checkout bug-238
I got:
Switched to branch 'bug-238'
Your branch and 'origin/bug-238' have diverged,
and have 17 and 13 different commits each, respectively.
(use "git pull" to merge the remote branch into yours)
So I tried git pull
again, but this time I got:
Auto-merging c172p-set.xml
CONFLICT (content): Merge conflict in c172p-set.xml
Auto-merging c172-sound.xml
CONFLICT (content): Merge conflict in c172-sound.xml
Automatic merge failed; fix conflicts and then commit the result.
And if I another git pull
, I get:
M Models/Interior/Panel/Instruments/AI/AI.xml
M Models/Interior/Panel/Instruments/dme/dme.xml
M Models/Interior/Panel/Instruments/dme/ki266.xml
M Models/Interior/Panel/Instruments/kap140/KAP140TwoAxisAlt.xml
M Models/Interior/Panel/Instruments/kma20/kma20.xml
M Models/Interior/Panel/Instruments/kr87-adf/kr87.xml
U c172-sound.xml
U c172p-set.xml
Pull is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use 'git add/rm <file>'
as appropriate to mark resolution, or use 'git commit -a'.
Do you know what is happening? If you can give me a hand solving this then I can push the new sound file as soon as possible.
@gilbertohasnofb, onox is definitely the one to sort this out but I can tell you on the second pull you had conflicts that required resolution (meaning you need to edit those files and correct the "tagged" lines that are in conflict). Then you commit those conflict resolution changes you just fixed.and you are ready to merge again. The third pull is simply telling you that you have files that aren't merged (all your new ones marked with "M") and the 2 files you need to edit that had conflicts (marked U).
Thanks @wlbragg. So if I manually copy the raw data from those two xml files from the but-238 branch here on GitHub and paste it on my repository, then I would have solved the conflict?
The "two files" being U c172-sound.xml U c172p-set.xml ?
Yep. Would that solve the conflict?
Yes, that sounds right.
Is your local branch older than #238 PR?
That is why when you get a conflict notice you edit the files that are flagged in conflict. Because technically you should be able to tell what part to keep and what part to discard in the conflict. Have you ever seen or edited one of those conflicts?
Is your local branch older than #238 PR?
No, I re-cloned the whole repository some days ago.
Have you ever seen or edited one of those conflicts?
Not really.
Yes, that sounds right.
I will give it a shot now then.
"should be able to tell what part to keep and what part to discard in the conflict" Because you might be ahead of the PR or behind the PR and that makes a difference in what conflict part is discarded. If you are ahead , you may want to keep your version of the conflict, if behind, you may want to keep what is in 238.
Sometime if I really can't or don't want to wait for help, I'll reclone a fresh copy of master, make my changes and push that back to github (that is if the changes aren't too extensive.. I have the cpu power speed and bandwidth to allow me to do that in a reasonable amount of time.
But then again I guess you trying to work with a PR so that is a bit different.
I really don't know then, and copying the raw data didn't solve it, the conflict is still present...
Because you might be ahead of the PR
How could I be ahead of the PR? I myself never touch those xml files, I only add wav files.
Sometime if I really can't or don't want to wait for help, I'll reclone a fresh copy of master
I do the same when I am at my uni, but at home my internet is rubbish. This repository is quite large nowadays, so I am hoping to solve it somehow else.
Open the files that have the conflict and find the conflict, take a look at it and see if you recognize both versions of the conflict.
There may be more than one conflict in each file.
Sure, I already checked with a difference checker, it's just some few lines of code per file. But the point is that simply correcting these lines on the files is not solving the conflict...
You know what, I need to do some other stuff that does not involve internet right now, so I will just reclone the whole repository. This is too much headache for me. Thanks anyway for the help!
Good luck!
Thanks, with my bandwidth I will need it! :wink:
@wlbragg okay, it took me 2h but cloning is finished and problem is solved. Thanks again!
@onox so the new trim sound is pushed, named trim.wav
. It should be really soft, and the sound is loopable. Let me know if we still need some work on these sounds, okay?
I did an interactive rebase as I said in https://github.com/Juanvvc/c172p-detailed/issues/238#issuecomment-111710053 and force push to clean up this feature branch a bit, but you might not have understood the consequences of it . So what happens is that your commit tree is something like:
A->B->C->D->E->F->G->H
while mine (and Github) is:
A->B->I->J->K
What you should do in this case is find the most common ancestor, which is in this case commit B. Then you do git reset --hard B
and then you do git pull
to get commits I, J, and K. That will save you having to do a full clone.
Perhaps I should have added these instructions on the PR page, but I didn't.
@gilbertohasnofb I get:
AL Error (sound manager): Invalid Enum at buffer add data
No such buffer!
Could it be because the sound is 24 bit instead of 16 bit? :confused:
I've modified c172-sound.xml
to use trim.wav
, so you can check if the sound is accepted by FG or not.
I did an interactive rebase as I said in #238 (comment) and force push to clean up this feature branch a bit, but you might not have understood the consequences of it
Yeah, I didn't realise it at all :smile but no worries, now everything is okay.
As for your error, I will convert the sound to 16-bit tomorrow and also test your last work.
About the nav radios and transponder, why don't we copy them into our project then? Together that's only 439 kb more.
I'll copy the files.
@gilbertohasnofb Done.
Great!
Great news, I contacted the authors of the two CC-BY sound files we were using and they authorized the FlightGear project to include them as CC0 (public domain). I updated the Thanks file to reflect this (so now this Thanks file is not a license requirement but only a polite way of thanking who deserves credit and no license conflict will ever be inflicted). Now I have to solve only one issue with a single texture I used as source and then our project will be completely GPL or public domain (meaning that even if that licensing discussion going on in the mailing list decides to completely block CC-BY, we are clear to go).
Apply new click sounds to cockpit switches (lights, master, avionics switch, etc.). Should be fairly soft.
Could you give me a hand with this, @onox?