• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Logger 1.0 Released (XML->HDD->XML)

taguilo

Resource contributor
Messages
1,585
Country
argentina
I will post the solution to that issue in a couple of hours. I have the paging working already, but now I am experimenting with Tom Aguilo's new XMLVar module instead of Robbie's string store macros to handle string storage. I am running into one issue with the module that I will post on Toms recent XMLVar update.

Anyway, I have a working version of a 9 line screen limit and a forward/backward page button to display the flight plan names. Once the number of the plan is entered, then that flight plan file is read from HD and loaded into Flight Sim. Also working is the Flight Plan Save feature that save the current FP to HDD and appends the FP name to the FPNamesList text file.

Give me a couple of hours max.

Bob

Hey Bob, I was going to post a very simple solution to Joao's new challenge using XMLVars module when I see your comment. So I'm going to wait and see what you have in mind.:)

Cheers,
Tom
 
Messages
1,564
Country
thailand
Hey Bob, I was going to post a very simple solution to Joao's new challenge using XMLVars module when I see your comment. So I'm going to wait and see what you have in mind.:)

Cheers,
Tom

No matter what, your solutions will always be more simple and elegant than mine! Mine always seem to involve a lot of inefficient brute force.

But, I have two versions. First goes through some fancy footwork with LOGGER in the display <Element>, and the second (actually it is still work-in-progress) uses LOGGER to read the flight plan names into XMLVar string vars and then the display <Element> works with those. Maybe your solution is more like my second idea.

One side note is that this prompted me to ask Robbie for a bit more functionality out of LOGGER - the ability to specify start record number and stop record number when reading a file, and a NumberOfRecords variable to augment LOGGER:eof. I guess I will find out if I still have some leverage over his time now that I have already paid his last University tuition bill haha!!

I will post my first approach in a few minutes.

Bob
 
Messages
204
Country
portugal
I will post the solution to that issue in a couple of hours. I have the paging working already, but now I am experimenting with Tom Aguilo's new XMLVar module instead of Robbie's string store macros to handle string storage. I am running into one issue with the module that I will post on Toms recent XMLVar update.

Anyway, I have a working version of a 9 line screen limit and a forward/backward page button to display the flight plan names. Once the number of the plan is entered, then that flight plan file is read from HD and loaded into Flight Sim. Also working is the Flight Plan Save feature that save the current FP to HDD and appends the FP name to the FPNamesList text file.

Give me a couple of hours max.

Bob
Fantastic, thanks again.
 

taguilo

Resource contributor
Messages
1,585
Country
argentina
No matter what, your solutions will always be more simple and elegant than mine! Mine always seem to involve a lot of inefficient brute force.

Let me disagree the most! Your contributions are a mandatory reading for everyone; you are always willing to help and your code is clear enough to be easy to follow by anyone (something that I cannot be proud of:()

But, I have two versions. First goes through some fancy footwork with LOGGER in the display <Element>, and the second (actually it is still work-in-progress) uses LOGGER to read the flight plan names into XMLVar string vars and then the display <Element> works with those. Maybe your solution is more like my second idea.

Yes, my solution is close to your second idea. But would be great that you try to figure out first:)

One side note is that this prompted me to ask Robbie for a bit more functionality out of LOGGER - the ability to specify start record number and stop record number when reading a file, and a NumberOfRecords variable to augment LOGGER:eof. I guess I will find out if I still have some leverage over his time now that I have already paid his last University tuition bill haha!!

I will post my first approach in a few minutes.

Bob

Hmm, I think that LOGGER and XMLVARS used together might provide a complete solution for those who need to handle file I/O plus arrays of text and numbers plus portability across the entire panelset. Some fancy macros could make the whole thing very easy to code; even I could write a bunch and post them when ready, what do you think?

Tom
 
Messages
204
Country
portugal
(...) the ability to specify start record number and stop record number when reading a file, and a NumberOfRecords variable to augment LOGGER:eof. (...) Bob
In my opinion, the LOGGER would benefit from an index and data counter. I mean, a way we could easily point and read a specific line on a file, and a counter of all data entries in that file - I believe this only applies for the line format (not comma), but would make file handling easier. I was afraid to ask :eek:

