scenery-sdk Syntax needed

    • New
    • Official Post

    Hi Thomas,


    Your TSC file seems to be from Aerofly FS 2. You need to update it first.

    For example the legacy orientation parameter is no longer supported in Aerofly FS 4.


    Also your path contains capital letters, try it again with just lower case letters.

    converting folder place = './scenery/poi/welcome_oahu/'


    This error code:

    ERROR: stripping problem(There is an error trying to break sequential triangle)

    indicates that there is a problem in the mesh where a triangle strip, alternating left/right triangles, is not saved correctly. This may affect one particular part but should not be critical.

  • the legacy orientation parameter is no longer supported


    Thank you Jan for your fast answer.

    Is there any document whre I can see the valid syntax?

    I NEED a substitute for the orientation parameter. My objects are not orientated the way they should (And I hope I do not have to make a new object copy to just give it a new direction...)

  • admin  Jet-Pack (IPACS)


    Sorry Jan, I did read the examples and they do not give me the slightest idea how to orientate a class of objects individually.


    If you intend to support the 3rd party community for more sceneries, we definitely need more support and documentation!

    Edit: We urgently need more tools for objects placing and cultivation.



  • This is what admin once wrote. I do not know if it helps you.

    The 'orientation' parameter in the tsc is no longer supported, you have to rotate the mesh in your 3D modelling software.

    Best regards,

    Thomas


    i7-6700K @ 4.0 GHz, Geforce GTX 1080, 32MB RAM, 500 GB SSD, 1 TB SSD, 1TB HD, 32" Monitor 4K, Oculus Rift

    • New
    • Official Post

    TomSimMuc: The TSC file you used for FS 2 can still be used for FS 4, except the orientation parameter to rotate an object after it has been loaded. Please rotate the objects in your 3D file format before exporting the TGI file.

    All the other 'issues' mentioned in the TSC file are not important, you can simply delete the lines with 'type', 'size', 'tower_height' and 'view_positions'. They are no longer needed.


    We have removed the orientation parameter as it has caused issues when adjusting vertices for larger objects not properly aligning to the earth curvature. So if possible, please do the rotation in your 3D object file.


    The TSC file is also just working as an input definition file. It will be converted to a separate new file format specifically just for 3D scenery objects.


    The explanation of cultivation files will follow, but we need to provide new tools for them first.

  • The orientation of an object must be defined in the 3D software.


    If I understand this correctly the impact will be substantial.

    Best regards,

    Thomas


    i7-6700K @ 4.0 GHz, Geforce GTX 1080, 32MB RAM, 500 GB SSD, 1 TB SSD, 1TB HD, 32" Monitor 4K, Oculus Rift

  • If I understand this correctly the impact will be substantial.

    Exactly.

    Especially for mass objects like boats (or all of things ObjctGen did for us) the work will not be handable any more.

    For small objects, where the earth curvature does not play a role, that parameter should be reactivated.

    • New
    • Official Post

    If possible please provide examples on how you organize your models and work so we get an idea what you are trying to achieve. We could then discuss if it's possible to do all that in a more efficient way.


    Previously we have seen scenery TSC files that were referencing a single geometry many hundred times and were placing them at different positions. This had a big impact on loading times and performance. A better way would be to add those 3D objects as XREF objects and then reference them in the cultivation file where we stil support the rotation parameter.


    Again, we need to know more on how you organize your work to understand what you are trying to achieve,


    As a rough overview, In FS 4 we currently have 3 types of scenery objects:


    - Airports

    - POIs: unique scenery objects, e.g. like bridges, unique buildings and so on

    - Cultivation: Our new cultivation system, for mass placing buildings, trees, windmills and other generic objects


    In order for all this to work properly, it's important that a certain loading order is preserved, e.g. airports are loaded first, then POIs and finally the cultivation files.

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

    Tschüss, Michael (🍎🚁)


    Configurations:

    -- MacBook Pro (16", 2021); Chip: Apple M1 Max; macOS 12.1

    -- iPad (12,9", 4th Generation); iOS 15.2

  • TomB: Why is that, can you explain more or give examples of specific cases?

    I am still not sure whether it is a misunderstanding. I thought of tools like fscloudports or the Scenery Editor where one can define the orientation of a building. If it is a particular bridge or church I see that the orientation can be defined in the 3D software as the orientation is given. My concerns are more about the mass objects. However now you say that the rotation parameter is still supported in the cultivation file.

    Think of a cable car pylon: the can have various orientations. I cannot imagine If this must be defined with the 3D software.

    Best regards,

    Thomas


    i7-6700K @ 4.0 GHz, Geforce GTX 1080, 32MB RAM, 500 GB SSD, 1 TB SSD, 1TB HD, 32" Monitor 4K, Oculus Rift

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

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

    • New
    • Official Post

    We're mixing topics here.


    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.

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

    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. :(