arrex

Dears, I was curios to understand, for NOAA weather, what the download interval is. And if there is a chance to freeze the download. Scenario I am often faced: between the planning and execution of my flight might take 1 day (free time is whatever it is....)... but weather updates in LNM in the meantime so I see discrepacies with what I execute...

I don't think so. You're better be a programmer to set this up for compiling. I don't think either.... mine was more an inquire if this is already available somewhere to easily modify, otherwise forget about it....

It's really going towards details here.... for example class D in US do not require ATC clearance, but ATC contact.... transponder in europe is compulsory in all controlled airspaces... if some personalization would have been possible, i would have done it (as the colors or airspaces....)

I think there is a misunderstanding. I have no problem with performance, airspace labels, and found the options you are showing on airspace label. Also I downloaded a little_navmap_mapstyle.ini and i did the changes i wanted. I was referring to the text of airspace, appearing in the information tab. For example, for class D it shows "Controlled, IFR and VFR, ATC clearance required.". Was wandering if it is possible to customize this text...

Ok, thanks Alex. Now I feel like the word not allowed that didn't read the changelog 😄 ... actually i read it but i missed the point apparently, so again, alzheimer... 😄 mh, interesting. Does it need to recompile or it's something doable a-posteriori? This i didn't follow.....

Good call. Indeed now it works.... why isn't it present in the default installation is still not clear, but ok....

I know, I modified them in ver 2.8.12, but now the file is not present. There is only this file here: little_navmap_mapstyle.ini_update-backup.1 Which contains my modifications for the previous version....

I see... the file little_navmap_mapstyle.ini is not present in my folder. There is the backed-up version of 2.8.12 there only.... I am afraid it takes a more complete compiler than the mingw I have installed here....

Thanks for answering. Didn't realize there was already a manual for ver. 3, but ok, that's aging 😉 More specifically: 1. I read 75.3, but in the file little_navmap_nightstyle.ini i don't find anything related to the color of different airspaces.... or it's again my alzheimer in action 😉 ? 2. I actually like them. I don't want to disable. I would like to be able to edit this text to add even more information useful for myself....

Hi, quick questions: 1. in version 2.8.12 I could set the color/line-style of the airspaces by editing the file little_navmap_mapstyle.ini. Is this option gone completely or is it replaced by some other function, which i couldn't find? 2. I noticed that in the info of the airspace now there is this informative line stating, for example of a class C "Controlled, IFR and VFR, ATC clearance required, transponder required.". Not sure if this present also before. Is there a way to edit this text, or it is hardcoded? Thanks Greetings, Antonio

Ok, will send it now....

I can provide you with the BGL, but: 1. you have to tell me how to pass it to you 2. it's a normal ADE file... nothing particular 3. from what you wrote i already see the problem: for the FSX-P3D world (not sure for Xplane and MSFS), you have only to check for ident, region and the "proximity".... frequency and type (guess by type you mean VOR, DME, VORDME or VOT) can be altered by programs like ADE and it's normal way of working to do it. The criterion for "overwriting" is only ident, type and position. In my file i have indeed changed the frequency and hence i get the duplication.

Thanks. Regarding VOT it is not used because FS (and AFAIK P3D) do not use them. And hence it becomes a trick to hack FS limitations: if you need to "delete" a VOR, you can set it in an addons as VOT, so it effectively disappears from the simulator.... Some sceneries (including mine) are using this trick. Was wondering if this can be somehow implemented in LNM (i.e. avoid showing VOTs, or listing as something else, that you can disable, or having a map option "show VOTs")... just a new feature, low priority, suggestion....

I see. From what i see, most properties are properly taken from addon airports (layout, frequencies).... I actually only found this inconsistency on the rating. Not a big deal anyway. That's fairly correct. You cannot exclude any type of navaid, but you can override some information. For VOR these are the type (VOR, DME, VOR+DME or VOT), the range and the frequency. If the navaid is moved more than a certain amount, it "gets duplicated". What I noticed is that if I just change the frequency and not the position, LNM duplicates it. So something must have gone wrong in the code. And I also noticed that VOR defined as "VOT" are simply listed as VORDME, like that property is not considered.

Thanks for answering. I see. So should be a problem of my installation if there i never get the star for addon sceneries, even if they are recognized as such. Final question (unrelated): i noticed that if I use ADE to modify some default VOR or navaid (mainly frequency), in LNM it gets duplicated. It finds the original one and the updated one, and keeps displaying both... is this normal? Also it seems like there is no code implemented to VOT-type of VORs.... VOT are useless in general, but it's a trick to make a default VOR disappear withing FS....