Hmm, I think that LOGGER and XMLVARS used together might provide a complete solution for those who need to handle file I/O plus arrays of text and numbers plus portability across the entire panelset. Some fancy macros could make the whole thing very easy to code; even I could write a bunch and post them when ready, what do you think?

Tom

That would be welcome. I believe the wiki must be appended when this thread ends (if it will ever end...).
A can't stop thanking you both Bob and Tom for your interest on taking FS XML gauge programming further behond its domain...
 
Last edited:
Messages
1,564
Country
thailand
Joao,

Here is a “working” version. The XML is a fully functional gauge written with FS9 XML syntax and tested in FS9.1. I handle the paging issue with confusing LOGGER instructions in the display <Element> (lines 219-242), and I can already tell that reading the Flight Plan Names list into XMLVar strings and displaying those in <Element> would be an easier, much more logical way to page. I will work on that tomorrow, but by then, you may already have it working anyway. I know Tom already does.

A few other random points:

• Change the Path macro (line 4) for your particular file path.
• Number of lines per page can be specified on line 17.
• Flight Plan files and the Flight Plan Names List file all go in the same folder in Path.
• I save the Flight Plans as .csv files so I can view them in Excel (I prefer that way), but I open the file with LOGGER:eek:penWrite, not LOGGER:eek:penCsvWrite. Saving them as .txt would work equally well.
• I do not use (@c:FlightPlanTitle) as the flight plan name because the way this code uses the gps variables - Direct To - to make flight plans, the (@ c:FlightPlanTitle) is always just Direct To. So, my code uses the departure and destination airport Idents plus the number of flight plan waypoints to construct the new flight plan name.
• The Flight Plan Names list is hard wired as FlightPlanNamesList.txt.
• The gray and red boxes on the left side are mouse click areas. To page the flight plan name list, PAGE -/+, left click to go backwards, right click to go forwards.
• When the FP Names List is displayed (by clicking DISPLAY FP LIST), direct keyboard entry is enabled, so all you have to do is type in the desired flight plan number and then click LOAD FP to load it.
• The ACTIVE FLIGHT PLAN list at the bottom just confirms the flight plan details.
• To save the active flight plan to file, click SAVE ACTIVE FP. A new flight plan file will be created in Path, and the Flight Plan Names List will be appended.

There are still bugs in it, but its close enough to show that it can be done. Again, reading the FPNamesList into XMLVars and displaying those is a more logical way to do the paging and definitely the way to go.

Good luck.

Bob
 

Attachments

  • FMS FP EXAMPLE1.jpg
    FMS FP EXAMPLE1.jpg
    62.6 KB · Views: 463
  • FMS_FP_Save_Load_Test3.xml
    15.6 KB · Views: 408
  • FlightPlanTest.zip
    3.4 KB · Views: 264
Messages
204
Country
portugal
There are still bugs in it, but its close enough to show that it can be done. Again, reading the FPNamesList into XMLVars and displaying those is a more logical way to do the paging and definitely the way to go.

Good luck.

Bob
Mission acomplished!
It works as expected: loads and saves flight plans, displays stored flight plans in a list, scrolls through the stored flight plan pages at will. Tested in FSXA. I got some crashes though, don't know if specifc flight plan related. It might be a good idea to enable the back button to correct some wrong key entry, although this is just a sample. I'll post back if I track down those crashes. Thanks. :)

PS: It's also a good idea to mention this test gauge needs the logger.dll and XMLVars.dll instaled, for someone else who might be passing by ;)
 
Last edited:
Messages
204
Country
portugal
(...)A few other random points:

• Change the Path macro (line 4) for your particular file path.
• Number of lines per page can be specified on line 17.
• Flight Plan files and the Flight Plan Names List file all go in the same folder in Path.
• I save the Flight Plans as .csv files so I can view them in Excel (I prefer that way), but I open the file with LOGGER: openWrite, not LOGGER: openCsvWrite. Saving them as .txt would work equally well.
• I do not use (@c:FlightPlanTitle) as the flight plan name because the way this code uses the gps variables - Direct To - to make flight plans, the (@ c:FlightPlanTitle) is always just Direct To. So, my code uses the departure and destination airport Idents plus the number of flight plan waypoints to construct the new flight plan name.
• The Flight Plan Names list is hard wired as FlightPlanNamesList.txt.
• The gray and red boxes on the left side are mouse click areas. To page the flight plan name list, PAGE -/+, left click to go backwards, right click to go forwards.
• When the FP Names List is displayed (by clicking DISPLAY FP LIST), direct keyboard entry is enabled, so all you have to do is type in the desired flight plan number and then click LOAD FP to load it.
• The ACTIVE FLIGHT PLAN list at the bottom just confirms the flight plan details.
• To save the active flight plan to file, click SAVE ACTIVE FP. A new flight plan file will be created in Path, and the Flight Plan Names List will be appended.

