![]() I hope the sim begins to be able to use the satellite terrain images as textures. Some places are beginning to look spectacular. Personally, I think using OSM has been a miracle boon for FG. If it is, then it is indeed broken, as its not for me. That being said, I am not sure if the Map (Canvas) is supposed to show terrain. Aircraft with a moving map display, such as the Viggen, worked properly with both the old date and the new date. i don't think the FG web server can even do https so check your browser is also not trying to force https.Īctually, as far as I can tell, in the Linux appimage version, everything seems to be working. if your browser or some other security tool is trying to enforce https everywhere. eg: -http=8080 would use in the browser.Īnd that brings up another possible problem. You should also be able to test this by not using that menu bar option, simply opening your browser while FG is running, and pointing it to where "port#" is the port you specified in your -http=xxxxx configuration line. load the external browser and point it to localhost on the port that the server is running on.Īssuming you are on windows, the first thing to check is if your firewall or some other security tool is allowing or blocking localhost connections.So looking at FGDATA/gui/menubar.xml, we see that the external browser option is called "map-browser" and that it uses nasal to ![]() Well, that change only affects the URLs used in the Phi map overlays. Personally, I think this increasing reliance on external 3rd party web services has been more and more problematic for fgfs.įoxwolfen wrote in Fri 2:04 am:I tried adding the date you suggest, but nothing changed. Someone should probably file a bug report to get this solved. The other option would be to use a Nasal script or property rule to update the AIRAC cycle based on the date set inside fgfs. Like I said previously, it would make sense to use a separate property/xml entry so that this can be easily updated automatically for each release. That's very true, and has been affecting the project and its users for several years now. Wkitty42 wrote in Thu 10:54 am:do you mean the map overlays like the one with the routing charts served from ? i don't recall the details but i think it was eventually solved for them. in a case some time back, the user's system was being blocked from that site and others for some reason. Now it is possible that you may be having another problem that is causing the maps to not be retrieved. at least the ones served from anyway.įWIW: the last time i did this on my system was when the 20211007 AIRAC was in use. at this time that looks to be 20221229 so we use that in the URLs and the maps should return. that gives me the YYYYMMDD number of the maps they are currently serving. then i select the media tab so i can look at the URL of any of the map tiles. i generally do this by going to and right clicking somewhere on the map so i can select to view the page info. find out what the current AIRAC number is that is using and change those two URLs to use it instead of the one currently in them. note the URL contains a number in the form of YYYYMMDD. With the above said, find your FGDATA/Phi/topics directory and look inside Map.js for the two sections. this is a task that must be done each and every time the AIRAC changes but for some reason no one has seen fit to do it or to automate it somehow so the current AIRAC number is fetched from somewhere and used in the URLs that Phi uses for these overlays. If the answer to the above is "yes" this is most likely because the AIRAC has changed but the code in Phi that uses the AIRAC has not been updated. Do you mean the map overlays like the one with the routing charts served from ?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |