Hi,
In the GUI MCX will use the character that is specified in Windows for the decimal character. But I have now changed how the TSC file is written, there I always use the dot now. Before that was dependent on the Windows setting as well and that is not correct. So I hope that will fix the issue. I'll push a new development release later tonight with the fix.
Display MoreHi Arno,
this is my experience regarding the aerofly exporter in AC3D:
+X points North
+Y points up
+Z points East
Regards
Rodeo
OK, the other information was about FlightGear and I believe also the native axes of AC3D. Seems like I should add an option here.
Hi Arno, could it be a locale <.> or <,> problem?
My PC is set to german.
Maybe, I'll test with the comma. Might also be my output is using the wrong decimal character.
What position did you try to place it?
Rodeo,
I have information that in AC3D the following axes convention is used, so that's how MCX exports:
+X points SOUTH
+Y points UP
+Z points WEST
Hi,
I'll try to reproduce it. Last time I could place the objects from MCX without problems. The actual TOC file is made by the content converter, with input from MCX.
Before delving into this - it's only available for the UK, and there's nothing comparable available for other countries, right?
Kind regards, Michael
More and more countries are making their data open. For example for the Netherlands and Luxembourg I know similar data exists and I've used it within scenproc for experiments.
Sorry to trouble you all. Simple user error after all. Inaccurately drawn kml!
OK, glad to hear it's solved. I didn't think of that option yet 
Hi Phil,
I think it is more likely something is wrong with the filter, causing no features to be considered. Are you sure the features have an attribute FEATCODE (with all capitals)?
And just to be sure, check if the KML file contains a polygon and not only a bounding line as well.
Phil,
Does the scenProc event log show any features that get the extra attribute and being unloaded?
I would start debugging there.
In your TGI file which texture format is referenced? When I did a test export in MCX I used the TSC writer and that converts everything to BMP on the fly. Maybe that's a difference.
In another object I had a 1024x512 texture. But the content converter turned that in 512x512 automatically without problems.
Hi Michael,
I tested your object but it shows fine here in my AeroFly.
You mentioned a warning about textures not being square. Do you have this line in your content_converter_config.tmc file in the texture settings?
[bool][make_square][true]
That should automatically ensure they are square.
Thanks, yes, it seems all the information I'm looking for is in that thread.
Hi all,
Maybe I didn't look correctly, but I read in the SDK that the different levels of the imagery have fixed locations (first level one image for the entire earth, etc). But is there a specification of this system somewhere? It would be useful to know how I can calculate the borders of each tile.
I'm asking because I have a (not yet released) feature in scenProc that can grab images from a WMS and export them to a photo scenery. I would like to give this a try for AeroFly as well.
Hi Rodeo,
scenProc is case sensitive, so STRING should be String.
And the second error says you don't have a SplitGrid step before the detection. That's used to do the analysis in chunks and thus more efficient.
Hi Michael,
I noticed the Sketchup file has parts without textures as well. These parts only have a color assigned. I'm not sure Aerofly supports that. If not the colors have to replaced by a texture.
Yesterday I didn't test the model in the sim, I'll try to do that tonight.
Hi Michael,
I just checked the model and here on my PC I don't get the same error. But I noticed that your TGI file contains comma's where I didn't expect them. That's due to the regional settings that are different in different countries. I have just pushed a new version of ModelConverterX that fixes this and makes sure the output always uses dots for decimal characters. I hope/think that will solve your error.
If you grab the latest development release you'll have the fix. Looking forward to hear if it helped 
Sounds interesting animation windturbines. Does anybody know how these animations can be put in scenery objects? I didn't find much about it in the SDK, but maybe I didn't look in the right location
Hi Ray,
With ModelConverterX you should be to convert Sketchup models to Aerofly. But the challenge is to find models that are designed efficiently enough. I don't have enough Aerofly experience yet to know that's good performance wise, but you see many Sketchup objects that are just too complex and wasting resources.
Converting content from X-Plane or MSFS is probably easier, as they are design with real-time simulation in mind. But of course the developer has to agree for his work to be reused.
I know there are developers interested in porting their addons to Aerofly as well. I just hope to make all those conversions a bit easier, because actually all sims have a lot of similarities as well.
Hi Michael,
I'm also still learning the details of FS2, so any feedback is useful to me.
You can ignore the warning about modeldef.xml, that only applies to MSFS. Same for the warnings about the texture sizes, as the Aerofly Content Converter will automatically resize them for you.
I think you found a bug in the MCX output. I think the TGI file is not written correctly. I'm not behind my PC now, but will try the object you posted and see if I can spot where the error comes from.
Yes, just tell me what limits you find
With this new feature it should be possible to go from for example SketchUp to AeroFly. ModelConverterX can export as TGI file, that you can run through the Content Converter yourself. Or you can export as a TSC scenery directly. I'm not sure if exporting directly to TSC suits in the typical AeroFly workflow, at the moment ModelConverterX can't add an object to an existing scenery. That might be a good addition for the future.