There are still bugs in it, but its close enough to show that it can be done. Again, reading the FPNamesList into XMLVars and displaying those is a more logical way to do the paging and definitely the way to go.(...)
Hi Bob,

I've been using and testing this code, and I found something I haven't noticed before: the logger ins't loading some flight plans correctly, and this is not a problem on this gauge, but the code itself, which you released early on, after the logger was presented. The problem is when loading flight plans with no region characters on their waypoints, the logger ignores them and the resulting flight plan is loaded with only 2 waypoints - the starting and destination airports. Just try to save a flight plan in Europe with several waypoints, and then load it again. If you check the file, all the waypoints are there - saving is ok - but when loading, the "V", "W", "N" waypoints are lost. Can you check this out?
 
Messages
1,564
Country
thailand
Hi Bob,

I've been using and testing this code, and I found something I haven't noticed before: the logger ins't loading some flight plans correctly, and this is not a problem on this gauge, but the code itself, which you released early on, after the logger was presented. The problem is when loading flight plans with no region characters on their waypoints, the logger ignores them and the resulting flight plan is loaded with only 2 waypoints - the starting and destination airports. Just try to save a flight plan in Europe with several waypoints, and then load it again. If you check the file, all the waypoints are there - saving is ok - but when loading, the "V", "W", "N" waypoints are lost. Can you check this out?

Hello Joao,

Sure, I will take a look. But the problem sounds strange indeed. To add a waypoint to a flight plan using gps module variables, one needs to specify the waypoint ICAO string - (the 12 character fs9gps ICAO, not Ident), or the lat and lon of the waypoint. The only* facilities I am aware of that do not contain a region identifier in the ICAO string are airports. Each airport has a unique Ident, but the same is not true of VORs, NDBs or intersections. So, those facilities must contain the region code in the ICAO to eliminate ambiguity. Consequently, if we try to enter an ICAO starting with a letter other than "A" but has no Region code in character positions 2 and 3, it is an invalid ICAO and the gps module should ignore it. *The exception is an ILS ICAO which starts with "V", but it also contains the owning airport Ident in character positions 4 through 7, so it's unique without the region code.

If an active flight plan was first saved using the code I provided, then either the waypoint ICAO or lat/lon in the case of Type 5 User Specified waypoints is saved. All of those ICAOs will, by definition, be valid. How did you create the flight plans that are giving you problems? Did you use the save flight plan code I provided?

Anyway, those are my initial thoughts, but I could certainly be missing something, so I will look into it a little more. Definitely give me the details of the waypoints in question if you used my save flight plan code and the region code is missing.

On another note, following up on your suggestions in this thread, Robbie updated LOGGER to include a skip command (skip the first X records when reading a file) and a countRead command (return the number of records that have been read since opening the file). As well, he changed LOGGER's response to a potential openRead failure thanks to a suggestion from Tom Aguilo. I've tested it in FS9 and he should be uploading the FSX and FS9 modules to the Blackbox website soon.

Regards,

Bob
 
Messages
204
Country
portugal
(...) Definitely give me the details of the waypoints in question if you used my save flight plan code and the region code is missing. (...)
Ok, here I send you a flight plan created by the FSX flight planner; it's a simple flight LPPR to LFLL, and you can create it too, using the "ingame" flight planner. Then, save it using the logger and then reload it again using the logger (I mean your logger code). If you look at the logger saved flight plan, everything seems ok, but when you load it back, the result is an airport to airport flight plan. Something is not right with the variable FlightPlanNewWaypointICAO, maybe it is FSX related only?
 

Attachments

  • LPPR-LFLL.zip
    728 bytes · Views: 274
Messages
1,564
Country
thailand
Joao,

I am not sure what is happening because it works fine for me. I'm running FS9.1 and would be a little surprised if this is a bug in FSX, but who knows???

Attached is my sequence:

• SLIDE 1 - I created your flight in FS's Flight Planner, loaded it as the active FP, and then used my FP Save code to save it in my waypoint format into a file named LPPR-LFLL-WPT5 on my desktop.
• SLIDE 2 - This is the file that was saved to desktop. I use .csv rather than .txt but there is no difference. All the ICAOs are valid, and the VOR and Intersection ICAOs all have the necessary Region identifier.
• SLIDE 3 - Next, I loaded a saved flight from the US and activated it. The Flight Plan detail is listed in the center of the gauge.
• SLIDE 4 - And the map view of the flight path
• SLIDE 5 - Next, I clicked DISPLAY FP LIST and all the FPs in my FlightPlanNamesList.txt file were listed. In this case, its just the LPPR-LFLL flight plan, so I selected "1" and clicked LOAD FP. It successfully loaded as shown by the Flight Plan detail in the center of the gauge
• SLIDE 6 - And, the map view of the flight path

So... no problems on my end. This is a strange one. Good luck!

Bob
 

Attachments

  • LPPR-LFLL Test.zip
    764.2 KB · Views: 274
Messages
204
Country
portugal
Looks like I messed it again :eek:

The files I was testing the logger with, were .pln format, and I thought they were saved by the FSX Flight Planner... I guess they weren't... they were saved by another flight plan aplication (probably fsbuild?), where the region digits weren't being saved. If you look at the file I attached in my previous post, the region tag isn't there, and that's why the logger wasn't reading them. The logger, as your code, they are ok, sorry for the trouble. As long as the flight plan is saved by the FSX planner, everything works as it should.
 
Messages
1,564
Country
thailand
As long as the flight plan is saved by the FSX planner, everything works as it should.

To expand a little on your last statement, my code uses the gps variables to save the waypoints of a loaded flight plan that is running in Flight Simulator and under control of the fs9gps module. The code goes to FS's gps module for all of its information and commands. If a third party nav application is used that bypasses the gps module in some manner, then my code is not relevant in the first place.

When you look at the the flight plan file that my code saves, you find that it is the waypoint list only, in the form of a 12 character ICAO or a lat/lon pair. All the ICAOs in that file will be valid by definition because the code simply writes FlightPlanWaypointIcao or FlightPlanWaypointLatitude / Longitude to file. And if the flight plan was loaded in FS when it was saved, then all of its waypoints will be defined by an ICAO or lat/lon pair because that's the way the fs9gps module defines waypoints.

Conversely, when my Load Flight Plan code reads a flight plan from file, it presumes that the file was written by my Save Flight Plan script, and the file is simply a list of the ICAOs or in the case of a Type 5 user specified waypoint, a lat / lon pair preceded by the string 'LATLON'.

BTW, I have never claimed that creating and saving flight plans using FS's fs9gps module is robust or ideal or that the gps module was even intended for this purpose - it was not. The Flight Simulator gps module provides no commands/variables to write (set) Flight Plan Type (VFR or IFR), Route Type (Direct, VOR, Low Alt or High Alt Airways), Cruising Altitude or automatic engagement of Flight Sim's ATC module. Flight Simulator's Flight Planner is still required to set those variables. Some third party flight planners may be able to do all of that too, but I do not know.

My script is what we can do in the XML world using the gps module.

Bob
 
Messages
204
Country
portugal
Clear explanation, as usual, thank you.

