FlightGear - Flight Simulator / Tickets / #2606 Ramp Marshall addon creates illegal property paths for ICAO starting with numeral

James Turner - 2021-07-05

FG handles it, but property names cannot start with a number. SOMeone is writing to the airport ICAO to a property name, which is not good. Does the same issue happen with the UFO?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Julian Smith - 2021-07-05

Could we maybe relax some of the requirements for property names?

For example how about we remove the requirement that the first character be a letter, and instead allow it to also be a digit or underscore or dash, like the remaining characters?

Jules
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

James Turner - 2021-07-05

The issue is I don't know /why/ we have the requirement, and we' ve had it for a really, really long time. So, I don't know what might break :D I'd sooner prefix the names above with icao_ or similar. But, fortune favours the brave.....

Last edit: James Turner 2021-07-05

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Julian Smith - 2021-07-05

I'm going to go out on a limb here and claim that relaxing this requirement will 100% not break anything. Because we'd only be changing current behaviour where it currently halts execution immediately.

I guess that there is a meta concern that relaxing things might lead to properties being misused, but i can't really see how this would happen.

The current limitations on the first character of a property name seem similar to the rules for C/C++ identifiers where the first character also cannot be a number. So i wonder... was there an intention at some point to allow properties to be named using Nasal identifiers - e.g. somehow allow Nasal code node.location.latitude_deg to be equivalent to node.getValue("location/latitude_deg")?

Jules
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

James Turner - 2021-07-05

Being able to seamless-ly mirror properties into Nasal is a long-standing 'would be cool' thing, indeed. But it's defintiely a wishlist thing, not worth making headaches over.

As for relaxing the requirement, my concern is places whcih parse text which 'might be' a property name (eg the Python sg-props code) : we'd have to relax the requirement in those places. It's likely only two or three at most, so ... not a big deal.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Edward d'Auvergne - 2021-07-05

From discussions a long time ago, I had the impression that this was exactly to support object-oriented use in programming languages. Hence the airports[0].7622 notation does not work in Nasal, nor in my FGPythonSys branches. How on earth did 7622 end up here anyway? Would it not be better to clarify the error message text instead and continue to block this non-programming language compatible concept?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Andrea Vezzali - 2021-10-25