Hi, I'm running LNM beta 3.0.1, but the same problem is also in 2.8.12. I am not fully understanding the airport rating. According to the instructions you get one start for: 1. Addon 2. Parking 3. Apron 4. Taxiways 5. Tower Besides it's a bit questionable if Apron and taxiway should be separated (many addon airports don't have aprons by design, as they use ground polygons), i noticed that the "addon" flag only works if the scenery is ONLY present out of the main scenery folder, i.e. it's not existing in the default airport database. If it's an update on an EXISTING default airport, then it does not get the start.... is there something wrong with my installation, it's a bug or a wanted feature? PS: "addon" is correctly listed in the "facilities" list of the airport information tab as expected, and the yellow overlay mark is also present, so LNM recognizes it as an addon airport.

Some of them yes.... but FS abuses of them.... many do not exist at all and are just fictitiously created.... This is the best doc around for FS9/FSX/P3D Database and GPS dll: GPS Guidebook Pag 12 on the ICAO format of MS simulators.... But probably we are deviating here... after all this 12 character icao is just the sum of type, region, airport icao and icao identifier. So if you read those elsewhere separately, you are already doing the job, irrespective on how the internal FS database can be queried....

For FSX and P3D the unique ICAO is actually a 12 character string. Unified for all waypoint types. The FSX+ unique identifier is: char 1 -> Type (A= airport, V = Vor ....) char 2-3 -> ICAO Region char 4-7 -> ICAO of the referring airports (typically only present in terminal waypoints) char 8-12 -> ICAO identifier So an intersection LAGON can be: WLILIPQLAGON if it is a terminal waypoint belonging to LIPQ or WLI____LAGON if it is a navigation intersection (unique within region "LI") Typically. terminal waypoint are not present normally in any real database, but they are there to help drawing the approach procedure. Probably what you suggest is the best: if you have a record for airport, use this, otherwise you fall back on distance. Should be working then.

aaah, that's the problem indeed! Duplicate waypoints on 2 nearby airports. I made an extra test: LFPB RWY 06 comes in my scenery with a CI06 that is on the extended centerline of LFPB at about 10 NM further.... and that makes it 5.7 NM from LFPO. Point CI06 of LFPO is 9 NM from LFPO, so the algorithm picks up erratically the one of LFPB as the closer of the two. Indeed is a marginal case, and happens twice for that airport (CF06 and CI06 for Vor and ILS approach)....unlikely of representing a significant problem. I solved it by renaming two points in LFPO. Out of curiosity, why using the distance criterion? Wasn't reading the airport record easier? I ses in the "navaid information" page that the referring airport, for both, is correctly identified....

Need to find it.... not easy, because i need to find a duplicated navaid name in the same region actively used in a procedure of another airport of the same region.... But it's strange: I created deliberately a faulty case (added 2 procedures on 2 airports with the same terminal waypoint name), but ... but.... it is correctly found. No idea what happened with my addon LFPO that found the navaid of Le Burget.... 😞 Maybe a problem with that scenery. I will dig more and if I find another problem I will flag it to you. Sorry for the inconvenience

fsx db and procedures. Navigraph disabled. I found a couple of cases, but all with addon scenery, so cannot immediately point out to a case. Question is: for FSX DB approach, how are terminal waypoints specified in the procedure selected? I have the feeling only by region and icao_ID. The criterion "Airport ID" is ignored.

After some days of intense use, I have the final report on use with FS9. Obviously offline. That's a pity as many amazing LNM functions are inhibited. But I consider this a given. Database: i did not find any problem, with hundreds of addon and custom made scenery installed. I Airport Rating: I don't fully understand it. How is it to be computed exactly? According to the instructions, Addon, Apron, Taxyways, Parking and Buildings should each add a "star". Most of my airports have always 2 or 3 stars, even if LNM finds more items Example this airport should have at least 4 stars: Grosseto (LIRS) ★★★−− Facilities ALS, Add-on, Aprons, Avgas, Helipads, Jetfuel, Parking, Procedures, Taxiways, VASI Is it a problem with FS9 or a bigger problem? Not sure. Not a big deal if it's a FS9 problem, if it's a more general problem, you can put it in the buglist.... Flight plan export: not very good here. I unsed initially the format "Blackbox simulation airbus", which is ok-ish, but not satusfactory enough. The format would require 3 easy modifications to be correct. Should be a relatively small task so I would ask if it is possible to implemented it in future versions.These are the corrections: 1. Add the static line AppVersion=9.1.40901 at the top of the file, immediately below the [flightplan] key. The mere presence of this line allows to link the waypoints with the navaids database for use with the internal navitagion module, the kneeboard etc.... 2. Add decimale precision in all coordinates Example of current coordinates: departure_id=LSZH, N47* 27', E8* 33', +001416.00 Example of desired coordinates: departure_id=LSZH, N47* 27.25', E8* 33.61', +001416.00 3. Slightly modify the definition of waypoints, adding ahead 3 fields used for linking with the database Example of current waypoint: waypoint.5=ZH553, I, N47* 25', E8* 21', +005191.94,U843 Example of correct waypoint: waypoint.5=LS, LSZH, ZH553, ZH553, I, N47* 25.33', E8* 21.37', +005191.94,U843 Some hints here: the red field is the icao_region. To use for Intersections, Vor and NDB, empty for Airports and "custom" waypoints. Empty means it's a just a comma;: "waypoint.5=, " The greed field is only used for "terminal waypoints", and it's the referring airport name. For all other type, the field is empty The blue field is a repetition (for the database search) of the name of the point. Empty for "custom" waypoint Regards!

Hi, I would like to report a problem with Approach procedure read by BGL files: many procedures refer to terminal waypoints (i.e. waypoints that exist in an airport record) in contrast to non-terminal waypoints (i.e. present out of the airport record). But names of terminal waypoints are repeated multiple time for all airports. Example many airports have points named "CI07"... even in the same icao_region. LNM only seems to look for the icao_region and the waypoint name. So if a procedure for, example, LFPO links to "CI07", LNM looks for this CI07 in the whole "LF" icao_region. Multiple are found, for example I have one also in LFPB. LNM uses the first found alphabetically. That is a problem as the wrong WP is used, a wrong procedure is displayed and I guess this also reflects into a wrong export. I guess the solution would be to also track the airport name for terminal waypoints.

Sure, i am even suggesting to maintain fs9 as officially "Unsupported". PS: I did more tests. Database is 100% working properly, including the magdec and addon sceneries (afcad and bglcomp format). Export format with "Blackbox simulation airbus" is good enough to generate FS9 .pnl, although not 100% perfect.

Fantastic. Maybe you should consider to add it in a future release as an "unofficial" support; you just need to add a reg key to check and add as default export the "BlackBox Simulations Airbus". If you want to overdo, disable the "connect" functions