I hope they develop something that the airport doesn't take about 5seconds to load when approaching it - that might be horrible in a busy online environment. I noticed that these loading-moments get longer with every scenery they release - in CYVR it feels like an eternety and i always think it crashed.... Other sceneries of that size don't have these (noticable) loading times (like OMDB, KIAD,...)

 

I have a feeling this maybe not be a scenery issue, but something related to their DRM, the Addon Manager. I have the same issue with Flightbeam airports (including KIAD). Quite nerve wrecking!

I have a feeling this maybe not be a scenery issue, but something related to their DRM, the Addon Manager. I have the same issue with Flightbeam airports (including KIAD). Quite nerve wrecking!

 

That might really be the case since i have a GTX570 - certainly not the newest model - but with the settings set up pretty low it should hanlde it.

 

 

That might really be the case since i have a GTX570 - certainly not the newest model - but with the settings set up pretty low it should hanlde it.

 

I don't believe it's a specs issue, I'm running a 4770k and a 4GB GTX680.

I have a feeling this maybe not be a scenery issue, but something related to their DRM, the Addon Manager. I have the same issue with Flightbeam airports (including KIAD). Quite nerve wrecking!

 

May I ask how the addon manager would have any affect on this? The addon manager is it's own program, seperate from FSX, with it's own address and VAS space, so it can't steal any memory, or anything else from FSX

I have a feeling this maybe not be a scenery issue, but something related to their DRM, the Addon Manager. I have the same issue with Flightbeam airports (including KIAD). Quite nerve wrecking!

That's doesn't have anything to do with "DRM", and much less the Addon Manager, which doesn't have any part in creating the scenery, not anymore at least (it used to be in early products such as Zurich, but you said it got *worse* with newer release...).

 

What creates our sceneries is a program written in the Python script language which, as explained many times, runs externally to FSX in order not to steal any resource from it, and its entire logic runs in the background so, nothing that program does can slow down or take away memory from FSX.

 

Of course, the actual *creation* of object takes a bit of time, and it "gets worse", because the newer products have way more detail than the old products.

 

At CYVR, we need to dynamically change all objects depending on time of the day, and we nned to switch the whole scenery and ground textures+tree to get seasonal changes. In order to NOT waste any memory, objects not needed will be destroyed to be replaced by objects for the current daylight or seasons, and this takes some time.

 

But the advantage of this, compared to a scenery made in the traditional .BGL way is that, we only keep in memory only ONE copy of the object, instead of pre-loading all the possible variations. Same for night/day objects such lamp posts, we don't even create them at day.

 

You mentioned Flightbeam: some of the most interesting features in KIAD are the extremely dense forest around the airport, which is multi-seasonal too, and the night lights that change depending on the weather (in low visibility, the apron lights project a *different* halo on ground, compared to good visibility), this feature was of course made possible with our Couatl scripting engine, and if they did those thousands+ of trees in multiple seasons without the Addon Manager, they would have taken 4X the amount of VAS...

 

Also, we need to create objects programmatically, in order to be able to use shaders on ground which, incidentally, give us full DX10 compatibility without heavy flickering ground problems, which is what you get if you try to use ground shaders and ground in native FSX code, if you don't add extra programming.

 

Someone on fsdeveloper.com proposed an alternative method based on LODs levels to achieve this, without needing a module, but with that method, guess what, the memory requirement increases dramatically for each ground layer used, while with our method, we don't create multiple version of the ground layers.

 

For the same efficiency reasons, the Addon Manager also handles Trial and registration, in order not to waste memory for an utility-only module and a protection-only module. By having both features in the same module, we save even more memory and resources compared to having two separate modules or (even worse) a separate module for every product, but fact that it's ALSO used for protection, does't mean the DRM it's the "cause" for the loading pauses you are referring to.

 

Even if we were to release a freeware scenery, it would load exactly in the same way.

That's doesn't have anything to do with "DRM", and much less the Addon Manager, which doesn't have any part in creating the scenery, not anymore at least (it used to be in early products such as Zurich, but you said it got *worse* with newer release...).

 

What creates our sceneries is a program written in the Python script language which, as explained many times, runs externally to FSX in order not to steal any resource from it, and its entire logic runs in the background so, nothing that program does can slow down or take away memory from FSX.

 

Of course, the actual *creation* of object takes a bit of time, and it "gets worse", because the newer products have way more detail than the old products.

 

At CYVR, we need to dynamically change all objects depending on time of the day, and we nned to switch the whole scenery and ground textures+tree to get seasonal changes. In order to NOT waste any memory, objects not needed will be destroyed to be replaced by objects for the current daylight or seasons, and this takes some time.

 

But the advantage of this, compared to a scenery made in the traditional .BGL way is that, we only keep in memory only ONE copy of the object, instead of pre-loading all the possible variations. Same for night/day objects such lamp posts, we don't even create them at day.

 

You mentioned Flightbeam: some of the most interesting features in KIAD are the extremely dense forest around the airport, which is multi-seasonal too, and the night lights that change depending on the weather (in low visibility, the apron lights project a *different* halo on ground, compared to good visibility), this feature was of course made possible with our Couatl scripting engine, and if they did those thousands+ of trees in multiple seasons without the Addon Manager, they would have taken 4X the amount of VAS...

 

Also, we need to create objects programmatically, in order to be able to use shaders on ground which, incidentally, give us full DX10 compatibility without heavy flickering ground problems, which is what you get if you try to use ground shaders and ground in native FSX code, if you don't add extra programming.

 

Someone on fsdeveloper.com proposed an alternative method based on LODs levels to achieve this, without needing a module, but with that method, guess what, the memory requirement increases dramatically for each ground layer used, while with our method, we don't create multiple version of the ground layers.

 

For the same efficiency reasons, the Addon Manager also handles Trial and registration, in order not to waste memory for an utility-only module and a protection-only module. By having both features in the same module, we save even more memory and resources compared to having two separate modules or (even worse) a separate module for every product, but fact that it's ALSO used for protection, does't mean the DRM it's the "cause" for the loading pauses you are referring to.

 

Even if we were to release a freeware scenery, it would load exactly in the same way.

 

I never knew the addon manager did this much... quite impressive.