atc-pie-testing — Feedback and discussion on ATC-pie dev branch features

Re: [ATC-pie-testing] Ready for v1.9?

[<wo...@ka...>]

Hello

Ready and loaded.
I have tomorrow night an ATC session at LIMJ

Will come back with feedback then.

Thank you

Woosh

On 2025-02-13 08:05, Michael wrote:
> Hello,
> I have pushed most of what I think will make the next release. The main 
> new
> feature announced will be *helicopter approaches*, but the most
> visible/practical upfront will be:
> 
>    - upgrade to *Python 3.13*: many were having trouble because of the
>    removal of Telnetlib in that upgrade, which I was using—I solved 
> this
>    without even using a substitute, i.e. using low-level socket work;
>    - central docking area and *user panel behaviour*: I figured there 
> was
>    no real use for a tabbed version of the workspace, that the Qt 
> windowed
>    mode was a bit awkward, and that the pop-out/reclaim mechanism was 
> messy,
>    so I changed for a unique but selectable central panel (including a
>    non-cluttered CPDLC panel collecting all connections)—see if you 
> confirm
>    the improvement, remembering that panel layout is saved per 
> location, and
>    that we want to accommodate any situation.
> 
> I also moved a few things around in the GUI, added a couple more
> features... See a copy of the current ChangeLog below.
> 
> I think I am basically only waiting for two things:
> 
>    - some idea that tests happened on all of this, not to roll this out 
> too
>    soon with bugs, so that is a call out to you;
>    - to work out helo approach phraseology in voice recognition (e.g.
>    helipad naming scheme), in a way that suits all airports... although 
> I may
>    provide this mostly niche feature on my own time later, as an 
> upgrade, so
>    that all of the rest benefits everybody sooner.
> 
> 
> 
> == ChangeLog ==
> Major feature addition: helicopter approaches and instructions
> Other notable changes:
>   - helipad use & parameters
>   - unlimited XPDR assignment ranges
>   - known ACFT types
>   - received strip auto-link to FPL
>   - solo MISAP probability
>   - toggle Mach numbers keyboard action
>   - improved ATIS action & dialog
>   - CPDLC panel collects connection windows
>   - dockable CPDLC panel and teaching console
>   - single central panel selection
>   - name radar & strip panel windows
>   - close non-dockable windows action
>   - read apt.dat v12 format
>   - extended ACFT DB
> 
> _______________________________________________
> ATC-pie-testing mailing list
> ATC...@li...
> https://lists.sourceforge.net/lists/listinfo/atc-pie-testing

[ATC-pie-testing] Ready for v1.9?

[Michael <mic...@gm...>]

Hello,
I have pushed most of what I think will make the next release. The main new
feature announced will be *helicopter approaches*, but the most
visible/practical upfront will be:

   - upgrade to *Python 3.13*: many were having trouble because of the
   removal of Telnetlib in that upgrade, which I was using—I solved this
   without even using a substitute, i.e. using low-level socket work;
   - central docking area and *user panel behaviour*: I figured there was
   no real use for a tabbed version of the workspace, that the Qt windowed
   mode was a bit awkward, and that the pop-out/reclaim mechanism was messy,
   so I changed for a unique but selectable central panel (including a
   non-cluttered CPDLC panel collecting all connections)—see if you confirm
   the improvement, remembering that panel layout is saved per location, and
   that we want to accommodate any situation.

I also moved a few things around in the GUI, added a couple more
features... See a copy of the current ChangeLog below.

I think I am basically only waiting for two things:

   - some idea that tests happened on all of this, not to roll this out too
   soon with bugs, so that is a call out to you;
   - to work out helo approach phraseology in voice recognition (e.g.
   helipad naming scheme), in a way that suits all airports... although I may
   provide this mostly niche feature on my own time later, as an upgrade, so
   that all of the rest benefits everybody sooner.



== ChangeLog ==
Major feature addition: helicopter approaches and instructions
Other notable changes:
  - helipad use & parameters
  - unlimited XPDR assignment ranges
  - known ACFT types
  - received strip auto-link to FPL
  - solo MISAP probability
  - toggle Mach numbers keyboard action
  - improved ATIS action & dialog
  - CPDLC panel collects connection windows
  - dockable CPDLC panel and teaching console
  - single central panel selection
  - name radar & strip panel windows
  - close non-dockable windows action
  - read apt.dat v12 format
  - extended ACFT DB

[ATC-pie-testing] "Known ACFT" feature + misc.

[Michael <mic...@gm...>]

Hello,
Those correctly pulling on dev will have noticed a few dialog improvements
(tell me if you think they are not), and a new "known ACFT" feature. This
allows to auto-fill type for callsigns frequently contacting you with the
same type, and cascade with WTC auto-fill if recognised and button is
pressed. Also made XPDR range list unlimited in the local settings.
Feedback naturally always welcome.

Besides, no trouble with the solo sessions? I was really afraid I had
busted things as a lot of it was redesigned to fit helicopters (helipad
use, straight-in APPs, etc.). Please mess with it and try to break it :-p

[ATC-pie-testing] Updates, incl. AI helos

[Michael <mic...@gm...>]

Dear list,
I have not posted about ATC-pie for a while, but as I expressed in other
places I had something going for a next update, namely proper helicopter
traffic for solo and teaching sessions, including straight-in approaches
and cascading necessities such as helipad parameters and use selection.

