Where did you generate that URL?
It’s missing the flight level/altitude and TAS at the start of the line throwing the error.
As for Y/Z plans, we need updates to every controller client in order to properly support it. I will probably add a middle ground at some point by implementing it on the form, but it will still be sent to the network as V/I until the clients properly support Y/Z
Hello Marcelo, thanks for the reply
It is the call I use every day with actual version of fpl and it works like a charm.
If I press the link “try the beta” I get this error.
[Edit] I added N0440F330 before the route and it works. It’s correcty removed.
If I add also on the previous version, the speed/level remains in the route item.
Umberto
Not sure if it’s been addressed.
Attempting to add the ADSB, UAT-in and Out (equipment code “U2”), there’s a phrasing error where the form doesn’t identify it as a valid code (not sure if by default, the form is looking for a 1 char equipment code, hence the error)
(would attach a screenshot, but the form doesn’t allow embedding)
(for ref if you look up the FAA Safety’s ICAO_Equip_Code_Definitions it does include a handful of two char equipment codes )
As a curiosity, what are we supposed to add for a transponder code; from real life experience flying in controlled airspace, its typically ATC thats assigning the code (even if VFR)
You’re not selecting your code, you’re describing what transponder you have installed, as per the link below. You’re fine to put C or S for most things, maybe consider E for longhaul across the North Atlantic, but I think they just lumps any modern airliner into automatic compliance anyway so shouldn’t matter much in any case.
https://support.foreflight.com/hc/en-us/articles/360050191733-ICAO-Surveillance-Code-Setup-Guide
Pilots should get into the habit of using correct equipment/surveillance codes. Euroscope and CRC, two of the primary controller clients in use, do recognize what equipment codes are filed. That information is displayed to ATC in various ways. ATC may (and should) tailor their service to you based on what equipment you have on board.
For example, if you fly in my airspace in the US and indicate that you are not RVSM capable, you’ll be limited to non-RVSM airspace (below FL290).
Sure, but that falls under the Equipment section, not the Transponder section which is a separate field (unless using old FAA codes, in which case they are linked).
While it’s a good habit to put in the correct info for your type in each field, the transponder field is not really critical at this point, because VATSIM haven’t implemented a correct simulation of modes A+C (standard equipment in the 1970s) yet, never mind Mode S.
Hi Marcelo,
through a discussion on our VACC forum it came to my attention that it is not possible to use the syntax CS/ and RTF/ (both used to define CS=callsign / RTF=radiotelephony callsign on VATSIM) in the RMK/ box as the system seems to only allow remarks that follow the syntax of official flightplan remarks.
Is there a possibility to add those two aforementioned formats to the syntax to allow them go through?
I agree it might be a bit too strict to remove those formats but why don’t the people who use that format update to a more “correct” one?
For example: RMK/CS ABC or RMK/CALLSIGN ABC?
Because this is VATSIM 
I personally am not impacted by this, because I still file directly through my pilot client and I can enter whatever I wish.
That issue has been raised before. For the initial implementation, discarding everything “not valid” was easier.
We will probably add some “custom” identifiers like CS/, but it won’t be a “free for all”, and anything outside what we consider valid will be discarded, or will have to be done via the correct way as Bernardo mentioned - they main reason being that parsers can’t really handle “everything”, and one of the reasons for the rewrite were ATC clients having issues parsing some of the remarks users put in. Having a proper structure and limiting to only “correct” remarks solves this.
I’ve been busy wrapping up an update on another part of myVATSIM, so updates to the flight plan form got pushed back a lot longer then I’d like, but I promise there will be an update soon, followed by the old form being completely removed.
I understand. If, at least, we’d have an official custom RMK for callsigns would make it easier for ATC clients (and their plugins) to extract the information and display it to ATCOs, in whatever way they deem necessary.
AFAIK ATC clients and/or plugins extract the callsign from an offline list. Not all FPLs have the CS in the remarks so the check would have to be something like "if no match found in file, look for specific section in the “remarks”.
vACCs can add callsigns to that file, so if a new or a established VA identify that their flights are not being called correctly, they can message the vACCs directly. I’ll add that not knowing the CS for the flight happens IRL and not all operators have the callsign in field 18.
I personally would prefer to see Marcelo’s time spent somewhere else than creating a specific field for callsigns when a perfectly good one (and reallistic) exists. I get Andreas’ comment saying “this is VATSIM” but it isn’t that hard to switch from RTF/abcd or CS/abcd to RMK/CS abcde is it?
Correct, as you know Euroscope refers to a file called ICAO_Airlines.txt. As you wrote, clients would need a modification of code to check ATC flightplans for remarks in the right format. If we made that an official remark it would be much easier for all parties involved.
No, it isn’t. But even this needs to be agreed on and communicated/documented for all pilots and ATC to refer to.
Having a standardised non-ICAO “CS/” or “RTF/” identifier in item 18 would allow tools to properly parse item 18 for callsign override information. RMK/ is by definition “free text” and there is nothing like any syntax in it.
While I generally applaud VATSIM’s motion to move to proper real-world ICAO FPL format very much, I can see the point of having a VATSIM-specific CS/ or RTF/ - one of the few cases where some pragmatism makes sense IMHO to cope with our VATSIMisms, but still “in the spirit” (in contrast to /V/, /T/ and /R/).
How about CS/xxx and RTF/TEXTONLY (or RTF/RXONLY) 
I understand the issue you are bringing, but it also happens IRL to not know the phonetic callsign of certain flights.
Regarding the “text only” or “receive only”, those are already included in the form, under “voice rules”
Hey all, I’m sorry if this was already covered and I didn’t see it:
I am having an issue with the beta form only; if I file through this form, the flight plan takes OK and appears to show up on vatsim-radar, but the aircraft type, equipment, and route information show up blank for the controller working. If I file the same exact flight plan through the old form, the information populates OK.
Got a generic error trying to file “TOW:1814 TAXI:5” in RMK, which admittedly is useless in vatsim, but is allowed IRL, and added by some tools such as autorouter.
See Login | EDI-GLA Real World Flightplan Database | Since 2005
I need a bit more information. Are you using a link to fill the form, or doing it manually? If you can provide a screenshot of the full form that would help me find out what’s happening.
‘:’ is not allowed anywhere, as it’s an important character of the FSD protocol
Remove the ‘:’
That is what I do.
