Posts by chrispriv

Thank you for your reply. Enclosed as requested some examples, how the orientation is used as very often in the existing freeware and partly also commercial sceneries of FS2:

A) Airport project with all its objects

- Ground, Rwy & Decals of all Airports based resp. (automatic) generated on fscloudport.com (with exception of the XREF-objects)

- Add. non XREF-objects like hangars, towers, houses etc. alligned with the runway (as it is the case e.g. for the commercial Lukla Scenery)

- Add. placement and orientation of (generic) Helipads at Heliports

B) Single objects (corresponding to the new POI's)

- some objects concerned like large ships, some special buildings, bridges (other objects may already have the correct orientation)

- Note: some objects like huts in the mountain also have a ground-integration resp. adapted (seems not to be supported anymore too)

C) Placement of repetitive smaller objects

- most objects (automatic) placed and rotated using “ObjectGen” like:
Boats and piers, powerlines, lift-stations and -pylons, passenger bridges and other non XREf airport-objects, cell towers, special vehicles, camping ground, trains and much more (f.e. rocks and tents of the base camps of the commercial Lukla Scenery)

Quote from Jet-Pack (IPACS)

Since POIs are unique buildings they should be modeled in the correct orientation and there is no need for an additional parameter to rotate them.

Exactly the missing support of the 'orientation' on FS4 makes the biggest part of the missing compatibility with FS2 sceneries, respectively makes it in practice nearly impossible to transfer sceneries from FS2 to FS4. This applies to both, professional sceneries and most of freeware sceneries!

For example, in the great "Lukla Mount Everst" add-on from Aerosoft, practically all objects (airport, ground and area, but also many objects like rocks, tents of the base camps etc.) are rotated without exception.

Aerosoft would have to realign and recompile several hundred objects, which they certainly won't do. With the possibility of the orientation it would be a relatively small effort to adapt this fantastic scenery for FS4, without this possibility simply not feasible, like for many freeware sceneries.

So I hope that at least for airports and all their objects the rotation resp. orientation will be supported furthermore on FS4.

@Question: Is it the case?

Thx Jan,

Just tried it out to place xref objects within the cultivation and it still seams to work.

This may be an approach even if not optimal at all for the reasons mentioned above. Anyway pleasing.

Would it neverless be possible to get an example of how the new definition/syntax for the buildings looks like with new building types, even if the SDK will then be released later?

Regards,
Christophe

Thank you for your clarification. I think we are already talking about the same things here and do not mix topics.

Regarding my first part of the request, I see that you added lights locally for an individual and unique point of interest buildings (POIs) and your new compiler seem also to support the implementing of some addition trees and builds (but not any XREF objects) to the POI.

Regarding the orientation parameter, which is as you write is not supported for POI's, we just asked you what than will be the work around resp. solution, how to solve this.

Quote from Jet-Pack (IPACS)

1) Individual and unique point of interest buildings (POIs), like the Statue of Liberty or the Eiffel tower or the Golden Gate bridge - now can be created with SDK
2) Scenery cultivation = widespread buildings, towers, trees, powerlines, windturbines, etc. - not yet included in SDK

3) Xref objects and buildings which are part of an airport - not yet included in SDK

Since POIs are unique buildings they should be modeled in the correct orientation and there is no need for an additional parameter to rotate them.

When you write in your answer, that XREF objects can only be used in the context of Airports and not also for Cultivation and also individual models may only be used for single-objects as POI's, it obviously an unfortunatly means that you probably have no solution for this need on FS4.

Quote from ApfelFlieger

If I understand it correctly, the idea is that I create a local object that occurs several times (e.g. a cruise ship)

- only once in XREF (preferably in north direction) and then

- and then want to vary the position and orientation at the respective positions (e.g. Pier1: 030°, Pier5: 270°).

The second option seems impractical and unfeasible to me because of the immense effort. This would mean that I would have to create 360 separted models of each repetitively used object depending on the orientation and compile them individually (e.g. boat01_000, boat01_002, boat01_003 ... and the same for boat02 etc.).

The first approach to create own user XREF libraries for all recurrently used single objects would be a big effort as well. This would also lead to an extensive and uncontrolled "jungle" of XREF user libraries, which are also very difficult to handle by the users of scenrey (which xref library is needed for which scenery?). I am also not sure if this would be in the sense of IPACS (some libraries als may have some bugs ...).

admin: For this reasons it seems to us meaningful and very important for us as freeware-scenery devlopers, if you would able to support the 'orientation' parameter again. Thank you very much!

Quote from Jet-Pack (IPACS)

Just take the two example POI's TSCs from our SDK https://www.aerofly.com/developers/scenery-sdk/

admin: Can you please also give us an example of a *.tmc file that allows to add locally a small cultivation to a POI (trees, new buildings), similar to what you did with the example of the tacoma_narrows_bridge with the lights.

I have noticed that there are only minor changes for the definition of lights and trees, but there are major changes for the houses (new defintions and changes about the texture-folder) and also there are two new types of building ("shaped" and "complex"). The two new house types are very recognizable in your cultivation.