I have pushed a first testable version (commit 0841bd), which includes a
couple other improvements like apt.dat 12.00 and better ATIS and DEP
clearance integration. The interface only suffered minor changes, but I did
rework quite some code, impacting more than just the new stuff. So even if
you do not test any new feature, it would be useful to use the latest dev
version in your normal sessions to ensure nothing broke inadvertently.

There may be things I eventually forgot about the helos, so tell me if you
find some of the behaviour strange. Voice recog. has not been fully updated
yet; I need to consult about the way to name helipads for example, then to
find a system working for all airports—insights welcome. A couple of
pending tickets I also want to address.

Cheers.

Re: [ATC-pie-testing] Two boxes ticked?

[Michael <mic...@gm...>]

> Actually in my solo session using in between 2 to 20 (sometimes more)
> planes are not stopping to show up.
> What would be the conditions to test/retest this ?
>

Sorry, I thought you had reported something along those lines, as I
remember linking back to something I had noticed myself at FSweekend (where
sessions could run for hours without being reset). Maybe it wasn't you...
Glad to hear there is no problem there in your experience.

Re: [ATC-pie-testing] Two boxes ticked?

[<wo...@ka...>]

Hello Micky,

1.
I have loaded the commit 2a5b2c4 and had a "regular" ATC session last 
Sunday without problems.

It has been a short session but the Mach nbr was looking coherent.

More tests and in deep asap, probably this aft 5 or this coming Saturday 
with the needed solo session.

2.
Not sure what you do means by "small change about that without reporting 
here".

Actually in my solo session using in between 2 to 20 (sometimes more) 
planes are not stopping to show up.

What would be the conditions to test/retest this ?

Kind Regards

Woosh


On 2023-03-16 07:08, Michael wrote:
> Hello,
> Two quick questions after modifications.
> 1. have the Mach values become acceptable with commit 2a5b2c4? I still 
> hope
> to merge more speed values from your file, but compared to the 
> corrections
> made those will only appear as marginal adjustments.
> 2. has the aircraft spawning improved in solo? (they used to stop 
> spawning
> after a while, and without reporting here I did make a small change 
> about
> that, i.e. now forgetting about ACFT going off radar *even if* they are
> still in map range—both conditions were previously necessary to be
> forgotten. although not the most thorough, my last code review did not
> yield any other reason for that problem)
> 
> _______________________________________________
> ATC-pie-testing mailing list
> ATC...@li...
> https://lists.sourceforge.net/lists/listinfo/atc-pie-testing

[ATC-pie-testing] Two boxes ticked?

[Michael <mic...@gm...>]

Hello,
Two quick questions after modifications.
1. have the Mach values become acceptable with commit 2a5b2c4? I still hope
to merge more speed values from your file, but compared to the corrections
made those will only appear as marginal adjustments.
2. has the aircraft spawning improved in solo? (they used to stop spawning
after a while, and without reporting here I did make a small change about
that, i.e. now forgetting about ACFT going off radar *even if* they are
still in map range—both conditions were previously necessary to be
forgotten. although not the most thorough, my last code review did not
yield any other reason for that problem)

Re: [ATC-pie-testing] Yellow Blue Glider appearing "where" tower is

[Michael <mic...@gm...>]

Hello,
I understand you are referring to the rendering in other players' FG
clients.

Changing the altitude is not a general solution if you use the tower view
feature yourself because it also controls its position. There is nothing
ATC-pie can do at this point to prevent others from rendering a model for
your connection out of the box. If you have their cooperation then yes they
can use an empty model like you propose for "ATC-pie", a string ATC-pie
sends in the model designator field over MP.
Improving the FG code for an even better solution:

   - not render anything for identified models: ATC, ATC-pie, OpenRadar...
   - even more useful in the longer run: implement connection types and not
   render anything in identified cases: observer, ATC, copilot...




On Sun, 12 Mar 2023 at 10:08, <wo...@ka...> wrote:

> Hi
>
> what would be the wished way to make disappear the not welcome yellow
> blue glider appearing where the tower is :
>
> - setting its altitude like 50 m below ground ?
>
> - setting a model that would be "not" the blue/yellow glider ( I can do
> the model )
>
> - something else ?
>
> Woosh
>
>

[ATC-pie-testing] Feedback and discussion on ATC-pie dev branch features --- file bigger than 40 kn (currenlty 162 kn)

[<wo...@ka...>]

file available here until 2023 19. of March.

https://www.moohw.com/Temporary-Docs/acft-db-1

kind regards

Woosh

Re: [ATC-pie-testing] Speed problem progress

[<wo...@ka...>]

Hi Micky,

that's great news!

> Could the values in acft-db be a little high in the first place?

Will double check them.







> I collected that from the FlightGear community quite a long while ago;
> I could not tell who wrote it.

Was'nt me...
O:-)





> May informed people check and report what to think of them?
Will do it using theses crossed sources:

- Manufacturer docs (where easily possible)
- Skybrary (the ICAO / Eurocontrol / flightsafety.org informative web 
site )
- Observed Values on OpenSky Network (the open alternative to 
FlightRadar24)




> For example we have:
> A306 heavy H 518 # AIRBUS A-300(B4/C4/F4)-600
> A320 jets M 510 # AIRBUS A-320
> A332 heavy H 540 # AIRBUS A-330-200
> B722 jets M 540 # BOEING 727-200
> B731 jets M 485 # BOEING 737-100
> B738 jets M 511 # BOEING 737-800, BBJ2
> B744 heavy H 570 # BOEING 747-400 (international, winglets), AL-1

