That’s odd.
I’ve located a few of your ICAO FPL plans from the logs, but none of them had that issue. Do you have an example for me so I can track this down?
It can be the link generated by Simbrief, you can right click on the “Prefile” button and “Copy link address”. Feel free to DM it to me if you prefer.
this might just be because i ofcourse dubbel checked everything before filing and corrected the error
nonetheless i have had to do this with my last flights with DLH callsign flown in the past 2 days while using the Beta, but again, when i load it in the normal system, everything comes out correctly, but when i switch to beta, my A/C REG: switches to the default (for fenix G-FENX)
Hello not sure if this functionality option has been mentioned before but can we please have an option to import a .SFP (Squawkbox Flightplan) File for PFPX Users.
Hello,
very good Planner, after VPilot feature isn’t available. Just a few findings.
- in case I’m on air and under VFR, it is expected that I didn’t fill FPL, it’s normal. In case that within longer flight the conditions can change very quickly, to IMC. Then it can be required maybe fill IFR FPL in the air, what isn’t possible now. If I have this situation, Planner says that I must tay on ground to fill FPL, this is some wrong option in my opinion. Also any changes in FPL are impossible in the air.
2, some US airports are not available/vissible for Planner looks like, typical Heavens Landing GE99 and Planner still reports error messgage about this name. FPL can be send but error still there and also desctiption not defined/existed is vissible. - after fill IFR FPL, generic VPilot ATC gives me code but if I good remember, there are some typical recommendations (IRL) what sqawk are need to set in case of not ATC. Is any description better behind here to explain about that?
Many thnx.
OMICO
in the US you set the auto-generated squawk if you are not under controll, otherwhise worldwide standard for ifr is 2000, for vfr it depends, mostly it is 1200 or 7000 depending on where you are.
for the airports throwing an error: airports without an icao code cant be filed in the ADEP or ADES field, for those you write “ZZZZ” and add in your remarks ADEP/“airportname” or ADES/“airportname”
for filing while airborne a Workaround is to quickly disconnect, then file and reconnect.
Hello,
yes, this is known to me about codes in case of not under ATC but 2000 is mostly used in Europe and other Countries. I know that with IFR is generally everytime under ATC but sqwk 2200 is somehow in my mind for US and around typically. I appreciate that workoaround with disconnect but this can happen easy under ATC so this is that problem.
I checked with the FPL string sent from Simbrief, before you adjusted it. That’s why I found it was odd. If you have a link generated by Simbrief where this happens I can test it and track it down.
I’ve looked at that format, but there are two issues: There’s little to no documentation on it that I could find. I generated one on Simbrief, and it does not contain any information on Aircraft Type/Equipment Code/Transponder.
I’ll keep it in mind for when we add some way to import flight plans from a file, but I’d rather choose a format that has a bit more information to be honest - and ideally that is used on a planning software that is still available/supported.
If you do not have a flight plan, FSD will let you file one even if you’re in the air. You need to make sure that you’re using the exact same callsign, otherwise it will throw an error. If you have a flight plan filed, than you will need to disconnect, change it, and reconnect - this Beta is not intended to change how FSD works, and this is a rule within FSD.
What error do you see? I’ve just tested it and it is allowing GE99 just fine. Airports that do not have an ICAO code, follow what @1535068 said, use ZZZZ with a ADEP/ or ADES/ - this needs to be on the remarks for now.
That’s a CRC thing, you can use the assigned code, that’ll make it easier for ATC later if they come online.
Small development update
Now that CTP is over, I expect the final changes/features to this Beta to be added over the next 2 to 3 weeks. This includes a “Guided Tour” for new users, hints on all fields, and an easier way to input things like Equipment Codes/Transponder.
After that, this will become the default form for users to file flight plans, and the old one will be removed.
Additional fields (eg.: STS and RIF) will be added after the Beta is over.
For now, a couple minor changes were published yesterday:
- Allow callsigns with less than 4 characters (minimum is now 2)
- Fix some errors when importing a flight plan using the “Flight Plan History” option, if that flight plan had invalid/incomplete information - You will still see a validation or parser error on those fields, but it won’t completely break the import.
why not just copy paste the ATC fpl? a lot easier and quicker
Would it be possible to support ICAO standard metric altitude? Like S1010 S1130 etc.? I’m pretty sure that swift supports this.
I’ve talked to Mike about this.
Right now, FSD “expects” all altitudes to be in feet. If Swift supports metric altitudes, I imagine they are converting it to feet before submitting it to FSD itself.
Accepting the altitude input in metric (with an extra field for the unit) and converting it to feet before sending it to FSD is a possibility, but it’s unlikely to be added before the beta is over. This is on my list of future improvements though, and maybe it’s something that can be changed on FSD itself in the future so no conversion is necessary.
New beta form enforces three-digit RVR/ items - where correctly it should just check for maximum three digits. RVR/75 is perfectly legal as far as I can tell (and seen in real world Eurocontrol FPLs) , but gets rejected - had to change to RVR/075.
Ref 1: Eurocontrol IFPS user manual: “The sub-field shall be denoted with the letters RVR followed by a ‘/’, then not more than three digits (…)”
Ref 2: Eurocontrol Flight Plan Guide Flight Plan Guide: Item detail “Maximum 3 digits to express the RVR requirement of the flight in meters”
On a separate note, I would massively welcome the use of “EOBT” in addition to “Off-block UTC” to start teaching vpilots correct ACDM nomenclature that becomes increasingly relevant in our virtual Europe. Either as “EOBT (off-block UTC)” or “Off-block UTC (EOBT)”.
Hello everyone! How can I write the coordinates of a user waypoint from the LittleNav map into the ROUTE section? For example, 25° 7’ 18.75" N 91° 31’ 1.72" E Thanks.
250719N0913102E
if you don’t need that precision
25N092E
and
2507N09131E
are also accepted. So either 2 degrees latitude followed by 3 degrees longitude, or 2 degrees and 2 minutes latitude followed by 3 degrees and 2 minutes longitude or, 2 degrees, 2 minutes and 2 seconds latitude followed by 3 degrees, 2 minutes and 2 seconds longitude.
Flight Plan → Flight Plan Route Description (alternatively Ctrl+Shift+N)
From there, you can simply copy the appropriate coordinates in the correct format and then paste them into the flight plan. Just be careful not to copy the entire thing because it will also have the departure and destination aerodromes as well as the cruising speed and level section in the plain text which don’t belong in the route section of VATSIM’s flight plan form.
No issues here thus far with the new form.
(Though, to be honest, I still very much miss being able to send flight plans via the vPilot client, rather than having to open another browser window. I know I’m likely the minority, just my personal preference.)
You may not be in the minority… Or we may both represent the minority…
swift pilot client continues using the in-built flightplan form! Now with the ICAO format.
when filing a RIF/ it is being shown as RMK/RIF/. It shouldn’t add the RMK infront.