I am not understand, problem with...

[EDDT-Sebi]

Hello,

So, i found some problem about Scenery Zurich. But why?

PMDG Aircraft is okay...
Captsim is okay...
other aircraft default is ok..

But, i fly with PMDG Boeing, no problem with Scenery Zurich
Overland/SMS Aircraft Airbus A321 with Eric Marciano Panel go to Zurich, it is problem..! Show my video..

Video

Scenery go off and on...

And two problem with AES, active with dopple Gate..

Sebastian

[virtuali]

From the video, it looks like that airplane is writing into one of the variables reserved for sceneries, and that would make it not compatible with Zurich. I guess it would show similar issues with EHAM, KLAX and all our former sceneries.

I'm afraid it's nothing we can fix, an airplane shouldn't use variables reserved for scenery, they are "reserved" just for a reason, so sceneries can use it.

[EDDT-Sebi]

Hello,
Yes, right! I try with Overland Airbus by KLAX, some problem! I change other aircraft, Klax scenery was okay!!
Why is Model of Overland Airbus?

Sebastian

[OPabst]

From the video, it looks like that airplane is writing into one of the variables reserved for sceneries, and that would make it not compatible with Zurich. I guess it would show similar issues with EHAM, KLAX and all our former sceneries.

I'm afraid it's nothing we can fix, an airplane shouldn't use variables reserved for scenery, they are "reserved" just for a reason, so sceneries can use it.

Hi,
I don't think that this is a good approach to see this issue: The uservariables in the FS Global are the only available space in FS, where Models (scenery or aircrafts) can write in. So all Animations will use this space to calc there values (ok, normally only the first bytes).
Solong as the space is not used over the area of a local code, nobody will be involved, and I think the Aircraft (or other Designers) will not expact that the value he is writing in can be readed in another model part or at the next frame.
In your case, you expact that this space is reserved only for you and nobody else can use this space within one frame, but I think nobody can't garantee that and it is not a problem of the other product.
I know you can't change it, but maybe you can think about another approach in future.

Brgds
Oliver Pabst

[virtuali]

In your case, you expact that this space is reserved only for you and nobody else can use this space within one frame, but I think nobody can't garantee that and it is not a problem of the other product.

That's exactly the same assumption that airplane made. He's assuming nobody else will need that variables, with the difference these variables are always been SCENERY variables, not "everybody's" variables. Of course, the problem happens only with that particular airplane, and I can't think of any reason why an airplane would need that, given it has access to anything else, and those user variables are the only ones that a scenery can use, so I don't see why an airplane should need to steal that ones as well.

I know you can't change it, but maybe you can think about another approach in future.

This is all legacy stuff that we need to support FS9. In FSX, but only starting with SP2 (I've got confirmation from MS developers just today) we can have much smarter objects and talk to them via Simconnect, so we might get rid of those variables.

But, as long as people wants FS9 scenery, we have to keep using them. It's only a SINGLE airplane that creates this issue and, since it's the first time someone reported this in the 3 years we are using that approach, it's a non issue.

[OPabst]

Hi Umberto,

I saw the problem in my Installation too, because I use this offset to make some debug possibe, because this variables are the only one, I can display via FSUIPC. In my Bremen Project I used this offsets for communication between my scenery objects and in FS2002 I had no problem. But with 2004, the Trick18 Animations (in AI Airplanes for example) used this offsets (first 2 uservariables) to generate the float input for the animation opcode. From that point on,my scenery get problems.
For AES I planed to use the offset 312-318 to animate my object too, but at the moment I only use 312-314 so it will not gernerate a confict.
Now, where I know that you use the rest, I will take care about that situation and use a different (more complex) way.

Brgds
Oliver

[virtuali]

It's quite normal a *scenery* might want to use those variables. Out of the 5 available, we need only 2, and we can specify which ones on a scenery by scenery base, because we are well aware that FS9 uses for the animation of several stock objects, so the Addon Manager database can specify which 2 we need for every single scenery. Since sceneries cover a limited area and when they are excluded, there are no interaction with variables for the excluded ones, once we check that no default objects in the area are using those variables, we are usually set.

What I was questioning, is why an airplane would need to write there...