well,
these are definitely values reported by some Super Navy Pilot test 
flying these ACFTs.


Give me a few days [quite busy currently], I will come up with an 
updated file.

Woosh

[ATC-pie-testing] Speed problem progress

[Michael <mic...@gm...>]

Hi,
I have looked at the speed problem, and found a unit mismatch somewhere (kt
over m/s division), which obviously cannot help getting values right. So I
corrected that and was still having Machs>1 while I not seeing anything
(else) wrong with the formulae.
So I figured it must be the data base's cruise values sourced from
"CONFIG/acft/acft-db" that might be off from the start.

Interpreting them as TAS (instead of IAS with a dodgy tweak for higher
alt's) did bring the Mach values down under 1, which is good news.
However, they still seem a little high: ~.9 with commit 2a5b2c4
implementing the changes above.

Could the values in acft-db be a little high in the first place? I
collected that from the FlightGear community quite a long while ago; I
could not tell who wrote it.

May informed people check and report what to think of them?

For example we have:
A306 heavy H 518 # AIRBUS A-300(B4/C4/F4)-600
A320 jets M 510 # AIRBUS A-320
A332 heavy H 540 # AIRBUS A-330-200
B722 jets M 540 # BOEING 727-200
B731 jets M 485 # BOEING 737-100
B738 jets M 511 # BOEING 737-800, BBJ2
B744 heavy H 570 # BOEING 747-400 (international, winglets), AL-1

Re: [ATC-pie-testing] in Solo / Mach numbers way out of scale ... and showing up ACFT with unrealistic speeds

[Michael <mic...@gm...>]

Hi,
Indeed you know there is a problem if you keep seeing Mach > 2 in solo.
For the reference I see you have placed a related ticket, which is good:
    https://sourceforge.net/p/atc-pie/tickets/26

I will look into this to check my formulae for Mach numbers but on first
look they seem to match what you propose.
I think the problem might instead be in the speeds generated in knots,
because:

   - you judge them wrong too, according to the title of your ticket
   - my code comments a compensation for "crazy speeds" when generating
   IAS/TAS for AI aircraft, so I suspect a problem was already detected and
   worked around with a quick and dirty fix to avoid proper physics [*]
   - Mach is based on them so if they are wrong, all bets are off about the
   value for Mach

At the time of [*] I did not have Mach numbers, but adding them afterwards
forced me to add the temperature considerations, etc. So something I might
want to try now is FIRST assume a Mach number for generated airborne
aircraft, and revert the Mach formula.

[ATC-pie-testing] in Solo / Mach numbers way out of scale ... and showing up ACFT with unrealistic speeds - warning

[<wo...@ka...>]

just to help avoid a frequent confusion / mistake

Speed Sound do not change with altitude

Speed Sound change with temperature.

Now temperature OAT change with altitude...

Woosh

[ATC-pie-testing] in Solo / Mach numbers way out of scale ... and showing up ACFT with unrealistic speeds

[<wo...@ka...>]

Hello,

in Solo (and I suppose in MP too) the Mach number are way out of scale.

B737 / FL270 / M2.74

A388 / FL220 / M2.57

A388 / FL330 / M3.11

(just to rem Mach 1.00 is 1x sound speed)

A388 at Mach 3 is a new future for the double deck :-)

---

I had a quick glance at your formulae

May I suggest to compute the Mach by

MACH = TAS / SSa

where SSa is the Sound Speed at a given altitude (what does change of 
course depending upon OAT)

Since the OAT is here in "solo" a missing data you could extract it from 
an somewhat not too much arbitrary table like this one :

https://www.engineeringtoolbox.com/elevation-speed-sound-air-d_1534.html

or any other one simpler.

I suppose we can have a bit high error tolerance in solo mode.


-----

but also

AI Planes showing up at :

A320 / FL170 / GND speed 713 kts

B747 / FL240 / GND speed 694 kts

that is way out of the reality

---

You could review your formulae baring in mind the following max for 
today aviation:

at cruise, (not climbing nor descending) and with no jet stream help, an 
airline would typically have a 480 kts GROUND speed flying about FL360

4 engines one might reach 490 G.kts at higher level if they are not 
flying in economy mode (some engines in STB)

For a France UK - average speeds at FL320 are about Ground 430-450 kts

---

You can leave out big jet stream advantages (+60 kias) because they 
happen quite rarely.

You need to fly quite high + in the right direction + ...

and directions change fast...



Woosh

Re: [ATC-pie-testing] Hoppie tests before ATC-pie update anyone?

[<wo...@ka...>]

Hello

On 2023-01-21 16:24, Michael wrote:
> Hi,
> .. ~ .. and sorry if you somehow felt dismissed despite no such 
> intention from me.

No worries, no offence taken.

Reported about that "dismissed episodes" just for your information in 
case it would matter to you to to change anything.
Was already presuming "no intention" from you.




> Thank you for being an assiduous user.

You are welcome.

Just reminding you my 2 reasons to use ATC-Pie,

in my little spare time, just for fun,
but mostly it is wrapped around the other project we already talked 
about.

The modifications I have made so far to your ATC-Pie are aesthetic / 
ergonomic,
as there is a need of improved "visual immediate awareness" not 
satisfied by the default configuration.
That need becoming blatant when traffic increase.

