• 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.

AeroFly FS 2 support in scenProc

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Hi,

scenproc has the special attribute FAREARAT for that. It's the ratio of the polygon area and the bounding rectangle area.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Hi,

Let me check. Probably I can use the same code as in the other step.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Hi,

I have added this option to the CreateAF2Building step as well, it will be in the next development release.
 
Hi Arno.

I am creating lights to replicate the effect of a TV or radio tower. These often have multiple stacked lights, usually 4 or more. The top light flashes, the 2nd down is steady, the 3rd down flashes and the 4th down is steady.

I am using the following commands to achieve this by using a single point that identifies the TV tower and then creating 4 lights from the same source point.
CreateAF2Light|man_made="tower" And name="*TV*" |1.0;0.0;0.0|5000|2.8;0.0;30|400
CreateAF2Light|man_made="tower" And name="*TV*" |1.0;0.0;0.0|5000|0;0;1|300
CreateAF2Light|man_made="tower" And name="*TV*" |1.0;0.0;0.0|5000|2.8;0.0;30|200
CreateAF2Light|man_made="tower" And name="*TV*" |1.0;0.0;0.0|5000|0;0;1|100

While scenProc correctly creates the 4 individual lights in the output file, it assigns all 4 lights with the same height taken from only the last line, rather than using the height value from each line respectively. The other values such as the colour, flashing or steady it gets right for each line, so it is only the height that is the issue.

If I manually correct the heights in the output file, the lights appear correctly as a vertical stack in Aerofly with some flashing and some not as expected. So Aerofly has no problem with this arrangement of lights.

Can you help please? I have attached the scenProc script (StackedLightsError.spc) , the source OSM data file (PowerTowermap.osm) and the output file it generated (YBBN-map.toc).

Regards Chris
 

Attachments

  • PowerTowermap.osm.txt
    311.3 KB · Views: 79
  • YBBN-map.toc.txt
    1.4 KB · Views: 55
  • StackedLightsError.spc.txt
    584 bytes · Views: 60
this may be by design, i'd think work around you could also try (not sure how you export atm) exporting to single lights than merging them after?
did you try classifying alt with calling a variable there instead of integer?
 
this may be by design, i'd think work around you could also try (not sure how you export atm) exporting to single lights than merging them after?
did you try classifying alt with calling a variable there instead of integer?

It would be odd if it is by design, as the height was the only value in the command line it grouped across separate output lights. Other unique values in the same command lines were correctly applied to each output light. Sorry, don't understand your comment about exporting and merging. I tried your suggestion of calling a separate variable for each height value, rather than using an explicit integer value in the CreateAF2Light command line. But it did the same thing and just used the variable value for the last line for each light output, rather than the variable assigned to each light output. In the example below all lights ended up with a height of 400.

AddAttribute|man_made="tower" And name="*TV*" |Integer;height1|100
AddAttribute|man_made="tower" And name="*TV*" |Integer;height2|200
AddAttribute|man_made="tower" And name="*TV*" |Integer;height3|300
AddAttribute|man_made="tower" And name="*TV*" |Integer;height4|400
CreateAF2Light|man_made="tower" And name="*TV*" |1.0;0.0;0.0|5000|0;0;1|height1
CreateAF2Light|man_made="tower" And name="*TV*" |1.0;0.0;0.0|5000|2.8;0.0;30|height2
CreateAF2Light|man_made="tower" And name="*TV*" |1.0;0.0;0.0|5000|0;0;1|height3
CreateAF2Light|man_made="tower" And name="*TV*" |1.0;0.0;0.0|5000|2.8;0.0;30|height4
 
Managed to find a work around. 1. Use the original point to create a polygon, 2. Then use the new polygon to create 4 new identical but separate points, 3. Then use the 4 new points to each create a light in the same location, but at different heights.

So the issue appears to be that if you use one point to create 4 separate lights in 4 separate lines of script, it ignores the height value of the 1st 3 lines and only uses the height value of the 4th line. But if you use 4 separate points, with exactly the same location, to create the same 4 lights, using 4 lines of script, each light ends up with the correct height value.

