FSDT Chicago a few days from release.

[Bob Scott 7,720]

23 hours ago, Michael Moe said:

few days ?  is it released ?

Michael Moe

In mid-May it was "certainly by the end of the month."  I saw the thread topic last week and just busted out laughing.

 

[Boeing or not going 578]

10 hours ago, PATCO LCH said:

Appreciating the profit motive greatly for what it has provided our lives let me say I respect any developers decision to target their product for max return. As a consumer of almost all of FSDT's products I have demonstrated that approval with cash. Since a forum is suppose to be an exchange of ideas suffer me to express my unqualified desire as a consumer.

The first word in Flight Sim is Flight. IMO the grand finale of any flight is a smooth realistic landing. If I'm hand flying my 747-8F I don't want pauses and stutters after I'm Outer Marker inbound.  Performance is king to me. If I'm curious about the internal views of the terminals I can google the airport and find plenty of photos and videos of the airport or even the city I landed in after the flight and I've enjoyed doing this often. Take a virtual tour during lay over if you will. Flightbeam's KMSP, KSFO and other offerings are visually stunning airports but I find more performance friendly then later FSDT products, especially KSDF and KMEM. Just my experience. I rather have better performance then eye candy but if eye candy is what sells who can fault? 

As far as calling user criticism whining I put much more stock  in what I read on AVSIM from users over any gushing infomercial disguised as a review to help me with buying decisions. Developers should be ready to receive criticism and preferences with objective maturity and should find them helpful and not consider it a personal attack on them or their work. After studying this thread I feel inclined to take a more serious look at the Drzewiecki offering  as I need an up to date KORD for one of my Atlas Air focus cities.   

Good luck finding the cargo spot in the DD Chicago they are missing many. Oh and DO NOT taxi on the bridge on taxiway B your airplane is going to fall through an invisible hole that you might or might not get out of. If the loading radius puts you off fsdt airports you can edit that in their manager.

[Patco Lch 1,465]

3 minutes ago, Boeing or not going said:

Good luck finding the cargo spot in the DD Chicago they are missing many. Oh and DO NOT taxi on the bridge on taxiway B your airplane is going to fall through an invisible hole that you might or might not get out of. If the loading radius puts you off fsdt airports you can edit that in their manager.

Thanks for that information.

[virtuali 4,421]

Wow, so much assumptions made here...

- The biggest mistake here, is to do any assumptions on how KORD will perform, based on our latest sceneries, like KMEM, KCLT or KSDF. Those don't have anything to do with KORD, because they were made under "impossible" conditions:

1) To look contemporary and next-gen

2) To work on FSX and P3D1, 2 and 3 *and* later on on P3D4

3) To NOT cause OOM, when used together with memory-hungry airplanes in FSX and P3D1, 2 and 3.

This is something that simply is not possible and, of course, you'll find thousands of "FlyTampa OOM" or "Flightbeam OOM" hit if you Google for them. Please note that, when those sceneries were DESIGNED, P3D4 wasn't available yet and, even if we released KCLT and KSDF shortly thereafter, they were still based on the lowest-common denominator, which is the FSX SDK.

And, as explained so many times, we took the stability of the simulator VERY seriously, more than anything else so, to prevent OOMs which happens with ALL OTHER similarly detailed airports in 32 bit, we had to do *very* aggressive memory management and, while we perfectly know they are not so smooth as they could, you don't usually don't hear much OOM issues, even in 32 bit, not as much as you hear from others. Now, everybody is of course entitled to his own opinion but, don't even try to convince me some stuttering is worse than an OOM crash, because I will simply not give up on this. 

Yes, under P3D4, the memory management we do is way less aggressive, but they are STILL airports made 90% with the FSX SDK and about 10% (just the ground polygons) made with the P3D V2 SDK, which makes a bit easier to do ground polygons in P3D, but it's no V4 SDK yet.

Unfortunately, due to the design of the simulator, it's not possible to create objects dynamically without causing some pause. Back then, this was mistakenly attributed to "the Couatl engine", as if it was "slow" or something like that. Of course, it's not and, in *itself*, it doesn't slow down the sim AT ALL, because it runs in a separate process.

The issue is, the simulator ITSELF, when it receives a command to create an object, it's not able to create it in the background, like when new terrain is loaded, because the creation of 3d objects with Simconnect stalls the sim.

Has anyone ever noticed how LONG the pause lasts when UT Live creates all the AIs ? That's exactly the same thing so no, it's not "the Couatl engine", is the simulator engine that stops whenever anyone requires a new 3d object to be created or destroyed.

But again, this was a necessarily evil to save your skin from an OOM, which would likely happen at the worse moment: during an approach, after the simulator already accumulated lots of memory trashing, usually after a long flight,.

SCRATCH ALL OF THAT FOR KORD V2

KORD V2 has *never* been designed to run in FSX or any other of the 32 bit simulators, because we really started working on it after we announced ( together with FlyTampa and Flightbeam, which were even more frustrated than we were of the 32 bit limitations ) our next airports would only be made for P3D4, back in 2017.

We know that some people are still convinced that, all the time we tried to explain the benefits of our software and the reasons for the custom memory management and that we needed our scripting engine to do things not possible with the SDK, this was some kind of lame excuse to justify a poorly optimized program that cause stutters (and saves from OOMs, everybody seems to forget that...) and I'm very happy we'll shortly release KORD, to prove these were really the real reasons why we used the way we did. Why ? It's very simple, really:

- Previous sceneries were made 90% of Simobjects created dynamically, with about 10% made in .BGL, because FSX .BGL format was TOO much limiting, didn't allow any interactivity, didn't allow any memory management and simply wasn't possible to add things that somebody might find "silly", while conveniently forgetting some serious *aviation* related stuff we DO have and nobody else has, like working FAROS, THL, RELs and a working EMAS which actually *stops* the airplane.

- KORD V2 will be made about 80% in .BGL (because it's P3D V4 .BGL), which means we used the Couatl engine only to do what's really impossible to do otherwise, but we won't create many objects with it, because we don't HAVE to.

1) It's 64 bit, so we don't really need too much memory management, because it will surely not OOM. That's why the bulk of the scenery is done with plain 100% native P3D V4 .BGL, and not as Simobjects.

2) We can do lots of dynamic stuff using the sim own native LUA scripting, like multiseasonal objects, etc.

3) We don't need to do strange tricks with terrain layers, because P3D4 .BGLs supports terrain layers just fine, and without the fps cost associated to use FS8 ground polygons that everybody (except us) used in FSX

4) To keep the fps up, we'll use the simulator own LOD system, which allows LOD switching with NO stutters. This, of course, it's no "magic", the sim native LOD system is so smooth, because it loads in memory ALL the LODs at once, so they can be switched over stutter free. Obviously, this takes way more RAM so, in 32 bit, ALL developers were stuck with two equally disappointing choices: either use native LODs and risk even more OOMs (because objects with LOD require more memory), or just not use LOD, and pay a big cost in fps. We had a 3rd choice, to do out custom memory management and custom LODs, so we could keep the fps up *and* not risk OOMs, but at a cost of some stuttering.

Again, this is history with P3D4, since we are now free to use the simulator's own LOD handling without fear of OOMs, so we don't get any stutters and we get the fps gain that comes with it.

Yes, we'll still use Couatl, of course, but not much for *creating* stuff, but for things impossible otherwise, for example:

- The working Information Panel on gates. They are in .BGL, but the dynamic text is made with a combination of Python scripts (which runs externally to the sim and don't create anything, so there's *zero* fps or stutter impact) and our exclusive DirectX 11 RTT, the same that does Jetway numbers and all Jetways, Catering and Handling logos in the GSX PBR update.

- The precise loading/unloading of the in-famous T1 C detailed interior, the one with the passengers and "Brenda". The *actual* loading/unloading is done ONLY in Avatar mode, before something will assume this very process will cause "stutter" while flying. It won't, the handling is just not there and the object is just staying on disk if not loaded. With "precise", I mean we can create a very precise perimeter of the terminal, so we can load the interior (again, in Avatar mode only) only when you walk very close to it so, it's not a simple circular LOD radius or a still simple bounding box: it's the precise perimeter of the terminal.

- This same custom collision system is used to handle the OPTIONAL visibility of animated passengers in the Terminal, from the airplane VC. Yes, this WILL be optional so, if you really hate passengers and are losing your sleep thinking of the frame rate they eat up, you can just turn them off, and they won't ever be loaded. But if you want to see them, we have a method to create them only fairly close around the airplane, because each walking path has its own precise and optimized loading perimeter.

- We'll use Couatl scripting to create an unique "hybrid" system for Dynamic lights, which allow to have the whole airport lit, but without too much fps hit, since we have some lights which are always on, and those are made with plain .BGL files, and some which are only loaded when you are close to the terminal they are attached too, and these are handled by our engine. However, since they are extremely *tiny* objects ( basically an empty object with some lights attached to it ), they are loaded with zero stutters, since they are extremely small. Nothing like loading an actual object, like a whole terminal.

Jetways

I see two issues that must be addressed here:

1) The fact our jetway logos are not square, like the real KORD. Guys, are you serious ? OF COURSE we'll have proper logos but, do you really think it's a good idea to make a quick fix JUST for KORD ? The jetways that come with KORD are obviously GSX L2 jetways so, right now, GSX only supports jetways with logos in the 4:1 aspect ratio but that will of course change soon, maybe not in time for KORD release day ( because it WILL be released in August, this is set in stone now), but when we'll do it, we'll do it in the PROPER WAY, which obviously mean allowing the whole GSX to use logos in multiple aspect ratios, so you won't get them just at KORD, but everywhere else as well.

2) Our jetways don't dock with AI. We said multiple times this will be looked at, and we had several talks with SODE author Jeffrey Stahli, because we thought, since SODE already does a lot of that work, it would be easier if we integrate with it, but that would require some support from it. Now, you all know SODE it's a free product and the author is not asking for any money to developers, which is incredibly generous, but also means we cannot be too needy when asking for new features. That's why it hasn't come yet. But, be sure that if we wouldn't find a way to do this together with SODE, we'll come up with our own solution we could do on our own, with the existing SODE.

The other tricky part of this, is how to do it without causing a dramatic impact on performances, because GSX L2 jetways were made assuming they'll work with the user airplane only which means, while the *Static* version is very well optimized and use multiple LODs, the *Dynamic* version, the one that docks, didn't use any LODs, both because (as I've said), we assumed they would work like GSX always did, with the user airplane only, but also because they take more memory than the static ones so, if the whole airport (because of AI) loaded dynamic jetways, the risk of OOMs would be higher, since GSX still supports 32 bit. Note that, a Docked jetway, even if it doesn't move, is still "dynamic", otherwise it won't connect to the airplane door. But again, this will be done, most likely for P3D4 only, but it must be done properly, over the whole collection of GSX L2 jetway models.

We'll probably have to bite the bullet, and model an entirely separate set of jetways in lower detail, just for AI use. And again, the whole GSX would benefit from this, not just KORD so, when they'll come, they'll come worldwide.

Edited August 11, 2019 by virtuali

[alex86 192]

I’m just here for  Virtuali’s awesome replies lol. Thanks for evolving our hobby and constantly pushing the envelopes. 

[Patco Lch 1,465]

Virtuali, thanks for the informative post. Very enlightening even if a great deal is beyond my primitive knowledge. Very much looking forward to the release of KORD v2.

[Skywolf 992]

Wow...Umberto did an awesome mic drop moment.  Fantastic Post!!!! Thank you for sharing some amazing insight on the backend of this.  This post should be frontpage on fselite/or avsim etc as a cover story or something

Edited August 12, 2019 by Skywolf

[SP2472 2,303]

Please FSDT don't tease us...it's like Peanuts with the interaction between Charlie Brown vs Lucy and the football. Virtali keeps showing us pictures and Chicago looked "almost" complete a year ago.

I guess FSDT just works slow....that's their prerogative.

 

[ComSimPilot 623]

Umberto thanks for the very informative reply. Such input is needed. 

Can you also comment about when approximately we'll be able to get the new KORD? I guess the "few days" does not hold anymore. Can we have a new target approximately?

[virtuali 4,421]

13 minutes ago, Daedalus said:

Umberto thanks for the very informative reply. Such input is needed. 

Can you also comment about when approximately we'll be able to get the new KORD? I guess the "few days" does not hold anymore. Can we have a new target approximately?

We have a date in mind, but we won't publish it because, if  we couldn't meet it for any reason, because nobody usually reads my complete sentences ( which in addition to "a few days", always said "release date can change at any time", the conspiracy theories will spread plenty.

Usually by the same people that would otherwise said "I found this bug and this other one, why they haven't released it a bit later to fix them ?"

In addition to that, we are trying to fit the release with all the team vacation times, which are all different, since we don't want to release it unless we are all available to work to fix any possibly emergency that might happen after the release. So, more than a release date, we have a "launch window" and the only thing which is 100% sure, is we'll release it in August.

For example, one thing that must still be done, it's a way to offer some kind of discount to owners of the old version, regardless where they bought it, which is not easiest thing to do, because of all the retailers that closed, the new ecommerce site we use doesn't recognize past orders, Esellerate has deleted the ones older than 10 years to comply with GPDR and all those things happened after we promised a discount so, we must do some kind of special website to allow users to get a discount. It won't be much, because this is a total remake, but it's still something and, more importantly, we *promised* it.

[environmental_ice 238]

I wish people would stop asking when is it going to be released. Really wondering if VIrtuali has ever answered that question with an actual date in the last decade

[ComSimPilot 623]

2 hours ago, Redwood said:

I wish people would stop asking when is it going to be released. Really wondering if VIrtuali has ever answered that question with an actual date in the last decade

The question of "when" is not requiring a date as an answer as some suggest. It can be answered by a range or window of expected release, with an asterisk that that can always change. It is better to have an estimate than nothing. Umberto's answer fully satisfies my question as the interest is not to come here after and ask why it was missed but to get an idea of when to expect it, again approximately. 

[environmental_ice 238]

3 hours ago, Daedalus said:

The question of "when" is not requiring a date as an answer as some suggest. It can be answered by a range or window of expected release, with an asterisk that that can always change. It is better to have an estimate than nothing. Umberto's answer fully satisfies my question as the interest is not to come here after and ask why it was missed but to get an idea of when to expect it, again approximately. 

hes answered this question a million times...here and on FSDT forums

[Skywolf 992]

on a funny side of things.  I can guarantee that users will complain what is the next release the minute after FSDT KORD is out.  Lol....

Thank you again for sharing insights and what a fantastic video.  What a massive airport

[_Gladius_ 24]

1 hour ago, Skywolf said:

on a funny side of things.  I can guarantee that users will complain what is the next release the minute after FSDT KORD is out.  Lol....

Thank you again for sharing insights and what a fantastic video.  What a massive airport

Why wait?  Here’s hoping for a P3D4 version of KLAX!

Edited August 13, 2019 by _Gladius_