No real change have been done so far to the functions/code,
but mostly because I deplore the absence of data-dictionary, functions 
description dictionary and or sufficient comments.
And I am do not feel teased to have to reverse engineer your creative 
mind.

I have seen the #notes-reminders in line with your code, but they still 
are insufficient dots to link together and build the "soft big picture".

At later time, the integration in my project will no matter what force 
me to dive in your code.
At that moment, due the volume of work and the goals, I am still 
considering a port in C.

As for now, we may consider all this as blah.

Back to "pushing to stable", if you ask me, considering most of user are 
not going to load their system as I do, I suppose it is 0K.


Woosh


> It is true that I have to sometimes choose what to prioritise, and also
> that I am sometimes confused or simply unable to diagnose, but no harm
> intended.
> 
> I would of course like to clear the program of identified bugs, but if 
> they
> already existed in the previous version I don't mind pushing without 
> fixing
> those, given how pressing I think the python3.10 compat has become. 
> I'll
> work on the rest later, and the Hoppie stuff will need quite a touch up
> (hence a subsequent push) anyway given how much guessing was part of 
> its
> design, and how little testing was possible at this point...
> 
> 

Re: [ATC-pie-testing] Hoppie tests before ATC-pie update anyone?

[Michael <mic...@gm...>]

Hi,
Thank you for being an assiduous user... and sorry if you somehow felt
dismissed despite no such intention from me.
It is true that I have to sometimes choose what to prioritise, and also
that I am sometimes confused or simply unable to diagnose, but no harm
intended.

I would of course like to clear the program of identified bugs, but if they
already existed in the previous version I don't mind pushing without fixing
those, given how pressing I think the python3.10 compat has become. I'll
work on the rest later, and the Hoppie stuff will need quite a touch up
(hence a subsequent push) anyway given how much guessing was part of its
design, and how little testing was possible at this point...



On Sat, 21 Jan 2023 at 10:11, <wo...@ka...> wrote:

