can someone please post a full description of the issue?

reading through all those posts in this thread I couldn't figure out exactly what the problem is, only what products "a problem" potentially exists.

 

Picture or a Video would be helpful ...

+1 Although a great discusion, it has been a bit confusing. Is this the same issue as some report as a "layering problem with orbx global"? Perhalps a new thread with only here is the problem and without the additional who is as fault ect. would be helpful although I am still not sure that this is going to turn out to be as big a deal to get fixed as some believe.

I am now on 3.3 But If I have to go back to V3.2, Do I simply uninstall 3.3 client and reinstall the 3.2 client?

 

How else do I go back to 3.2 if I do decide to go back?

I also go back, using my Acronis images. To many issues with airport ground layers of P3Dv3 "compatible" airports (e.g. AS EGLL, FT EKCH, T2G KSEA).

Sorry Rob but I personally will neither post videos nor screenshots about the problem. The reason is simple, it's already been mentioned by many people here, in the LM forum and elsewhere.

 

Then what is the purpose of this thread?  

 

 

 

The scenario was similar, hundreds (if not thousands) of users experienced the problem, they wrote about it here and elsewhere, while yourself and some others of course tried to deny the existence of the problem, until it became obvious that it exists and LM did its best to solve it, and did that almost instantly.

 

Completely false ... please don't misinform others.  I looked into the rotating clouds claims and was able to replicate it a high zoom levels and extreme angles and reported the issue to LM to see if it could be improved ... understanding how the cloud processing system works (2D plane that rotate in 3D virutal space to face the view point) in order to retain acceptable levels of performance ... this system will never be "perfect" and it was never designed or coded to be perfect and the rotating clouds issue still exists today at extreme zooms and angles.  No sim to date use truly volumetric clouds because of the the rendering overhead ... no hardware today or probably 10 years from now would be able to render true volumetric clouds, so we live with a compromise so as to meet the 90% case and retain acceptable performance.

 

 

 

As I mentioned earlier, it simply should have been checked how the change affected the majority of sceneries out there, regardless the method they were made by.

 

This is a huge exaggeration, so far the only airports presenting this issue on my system is with UK2000 that claimed to be P3D V3 compliant ... I still can't imagine UK2000 are still using the FS2002 SDK to produce airports for P3D V3 - do you have a source for this??  But I'm sure you are aware some airports can't be tested by anyone OTHER than the developer such as those that use Orbx ObjectFlow and/or Virtuali's (aka FSDT, FB, etc.) as they tie those DLLs to specific P3D versions and during the Beta we Beta testers will have non-functioning ObjectFlow, add-on manager, etc. so we could NOT test those airports even if we wanted to.

 

My interpretation of your content in this thread is to suggest fault towards Beta testing/testers because your specific airports using very old techniques going back 14 years should have been tested by someone other than the original developer of the scenery/airport.  You've completely ignored my information on the duration of this Beta cycle and how that could even be possible for anyone and made an assumption that "sceneries/airports" is the "focus" of all Beta testers ignoring the many other aspects of 3rd party content beyond just scenery and airports.

 

But like I said, I've presented this info to LM. If it was an obvious oversight, then I'm sure they'll fix it, but if it was "by design" then it's unlikely to be fixed and 3rd party devs will need to step up to the plate and make the necessary changes using the appropriate tools/SDK.  Alternatively users could just stick with P3D V3.2 and wait and see what happens.

 

Cheers, Rob.

Attacking BETA testers isn't productive especially when you don't know the cycle frequency and/or time frames nor what's involved or scope. It would be very unrealistic to expect Beta testers to run through 40,000+ (going back to FS2002) 3rd party products in a matter of 1 week and re-test per weekly beta update release for about 5-6 weeks until released to public.

 

would suggest you use an approach that isn't filled with assumptions and be positive ... odds of being heard are greater, just don't bring expectations.

Well said Rob....are you a beta-tester , and are you showing the same problem described here?

 

If you ARE a beta tester! but;

1. did NOT show the same 3.3 Layering "bug" ,

