Please don't spend too much time with trying to make aircraft tools, I already have a decent aircraft editor which works in 3D
Looks amazing Jan and just what AFS needs to allow more people to have a go at aircraft development. Looking forward to its release.
To programming types it will look ok
It looks horrendous to this programming type too!
I get why they've done this, you can parse this a lot faster than you can parse XML, but XML as the intermediate format would have been preferable.
For example, if Jan's bare bones TMD file was XML, you could see the hierarchy in a free XML editor and also edit the values in the text box in the bottom left of the screen. Any syntax errors would be validated.
I'll have a look at writing a two-way converter as I think it would be useful for the scenery stuff too.
Well done! Looking great already. I'm pleased that AeroScenery helped out 
It seems like you might have figured out getting the _detail textures to work for the runway? Do you have to add these in the Max material editor? If so, to what map channel? Or do you just include them in the same folder and things work auto-magically?
if you check out the wiki, I've recently added a few code snippets:
Thanks for progress on the Wiki Jan. I'd love to do an aircraft project one day, but lack of documentation puts me off at the moment. This is already a step forward. (I will fly a Cessna 208 in Aerofly even if I have to make it myself )
Is the XML-ish format that IPACS uses something developed in house? I've been tempted to whip-up a quick app that converts it to XML and back again
Something like XML Notepad could then be used to edit this stuff hierarchically, which I think would be a lot easier for the large TMD files.
https://github.com/Microsoft/XmlNotepad/wiki
Example:
<[string8][object][jet_engine]
<[string8][Name][JetEngine]>
<[string8][Body][Fuselage]>
<[string8][ThrottleControl][ThrottleInput.Output]>
<[float64][MaximumThrust][10000.0]>
>Converts to
<object type="string8" value="jet_engine">
<Name type="string8" value"JetEngine" />
<Body type="string8" value"Fuselage" />
<ThrottleControl type="string8" value"ThrottleInput.Output" />
<MaximumThrust type="string8" value"10000.0" />
</object>I was really just trying to understand what IPACS plan is for this sim and get a handle on how other enhancements would impact it.
From what I recall of previous posts by Admin here, IPACS intention is to add all the features that you mention.
I've never read anything that makes me think that they want to make it as a "lite" flight sim for casual use.
What brought me to Aerofly was that, as an industrial simulation software engineer myself, i got sick of reading posts about how we can't expect too high performance from AFS's main competitor because of flight dynamics, ATC, etc. How 30fps is great with my £2ks worth of PC kit. People buying £600 CPUs to get up to 45 fps yet only one thread being used.
The physical flight model (including weather) will be the most computationally expensive thing. ATC, other air traffic, other ground traffic, is not hugely taxing if it's properly optimised and threaded.
Assuming IPACS does intend to develop the same functionality as those currently more 'serious' sims, can we expect framerates to drop correspondingly? Or does the FS2 engine have some design features which will maintain frame rates even with the extra processing required by traffic, ATC, real world weather etc etc?
Remember that these features are CPU intensive, not GPU intensive, maybe excluding weather.
Performance problems with these features in other sims is largely down to lack of multi-threading and concurrency.
In terms of GPU resources, flight sims aren't as taxing as AAA game titles. CPU is often the bottleneck that pushed down frame rates.
Without 15 years of legacy cruft in the codebase I'm hopeful IPACS will do a great job at keeping performance where it needs to be at 90fps+
Hey Jarrad - ORBX if you're allowed to share, what do you develop your scenery for AFS in? How does the development process compare to other sims; what's easy, what's challenging? How much time goes into porting something like this?
Inquiring minds would like a glimpse behind the scenes.
The Developers Camera is certainly better than nothing, but the controls sure could use some work.
Yeah, the controls aren't that great. Slew with A and D should be made to work.
Trick is to use the mouse to look where you want to go, or I suppose literally look where you want to go in VR, then use W to more towards where you're looking.
You can go anywhere you want with it when you get the hang of it.
Could you look into adding Orbx BOB to AFS2? It sure would be nice to be able to walk around Palm Springs and checkout all the new items in great detail. I am especially enjoying the mini aircraft museum displays.
Just use the developer camera, Ctrl-F8 then W or S keys to go forwards or back in the direction you're looking.
Confusingly, to met at least, Ctrl-F8 or Esc does not exit the developer camera. You need to go back to an "in-plane" camera (number keys), then press Esc.
Also looking forward to buying this and flying when I get time this week.
I installed definitely version v0.6. Now I reinstalled everything again, but the bugs still occur with Bing.
Thanks for confirming.
What zoom / image detail level are you using?
I don't change the value "Max tiles per stiched image". The value is 32. The GeoConvert value of "Shrink TMC grid squares" is 0 degrees - is this ok?
Yep, just need to know the zoom level you're using (slider on the top left of the main window). Probably 16 or 17 but I'd like to do everything exactly the same as you.
Also, could you confirm that this is definitely v0.6 (top right of the main window)
Thanks.
I found the error on all tiles I created in the area of Munich and for the Greek island Kos. The screenshots are from the tiles map_09_8800_a800 (Erding near Munich) and map_09_9300_9c80 (LGKO Kos).
Thanks for the bug report. Let me know what setting you're using for "Max Tiles Per Stitched Image" and also the zoom / image detail level youre using. I'll take a look at it this week
If you look at FSCloud AD, they're only featuring a lonely runway without much mesh smoothing outside, as the case may be Spit40 could help you in automated generation of runways, taxiways and aprons.
Thanks Antoine.
In a nutshell the issue is that the more features you want in the ground poly (multiple runways, taxi ways etc) the harder it gets to automate because AFS really needs a single poly with sufficient vertices. If it could cope with separate objects for those features it'd be relatively easy.
I'll keep messing around with it as I get time and compare notes with Spit40 at some point.
That was that all buildings be designed with several subterranean floors or sub basements, so that rather than building-edges dangling awkwardly in the air on angled terrain, they would still (mostly) manage to fit properly.
Sounds like the most good approach to me.
Something else to work out.
FS2 uses the objects pivot point to locate the object in the sim
Hi Steve,
Yeah, I did this the wrong way round. I should have built a few airports before writing code. Typical developer eh, code solves everything 
I didn't realise about the buildings issue. It explains why none of the Xref buildings are very big.
As I said in a previous post, in an ideal world, the mesh smoothing area would be defined and controlled in the TSC and you'd be able to dial it up to "flat" if you don't mind things being inaccurate. This would eliminate the need for a complex full ground poly and make airport creation a lot easier.
This is how AFS's competitor works and most payware airports for that sim are indeed flat.
Anyway, I'm sure I can do something useful with the code.
Worst case it's a tool that takes some of the grunt work out of creating a custom airport.
If I can get it to create ground polys, runways, taxiways and decals, there's value in that when mixed with hand positioned buildings from FSCloudPort.
But yes, automating building creation seem like too ambitious a goal unless IPACS rethink giving us control over mesh smoothing.
I still have problems with misaligned photos when using Bing as the image source. When using Google the photos are aligned correctly. Am I doing something wrong or is that still a problem in the AeroScenery version 0.6 beta?
There's no alignment issue confirmed with 0.6, but that doesn't mean one doesn't exist.
If you could let me know what grid square(s) you're working on, the zoom / image detail level and whether you're changed the number of tiles stitched together I can look into it. A screenshot of the alignment problem would help too,
That's got to be some of the most realistic scenery I've seen on any flight sim, ever.
Amazing work.
Let's chip in/crowdfund to make nichod a possibility to buy Cinema 4D, we will benefit everyone like we have,
Thanks, very kind of you, although I don't think Cinema 4D makes anything any easier.
It's taken several years to be roughly proficient in 3DS Max, so I'll push ahead with that.
I'll figure something out.
The method mentioned in my 3DS Max tutorial works flawlessly when making an airport (even complex one)
Thanks, yes it's a good tutorial. Like Hartman I was curious what steps are essential vs what steps were just done that way.
A "let's create a runway in as few steps as possible" Max tutorial might be a nice addition.
For anyone else reading this in future, my trial and error showed that the bare minimum for "ground" objects in the TSC is:
What isn't strictly essential
I finally got there ... kind of. I'm disappointed with the conclusion though. I think Hartman is right that it's almost impossible to automate anything complex.
The image above is the runway mesh texture being mixed with the terrain mesh texture because there was no extended ground poly.
I tried just creating a ground poly underneath it, setting the vertices to black, and letting the runway sit on top. The runway was mostly visible but there were issues with overlapping polygons.
Next I tried the "carve out the runway" method from the Max tutorial, which does work, but is near impossible to automate.
IPACS missed a trick here, sad to say. The airport boundary for mesh flattening should have been defined in the TSC. This would mean that runways and taxiways could be created with simple geometry.
I'll continue to experiment, but it doesn't look promising.
I can only imagine how complex creating the ground poly for KORD would be with the method in the Max tutorial.