I made this slight improvment to your save/load code (written in red):
Code:
<Update Hidden="No">
	<!-- SAVE FLIGHT PLAN (WRITE FP TO FILE) - LOGGER WRITE  -->	
	<!-- THIS ROUTINE SAVES ONLY THE FLIGHT PLAN WAYPOINTS  -->
	(L:SavingFlightPlan, enum) 1 == 
		if{ 
			<!-- WRITE WPT AS LAT LON PAIR OR ICAO DEPENDING UPON WPT TYPE -->	
			(L:NumberFlightPlanWptsSaved, enum) (L:NumberFlightPlanWpts, enum) &lt; 
				if{ 
					:1001
					(L:NumberFlightPlanWptsSaved, enum) (>@c:FlightPlanWaypointIndex)
					(@c:FlightPlanWaypointType) 5 == 
						if{
							[COLOR="Red"](L:LatLonWapointNumber, enum) ++ (>L:LatLonWapointNumber, enum)
							'WPT' (L:LatLonWapointNumber, enum) int scat (>C:LOGGER:string)[/COLOR]
							(@c:FlightPlanWaypointLatitude, degrees) (>C:LOGGER:number) 
							(@c:FlightPlanWaypointLongitude, degrees) (>C:LOGGER:number) 	
						} 
						els{ 
							(@c:FlightPlanWaypointICAO) (>C:LOGGER:string) 
						} 
					(L:NumberFlightPlanWptsSaved, enum) ++ (>L:NumberFlightPlanWptsSaved, enum)
					(L:NumberFlightPlanWptsSaved, enum) (L:NumberFlightPlanWpts, enum) &lt; 
						if{ g1001 }
				}			
			<!-- CLOSE WRITE FILE, THEN UPDATE THE FLIGHT PLAN NAME LIST. -->
			(L:NumberFlightPlanWptsSaved, enum) (L:NumberFlightPlanWpts, enum) == 
				if{ 
					1 (>L:FPWasSaved,bool)
					1 (>C:LOGGER:closeWrite)				
					0 (>L:SavingFlightPlan, enum)
					@Path 'FlightPlanNamesList.txt' scat (>C:LOGGER:openAppend)
					'NewFPFileNameShort' @FindIndex
					@ReadString (>C:LOGGER:string)
					1 (>C:LOGGER:closeWrite)
				}
		}

	<!-- LOAD FLIGHT PLAN -->	
	(L:LoadingFlightPlan, enum) 1 == 
		if{ 
			(L:LoadingCyclesCount, enum) ++ (>L:LoadingCyclesCount, enum) 
			(L:EOFReached, enum) -1 == 
				if{ 
					:1100
					<!-- CHECK IF WAYPOINT IS A LATLON. IF YES, USE LAT LON TO ADD NEW WPT.  IF NO, USE ICAO TO ADD NEW WPT -->	
					(C:LOGGER:string) d 	
					(C:LOGGER:eof) 1 == if{ 1 (>L:EOFReached, enum) g1101 }
					[COLOR="Red"]slen 12 &lt;[/COLOR] 							
						if{
							[COLOR="red"](>@c:FlightPlanNewWaypointIdent)[/COLOR]  
							(C:LOGGER:number) (>@c:FlightPlanNewWaypointLatitude, degrees) 
							(C:LOGGER:number) (>@c:FlightPlanNewWaypointLongitude, degrees) 
						}							
						els{ 
							(>@c:FlightPlanNewWaypointICAO) 
						} 
					(L:NumberFlightPlanWptsLoaded, enum) (>@c:FlightPlanAddWaypoint)	
					(L:NumberFlightPlanWptsLoaded, enum) ++ (>L:NumberFlightPlanWptsLoaded, enum) 
					g1100				
				}

			<!-- MAKE WAYPOINT 1 = ACTIVE, THEN CLOSE READ FILE -->		
			:1101
			(L:EOFReached, enum) 1 ==  			
				if{ 					
					1 (>@c:FlightPlanActiveWaypoint)
					1 (>C:LOGGER:closeRead)		
					0 (>L:EOFReached, enum)
				}	
			<!-- SKIP 3 CYCLES THEN UNLOCK ACTIVE WAYPOINT, CLOSE LOADING FP ROUTINE. DONE. -->			
			(L:LoadingCyclesCount, enum) 3 ==   				
				if{ 
					0 (>@c:FlightPlanIsActiveWaypointLocked)
					0 (>L:LoadingFlightPlan, enum) 	
					1 (>L:FPWasLoaded, bool)
				}
		}
</Update>
We also must add the following to the "SAVE FLIGHT PLAN" mouse area, to reset the waypoint counter:
Code:
<Mouse>
	<Area Name="SAVE CURRENT FP Button" Left="5" Top="5" Width="15" Height="15">
		<Cursor Type="Hand" />		
		<Click Kind="LeftSingle">
			(...)
			[COLOR="red"]0 (>L:LatLonWapointNumber, enum)[/COLOR]
		</Click>
	</Area>
	(...)