2. publishing your setup might be a good baseline from which to troubleshoot

 

 

Chas

In version 3.2 ORBX KSQL had this issue.  Doing a quick test it seems KSQL is ok, but now the issue that was there is now present at every other addon airport I’ve tried including other ORBX airports.
 
Here’s the post showing the problem at KSQL:
http://www.orbxsystems.com/forum/topic/112552-trouble-in-san-carlos

 
Here’s an example from ORBX KSTS rwy 14 in 3.3. The problem is not present when I revert to 3.2.

 

 

 

Nice Brian and this quote from Orbx site - nothing to earth shattering - I can wait - 3.3 is better imo - smooth clouds way better AA on aircraft exterior - smooth payware night light action -  that alone for me is great 

 

Just an update, LM will have a patch for us to test in a couple of weeks. 

 

FWIW These airport developers using old tools need to up Their game or be left behind

 

 

In version 3.2 ORBX KSQL had this issue.  Doing a quick test it seems KSQL is ok

 

This is what I mean by mutually exclusive fix ... can't work both ways.

 

Cheers, Rob.

Then what is the purpose of this thread?

 

Completely false ... please don't misinform others.  I looked into the rotating clouds claims and was able to replicate it a high zoom levels and extreme angles and reported the issue to LM to see if it could be improved ... understanding how the cloud processing system works (2D plane that rotate in 3D virutal space to face the view point) in order to retain acceptable levels of performance ... this system will never be "perfect" and it was never designed or coded to be perfect and the rotating clouds issue still exists today at extreme zooms and angles.  No sim to date use truly volumetric clouds because of the the rendering overhead ... no hardware today or probably 10 years from now would be able to render true volumetric clouds, so we live with a compromise so as to meet the 90% case and retain acceptable performance.

 

This is a huge exaggeration, so far the only airports presenting this issue on my system is with UK2000 that claimed to be P3D V3 compliant ... I still can't imagine UK2000 are still using the FS2002 SDK to produce airports for P3D V3 - do you have a source for this??  But I'm sure you are aware some airports can't be tested by anyone OTHER than the developer such as those that use Orbx ObjectFlow and/or Virtuali's (aka FSDT, FB, etc.) as they tie those DLLs to specific P3D versions and during the Beta we Beta testers will have non-functioning ObjectFlow, add-on manager, etc. so we could NOT test those airports even if we wanted to.

 

My interpretation of your content in this thread is to suggest fault towards Beta testing/testers because your specific airports using very old techniques going back 14 years should have been tested by someone other than the original developer of the scenery/airport.  You've completely ignored my information on the duration of this Beta cycle and how that could even be possible for anyone and made an assumption that "sceneries/airports" is the "focus" of all Beta testers ignoring the many other aspects of 3rd party content beyond just scenery and airports.

 

But like I said, I've presented this info to LM. If it was an obvious oversight, then I'm sure they'll fix it, but if it was "by design" then it's unlikely to be fixed and 3rd party devs will need to step up to the plate and make the necessary changes using the appropriate tools/SDK.  Alternatively users could just stick with P3D V3.2 and wait and see what happens.

 

- The purpose of this thread (in this forum) is to warn those users who are willing to update immediately. They can do that of course (just as I did) but they need to face this specific problem, which renders 60-70% of their "airport-collections" almost useless.

 

- With some 2.x version, the "rotating clouds" problem was so obvious that meant a no-go for many. I consider you being an admirable fighter defending your own truth and opinion, and I appreciate that, but I do hope you don't seriously and really want to start again an almost two years old debate...

 

