Beiträge von Goof

M 0.67--> ETA 2059z

ZU guter Wind

Bah, blöder Wind Meine ETA geht immer weiter von 2100z weg.

Ab heute bin ich Fsdreamteam-Fanboy. Wahnsinn, was die da gemacht haben Paar Impressionen vom Taxi-takeoff in Vancouver

Opus :streichel:

So, enroute, Bilderchens kommen gleich

So, ich steh am Apron in Vancouver, alles soweit fertig, pushback gegen 1540z.

Da gibts eh net viel.. ILS /Loc 22, Rnav 22/04, Taxiways. Ist halt doch ein dorfflughafen

Jo, aus meinem transatlantikflug wird leider nix mit der F18 Kriegt man auch so wenig Paxe rein

Opustier bei der Arbeit :streichel:

Kuck, das was für die NGX übrig bleibt... DIE ist Pflicht für jeden FSX

Also Unicom

Timo:

Der Trick beim Autopiloten ist es, dass es ohne einfacher geht Der ist sehr unpräzise. Die Höhe hält er +/- 350 Fuß. Kurse kann er aber recht gut abfliegen Die Mühle ist aber echt super

Ich freu mich.. Ich hoff nur, dass es bei mir hinhaut.. Meine Mutter ist heut krank und es kann sein, dass ich meinen Vater heut abend vom Flughafen abholen muss. Mal schauen, ich werd auf jeden fall mal losfliegen.

Edit: Neue Berechnungen mit Current winddata:

45 Knoten Rückenwindaverage auf der Route von CYVR nach KBHB, hochgerechnet auf eine Groundspeed von ca. 500 bei der 737 komme ich auf 4:43 Flugzeit. Kumiaufschlag heute mal 10 Minuten--> 4:53.

Departure in CYVR: 1607z.

Das heisst ich steh um 1530z sowas am Apron

christian, sei unbesorgt, du warst nicht der einzige, der mir heut hinter der 28 in die wiese gebrettert ist Die 747 mit low fuel hat das auch geschafft

feddisch mit Lotsen heute Jetzt gibs erstmal was zu essen

Haben wir eigentlich äi di si oder lotst der unicom?

Heute das erste Mal lotsen auf IVAO Ich schieb jetzt schon nen Hass auf VFR...

Also ich komm dann wie oben gerechnet von Vancouver mit NGX

Alles Guuute

Alles Gute Maik Feier gut da drüben :party:

Zitat

On the other hand, FSDT has to consider that most users already have a range of addons installed that they consider as a "base"

It's exactly this kind of reasoning that HAS to be changed.

What people seem not to get (not many, fortunately, most understood it) is that this problem WILL happen in a few months, unless other scenery developers will keep being smarter than us (it doesn't take much, we know to be reckless and always trying to do the difficult things) and will all revert doing airports in desert areas, is that this "base" you are referring to, sooner or later WILL EAT ALL YOUR 4GB!

It happened first here, only because there are many Add-ons in this area, you make it sound as if the "OOM" message never existed before CYVR, which is obviously not true and, in fact, the cold hard reality, is that it was usually associated with other products.

Once the "add-ons you can't live without" wil reach 4GB when used all together, the "base" you are suggesting we should take into account, will not exist anymore. What would be your suggestion, in that case, keep making sceneries *lighter* and *lighter* ? Even that will end eventually, up to a point that, when we'll have 0 bytes left at our disposal, we couldn't even start adding anything, and some areas in the FSX world will be untouchable. Which, of course, happen to be the most commercially interesting ones.

We can do a "big fat" scenery in the middle of nowhere but, how many people will buy it ?

Quote
I'm talking about AS2012, REX, NGX, FSinn/IVAP and in this case, ORBX. These addons can be used at the same time without OOM's at any other airport on the market.

The easy answer is, that airport works with any other airplane too. And that doesn't obviously mean CYVR doesn't work the NGX, because it does, the problem is pretending to use *everything* at once, as if the 4GB limitation didn't existed.

And you can probably use all those products together, but you have to renounce to SOMETHING, for example making some compromises with visual quality. You can start playing with your sliders. You don't HAVE to keep your scenery range to Large, and that takes quite a bit of memory too.

We have a switch in the Addon Manager, that allows you to turn off 4096x4096 textures, and that can be used without having to restart FSX.

The CURRENT version, which we uploaded yesterday, has a 3 position switch instead of the previous on/off, so you can also choose the 2048x2048 resolution, which is still very nice, and still results in a considerable memory saving.

Quote
If Vancouver, despite all innovate techniques, turns out to be the ONLY place where they can't be used together, FSDT should probably consider offering a "light" version of the product that can be used without creating OOM errors.

It has already been discussed, here and on Avsim, that we ARE working on an update.

Not that there was anything "wrong" with the scenery in the first place, it just happened to be a bit larger than KLAX, but in an area that has far more additional purchasable scenery than KLAX. Let's hope the PMDG 777 will not use more memory than the 737 because, if you were lucky to be able to use the 737 (together with all the other stuff) until now at, KLAX or PHNL, but just barely (you don't know you are close to an OOM, until you get one), it's might be enough adding a bit more of memory requirement, and you WILL crash elsewhere other than CYVR.

What will happen then, people coming here asking for lighter versions of all our past sceneries, just because the "newest and greatest" came out ?

This to be very clear about what we believe is right.

Either people will get reasonable, and don't feel "diminished" if they are not able to run with 6-7 add-ons at the same time with all sliders to the right, or this situation will escalate soon enough with something else and, looking at the near future, it will make the sim entirely unusable, or any new product launched will fail, because nobody would be able to use it because your "minimum base" is already too near to the maximum memory limit in FSX, which is a FINITE resource.

Quote
I'm just really disappointed that the scenery is not useable to me at this point. It would be kind and fair if FSDT recognizes and acknowledges the comments of a valued customer instead of waving away these comments by stating it's the customer to "blame".

It's not your "fault" if you weren't exactly aware of the 4GB limitation in FSX, which is something that can't be fixed, unless the sim is remade in 64 bit code, which seems to be specifically difficult with FSX, since part of its code are very old and written in Assembler code, which is very hard to convert to 64 bit. But once you get to know about it, you have to live with this limit and start making choices, if not about the number of products used together, at least to the visual quality.

Since a 64 bit FSX is not coming out, not in the foreseeable future, we must do with what we have, but you can't pretend that limit doesn't exist, and keep adding stuff and pretending the developer would magically be able to "fit" in a progressively reduce space, because of the "established base", which can only grow larger. And BTW, who decides exactly *what* add-ons make the minimum base ? It takes about 1 year to do airport like CYVR, what happens if something new comes out in the mean time that takes another slice of the memory that we believe to have at our disposal, when the design of the scenery just started ?

But of course, this doesn't mean we don't listen to suggestion. We obviously do and, as I've said, we are working to change a few things, at least to allow users to choose exactly *where* they can work to reduce memory usage at CYVR.

The first improvement is already out, the updated Addon Manager will let you choose the 2048x2048 resolution (again, without a restart, so you might find convenient using 4096x4096 in less dense areas if some of your products requires it, and switch to 2048 in the more critical areas ) and VISUALLY, it's much closer to the 4096x4096 compared to going down to 1024x1024, which might be too big of a compromise.

This goes together with the upcoming CYVR upgrade, which is already done, we are just testing it, which will allow to make some choices during the installation:

- You will able to choose the resolution of the Dynamic Shadows separately from all the other textures. A screen while installing will allow you to install 1024, 2048 or 4096 versions of the shadows textures, with an estimate of how much memory each option will require. IF the dynamic shadows were just the thing that put you on the other side of the OOM threshold, you can now control them separately, without affecting the rest of the scenery quality.

- You will be able to choose the resolution of the Ground textures separately (for example buildings, etc.), another screen will provide with a sample and an estimate in memory usage for 1024, 2048 and 4096 versions.

With the resolution options, you have complete flexibility about were you can act on the scenery memory requirements. For example, choosing 1024 resolution for the dynamic shadows and 2048 resolution for the photoreal background and 4096 for everything else, will still look very good, and will bring overall memory requirements to be same or less than KLAX.

- We ADDED a new Season, but since there's only one in memory at any given time, it doesn't affect memory usage at all, but you will be also able to select how many seasons you want, with 3 choices, Winter/Spring/Fall, or Winter/Spring, or Evergreen with just Spring. ON TOP OF THAT, by changing two easy parameters in an .INI file, you can even customize the *dates* when seasons change, to allow a better compatibility with any other land-class scenery you might have.

Alles anzeigen

Spiegelt ganz gut die Problematik beim FSX wieder