</Mouse>
This way we have ident names WPT1, WPT2, ... for LATLON waypoints when displaying the flight plan.

Code corrected for PT region conflict (Palau, Micronesia).
 
Last edited:
Messages
1,564
Country
thailand
Joao,

That's a nice upgrade, I like it!

Bob


Oops. On second thought, I believe there is a problem using 'WPT' as you indicate. In your code, you look for 'WPT' as a sstr of the record returned by LOGGER:string. However, ICAOs of Intersections in Micronesia, Palau (if any; I haven't actually checked), whose region code is PT, will begin with 'WPT', so for our friends in the Philippine Sea, maybe that won't work :)

Why don't you add a slen 12 &lt; &amp;&amp; to that sstr line, that ought to take care of it.

Bob
 
Last edited:
Messages
204
Country
portugal
Joao,

That's a nice upgrade, I like it!

Bob


Oops. On second thought, I believe there is a problem using 'WPT' as you indicate. In your code, you look for 'WPT' as a sstr of the record returned by LOGGER:string. However, ICAOs of Intersections in Micronesia, Palau (if any; I haven't actually checked), whose region code is PT, will begin with 'WPT', so for our friends in the Philippine Sea, maybe that won't work :)

Why don't you add a slen 12 &lt; &amp;&amp; to that sstr line, that ought to take care of it.

Bob
It's a good point, and you're right, waypoints with region characters PT do exist.

The problem is that adding a second condition to that line of code, messes up the whole display :confused:

There's a flight plan attached with user waypoints and local intersection in the PT region. The saving is ok (I included a saved .csv) but loading doesn't work as it should. Wanna try to figure this out?
 

Attachments

  • PTKK-PTSA-WPT7.zip
    1 KB · Views: 253
Messages
1,564
Country
thailand
It's a good point, and you're right, waypoints with region characters PT do exist.

The problem is that adding a second condition to that line of code, messes up the whole display :confused:

There's a flight plan attached with user waypoints and local intersection in the PT region. The saving is ok (I included a saved .csv) but loading doesn't work as it should. Wanna try to figure this out?

Hi Joao,

I think the easiest way would be to just eliminate the 'WPT' sstr 0 == condition, and have that line read only slen 12 &lt;.

All ICAOs have a 12 character string length, even in cases where the Ident is less than 5 characters long. So, User* waypoint Idents with slen less than 12 will not create a conflict.

In fact, FlightPlanWaypointIdent can accomodate slen only up to 10, so a conflict using this method should not be possible in the first place. Therefore, with your method of naming User waypoints, you can safely have up to WPT9999999. Obviously sufficient.

Assigning a string such as 'WPT123' to FlightPlanNewWaypointIdent does not update the gps database, of course. Idents with string length greater than 5 do not exist in the fs9gps database, and consequently, ICAOs have space for Idents up to slen 5 only. When adding a User waypoint to a flight plan, the added waypoint will not have an ICAO.

This works well and is a nice upgrade!

Bob

*User waypoint = a waypoint added by specifying latitude and longitude rather than ICAO
 
Last edited:
Messages
204
Country
portugal
Hi Joao,

I think the easiest way would be to just eliminate the 'WPT' sstr 0 == condition, and have that line read only slen 12 &lt;.

All ICAOs have a 12 character string length, even in cases where the Ident is less than 5 characters long. So, User* waypoint Idents with slen less than 12 will not create a conflict.

In fact, FlightPlanWaypointIdent can accomodate slen only up to 10, so a conflict using this method should not be possible in the first place. Therefore, with your method of naming User waypoints, you can safely have up to WPT9999999. Obviously sufficient.

Assigning a string such as 'WPT123' to FlightPlanNewWaypointIdent does not update the gps database, of course. Idents with string length greater than 5 do not exist in the fs9gps database, and consequently, ICAOs have space for Idents up to slen 5 only. When adding a User waypoint to a flight plan, the added waypoint will not have an ICAO.

This works well and is a nice upgrade!

Bob

*User waypoint = a waypoint added by specifying latitude and longitude rather than ICAO
I agree. I already corrected the code above. Thanks.
 
Top