- Yes, the problem should have been checked by one of the dedicated beta testers (preferably a scenery designer) because by re-touching the layering code, there was a chance (as it's always the case with these types of tiny changes) that it may negatively influence airports based on the older code.

As this small fix was NOT intended to render ALL those airports or code-type useless, and LM is aware that there thousands of users still using those airports (still being sold and advertised) so a simple look at compatibility would have been an easy and logical move. That's why I dared to mention the beta-cycle, because it was seemingly not tested.

Thus it not an "accusation" towards beta-testers, specially not yourself, it is just a logical and general mention of the lack of thorough testing.

 

- This part of the code changed when version 1.4 came out. Until then (and in FSX) layers could be numbered by any number (between 0 & 44), after the change only those numbers could be used, which were a power of 4. Designers modified their layers accordingly and in v. 3.0 it has changed back to the original numbering, once again.

The core of the problem is (which can only be tested by a designer) that regardless the numbering of those layers, the problem always exists, although appears at different places if the numbers are changed. There is no solution to layer those, without getting one or two layers to disappear, depending on the reference-point of each of them.

 

- There are many users out there, with these older sceneries, who did not notice the problem as yet, due to the fact that it is dependent on the aircraft's position, but sooner or later you will get more and more "reports" about the problem.

 

- I think there's no use to specifically mention companies, but if you insist, I can do that: all Aerosoft sceneries (apart from the latest), all UK2000, all BluePrint, all  FlyTampa, all Alphasim, all Cloud9, all EireSim, all LHSIM, all Flightbeam, all Flylogic, all FSAddon, all Japanese sceneries, all Imagesim, all Taxi2Gate, all TropicalSim - and a lot of other sceneries, should I go on?

 

- You mention your own interpretation of the problem, which has little weight in my eyes, as you are not a scenery designer, did not see the problem, that's why you need "proof" before all.

That proof is there, thousands of user see it or will see it, so there's little to debate about the very existence of the problem, which you rightfully channel towards the obsolesce of the elderly code type, but you need to understand that at this moment, at 3.3, it is most probably an unfortunate glitch by a single developer at LM, and not a step towards the glorious future.

 

Edit:

Simply forgot to mention an important thing. Namely that you mention "the 14 years old" factor, as if there were mentally retarded scenery designers, who for some unknown reason are reluctant to change their ways and stick to the 2002 method.

It is definitely NOT the case, as we are actually NOT talking about anything else, but ALL AIRPORT sceneries made for FSX. In FSX there is no other method available. Neither in ESP nor in P3D 1.x

So just to be precise, we should mention FSX airport methods, rather than living too high on the horse and belittle what is still the only way for FSX.

Yes, P3D 2.x introduced a different and easy method, it works fine, but if you compare the very same airport with the two methods (which used to work fine until 3.3) the actual performance gain is noticeable, measurable, but marginal...

 

Potroh

I am now on 3.3 But If I have to go back to V3.2, Do I simply uninstall 3.3 client and reinstall the 3.2 client?

 

How else do I go back to 3.2 if I do decide to go back?

 

If you Only Updated with Client,  Just Uninstall Client 3.3,  and Update down to Client 3.2 

Any specific stuff we have to do appears all Aerosoft stuff is broken now :( i fly alot to PANC and its crap now due to this bug, anyone know another PANC scenery thats great on part to flytampa or fsdt?

PANC was never upgraded for P3D V3, however I landed in FlyTampa St Maarten in 3.3 and it looked fine.

 

 

Just an update, LM will have a patch for us to test in a couple of weeks.

Rich, that comment that Ed made about the patch was indeed made on May 4 and actually refers to this 3.3 update, i have just updated and found no issues with FB Denver, any of the NA Orbx airports i have, FT Sydney is fine and Dubai also, i have not tried any unofficial FSX--> P3d airports yet?

For UK2000 users, more information from Gary Summons, also technical background of the problem.

 

http://www.uk2000scenery.org/forum/index.php?PHPSESSID=a9a453871aa9195133158475239c68cc&topic=8548.msg59657#new

For UK2000 users, more information from Gary Summons, also technical background of the problem.

 

http://www.uk2000scenery.org/forum/index.php?PHPSESSID=a9a453871aa9195133158475239c68cc&topic=8548.msg59657#new

 

This are good news. Garys statements are clear and promising. Let's hope that other developers have the same attidude and are willing to renew ground tiles with P3D code.