Hello thank you for the answer. :-) I have to be honest, I was reading the mailing list and I did not recognize the question was from myself. I suppose 1 year and a half without answer for this ticket helped me to forget I had raised it. (please, really no offence and no hard feeling) For what it does matter, a few weeks without answer did push me to invest some unplanned extra time and dive in the code to lookup for a clue. So I did solved it by myself but I did not feel comfortable to port back...
SOLO - buggy Mach speed and buggy flight speed
Hi Michael and Community tried for about an hour with dev 49e232, as far, all OK. only a few qt Bad windows report and some Jack errors, nothing related with the 3.10 and other qt issue. So You have did a big deal of, sorry, an outstanding correction work. Bravo! and thank you! Will dive more in deep somewhere, this WE and report here. Regards Woosh On 2022-12-09 10:56, Michael Filhol wrote: Commit 49e232 is the first one to try and address this issue. Please start testing and report with tracebacks...
Hello Micky I am glad to see where to fish to solution. I will wait you root a way through this ( and help the 2 other users to patiently wait for ) Thank you. If it is only up to me, we can close the ticket. Thank you LoCall
CORR dev 1d0706
Settings Windows not opening - long list of python errors
Got it. thank you. Just to avoid misunderstandings, the idea of a dependencies dictionary was aimed not at properties but at the whole FG code. I suppose many valuable developers implements nice features and improve other just missing out how it impact other parts of the code. It could be even a simple log, or anything simple to consult, query and update. And, yes, I understand, voluntary needed. Unlikely than me, it should be someone with a good large vision of what already have been done until...
just dived a bit in the nasal ... file : controls.nas 744 var setMouseFlightControlsSensitivity = func(sensitivity) 745 { 746 setprop("/input/mice/mouse/mode[1]/y-axis/binding[0]/factor", -sensitivity); 747 setprop("/input/mice/mouse/mode[1]/x-axis/binding[0]/factor", sensitivity); 748 setprop("/input/mice/mouse/mode[1]/x-axis/binding[1]/factor", sensitivity); 749 } 750 751 setlistener("/sim/mouse/flight-controls-sensitivity", func(prop){ 752 setMouseFlightControlsSensitivity(prop.getValue()) 753...
had a try right now on AppImage 2020.3.13 in original mice.xml line 122 : factor type double 4.0 (mouse[0] / mode[1] (crosshair) / x-axis ailerons ) line 140 : factor type double -4.0 (mouse[0] / mode[1] (crosshair) / x-axis rudder ) line 165 : factor type double -4.0 (mouse[0] / mode[1] (crosshair) / y-axis elevator ) changed respectively for trace to 99 / 101 / -102 result after launch 1. using launcher and no settings specified at all --prop:/input/mice/mouse/mode[1]/x-axis/binding/factor=4 --prop:/input/mice/mouse/mode[1]/x-axis/binding[1]/factor=4...
User Settings - Mice Factor - overwritten by FG
(test lasted 2 hours and half non stop)
tried with > 20 planes // in heavy/complex situations : not a glitch. solved. Regards
under try with just a few planes - at first glance - the behaviour seems correct. will do an extended test later in the day then will let you know. thank you for the retouch.
np about the crossing mssgs. going to try 10aef55a Coming back later with the feed back ++ If it does matter here at this point of cruise ... the reported error have been noticed by other users too. And, yes of course, if not reported here, hardly you will know. ...unless I report it too you.. Regards
Correction http://www.moohw.com/media/ext/FGForum/ATC-Pie-bug_ScreenRecord_2021_07_16.mkv
Full Video 1 shot downloaded from SF installed on a Linux full dependencies satisfied launched configured defined solo session clicked one plane - all follow instruction : "proceed Direct to" ( not the first plane - but after given some instruction the the first plane, this 1st plane start to follow the whole sheep company. http://www.moohw.com/media/FGForum/ATC-Pie-bug_ScreenRecord_2021_07_16.mkv Regards
hI copy pasted from FG forum will continue here only [quote]which impedes my confidence in the status of your repo[/quote] tries done on a fresh downloaded tarball test done on 4 machines - 3 different OS all Linux flavour - 1 Windows 10 edge Not enough nuts to report bug on my own alternative version, thank you Micky. And the sequence is : - click a plane - write a FIXE name ins instruction - click on proceed to does seem pretty what is expected as way to use. Regards
BUG - Solo Mode - Proceed Direct to is applying to all planes
on the explicit matter of rules dedicating any ORCAM code range to IFR VFR LIFR or MVFR... i will do an explicit research. FWIS i can clearly see that it would go contraire wise to the ORCAM method. Worse it could quickly recreate, this time at local scale, the diffulties avoided at large scale. To me it is definitely clear this would bring no advantage in matter of flight management. A plane, already in flight, will have to swap, due for ex. to modifying MVC vfrom VFR to MVFR or even IFR. Thus,...
So, No need to reinvent methods. "Having a global squawk assignment system" have been tried in real life and it has been abandonned. The main reason is The conflict exist only globally. It does not even exist at local scale. I repeat, this conflict do not happen at regional scale. Each service, be local, be "en haut / up there" FIR or UIR have they very own range of ORCAM code. Each of theses services only have to attribute code to : planes/flights starting from their "zone" planes/flights entering...
the problem and the solution already exist. I will take an extra off line time to compose an answer and review it / shortening etc. But, 1, yes, Colin, your concern exist even in real life. 2, yes, Micky ATC-Pie alread address this concern. the fail is in how to use codes, and this is perhaps a matter of understanding ot the method. ORCAM is a method. Be NPCap be Euro ORCAM the principle is nice and powerful since it is, still today able to manage way more DOMESTIC and SUPERDOM flight than codes...