Posts by Trespassers

    Hi Jan,

    Sorry, this was probably improper wording from my side and I apologize if it hurts you, it was not my intention.

    Yes, looking at aircraft files I can see there's actually an electrical system behind, despite without much obvious effect except on the ammeter.

    But still engine startup/shutdown when featured is just a discrete step based on a few booleans, magnetos are not featured, I have to set very low throttle (approx 40%) to cruise at a realistic power setting be it at 5'000ft or 10'000ft without over-rev. Whatever the flight I have the same weight and balance.

    There were more systems featured in FS3.1's C172 when I started some 25 years ago, if we only look at aircraft systems.

    Regarding weather I can just play with sliders to make it more or less windy (without value), changing the direction and turbulences, add more or less cumulus or cirrus around me, still by the mean of sliders without values, that's far from what can be called a weather engine, without talking about real weather.

    The flight planner only allows to set a departure and a destination, without allowing to set your route with your desired exit or entry points or use aerodromes as enroute waypoints, no way to compute your horizontal navigation, no talk about vertical navigation and a way to load/save routes.

    Yes you've all been doing and keep doing a great job. I think I've ever been supportive, saying it takes time and praising what's good in AFS2, fortunately enough I could find other things I enjoy in this sim.

    But it's a fact you should not expect simmers used to other platforms to consider AeroflyFS 2 to be more than a "light" simulator with what's currently featured.

    The fact that Marc is busy programming an ATC tends to prove that aircraft basic systems rendering (like e.g. magnetos, mixture, fuel circuits, engine power output depending on air density, startup/shutdown sequence, etc.) is not your current highest priority and I'm fine with it.

    Sure it will come later (hopefully), as well as a weather engine, a flexible flight planner, and many other features, and one day Aerofly FS2 will be called a full grown simulator. But it takes time and it's not yet in it. Expecting reviewers or users to say the opposite would by lying to potential future customers that could be pretty much disappointed when stepping in.

    Keep up the good work.

    Antoine

    Hi Antoine,

    I believe the freeze is due to the size of your tiles.

    From what I could observe in the log files, AFS2 loads all sceneries (.tsc files) that are in a radius of about 25 kilometers from the aircraft position. I would recommend not making tiles bigger than 15 to 20 kilometers.

    Hi Sylvain,

    The freeze is definitely due to the size of the tiles, because they're currently loaded as a pack.

    In the tsc files you define the load radius with the airport size, I assume it's in meters. For the 1 deg x 1 deg tiles I tried the of 60'000 which is a little bit bigger than half a cell size.

    Flying around various places the next tile seems to load before being visible , but the lack of slew mode makes efficient scenery testing difficult.

    Setting the value to 5'000, the next tile won't load before you nearly reach the center of the next slide. Thus you fly without cultivation and, suddenly, it loads below your buttocks.

    Of course, if AFS2 keeps with such a loading behaviour, the only solution would be to dramatically reduce the tile size, probably similar to MSFS LOD13 autogen tiles (ca. 1.2 x 1.2 km) and load/unload them according to the LOD radius scheme.

    Knowing that in Aerofly FS2 current cultivation concept you'll need for each TOC file a corresponding TSC file defining the center point of the tile as a ghost airport and a radius, that would be definitely a no go. A small country like Switzerland represents approximately 25'000 tiles of LOD13 size, forget it.

    The only solution - and IPACS is obviously working on it - is to adapt the concept, how TOC files are saved (binary ?), loaded and unloaded, something similar to current default vegetation which works fine.

    The problem with binary toc file format is, if we need a compiler for the ExportTOC step, we also need a decompiler ImportTCO function, otherwise there's no way a cultivation zone can be edited.

    Without such a function, it will be impossible to add anything, be it a simple 3D landmark, without conflicting with cultivation underlayer.

    It will thus also be impossible to add an airport, to clear inaccurately placed cultivation (e.g. trees on highways) or to correctly merge interfacing tiles where 2 adjacent sceneries meet, because you never know what data the other editor used and where they stop.

    The only workaround would be a system of exclude polygons, provided that it allows to place new cultivation on top and make it visible, thus work with priorities.

    Hope IPACS will take this into account to make it a success.

    Cheers

    Antoine

    by compiling Switzerland with some 10 millions buildings in tiles if 1 deg x 1 deg I keep 250+ FPS, but still a freeze of ca 2 seconds when loading the next zone, because each zone laods in 1 step.

    Moreover, currently cultivation must be linked to an airport, thus the load zone must be adapted to the tile size, otherwise the neighbouring tile won't load before you're overflying it.

    These are hopefully things IPACS will improve when defining the new binary file system.

    The most interesting thing with current tests is people gain experience with ScenProc, which is good to make cultivation coverages once IPACS release their binary format...

    Cheers

    Antoine

    very nice job for Lisboa.

    I havn't much worked yet on lights, but there's still much to do. For instance deeper use of osm street maps to set different layers of lights.

    Since there's no ground traffic in AFS2, we should cover highways with a wise mix of red and white dots, because dense traffic is what you see best in night flight. What is not alight must be pitch black.

    Cheers

    Antoine

    Well, it's a learn by doing, trial and error process...

    CORINE is free and will be especially useful when there are more trees species available in AFS2.

    ScenProc has an integrated feature to spread clouds of points inside polygons to generate single trees, because AFS2 doesn't handle polygons of vegetation.

    In FS we generate polygons, it's much lighter, and allows to automatically subtract intersecting polygons => typically when you have a road crossing a wood, so that trees don't get planted on the road.

    But the drawback of compiled polygons is it makes post-compilation corrections more difficult, for instance when a bunch of trees fall into water or on a road, a house or whatever (CORINE database is quite comprehensive and covers 39 countries, but placement is quite coarse).

    Cheers

    Antoine

    Salut Luis,

    Very nice job indeed, congratulations !

    I see you started planting a few trees, probably by hand.

    There are some trees in OSM, mostly compact woods (no fences and isolated trees, and seldom trees in cities) usually without much information.

    A good alternative source for vegetation is the CORINE database.

    Currently there are only 2 kind of trees in AFS2, conifer and broadleaf, but no doubt the library will evolve with multiple species...

    Cheers

    Antoine

    Antoine? any idea?

    If you talk about trees, they're already featured in the scenery by default, I didn't add a single tree yet in my test, only buildings and street lights.

    Buildings load exactly like trees, as far as the eye can see. No popup effect, no flickering.

    I don't know how memory handling is managed, how cultivation is cleared from memory when leaving a place, this is an important key for dense scenery making...

    Cheers

    Antoine

    Great, that you are finally exploring the cultivation file. (...)

    (...) it's not fully ready to be public yet in my opinion. Please pump the brakes a little bit while all of this is worked out.

    Well, on the one hand I read I was expected to do it earlier, on the other hand that I should have waited a bit...

    I'm aware the cultivation concept and it's file structure are in early phase and due to evolve, it doesn't remove the need and interest of testing coverage on large zones. There are also plenty of other ScenProc steps that should be setup and optimized to improve the result, but I think it's worth it to take users experiences into consideration for tools making, rather than wait for tools to be finalized and ask users to adapt their expectations.

    Talking about file structure evolution, one aspect that should be considered by "cultivators" is, cultivation areas should be divided into cells of "reasonable" size (reasonable is still to be defined) with a self explaining name, for instance reflecting the coordinates of NW corner, meaning easier maintenance.

    This can be done in ScenProc without the need for extra tools, but then each single toc file must be declared individually, which is a pain in the a...

    One idea would be then to enable the automated declaration of a global set of toc files in the TSC file structure, for instance all the toc files located in a specific folder - in other words declare the folder of files instead of the files.

    Keep up the good work.

    Best regards.

    Antoine

    Yes, the airport part is documented, but I cannot get the cultivation part working without filling up the airport stuff, while cultivation has nothing to do with airports.

    The only workaround I could find was to create a dummy phantom airport with a dummy name and zero feature and attach my cultivation files to it.

    Good to hear IPACS is considering to improve cultivation. Please make sure Arno is in the loop to adapt his tool accordingly, it will be a closer loop with direct source of information, unlike when somebody external like me has to improvise specifications on new stuff that isn't yet fully documented.

    Cheers

    Antoine

    Salut Antoine, any chance you couls make a quick and dirty tutorial on how you made it work with Arno's tool and your results in creating cultivation?

    First you need to get OSM data for the zone you want to cover. http://www.geofabrik.de/

    If you have a GIS (for instance, QGIS is free and very powerful) you can also directly download a window of data for your desired zone.

    Then in ScenProc you follow the steps described in chapter 5.9 of the manual.

    Chapter 5.9 is the AFS2 derivative of chapter 5.1 to create autogen from XML OSM data (i.e. with .osm extension).

    In case you have shapefile OSM data (.shp) check chapter 5.2 for correct Import syntax. Use QGIS to check your data and identify attributes as described in ScenProc manual

    You should use SplitGrid function (cf. chapter 9.2.22) in case you make a large flight zone, typically larger than 1.0x1.0 degree cell, but you should start with a small zone.

    Launching the steps (should) create a cultivation.toc file.

    Check Rodeo's Airport creation tutorial for the next steps, how to use the cultivation.toc file in AFS2...

    Especially you need to create a .tsc file which isn't documented yet.

    I picked an existing one and created a phantom airfield to attach my cultivation file. Without the phantom airfield my autogen doesn't show off, I hope the needed structure will be documented soon.

    Hope this helps. There are plenty more great functions in ScenProc, just read the manual.

    Rodeo started trying out ScenProc, he might consider starting another nice little tutorial of his... who knows.

    Cheers

    Antoine

    Toprob said it all.

    Even if you work with OpenStreetMap, be it shapefiles or osm data, attributes and formats may change from a place to another.

    And you can get beautiful shapefiles from various sources.

    You then definitely need a GIS to check what's in and how to feed ScenProc with suited parameters.

    The manual looks tough, but if you start slowly it isn't so difficult. A tuto could be done with a specific piece of osm data (known format).

    Cheers

    Antoine

    I hope ipacs will work on the sky colours and on terrain shades soon, that will enrich the sceneries and

    even patch better if terrains are properly coloured.

    well, you're quite right. The difficulty in photoscenery making is colour balancing, and depending on the raw material you start from it can be quite desperate.

    The photomaterial of the Swiss scenery is the more than 20 years old Endoxon base with extreme saturated colours that served for all Switzerland Pro series since 2003.

    However, as long as the lakes are painted electric blue with partially very low res satellite pictures in the middle, I would not complain about green grass or sky exact colour. I very much hope IPACS will do something to correct the Swiss lakes that unfortunately look so ugly in AFS2...

    Cheers

    Antoine

    Great,

    what a good idea to add aerofly support to scenProc. This will enable all interested users to 'cultivate' aerofly with OSM data.
    Is it already available on the fsdeveloper page?

    Regards

    Rodeo

    Yes, Arno already made it available in the dev version (the last official stable version is quite old anyway, many new features aren't available).

    While figuring out how to generate cultivation files from my shapefiles I quickly realized it didn't make sense for me to try re-inventing the wheel: ScenProc does it all with quite a lot of nice features. All we need it to export in TOC format instead of agn. So I approached Arno...

    For those who want to work from OSM (i.e. free, easy and legal to share provided that you name your sources), there is usually no building height information.

    For my test I took Arno's simple rule defining 2 or 3 floors depending on approached footprint size. It's somewhat low for cities but not shocking seen from the sky.

    Having this optional step in ScenProc is anyway a great enabler, I'm thankful to Arno for that.

    Cheers

    Antoine

    How is this achieved?

    For those who are interested, it's all there...

    http://www.fsdeveloper.com/forum/threads/…cenproc.441173/

    One aspect to define is the ideal size and structure of TOC files.

    I tested on purpose 1 single TOC file, with approx. 280k buildings, it works, but it's not ideal.

    My feeling is we could write separate TOC files for plants, buildings and lights, for easier maintenance.

    As well we should split the data into cells, i.e. several TOC of reasonable size to cover a country.

    We could think of 1 degree by 1 degree cells, or 30' by 30' cells and name them according to coordinates.

    Keep in mind that each TOC must be declared in a TSC file - the structure of which isn't yet very clear to me.

    I.e. too many files is a drawback. But too large files with everything inside makes it difficult to locate and remove the group of trees that cross the highway...

    Cheers

    Antoine

    For those who are interested, it's all there...

    http://www.fsdeveloper.com/forum/threads/…cenproc.441173/

    Read ScenProc Manual chapter 5.9 to see how to proceed.

    There are however a lot more things to investigate and define.

    One aspect is the size and structure of TOC files.

    I tested on purpose 1 single TOC file, with approx. 280k buildings.

    My feeling is we may write separate TOC files for plants, buildings and lights, for easier maintenance.

    As well we should split the data into cells, i.e. several TOC of reasonable size to cover a country.

    Of course, ScenProc has everything built in to do it. No need to split to agn file size, we could think of 1 degree by 1 degree cells, or 30' by 30' cells and name them according to coordinates.

    Cheers

    Antoine

    looks like x-plane?

    what location is it?

    Annemasse, just next to Geneva on French border. I've been working with Geoconvert on the interface with the Swiss DLC...

    Below some pics of Lausanne area with the next test zone. Still a lot to improve, but I'm currently concentrating on feasibility rather than aesthetics. The good think is it works and already doesn't look so bad...

    [Blocked Image: https://img11.hostingpics.net/pics/603779aeroflyfs22017100822041658.jpg]

    [Blocked Image: https://img11.hostingpics.net/pics/274963aeroflyfs22017100822025757.jpg]

    [Blocked Image: https://img11.hostingpics.net/pics/780229aeroflyfs22017100822031373.jpg]

    Villages too are much enhanced by 3D...

    [Blocked Image: https://img11.hostingpics.net/pics/601907aeroflyfs22017100822064828.jpg]

    [Blocked Image: https://img11.hostingpics.net/pics/823460aeroflyfs22017100822080054.jpg]

    Yverdon-les-Bains

    [Blocked Image: https://img11.hostingpics.net/pics/769287aeroflyfs22017100822160491.jpg]

    [Blocked Image: https://img11.hostingpics.net/pics/972128aeroflyfs22017100822163503.jpg]

    [Blocked Image: https://img11.hostingpics.net/pics/419137aeroflyfs22017100822175940.jpg]

    Back to Lausanne, morning light. Here looking towards Evian

    [Blocked Image: https://img11.hostingpics.net/pics/993699aeroflyfs22017100822241711.jpg]

    [Blocked Image: https://img11.hostingpics.net/pics/895565aeroflyfs22017100822250525.jpg]


    And for those who are not about to rock...

    [Blocked Image: https://img11.hostingpics.net/pics/613693aeroflyfs22017100822331212.jpg]

    ...the buildings density slider works (digital : max = ON, less than max = OFF)

    [Blocked Image: https://img11.hostingpics.net/pics/201499aeroflyfs22017100822304709.jpg]

    Cheers

    Antoine