Posts by crispy136

    Yes I am on the latest version of FS2 (i have subscribed to the BETA edition), and I am running it in full screen.


    Finally worked out that the problem was caused by the Microsoft game bar, used for screen shots and video recording. Disabled that and the problem went away.

    Recently purchased a new system with a Nvidia RTX2060 video card. When I reinstalled FS2 I found that the mouse pointer gets stuck over the aircraft selection option in the main screen. This problem is repeated is exactly the same position of the screen when flying any aircraft. The original FS2 pointer stays locked in place on the screen while the Windows pointer appears (slightly smaller) and you have two mouse pointers on the screen. Once you move a cm or 2 off this area, the windows pointer disappears and the FS2 pointer becomes active again. Makes it difficult to select anything in this part of the screen, as when this happens the FS2 clicks don't work. Problem occurs using either open GL and Vulkan and the problem is not repeated in other Steam games . Normal screen captures don't show the double curser so used my tablet to take a picture of the problem.


    Thanks. I initially assigned the prop +- to 2 adjoining buttons on my joystick. Then whe that didnt work also tried assigning to 2 keyboard buttons. I used [] as they didn't appear to be assigned to anything. The only axis I have is the throttle so didn't assign it to any lever.

    About a year ago I logged a problem with the key assignment of prop levels on the Dash 8. You can assign the prop controls to a keyboard key or joystick button and both work with other FS2 prop aircraft like the Baron or King Air but not with the Dash 8. This is an introduced problem as it initially did work on the Dash 8 when it was first released, but was later disabled by an update I assume. When will this be fixed or is there a work around I can use?

    Hi Chris


    Is the Australia terrain mesh tutorial still available? I couldn't find the the link.


    Many thanks


    Ian

    Hi Ian, The tutorial is still available for download. You won't see the download link to the tutorial document unless you are logged in to flight-sim.org. Once you have logged in a blue download box appears in the top right of the screen. Regards, Chris

    i used the one in the link above but there seems to be a problem with the ausralian elevation page see pic

    I got the same error so there does seem to be a problem with the data page at present. In Australia, all Government agencies shut down over the Christmas/New Year period. My guess is that either something has broken and there is no-one to fix it, or they have brought that part of the system down for maintenance since everyone is away. You could log a support request with the website owners, but I expect they won't be back until 8 Jan.

    I get red error messages for each of the "CreateAF2Building" lines saying that 4 arguments are required.

    HI Ian, You may be using a different version of ScenProc. I'm using a ScenProc build dated 16/10/18. You can find this information right at the top of the screen after the version number. I had a look through the changelogs for Scenproc and can't see any changes to CreateAFSBuilding code since 16/10/18. Try updating and see if the problem goes away.

    These 2 lines control the placement of the houses on each side of the street.

    PlacePointsAlongLine|FTYPE="LINE" And highway="residential"|SINGLE|16;18|20;21|0|String;type|build1|hdg

    PlacePointsAlongLine|FTYPE="LINE" And highway="residential"|SINGLE|16;18|-20;-21|0|String;type|build1|hdg


    The value |16;18| sets the distance between houses to 16 to 18 metres. I was originally using 20;25 but found it was too sparse for cities, so give that go first then increase it until you get the desired density.


    The value |20;21| and |-20;-21| sets the distance of the houses from the centre line of the street to 20 to 21 metres. Increase this for wider footpaths. There are a pair of lines for each street with one set being negative. You need to change both together or you well get houses closer to the street on one side.


    Even with increased house spacing it look like you will need an include, to get rid of the houses in the background. Unfortunately OSM seems to consider any street with a house on it as residential, even though there might be just a couple.

    Have released my housing fill template to create houses where there are no housing footprints in OSM. The script is run separately from my other template which will continue to be developed. This means you will need to insert references to the 2 TOC files into your airport TSC file as indicated in the Honolulu (PHNL) TSC below.



    The template uses residential roads to decide where to place the houses. This has some limitations. For instance it is not possible to have it align the houses with the photo imagery of the houses, and you will find some small areas with no houses. Houses will not appear on other road types as these proved difficult to use successfully. The script is also limited to only houses, no larger buildings are generated .


    This template is designed so it won't create overlaps of buildings, or plants generated by my other template and has no impact on street lighting. The template is not 100% perfect so you may find the odd house where it shouldn't be, but houses are filtered out of most areas where they shouldn't be.


    As the template uses residential roads, and these sometimes appear in rural areas in OSM, I found you can often get lines of houses on a single street in the middle of a rural area. To combat this problem, I create an include polygon using Google Earth to define the urban areas of my cities and towns. You can run the script without an include but you will need to comment out a few lines of the template. The lines to comment out are documented in the script itself. The script makes no allowances for exclude polygons, as it is a lot easier to define an urban area to include than it is to define a rural area surrounding an urban area to exclude.


    You can have multiple polygons in your google earth include.kml file. And I also create the polygons for my whole city area, then use the same include for each level 10 area I am generating cultivation for, so there is no need to try and align the size of your include with the size of the OSM data area. When creating your include polygons in Google Earth it is best to set opacity to 40% so you can see the underlying urban areas as you create the polygon. This appears on the "style color" tab on the popup window that appears when creating or editing Google Earth polygons.


    Its a pretty quick process once you get the hang of it. Anyone wanting to know how to create Google Earth Polygons should look at the original "learning cultivation" video. The same method is used to create include polygons required here, as detailed in the video to create exclude polygons. https://www.aerofly.com/dokuwiki/doku.php/sdk:scenerydev4. Larger city areas may not require the use of an include polygon.


    Unlike my original template which is always attached to the first post in this thread, this one is attached to this post. Just rename it as .spc, create your include polygon (or comment out the noted lines) and you're good to go. As with my other template this one also works best when you are using a level 10 sized area from OSM. Run time was 5 minutes for my level 10 sized area in Honolulu and 40 minutes for my level 10 area for New Orleans which is mostly houses. The resulting TOC files are not large but it does require a lot of calculations to create them. My other similar sized test areas took 5 to 10 minutes. CPU usage peaks at 90%+ for some parts of the script but varies from step to step to as low as 15%.


    Example of a Google Earth include polygon. Not separate polygons for the satellite towns to the north and north east of the main city area.



    Example of houses created for Honolulu, before on the left and after on the right.


    Example of what can happen when you don't use an include polygon to define your urban areas.


    Sorry, its not ready yet. Have fine tuned the performance a little further since my last post, but still a few things to resolve. At present it is a separate template you have to run, creating a second toc file to be added to your airport tsc. It runs on the same map.osm file as the OSM sourced building, plant & light data though. Will probably stay as a separate template as I think it is going to be too difficult to integrate it into the existing template. My initial test of a very small area took 40 minutes, so I had to fine tune the template for better performance in order for it to run for a level 10 sized area. While the level 10 sized area in Australia shown in the screen shots above ran fine and completed in about 10 minutes, New Orleans ran for 2 hours before I gave up and cancelled the job. After the fine tuning the template a little more, the Australian test area running time dropped to 5 minutes and New Orleans completed in 10 minutes. CPU usage originally peaked at 15% in earlier tests but now peaks at 70% so scenProc is working harder. I'll also see if I can apply these performance enhancements to the main template.


    In the meantime here are some screen shots of testing done in New Orleans. Once again the left shot is OSM building data only, while the right has the generated buildings from the new template. A few of the original buildings may look like they are missing or different, but this is not the case. FS2 randomly assigns building colours at startup so a building with a white roof may be less visible with gray roof the next time you load FS2.


    Looking towards Louis Armstrong airport where there is little OSM building data.



    And here a little further to the east and integrated into an area that already had a lot of OSM building data. Notice OSM buildings on the right are not compromised, even though they were included in the area the scenProc script was generating.


    Have been working on a project to add houses where no building footprints exist in OSM data. It is still work in progress but I have managed to add housing using OSM data not related to buildings. The left image shows the cultivation using just OSM data, while the right image shows buildings added with the new housing process. The limitation is that the new houses don't occupy the footprint of the houses in the textures, but you won't find them in the middle of roads, rivers, plant areas or any area with existing OSM recorded buildings. Only tested in Australia so far and not sure of the impact of denser areas.


    Additional housing added without impacting existing building, plants or lights.



    Added housing follows street layout


    Houses everywhere now.


    Had a quick look at other refineries in the USA and many do record the storage tank attribute in OSM, so hopefully you won't need to use an exclude everywhere.


    I have tested the change in the template and confirm that it does work where this attribute is recorded in the OSM data. I will include it in the next template update.


    I added it to "Filter Buildings" section as "AddAttributeIfInside|building="*"|man_made="storage_tank"|String;skip|yes" rather changing the "CreateAF2Building|building="yes"" lines. This way it works for all building categories rather than just those classified as "yes". This should cater for some inconsistencies in OSM data.

    I tried the "storage tanks" code and it failed. It actually added even more houses in the "storage tanks" area

    Hi Ray. I hadn't had a look at the area before as I was just responding to the code supplied by Ken. When I had a look at your area unfortunately none of the storage tanks I looked at have the attribute "man_made" = "storage_tank". As a result the code supplied by Ken will not be effective here.


    When looking at your problem I found I have a similar problem for an oil refinery near my local airport. Luckily these tanks do have the "man_made" = "storage_tank" attribute in the OSM source data, so I'll include the fix in my next template release. At least this will remove tanks in some areas.


    All your tanks sit in an industrial area, so you could use that area to exclude any buildings (ie the tanks) in much the same way my template excludes airport buildings automatically. But unfortunately that would also exclude any buildings in the same area as well. It would also prevent buildings appearing in other industrial areas, which is probably not desirable.


    I think your best option is to manually create an exclude for the area with the tanks.


    You are limited to what detail is recorded in OSM and sometimes really odd things are classified as buildings. For instance static historical ships, like the USS Missouri in Hawaii, are classified as buildings in OSM. Luckily they have enough other detail in OSM that allows me to exclude them easily.


    CreateAF2Building|building="yes" And man_made<>"storage_tank" And FAREARAT>0.7 And FAREA >=700 And FAREA <6000|2|1|flat|commercial|0

    CreateAF2Building|building="yes" And man_made<>"storage_tank" And FAREARAT>0.7 And FAREA >=700 And FAREA >=6000|4|1|flat|commercial|0

    Don't think that will work as scenProc only imports the following fields for any object even when you nominate everything "*"..

    aeroway,amenity,boundary,building,craft,geological,historic,landuse,leisure,military,natural,office,place,shop,sport,tourism

    You would need to add "man_made" to osmconf.ini in order to use it as a restriction.


    Also I haven't had any luck using "<>", so I think you would need to use "NOT" as indicated below.


    CreateAF2Building|building="yes" And NOT man_made="storage_tank" And FAREARAT>0.7 And FAREA >=700 And FAREA <6000|2|1|flat|commercial|0

    CreateAF2Building|building="yes" And NOT man_made="storage_tank" And FAREARAT>0.7 And FAREA >=700 And FAREA >=6000|4|1|flat|commercial|0


    Have updated the template with the following enhancements:-

    . Added feature to filter buildings from airport areas automatically. It is no longer necessary to create an exclude for airport areas. This works in most parts of the world.
    . Added feature to remove trees from playing fields. In Australia UK and the USA it is common to have playing fields located in areas designated in OSM as parks. Without this update you end up with trees appearing in playing fields such as cricket pitches, hockey fields, baseball diamonds etc. European countries do not seem to categorise areas with playing fields as parks in OSM, so is not a problem for them. Note - this feature has a slight time penalty of about 2 minutes on level 10 my test area.
    . Corrected comments about the size splitting of houses.
    . Added new plant area for scrub (Australia specific I think)
    . Added new street lighting with traffic lights created by Kenventions.