Your completely new cultivation system for larger coverages is then another topic. There is no *.tsc-file anymore and everything has to be recompiled and organized resp. stored on 11-tiles-level using the correct naming convention for the identification (instead of the coordinates of the ancient *.tsc-file). This is my current insight to this. Correct?

Everything looks normal to me with your script. I think it has to do with the data consistency of your osm file.

Questions:

- Do you have the issue also with other osm files from another area?

- Do you have some lights generated in your *.toc file anyway?

If you have some generated lights and no issues for other areas, i think you may ignore the error-messages.

The cause which I assume is that corresponding osm data file contains roads with only a single point instead of a line/vector.

Else I have no idee too.

Quote from higgy

can you upload it again at our server please ?

Since IZ0JUB will upload a new Photo Scenery soon, I will not do the upload at the moment:

Quote from higgy

You found the cultivation on your HDD or on a server online ?

I write / ask him, but he was long time ago online, i write here when i knew more ...

Think that I still have the images files on my HDD up to level 13:

Shall I send you the files via a google drive link so you can do the upload?

... or to MartinM?
Just noticed that MartinM made the upload for the cultivation on flight-sim.org.

All files go into the "...\addons\scenery\<scenery-name>\" folder *) respecting the correct subfolder structure:

It's easier for updates if you keep the 5 parts as separate ones (mergin into one scenery would also be possible). Feel free to rename the scenery-names (lowercase without spaces then required especially for FS4).

Does it work for you now?

*) There is often a confusion: "..\addons\scenery\" ist not same folder as just "..\scenery \"
... and sorry, just noticed that in my description the "scenery\" has been missing after "...\addons\...", fixed that now!

You can find some information about this in the FAQ's of flight-sim.org or just take a look at one of my sceneries like Vancouver Mega Scenery, BC.

Quote from MartinM

A stunning package - unfortunately, cultivation no longer working in AFS4

Many thanks for your feedback!

Indeed, my cultivation does not work any more. On the other hand, there is already included a new cultivation for this area in FS4.

Combined with the images of my FS2 scenery the scenery is allready quite nice and performant flying in VR (especially nearly without loading interruptions anymore as a great improvement on FS4):

What is missing are all the special buildings, the container harbor etc. and also especially all the airports in BC, Canada (only KBLI Bellingham, USA is available).

admin :

I hope that there will be a work around soon, which will also have the possibility of excluding the cultivation and especially the buildings.
Otherwise, it will not be possible to adapt the existing sceneries with special buildings like e.g. the huts in the Swiss Mountains or some objects individual objects in the towns, allready covered by the new cultivation of FS4, that in principle is well done in my opinion.

Glad that it works for you now. Would be great if you could share this new texture.

What do you mean by installed?

Did you just decompress the last version 1.1.3? Then it will probably not work.

First install the older version with the appropriate "msi" installer version 1.0.1 and then overwrite the installed version with the new unpacked version 1.1.3.

After the installation you should have a new directory in your user directory "<user>\Documents\AeroScenery\" containing the setting.xml and the subfolders "database" and "working". Do you have them and does it work now?

Quote from Jet-Pack (IPACS)

IMO it would be best if each user created scenery is checked for errors in the tm.log and can then be verified by other users. A clean and error free updated version of the user made airport or scenery could then be uploaded and it's not much work for everyone involved.

In principle, I fully agree with it. But it also needs detailed information in advance and not only afterwards, as well as active support from IPACS when there is a need.

Also I hope that IPACS is actively engaged in a community which also creates freeware addons in the future.

Basically, the other image sources still works on Aeroscenery.

Maybe it would be possible to implement mapbox as an additional source. As it looks mapbox also has access via XYZ tile server, similiar to Google. In any case, the integration into Aeroscenery needs a modification in the program code of the application. What makes this more difficult is the fact that it requires an individual token for access to mapbox. This needs to be specified in the config file as well as in a mask. May try it. But the author of this fantastic app nickhod would probably better be able to implement this than me.

Finally, it should be possible with a work around to download all the small photo tiles separately and then "stitch" them again as usual in Aeroscenery.

However, it would certainly be more convenient if this could be done resp. works again directly via Aeroscenery in a user-friendly way.

The good news is that the ArcGIS server is still active and alive.

Also, it is still possible to download tile images manually or via simple web server access.

The bad news is that parallel and asynchronous access via Aeroscenery is no longer working and I am unable to fix this in Aeroscenery (had tried it this WE changing some parameters in the programm code - there is still no response of the server).

Maybee the author of this fantastic tool nickhod would have a solution with his experience to fix it, even if he is no longer active on Aerofly. I hope he may even read this message.

Thanks for your hint.

Made the bug-fix of the flying trees for the airports of Sechelt and Chilliwack and removed the overlay of cultivation with airport-buidlings of CAP3 Sechelt. Just upload "v1.01-fixed".

The issue is due of a bug in the TOC-File of some airports of fscloudport having no towers.

Initially I had this indeed in mind. For an airport of this size with all the runways, taxiways and taxilines, this is a huge amount of work, so I will not be implementing this at this time.