Creates a very long and complex script if you also want towers located near each other to use different light flash timing, but I managed to get that to work as well. Just used lots of lines of script.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Hi,

This sounds like a bug, I'll see if I can reproduce it here.
 
Hi Arno,

How does the new AF2 SplitGrid command work? I couldn't find any reference to it in the manual. I tried using SplitGrid|AF2LEV11|*|building="*" and it split my data into 65 cells. As I was processing a level 10 sized OSM data file, I was expecting just 4 cells, since 4 level 11 tiles are the same size as 1 level 10 tile. A level 10 tile varies in size depending on where you are in the world, but it is roughly 10km x 10km.

I have always found that the SplitGrid command doesn't uniformly split data, so it could be that I just don't understand how it works. I have 2 adjoining areas I test with. Both are a 10km x 10km extract of OSM data. While they are the same geographic size, one has more OSM data than the other. Then less detailed file gets split into 396 cells while the more detailed one splits into 925 cells. Yet both used the same SplitGrid value of 0.03.

I am assuming this new process was to enable the data to be split for the ExportTSC command. If this is the case then the split values needed for script lines are different to the split values needed for the ExportTSC command. I found that script commands (with some exceptions) utilise the CPU best when using a low value of 0.03 or less. However this would create far too many output files. I did try using more than one splitgrid line, but the 2nd splitgird (after the 1st mergegrid) ended up with the same 925 cell split as the first even though the 1st split used 0.03 while the 2nd split use AF2LEV11.

Thanks, Chris
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Hi,

I just remembered a few hours ago that I forgot to update the manual :)

Are you sure your OSM data is exactly level 10? Then I would expect 4 cells indeed. It might be that the OSM data contains features that are inside the level 10, but strecht out much further.
 
Yes they are both the same size. But I think you may be right about features that than are outside the area. I think power lines would be the culprit here.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
If you specify a bounding box in the SplitGrid step that matches the level 10 you are processing those elements that stick out should be clipped and ignored.
 
Thanks, I'll give that a go. OSM provides the coordinates of the data extracted, and this could be used as the bounding box for SplitGrid. But this would be a manual task and adding manual tasks into an automated process sort of defeats the purpose of having it automated. A level 10 sized OSM data file takes some time to open in a text editor.

That just leaves the problem of the different outcomes the SplitGird command needs to achieve. Using 0.03 sees my CPU regularly hit 100% processing the script in the minimum time, But this gives an unrealistic 1000 output files. While using AF2LEV11 should give 4 output files (once I use a bounding box), but my CPU is so under utilised it significantly increases the processing time.

The current process is to download OSM data in a level 10 sized chunk, and output that as one file. I guess we could use OSM data files covering a much greater area, then use AF2LEV10 to spit the result out into level 10 sized chunks. But you would need to be able to download data from OSM covering a vast area into for the AF2LEV10 to create enough cells to effectively use your CPU. Using AF2LEV10 a 200km x 200km block of OSM data should result in 400 cells which would keep the CPU busy. Was this the purpose of the change?
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
These AF2 levels were added because I got a request for them. It seems it is more efficient if the output can be arranged per AF2 level.

For the CPU, if there are more grid cells, scenproc does more parallel work indeed. If you see less CPU load it might be SplitGrid hit a complex polygon with holes it is working on.
 
Hi Arno,
I also have the problem, that more tsc files are generated then the AFS2LEV10 is defining. Indeed there are elements, which reach beyond the downloaded box.
You suggested to enter the bounding box parameters to prevent this.

May I suggest an easier approach?
Regulary the downloaded OSM file has the parameter <bounds>, i.e.
<bounds minlat='48.7432857' minlon='2.2671318' maxlat='48.7532462' maxlon='2.286272' origin='https://overpass-api.de/api/' />
If this parameter is contained, could you use it to automatically clip to that bounding box?

see also https://wiki.openstreetmap.org/wiki/DE:OSM_XML
 
Last edited:
Top