> Sorry, I was forgetting the elephant in the corridor ...
>
> Huge memory leak!
>
> There still is a serious problem of memory leak going fast to saturation
> certainly due to some used and then non freed resources/loop/snippet of
> your code. (I did not dived any more in your code, sorry for that).
>
>
> It is a huge proportion where ram consummation more than triples.
>
> ATC-Pie starts using 3GB~ish (using advanced BG Maps) then reach > 15GB
> in about 90 minutes.
> (Then all the computer become irresponsive due to severe swapping.)
>
> I use maps I factor from scratch:
>
> - All -1 are "lines only";
> - 1 is a SVG for shore lines ( file : 85kb / < 400 nodes / 2 colours +
> bg /// so a very ligh SVG).
>
> Other details
> - 2 or 3 maps are use at the same time, like :
>       APP RADAR: AWYS, STARs, HIPPOS and Constraints
>       TWR RADAR: HIPPOS, Choosen FNA, MApt path
>
> I use 2 or 3 screen radars spawning 3 monitors
>
>
> ---------
>
> So the question here is ***not*** about if "this is heavy"
> My computer have resources enough for all this and more.
>
> The question is ATC-Pie starts using 3GB and quickly ramp up to RAM
> Saturation at a rate of about 130 kB/min.
>
> ---------
>
> I suppose the problem have become visible to me because of how "advanced
> maps" use act as magnifying glass for resources usage.
>
> While there was the PyQT/Python 3.10 issue, I was using ATC-Pie on a
> virtMachine.
>
> The problem was already there, but I was unable to exclude all possible
> causes due to virtMachine side effects.
>
> I am using now on my bare Linux, the problem persist.
>
> I have tried with nothing else load in RAM, (system + ATC-Pie only ///
> no mumble / chat / ... nothing)
> the problem persist.
>
> ---------
>
> While in the past I had to see my reports to you some what dismissed,
> probably because some difficulty to understand each one other, I have to
> work out videos just to show "what I mean".
>
> I feel that like a bit unfair, but I like your software and I do it for
> it.
>
> ---------
>
> Again,
>
> if you feel the "normal" usage by other users loading "less" ATC-Pie can
> live with this resource leakage, I will understand you push it for
> "stable".
>
> If not, you will have more info from me as soon as I have them.
>
> If you have questions specific about my ATC-Pie usage , go for it.
>
>
> Woosh
>
>
>
>
>
>
> On 2023-01-20 08:25, Michael wrote:
> > Hello,
> > In the last dev commits as some will have noticed, I implemented the
> > (somewhat overdue) fixes to the lost compatibility with PyQt with
> > Python
> > 3.10. I have had no reports of anything still breaking, so I will push
> > that
> > as a new stable release soon.
> >
> > I have also been improving the FSD session type, in particular by
> > adding
> > CPDLC through the Hoppie ACARS system. This has not much to do with the
> > FlightGear experience, but many FG users now connect to VATSIM through
> > SWIFT. And I was wondering if any such user on this list also used
> > CPDLC
> > there, whether through the standalone client [1] or through the cockpit
> > directly if equipped (Tobias Dammers's Nasal integration [2] in the
> > E-jet
> > family for example).
> >
> > If so I would love to have just a couple tests with them, see if I get
> > the
> > dialogues to work following their use of the system.
> >
> > [1] https://www.hoppie.nl/acars/prg/air
> > [2] https://github.com/tdammers/fg-cpdlc-lib
> >
> > _______________________________________________
> > ATC-pie-testing mailing list
> > ATC...@li...
> > https://lists.sourceforge.net/lists/listinfo/atc-pie-testing
>
>
> _______________________________________________
> ATC-pie-testing mailing list
> ATC...@li...
> https://lists.sourceforge.net/lists/listinfo/atc-pie-testing
>

Re: [ATC-pie-testing] Hoppie tests before ATC-pie update anyone?

[<wo...@ka...>]

Sorry, I was forgetting the elephant in the corridor ...

Huge memory leak!

There still is a serious problem of memory leak going fast to saturation 
certainly due to some used and then non freed resources/loop/snippet of 
your code. (I did not dived any more in your code, sorry for that).


It is a huge proportion where ram consummation more than triples.

ATC-Pie starts using 3GB~ish (using advanced BG Maps) then reach > 15GB 
in about 90 minutes.
(Then all the computer become irresponsive due to severe swapping.)

I use maps I factor from scratch:

- All -1 are "lines only";
- 1 is a SVG for shore lines ( file : 85kb / < 400 nodes / 2 colours + 
bg /// so a very ligh SVG).

Other details
- 2 or 3 maps are use at the same time, like :
      APP RADAR: AWYS, STARs, HIPPOS and Constraints
      TWR RADAR: HIPPOS, Choosen FNA, MApt path

I use 2 or 3 screen radars spawning 3 monitors


---------

So the question here is ***not*** about if "this is heavy"
My computer have resources enough for all this and more.

The question is ATC-Pie starts using 3GB and quickly ramp up to RAM 
Saturation at a rate of about 130 kB/min.

---------

I suppose the problem have become visible to me because of how "advanced 
maps" use act as magnifying glass for resources usage.

While there was the PyQT/Python 3.10 issue, I was using ATC-Pie on a 
virtMachine.

The problem was already there, but I was unable to exclude all possible 
causes due to virtMachine side effects.

I am using now on my bare Linux, the problem persist.

I have tried with nothing else load in RAM, (system + ATC-Pie only /// 
no mumble / chat / ... nothing)
the problem persist.

---------

While in the past I had to see my reports to you some what dismissed, 
probably because some difficulty to understand each one other, I have to 
work out videos just to show "what I mean".

I feel that like a bit unfair, but I like your software and I do it for 
it.

---------

Again,

if you feel the "normal" usage by other users loading "less" ATC-Pie can 
live with this resource leakage, I will understand you push it for 
"stable".

If not, you will have more info from me as soon as I have them.

If you have questions specific about my ATC-Pie usage , go for it.


Woosh






On 2023-01-20 08:25, Michael wrote:
> Hello,
> In the last dev commits as some will have noticed, I implemented the
> (somewhat overdue) fixes to the lost compatibility with PyQt with 
> Python
> 3.10. I have had no reports of anything still breaking, so I will push 
> that
> as a new stable release soon.
> 
> I have also been improving the FSD session type, in particular by 
> adding
> CPDLC through the Hoppie ACARS system. This has not much to do with the
> FlightGear experience, but many FG users now connect to VATSIM through
> SWIFT. And I was wondering if any such user on this list also used 
> CPDLC
> there, whether through the standalone client [1] or through the cockpit
> directly if equipped (Tobias Dammers's Nasal integration [2] in the 
> E-jet
> family for example).
> 
> If so I would love to have just a couple tests with them, see if I get 
> the
> dialogues to work following their use of the system.
> 
> [1] https://www.hoppie.nl/acars/prg/air
> [2] https://github.com/tdammers/fg-cpdlc-lib
> 
> _______________________________________________
> ATC-pie-testing mailing list
> ATC...@li...
> https://lists.sourceforge.net/lists/listinfo/atc-pie-testing

Re: [ATC-pie-testing] Hoppie tests before ATC-pie update anyone?

[<wo...@ka...>]

Hello

0b52dc Dec 11
=============
Tested quite extensively in FGFS - no bugs detected

Solo session - a few bugs - still documenting the bugs
If the "Solo" aspect does matter to you, you might want to delay the 
push on stable.

2 Ex Bugs

After closing 11st solo session,
-  if opening then closing more ATC-pie will not generate more acft nore 
remove some ...
    One have to completely restart ATC-Pie

When starting a session in APP
-  one have absurd acft (B772 flying mach 2.53 at FL190 ...)
-  Holding pattern in fantasy heading / parameters
-  Way too much false positives for ECDA ...

Solo, as said, still under test.


8c0f09 2023 Jan
===============
Same notes than about 0b52dc Dec 11



Again thank you for the long crawl correction for PyQT / Py3.10

Will let you know as I finish the Solo tests.


Woosh





On 2023-01-20 08:25, Michael wrote:
> Hello,
> In the last dev commits as some will have noticed, I implemented the
> (somewhat overdue) fixes to the lost compatibility with PyQt with 
> Python
> 3.10. I have had no reports of anything still breaking, so I will push 
> that
> as a new stable release soon.
> 
> I have also been improving the FSD session type, in particular by 
> adding
> CPDLC through the Hoppie ACARS system. This has not much to do with the
> FlightGear experience, but many FG users now connect to VATSIM through
> SWIFT. And I was wondering if any such user on this list also used 
> CPDLC
> there, whether through the standalone client [1] or through the cockpit
> directly if equipped (Tobias Dammers's Nasal integration [2] in the 
> E-jet
> family for example).
> 
> If so I would love to have just a couple tests with them, see if I get 
> the
> dialogues to work following their use of the system.
> 
> [1] https://www.hoppie.nl/acars/prg/air
> [2] https://github.com/tdammers/fg-cpdlc-lib
> 
> _______________________________________________
> ATC-pie-testing mailing list
> ATC...@li...
> https://lists.sourceforge.net/lists/listinfo/atc-pie-testing

[ATC-pie-testing] Hoppie tests before ATC-pie update anyone?

[Michael <mic...@gm...>]

Hello,
In the last dev commits as some will have noticed, I implemented the
(somewhat overdue) fixes to the lost compatibility with PyQt with Python
3.10. I have had no reports of anything still breaking, so I will push that
as a new stable release soon.

I have also been improving the FSD session type, in particular by adding
CPDLC through the Hoppie ACARS system. This has not much to do with the
FlightGear experience, but many FG users now connect to VATSIM through
SWIFT. And I was wondering if any such user on this list also used CPDLC
there, whether through the standalone client [1] or through the cockpit
directly if equipped (Tobias Dammers's Nasal integration [2] in the E-jet
family for example).

If so I would love to have just a couple tests with them, see if I get the
dialogues to work following their use of the system.

[1] https://www.hoppie.nl/acars/prg/air
[2] https://github.com/tdammers/fg-cpdlc-lib

[ATC-pie-testing] Making ATC-pie compatible with Python3.10

[Michael <mic...@gm...>]

Hello,
I have finally come round to working on this Python3.10 incompatibility.
I think I have done most of the necessary code adjustments, and the basic
tests. However, I am only certain that bugs are still lurking, which is why
I would love it if those still interested in the developments here tested
on their side, challenging the program with all the corner cases they can
think of.
Thanks for your patience, I think this was almost overdue.

[ATC-pie-testing] Mach numbers

[Michael <mic...@gm...>]

FYI, I have added Mach numbers to mode S XPDR interrogation, and the
possibility of displaying them in radar tags instead of ground speeds (tick
option in "ACFT" menu under scope). If available, the value will also show
in the selected contact detail panel (Alt+D dock and compact tool bar).

Problem is, FGMS does not expose that value in its protocol packets, so I
implemented (and tested) a change to FlightGear and asked for a merge
request: https://sourceforge.net/p/flightgear/flightgear/merge-requests/299/
Until it is accepted this will only work in solo and tutoring sessions (FSD
does not support mode S).

[ATC-pie-testing] Sequence optimisation help

[Michael <mic...@gm...>]

Hi,
It has been a while since I last posted here I think... I just thought I
would inform those not monitoring the commits that (I think) I improved the
APP spacing hints.

The spacing hints are a measure of the expected touch-down time difference
between an ACFT *X* and the preceding one *Y* on their rack, assuming their
present speeds and a path for *X* through position *Y*. It also displays a
"!!seq" warning when that difference would theoretically be negative, i.e.
*X* is bound to overtake *Y* on its path. That being a strong incentive to
move *X* up in the sequence.

I recently added further *sequence optimisation suggestions* in those
hints. Outside of the "!!seq" case above, these new hints show when moving
up *X* would reduce the time before both *X* and *Y* are on the ground,
although this time at the cost of a delay for *Y*. That being a trade-off
to decide on as the ATC.
They show after the spacing hint as "opt. *tt:tt*/*dd:dd*" where *tt:tt* is
the combined time gain (seq. optimisation) and *dd:dd* the delay for
aircraft *Y*.
Two new (general) settings were added to condition these suggestions on a
min. value for *tt:tt* and a max. one for *dd:dd*.

The reason I call the feature out is because I alone think it can be a nice
tool, but this was not inspired by real practice I know of. So if it looks
like a bad one to some it can be discussed. I will happily read any
informed comment anyway.

Re: [ATC-pie-testing] Bug: Crash when opening runway choice (among many other situations)

[Michael <mic...@gm...>]

Hello,
...and a happy new year by the way to all list users.

I was already reported this in private, which confirms the problem, and
with the same premise: a Python upgrade. The other user reported crashing
with v3.10---confirm this is also the upgrade you did?---and no crash when
back in a 3.8 environment.

Something changed with 3.10 that broke the signature selection in
overloaded Qt methods, in particular where a float could match an expected
int, which seems no longer to be true.

This error seems to come most of the time from integer divisions being
> evaluated as a floating point number.
>
> [Suggestion:] When an integer is expected, replace / by //.
>
Negative.
Probably dangerous to expect the divided values to always be integers
themselves (and in Pyhon 3.0 // 2 results in... a float!). But mroe
importantly, the report I had included a traceback incriminating a line
where no division was even present.

So the solution will be to more aggressively convert values to integers
before using Qt functions where int's are expected. But to know the extent
of the required change I want to trace what actually changed. E.g. is it a
(possibly non intentional) pyqt upgrade more than the Python3.10 problem?
If it is Python now being pedantic about typing, there may be a lot to
check around the code...

[ATC-pie-testing] Bug: Crash when opening runway choice (among many other situations)

[<num...@ne...>]

Hello,


    Context

After the holidays (and a Python update), I am back to the FGFS network, 
but ATC-pie crashes with a dump about the types of arguments of Qt 
functions.


    Troubleshooting

This error seems to come most of the time from integer divisions being 
evaluated as a floating point number.


    Suggested modifications

When an integer is expected, replace |/| by |//|. To help doing this, 
the (|vim|’s) regular expression |[^/]\/[^/]| can help as it detects all 
the single |/|:s.

But in all the python files (|ui/| folder excluded), there are 1048 
occurrences of singles slashes. I filtered them, keeping only divisions 
(not in a comment, not in a string), and I found 181 items, listed at 
the end of this message. This is still quite a lot, and maybe not all of 
them need to be replaced by integer divisions.

The filter process is the following: a |vim| script, for a given file, 
appends in |list.txt| the list of all the locations where a division is 
found. It searches the regular expression above, removing occurrences 
with a special syntax (text, comments, etc.). (Hence it relies on the 
|vim|’s syntax algorithm.)

|norm gg while search('[^/]\zs\/\ze[^/]', 'szW', '', 0, 
'synID(line("."), col("."), 0) != 0') exe ":silent !echo " . expand("%") 
. ":" . line(".") . ":" . col(".") . ">> list.txt" endwhile q|

Then I applied this script on all the Python files of ATC-pie except 
those in the |ui/| folder, with the following |zsh| line:

|for f in ^ui/**/*.py; do vim $f -c ':source script.vim'; done|

Note: if you use |vim|, you can navigate to all the places listed in 
this file with the two commands below. The second command loads the list 
from the file using the format given by the first command. Then use 
|:cn| to navigate to the next location and |:cp| to navigate in the 
previous location.

|:set errorformat=%f:%l:%c :cf list.txt|


    List of divisions in the project

  * gui/graphics/radarContact.py:180:35
  * gui/graphics/radarContact.py:180:56
  * gui/graphics/radarContact.py:368:76
  * gui/graphics/radarContact.py:377:70
  * gui/graphics/radarContact.py:466:20
  * gui/graphics/radarContact.py:466:28
  * gui/graphics/radarContact.py:487:20
  * gui/graphics/radarContact.py:487:28
  * gui/graphics/radarContact.py:493:24
  * gui/graphics/radarContact.py:493:32
  * gui/graphics/radarContact.py:509:20
  * gui/graphics/radarContact.py:509:28
  * gui/graphics/radarContact.py:538:33
  * gui/graphics/radarContact.py:538:54
  * base/acft.py:209:81
  * base/acft.py:222:61
  * base/ad.py:236:66
  * base/ai/baseAcft.py:44:19
  * base/ai/baseAcft.py:164:55
  * base/ai/controlled.py:112:75
  * base/ai/controlled.py:185:48
  * base/ai/controlled.py:353:60
  * base/ai/controlled.py:400:42
  * base/ai/controlled.py:464:84
  * base/ai/controlled.py:690:50
  * base/coords.py:34:10
  * base/coords.py:35:10
  * base/coords.py:59:32
  * base/coords.py:59:40
  * base/coords.py:59:48
  * base/coords.py:69:15
  * base/coords.py:79:16
  * base/coords.py:139:9
  * base/coords.py:189:36
  * base/coords.py:191:37
  * base/coords.py:309:16
  * base/coords.py:333:9
  * base/coords.py:344:14
  * base/coords.py:346:19
  * base/coords.py:369:8
  * base/coords.py:370:17
  * base/coords.py:373:38
  * base/coords.py:374:20
  * base/coords.py:376:23
  * base/coords.py:378:20
  * base/coords.py:382:35
  * base/elev.py:43:25
  * base/elev.py:46:25
  * base/fpl.py:125:26
  * base/fpl.py:126:26
  * base/params.py:163:27
  * base/params.py:218:24
  * base/params.py:241:32
  * base/radar.py:194:64
  * base/radio.py:38:21
  * base/radio.py:86:65
  * base/util.py:48:34
  * base/util.py:48:39
  * base/util.py:172:57
  * base/weather.py:32:18
  * base/weather.py:58:27
  * base/weather.py:117:35
  * base/weather.py:118:20
  * base/weather.py:171:20
  * base/weather.py:172:15
  * ext/fgms.py:477:54
  * ext/fgms.py:564:87
  * ext/fgms.py:1120:28
  * ext/fgms.py:1121:12
  * ext/fgms.py:1121:38
  * ext/fgms.py:1133:10
  * ext/fgms.py:1134:10
  * ext/fgms.py:1135:10
  * ext/fgms.py:1161:13
  * ext/fsd.py:111:41
  * ext/fsd.py:112:28
  * ext/fsd.py:211:96
  * ext/fsd.py:216:77
  * ext/fsd.py:221:53
  * ext/mumble.py:68:21
  * ext/mumble.py:71:14
  * ext/mumble.py:73:26
  * ext/sr.py:164:37
  * ext/xplane.py:707:38
  * gui/dialog/bgImg.py:66:71
  * gui/dialog/bgImg.py:76:71
  * gui/dialog/bgImg.py:77:49
  * gui/dialog/detailSheets.py:382:38
  * gui/dialog/miscDialogs.py:121:76
  * gui/dialog/miscDialogs.py:129:45
  * gui/dialog/runways.py:66:78
  * gui/dialog/settings.py:272:74
  * gui/dialog/settings.py:274:63
  * gui/dialog/settings.py:275:69
  * gui/graphics/airport.py:103:34
  * gui/graphics/airport.py:179:30
  * gui/graphics/airport.py:179:43
  * gui/graphics/airport.py:182:31
  * gui/graphics/airport.py:250:50
  * gui/graphics/airport.py:250:56
  * gui/graphics/airport.py:254:40
  * gui/graphics/airport.py:255:83
  * gui/graphics/airport.py:256:44
  * gui/graphics/airport.py:304:34
  * gui/graphics/airport.py:468:38
  * gui/graphics/airport.py:468:60
  * gui/graphics/airport.py:468:101
  * gui/graphics/airport.py:468:119
  * gui/graphics/airport.py:577:32
  * gui/graphics/airport.py:591:29
  * gui/graphics/airport.py:592:32
  * gui/graphics/airport.py:593:45
  * gui/graphics/flightStrips.py:308:6
  * gui/graphics/flightStrips.py:309:39
  * gui/graphics/flightStrips.py:310:20
  * gui/graphics/flightStrips.py:310:28
  * gui/graphics/flightStrips.py:410:76
  * gui/graphics/miscGraphics.py:205:24
  * gui/graphics/miscGraphics.py:244:50
  * gui/graphics/miscGraphics.py:244:84
  * gui/graphics/miscGraphics.py:463:39
  * gui/graphics/miscGraphics.py:480:57
  * gui/graphics/radarContact.py:180:35
  * gui/graphics/radarContact.py:180:56
  * gui/graphics/radarContact.py:368:76
  * gui/graphics/radarContact.py:377:70
  * gui/graphics/radarContact.py:466:20
  * gui/graphics/radarContact.py:466:28
  * gui/graphics/radarContact.py:487:20
  * gui/graphics/radarContact.py:487:28
  * gui/graphics/radarContact.py:493:24
  * gui/graphics/radarContact.py:493:32
  * gui/graphics/radarContact.py:509:20
  * gui/graphics/radarContact.py:509:28
  * gui/graphics/radarContact.py:538:33
  * gui/graphics/radarContact.py:538:54
  * gui/graphics/radarScene.py:198:45
  * gui/graphics/routeScene.py:117:35
  * gui/graphics/routeScene.py:118:37
  * gui/graphics/routeScene.py:119:47
  * gui/graphics/routeScene.py:119:67
  * gui/panels/atcCoordination.py:107:38
  * gui/panels/radarScope.py:187:44
  * gui/panels/radarScope.py:187:77
  * gui/panels/radarScope.py:240:64
  * gui/panels/towerView.py:79:77
  * gui/panels/unitConv.py:47:70
  * gui/panels/unitConv.py:47:77
  * gui/panels/unitConv.py:48:70
  * gui/panels/unitConv.py:49:57
  * gui/panels/unitConv.py:50:63
  * gui/panels/unitConv.py:50:70
  * gui/panels/unitConv.py:51:63
  * gui/panels/unitConv.py:52:63
  * gui/panels/unitConv.py:52:70
  * gui/panels/unitConv.py:59:83
  * gui/panels/unitConv.py:64:76
  * gui/panels/unitConv.py:69:80
  * gui/panels/unitConv.py:115:44
  * gui/panels/unitConv.py:115:51
  * gui/panels/unitConv.py:117:44
  * gui/panels/unitConv.py:126:37
  * gui/panels/unitConv.py:135:41
  * gui/panels/unitConv.py:135:48
  * gui/panels/unitConv.py:137:41
  * gui/panels/unitConv.py:139:41
  * gui/panels/unitConv.py:139:48
  * gui/widgets/routeWidgets.py:61:15
  * gui/widgets/stripView.py:86:36
  * session/config.py:554:103
  * session/config.py:556:107
  * session/config.py:566:109
  * session/config.py:625:110
  * session/config.py:637:103
  * session/config.py:650:115
  * session/config.py:690:116
  * session/env.py:195:89
  * session/managers/solo.py:188:35
  * session/managers/solo.py:747:120
  * session/managers/solo.py:773:40
  * session/managers/teacher.py:186:35

Re: [ATC-pie-testing] Bug fix: QNH is N/A

[Michael <mic...@gm...>]

Thanks a lot for the notice. One more unfortunate effect of my "cleaning"
the code to conform to PEP recommendations (although in my opinion they
reach rather deep in rules of style).
The good news is: this happened past the last master push, so only the dev
version was affected. Now corrected.


On Sun, 17 Oct 2021 at 02:28, <num...@ne...> wrote:

> Hello,
> Context
>
> During an ATC session, Woosh told me that in a3dcd0 the value of the QNH
> was replaced by “N/A” in the Weather tab.
> Troubleshooting
>
> A git bisect has showed that the bug was introduced by
> d39845e7f0a02bc23f7cd038a14423246d63e6b3, which contains in
> base/weather.py:37 a modification of a regular expression about the QNH,
> replacing (Q|A) by [QA].
>
> The compiled regular expression is then used with the groups, but the
> replacement deletes the first group (indicating the unit) because the
> replacement does not use parentheses.
> Suggested modifications
>
> The bug can be fixed by applying one of the following modifications:
>
>    - Replacing back [QA] by (Q|A)
>    - Wrapping the new expression in a pair of parentheses: ([QA])
>
> _______________________________________________
> ATC-pie-testing mailing list
> ATC...@li...
> https://lists.sourceforge.net/lists/listinfo/atc-pie-testing
>