Again... After 8:07 hours into flight.... :-(

Last edit: Andrea Vezzali 2021-10-25

Schermata da 2021-10-25 06-43-49.png

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Julian Smith - 2021-10-25

Maybe we could change the airport code to always use a leading underscore so that digits are ok, e.g. /airports[0]/_7622 and /airports[1]/_LOWI?

This might make some code a little more complex, e.g. removing the leading underscore, but we need to do something here - crashing due to numeric airport names is pretty unfortunate.

Alternatively, how about we relax the restrictions on the first character of property names on next, and see whether anything breaks?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

James Turner - 2021-10-25

I'd suggest to add a prefix such as 'icao_', I'm pretty concerned about touching the property naming scheme.

For one thing, we do also have the notion of a property's child index, and therefore /foo/bar/42 could be interpreted as 'the child with index 42 of bar'. This scheme is not used in XML or Nasal but we do use it in C++.

(It's different from the index attribute used in XML, which name speciifc: there is also an index over all children, independant of their name)

Given in this case we definitiely want a property name string, I think a prefix like airport_XXXX or icao_XXXX is the way to go.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Andrea Vezzali - 2022-03-17

Still getting this problem... Does anyone is going to fix this? I read the code in order to fix it by myself but unfortunately this task is above my knowledge. Is there any workaround in order to bypass FG crash?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- xDraconian - 2022-03-18
  
  That's not an ICAO code.
  Use ICAO: LFYV
  
  On 3/17/22 16:38, Andrea Vezzali wrote:
  
  Still getting this problem... Does anyone is going to fix this? I read
  the code in order to fix it by myself but unfortunately this task is
  above my knowledge. Is there any workaround in order to bypass FG crash?
  
  [codetickets:#2606]
  https://sourceforge.net/p/flightgear/codetickets/2606/ FG Crash -
  Illegal character '7' at start of leaf of property path:/airports[0]/7622
  
  Status: New
  Milestone: 2020.4
  Created: Sun Jul 04, 2021 08:27 PM UTC by Andrea Vezzali
  Last Updated: Mon Oct 25, 2021 08:47 AM UTC
  Owner: nobody
  
  FG is crashing with error:
  Illegal character '7' at start of leaf of property path:/airports[0]/7622
  this is when my plane (A320-family) passes near the aiport 'Yvetot
  Baons Le Comte' - ICAO '7622'
  Does FG can handle numeric ICAO Airport's names?
  
  Sent from sourceforge.net because you indicated interest in
  https://sourceforge.net/p/flightgear/codetickets/2606/
  
  To unsubscribe from further messages, please visit
  https://sourceforge.net/auth/subscriptions/
  
  Related
  
  Tickets: #2606
  
  alternate
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

James Turner - 2022-03-18

Going to take a look: I supect the fix would be in the A320, since I don't think FG itself creates these properties.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

James Turner - 2022-03-18

As an aside, according to Navcigraph, the actual ICAO for this airport is LFYV, I wonder where the '7622' comes from.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

James Turner - 2022-03-18

Just spent some time with the current A320 (from the catalog/hangar, not Git) flying around this corner of France without triggering this, bit strange. Is there some option needed? I enabled ARPT view in the nav display.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Andrea Vezzali - 2022-03-19

I'm getting this crash also with 777-300ER above north-east of Canada (I was flying from EGLL to KLAX). I also enabled ARPT view on NAV display at maximum range. Don't know if it can be related... I also have Navigraph SID and STARS data installed

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

James Turner - 2022-09-01

Discussed this with the A320 author, we're pretty sure this is not caused by the aircraft Nasal. Andrea we suspect it's one of the add-ons; can you disable them all and re-enable them one at a time to figure it out? I'll also contact the CPCDLC author directly to ask them.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Andrea Vezzali - 2022-09-01

Ok, will try and report... thanks!

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

scarymovie - 2024-01-02

It's good to find this longstanding ticket. I can confirm, after using UFO in my testing, that the issue remains unresolved.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

scarymovie - 2024-01-03

I've disabled all add-ons and tested it with UFO. Unfortunately, the problem still persists. Do you have any other suggestions?

Thank you.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

James Turner - 2024-01-04

VT: we really need a test case that I can reproduce, to fix this: knowing it happens with the UFO and no add-ons he,sp. Can you give a flight path with the UFO, eg 'start at CYZZ and fly on a heading of 190 degrees, should crash after < 30 seconds' ?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

scarymovie - 2024-01-05

Hi James,

You can start at LFBZ and fly on a heading of about 55 degs. It shouldn't take long until it hits the issue. I've attached a screenshot of the point when it happened.

Coordinates: 43.603327, -1.313679

Thank you so much.

Last edit: scarymovie 2024-01-05

Illegal_prop.jpg

Illegal_prop2.jpg

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gijs - 2024-01-05

What happens if you start FlightGear at --airport=7622? We have this airport ID in our airport data (see below), but I cannot replicate the issue. Regardless the airport, I don't see any /airport[n] props being created at all in a vanilla FlightGear version...

X-Plane (where our data comes from) seems to have explicitly chosen to use the 7622 code instead of the (apparently non-ICAO?) LFYV:

https://gateway.x-plane.com/airports/LFYV/show?tab=discussion
https://gateway.x-plane.com/airports/7622/show

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

scarymovie - 2024-01-08

Hi Gijs, launching FG with both "--airport=7622" and "--airport=6452" was successful. However, the underlying issue appears to be related to the designated coordinates rather than the selected airports.

Thank you so much.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

scarymovie - 2024-01-09

Replicating this issue is straightforward within US airspace. Specifically, when departing KIAD towards CYQB, the issue manifests shortly after takeoff. One of the ICAO is:- 3md4

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

waldo kitty - 2024-01-13

FWIW: i cannot replicate this problem with latest NEXT... i've taken off from KIAD and flown all over the area... there's at least a dozen or two of airports within 20 minutes at ~500kts that all start with a numeral... some in Maryland, some in Pennsylvania... i've flown over them, landed at them, dive bombed at them and nothing... my FG doesn't blink an eye at them...

** Build Info: **

OSG 3.6: 925270d9094d87f925003cd173037601ac637caa
Simgear: a5af7601cff9c82efe6b1d584be624fb79bc863b
FGFS: cdc815cda852b9dbd3391d27b4af00d009827c8f
FGData: edf4077402ee72007075e30624e88fc5c6b3ac2f
FGAddon: r7992 | helijah | 2024-01-12 10:50:53 -0500 (Fri, 12 Jan 2024)

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ramp Marshall addon creates illegal property paths for ICAO starting with numeral

FlightGear Flight Simulator: free open-source multiplatform flight sim

Milestone

Searches

Help

#2606 Ramp Marshall addon creates illegal property paths for ICAO starting with numeral

Related

Discussion

Related