FSDreamTeam forum
Products Support => Dallas FSX/P3D => Topic started by: cmpbllsjc on August 07, 2010, 07:15:54 am
-
Umberto, I though that by setting my Mesh to 10m it fixed the problems I was having but I was wrong. I attached some pics. Seems like the bleed thru is in the same places. I also tried disabling MegaScenery Dallas and was faced with the same bleed thru, except that instead of bleeding thru the MegaScenery Dallas photo textures, it bleeded thru the GEX ground textures.
Not sure what else to try. I tried increasing my Mesh to even lower than 10m which if I remember right was 5m, but that didn't help.
Would changing the elevation of the airport help at all, maybe by a foot or so? I will wait until I hear back from you before I change the ADE file, but in the mean time I am out of ideas. I attached the best pics I could but its hard to capture the bleed thru becasue it comes in flashes and therefore is hard to capture.
Thanks
BTW, the first pic of the exterior of the helicopter was taken at one of the fuel boxes. There are some areas like that one where the a/c sink into the ground a little bit. However I dont mind a little ground sink if it will prevent the underlying textures from bleeding thru.
-
Umberto,
While you were sleeping last night I did some further testing to see if I could eradicate the texture bleed thru.
Here's what I found, running mesh at 10m and at full mesh complexity didn't have an effect on the areas in the pics I posted.
I closed FSX and renamed the file in the FSDreamteam/KDFW/Scenery folder mesh.bgl to mesh.bgl.bak then ran the sim again to see if that made a difference. What I found was that it eliminated the texture bleed thru on the south end of the airport, but the texture bleed on the north side of the airport by the UPS ramp and north entrance still exists.
I am convinced now that this is some type of a mesh issue causing the bleeds and flickering ground because now it is only isolated to those two specific areas since I remaned the other mesh.bgl in your folder.
Attached are two pics showing were the texture bleeds are now.
I will check back in the morning to see what you have to say.
Thanks - Sean
-
I closed FSX and renamed the file in the FSDreamteam/KDFW/Scenery folder mesh.bgl to mesh.bgl.bak then ran the sim again to see if that made a difference. What I found was that it eliminated the texture bleed thru on the south end of the airport, but the texture bleed on the north side of the airport by the UPS ramp and north entrance still exists.
The mesh.bgl file is there just to fix any possible bleed-through. However, if removing it fixes (or change) the problem, apart from proving it IS someting mesh-related, it means this file is "losing" against some other mesh you might have installed. Which is odd, since it has an high enough resolution that should "win" over any other mesh out there. However, I'll check it better, perhaps there's some rounding error somewhere. It's nothing you can fix with the AFCAD, though, because it's a fight between the hi-res ground textures and the low-res photoreal background.
-
Thanks for the info. Well go to know that it is mesh related and narrows down the possible things that could be causing the problem.
The only after market mesh I have is the payware mesh for North America by Justin at FSGenesis. If you want I can try disabling that one particular mesh bgl that covers the area if you can tell me which file it resides is, that part I have no idea.
Thanks again for the help.
Aside from this little problem the airport is a wonder work of art :-)
-
Umberto, I though that by setting my Mesh to 10m it fixed the problems I was having but I was wrong. I attached some pics. Seems like the bleed thru is in the same places. I also tried disabling MegaScenery Dallas and was faced with the same bleed thru, except that instead of bleeding thru the MegaScenery Dallas photo textures, it bleeded thru the GEX ground textures.
I do have exactlly the same problem.
Idem about the pics attached above. Exactly the same.
??? ???
-
Umberto, I though that by setting my Mesh to 10m it fixed the problems I was having but I was wrong.
There are two different situations here:
1) You don't have any other mesh for this area:
- In this case, setting the mesh complexity to 10m or better IS still required, but it will surely fix the problem
2) You have another mesh that is taking precedence:
- In this case, you still have to set the complexity to 10 m, but it will not be enough to solve the problem, the other mesh should be probably disabled.
-
I don t have any third party mesh installed, only Mega SceneryX Dallas.
All set to the required settings.
It is as if two different layers of textures lay one on the other and for some reasons the "lower" texture layer "flickers" through the upper texture layer. With the Mega Scenery X installed, THIS particular texture layers breakes through the Dreamteam Texture layer, and without the Mega Scenery X installed, the default texture layer breakes, "flickers" through to the surface.
See pictures above.
So what can that be as it is NOT a MESH problem?
-
See pictures above.
So what can that be as it is NOT a MESH problem?
Alright, but I see two different kind of pictures: normal view, and top-down view. On top-down view, I think it's normal what's happening, and we might have a different fix for it.
But, on normal views (in-cockpit or outside the airplane) it simply shouldn't happen.
Have you tried playing with video card settings ? Like, for example, setting everything at default in the video card control panel, and see if there's any difference ? Are you running in 32 bit color mode ?
-
I have a brand new PC and I do have the Nvidia GTX 275 installed with the latest drivers. No settings changed for the rest. So I guess it can't be a graphic driver issue, otherwise, if I de-install drivers, I go backwards and for the worse, not for the better.
Top down view and outside view of the plane do show the flickering. I have not been checking the "out-of-the-cockpit-down-the-airport-view".
I just wonder why only Dallas now has this problem and all the other Dreamteam airports don't.
-
So I guess it can't be a graphic driver issue, otherwise, if I de-install drivers, I go backwards and for the worse, not for the better.
I haven't said to uninstall or change your drivers, I've said to set their control panel to the default settings. Can you try that ?
I just wonder why only Dallas now has this problem and all the other Dreamteam airports don't.
The way the ground is made, doesn't have anything in common with any other scenery we made so far.
-
putting the graphic cards settings to default only makes the flickering worse.
That's what I meant: changing things for the wprse.
Funny is: the "inside-the-cockpit-to the-outside-down-the-airport-view", there is indeed no flickering texture at all. Changing to the outside-view, no flickering neither. It it appears to be the worst if I navigate around with the DBS walk and follow function, up and down the area, it is a terrible flickering sight. The higher, the worse.
??? ???
-
So, if I understood correctly, you have flickering only when using Top-down view OR DBD Walk and Follow, but the normal in-cockpit views and the Spot plane external views are ok ?
-
Hi Umberto, even though you weren't addressing me I though I would chime in and answer for how I see the flickers.
I see them from in the cockpit and from spot view and locked spot using the default camera, but as I pointed before, only in those localized areas in the north side with the mseh.bgl renamed. I do see the flickers from top down view, but like you mentioned before thats normal and frankly I dont care about the top down view so much since I dont fly using it.
Anways, as far as the mesh issue are their any new developements today on it. I remember last night/this morning you said that you may check the rounding to see if there are any errors. Also if you can tell me which dem file in the FSX/Scenery/folder unknown/ to disable I can try it. I have folders named from 0000 to 1107 and have no idea which folder represents the Dallas area.
Thanks for the help so far. I look forward to getting those two areas to quit flickering. Last night I did find a few more things that are probably easy to fix so I will start a new thread for those.
Regards,
Sean
-
I see them from in the cockpit and from spot view and locked spot using the default camera, but as I pointed before, only in those localized areas in the north side with the mseh.bgl renamed.
This seems to indicate, your problem is different, and looks like a problem of two conflicting sceneries. The problem petsumnets has, seems to be different, and I believe I know what might be.
-
This seems to indicate, your problem is different, and looks like a problem of two conflicting sceneries. The problem petsumnets has, seems to be different, and I believe I know what might be.
Ok, should I just standby and wait while you and your team investigate the mesh?
-
Umberto, I did some more testing and found out where the after market mesh I own resides. Its in the FSX/Scenery/0202 folder and was called FSGdem0202_us_011010.bgl. I removed it and re-enabled your mesh file and still no good, more texture bleeding like at first. So I renamed your mesh.bgl to .bak and tried again. This time was better and most of the bleed was gone except for one tiny spot on the southeast corner of the airport. The bleeding on the north side by UPS and the north parking was gone as well, however if I try to taxi by terminal A or B, I end up 1/2 way under the ground scenery,so that wont work.
I guess I will just have to wait until you can make a new mesh or something.
Would it be possible to just make 2 flatten.bgl's one for each side of the airport using the freeway that runs thru the middle as a divider? This way the whole airport will be prefectly flat and with no bleeds or bumps?
-
So, if I understood correctly, you have flickering only when using Top-down view OR DBD Walk and Follow, but the normal in-cockpit views and the Spot plane external views are ok ?
For so far, yes.
Eventhough, from outside the cockpit, there is still some kind of flickering, but not to be compared to the intensity of the DBD walk and follow navigation around the area. Out of the cockpit it seems more like a flickering shadow, especially over the grass fields around the runways.
Indeed, the top down-view, is terribly flickering all over the place, the higer in altitude, the worse it becomes.
-
Its in the FSX/Scenery/0202 folder and was called FSGdem0202_us_011010.bgl. I removed it and re-enabled your mesh file and still no good, more texture bleeding like at first. So I renamed your mesh.bgl to .bak and tried again. This time was better and most of the bleed was gone except for one tiny spot on the southeast corner of the airport.
Ok, this confirms your problem was related to a mesh. Do you know, what meters/pixel resolution the FSGdem0202_us_011010.bgl mesh is ?
I guess I will just have to wait until you can make a new mesh or something.
Probably yes. Another test: could you try to set your Mesh complexity slider ALL THE WAY to the right ? With our mesh enabled or disabled, and see any differences ?
Would it be possible to just make 2 flatten.bgl's one for each side of the airport using the freeway that runs thru the middle as a divider?
We'll try that.
-
Eventhough, from outside the cockpit, there is still some kind of flickering, but not to be compared to the intensity of the DBD walk and follow navigation around the area. Out of the cockpit it seems more like a flickering shadow, especially over the grass fields around the runways.
Alright, can you please try to update the Addon Manager (just run the scenery installer again, it will get the updated version automatically), and see if it improves the regular views in/out cockpit ?
Don't mind the DBS camera and the Top-down view for the moment, just check the normal views with the updated version, and see if you have an improvement. If this improves the flickering, we will deal the far away cameras separately with another update.
-
Ok, this confirms your problem was related to a mesh. Do you know, what meters/pixel resolution the FSGdem0202_us_011010.bgl mesh is ?
The website says is 9.6m, so basically 10m.
Probably yes. Another test: could you try to set your Mesh complexity slider ALL THE WAY to the right ? With our mesh enabled or disabled, and see any differences ?
Ok, I will give it a shot now with your mesh enabled and disabled and note the difference and report back..
Thanks again.
Sean
-
Probably yes. Another test: could you try to set your Mesh complexity slider ALL THE WAY to the right ? With our mesh enabled or disabled, and see any differences ?
Umberto I just finished the tests and here are the results.
1st Test with FSDT Mesh.bgl installed
Mesh Complexity 100
Mesh Resolution 10m
Results: Really bad texture bleed thru the whole airport, mostly on runways on the western side (18L/R), the UPS area, the north entrance area, middle of the runways on the eastside (17L/C/R) and Delta Hanger area, south entrance.
2nd Test with FSDT Mesh.bgl removed from scenery folder
Mesh Complexity 100
Mesh Resolution 10m
Results: Much better with very minimal texture bleed, however there are some of the grassy areas in between the taxiways and other areas that kind of flash a little bit. Almost like the underlying ground textures want to come thru, but never make it so they just highlight themselves a little bit. Also this setting seemed to have cleared up the FSDT Van and Tug that drive around Terminal D. Prior to this setting the van and the tug would drive around half way under the ground texture.
A few other observations on Mesh Complexity 100 and Mesh Res 10m. There seems to be a few slight drop off points near the north side of Terminal A and B. In this same area it seems the some of the taxiway lines are not matched up exactly and there is a slight line that extends from the same point at Terminal B east to Terminal A. I also found a seam of bleed thru by runway 36R. I attached a few pics of these areas for you to take a look at but the 2nd test seems to be the best setting yet with only a few minor bleeds and flashes.
BTW, there are some funny things going on with the PAPI's on 36L/R and 35L/C/R where the lights dont seem to jive with the approach and sometime rather than showing white/white/red/red will be red/red/white/red and other combinations. I haven't noticed this on the runways facing south, just the ones facing north. I will start another thread on this later so as to keep to one item at a time since the bleeding is more of a concern to me at the moment.
Anyways, I hope these tested helped. I will probably try a few more with different a/c just to make sure it wasn't a fluke. If it was a fluke and other a/c give different results I will post back, but that shouldn't make any difference.
I will probably be going to be soon since its 5am here in Dallas, so if you need more info I will be back in a few hours. Let me know however if you want me to test any new mesh or flattens.
Regards,
Sean
-
I just did a few more post test fly arounds and had a weird occurence.
In the tests I posted above I was using the RealAir SF260 to conduct the tests.
After I did the write up I started FSX again and without making any changes tried a new plane, this time the Lionheart Quest Kodiak. I loaded a new flight at KDFW and the texture bleeding started again mostly in the same areas I documented previously. Then I quit the flight and started a new one with the RealAir SF260 and the bleeding continued in the problem areas again.
Then I closed FSX completely and started FSX again. This time I started out with the RealAir SF260 with a flight at DFW. I was getting the bleeding again but not as bad as in the last session. This was still with the FSDT mesh.bgl removed from its folder and Mesh Complexity at 100 and Mesh Res at 10m. So frankly beside the mesh issue which I still believe is valid because some areas bleed more than others, I wonder if it could also be a shader issue as well since the scenery seems to cooperate with one a/c better than another? Not sure if taking the specular textures would have any effect so I will wait and see what you have to say.
All in all I think your diagnosis of the mesh is most likely the cause since different settings and mesh combinations can cause the vehicles to sink in the ground, plus the fact that all the FSDT sceneries I own act the same no matter which a/c I start with.
Regards
-
Alright, can you please try to update the Addon Manager (just run the scenery installer again, it will get the updated version automatically), and see if it improves the regular views in/out cockpit ?
Don't mind the DBS camera and the Top-down view for the moment, just check the normal views with the updated version, and see if you have an improvement. If this improves the flickering, we will deal the far away cameras separately with another update.
I ran the installer again and can t see a difference between before and after. Both are good. The moment I change to top-down view or switch to the walk and follow camera, the flickering textures break through badly again.
-
I found a mesh type problem on 17C. In game it is set to 10m and stripped down to this as the only add-on scenery also. I was wondering why I bounced twice. :D Seeing the same over by FedEx too.
Great work guys, no fps hit on my rig !!!
-
BTW, there are some funny things going on with the PAPI's on 36L/R and 35L/C/R where the lights dont seem to jive with the approach and sometime rather than showing white/white/red/red will be red/red/white/red and other combinations.
Unlikely as it might sound, this might be the most revealing hint.
I would like you trying something entirely different: leave everyting as we suggest to use, which means Mesh density at 10 m, and keep the mesh.bgl active.
BUT:
1) Go through your
%APPDATA%\Microsoft\FSX\DLL.XML
and set
<Disabled>True</True>
for EVERY other module you have there, EXCEPT (of course) our Addon Manager (bglmanx.dll)
2) Do the same for your EXE.XML in the same folder, disable every 3rd party module you might have there, EXCEPT for our own Couatl.exe
Now, try KDFW, with a default airplane, and check if you see any difference/improvement.
-
OK I will give it a try.
Doesn't the actual >dll.xml< entry in the xml file still need to still be set to false, as well as the >exe.xml< entry in that xml file?
-
No, change only the <Disabled> sections.
-
No, change only the <Disabled> sections.
OK I will try now and report back.
-
Ok, I did what you said exactly and took 3 screen shots below. 2 are of the dll.xml and 1 is the exe.xml. I couldn't fit all the contents of the dll.xml into one shot.
Anyway, I put the FSDT Mesh back in the folder and started FSX. Created a flight at KDFW and when it loaded all I had was the FSDT Jetways and the underlying MegaScenery Dallas photo scenery. This is with Couatl and bglmanx still set to False.
What should I try now? BTW, I took a screen shot of that also if you want to see.
-
You have set <disabled>true also to the main xml section, which I said not to do it, when you asked it.
You need to disable ONLY the addons sections, not the main xml section, otherwise you are excluding the *whole* xml file which means, nothing will be loaded, even if its <disable> flag is set to false.
-
My bad, I misunderstood.
Will try again now and report back.
-
OK. Good news I think.
I set the both xml's like you wanted to nothing will start except Addon Manager and Couatl and put your mesh.bgl in the FSDT/KDFW/Scenery folder.
I started FSX with Mesh Comp at 100 and Mesh Res at 10m, selected the Realair SF260 and flew a few times around. For the first time with your mesh.bgl active I didn't get any bleeds, a flew little flashes in those couple grassy areas in the south east corner, but no bleeds or bad flickers.
Then I landed and changed planes to the Quest Kodiak. Everything still working ok, but after switching planes without exiting the flight the PAPI's stayed all white.
Just to mix the test up, I completely closed FSX, opened it again, still same settings and started flight at KDFW with the Quest Kodiak. Everything worked good again no bleeds or bad flickers except the one grassy area. Also the PAPIs worked correctly.
Then I changed planes again and still everything working good again, except that it seems like changing planes makes you lose the PAPI's.
One other thing of note. With the mesh.bgl back in, I am getting the tug and van that circle Terminal D slightly buried. The van is sunken about 1/2 way as well as the tug. Same thing also on Terminal E or C with the van slightly below the surface. Unfortunatley I didn't make a note for sure if it was E or C.
What would you like me to do next?
-
I set the both xml's like you wanted to nothing will start except Addon Manager and Couatl
For the first time with your mesh.bgl active I didn't get any bleeds, a flew little flashes in those couple grassy areas in the south east corner, but no bleeds or bad flickers.
Ok, I think this probably proves that in your case, the bleeding wasn't caused by the scenery, but from another module that is interferring. The issue is: it would be impossible to do the ground with our method with normal FSX SDK without having severe flickering. So, we need to use Simconnect commands to stop the flickering to appear.
Now, if there's another addon module that is sending too many commands in a short time, it might be the communication channel between FSX and the addons is too busy so, our module doesn't get much chances to send its commands, hence the flickering/bleeding...
What would you like me to do next?
Enable back your modules, ONE A THE TIME, and test each time, until you find which one is causing this.
-
Guess there are no news abaout the flickering/breaking textures.
As I said before, I ran the installer again but it doesn't show any difference. Before and after are the same. Badly flickering textures still over the whole place while in top-down view and DBS walk and follow navigation.
-
Guess there are no news abaout the flickering/breaking textures.
There were lots of news, instead, if you follwed the thread...
You two were having to entirely different issues: cmpbllsjc problem seems to be caused by another addon module, because he was having flickering in *every* view, not just Top-down or custom cameras.
You, instead, were having flickers ONLY in those views, but the scenery works normally in the standard views.
As I said before, I ran the installer again but it doesn't show any difference. Before and after are the same. Badly flickering textures still over the whole place while in top-down view and DBS walk and follow navigation.
Ok, this means the standard views were always right. As I've said, the updated Addon Manager update wasn't supposed to fix those other views, it was just a test, to be SURE what your problem was.
In any case, we'll still try to research a bit about this but, I'm afraid the flickering in the Top-down view can't be entirely fixable, without creating much worse side effects, which would happen when you open TWO views at the same time, like a standard view and a smaller Top-down view as a map. We could be fix each view separately, but if they are open together, they can't be both corrected.
So, I'm sorry but, it's not really a bug of the scenery, but a consequence of how it's made which, in turns, is what makes possible such performances and quality, which would have been otherwise impossible in FSX, with an airport of this size. I think getting flickers in Top-down view it's a reasonable compromise.
-
Enable back your modules, ONE A THE TIME, and test each time, until you find which one is causing this.
I had a feeling that was what you were going to say. So, I had actually already started doing it.
Here's what happened though. I only changed the one entry for the Level S simulations from True to False so that I could use this plane. I started FSX and selected the LDS 767 with a flight beginning at runway 18L. This was also with no AI turned on and just Addon Manager running and Level D-Sim running. When I took off I started getting the bleeding again. I quit FSX completely and then reopened it and started another flight from KTKI Mckinney, TX which is about 30 miles north of DFW with the LDS 767 again. I flew to the airport, over the runways and around the airport then landed and no problem with the textures. So it seemed that when I started at DFW with the LDS 767 I had problem, but when I started at another airport and flew here no problem and this was done with the same settings.
Having said that, what if there is no way to have all the modules turned on or some of them turned on and still get the ground to work ok because sim-connect is getting flooded?
I have a decent computer E8400 at 3.85 ghz, GTS 250 OC 1GB, 2 GB ram at 1088mhz and all the other FSDT sceneries work ok and I am getting good FPS here.
Would it be possible to have some type of alternate ground textures that would work seperate from Simconnect so that for some of us who have lots of info going thru simconnect we can avoid this problem? Prior to having all the stuff in the dll.xml and exe.xml turned off, I did have a marked improvement in the ground bleeds with the mesh.bgl removed so maybe a flatten would work better for some of us even if it means the PAPI's dont work correctly all the time?
Frankly as much as I love this airport, I am scared that if I cant pinpoint which module or the amount of modules running that I and maybe others will be having this problem with the ground textures. Let me know if there is another type of solution in case this arises.
The problem these days is there are so many items running thru simconnect for me like Active Sky Advanced, Ultimate Traffic, Addon Manager, LDS 767, and maybe other things that I dont even know about that rely on simconnect.
One last thing. Is there any particular order that the different addons should be listed in dll.xml that may make a difference as far as priority.
Thanks for all the help so far and as you can see by the time I put in to test and try things I am willing to try just about anything to get this to work for me all the time. I hope that if I cant get this ironed out that maybe you can help me with some other alternate ground/flatten/mesh, since this is the only probelm.
Thanks
Sean
-
The problem cmpbllsjc has is a way too complicated for me to understand and to follow. I am a beginner and I just want to enjoy your beautiful scenery but it is a pity that now KDFW has this flickering problem while all the other dreamteam airports work perfectly and are just wonderful. I understand that KDFW is made with new techniques but it doens't take away the fact that the side effects are in my case flickering textures which makes KDFW enjoying KDFW only for 50%.
Mesh and dll.xml and exe.xml is like chinease to me which I just don t understand. I just want to download, install pay and enjoy. In this particular case, enjoying is difficult because walk and follow is a wonderful tool which makes it possible to navigate to every single pixel of the scenery. But the side effect is disappointing, despite the new techniques.
Thanks a lot anyway for your quick answers and support. I appreciate a lot.
-
but it doens't take away the fact that the side effects are in my case flickering textures which makes KDFW enjoying KDFW only for 50%.
You mean you fly 50% of the time using the Top Down view?? As I've said, we could fix it, but it still won't work when two views (normal and Top-down) are opened at the same time.
What will happen in that case, would the Top-down view will be flicker-free, but the ALL the other views, which are the most important for flying (if opened together with a Top-down view), will be unusable.
So, I guess we really can't win, because there would always be someone that will complain that, not being able to open a Top-down view together with a normal view, would made the scenery 50% less useful so, we have to make a choice, and the only one that make sense, it's preserving the main views used for flying.
Mesh and dll.xml and exe.xml is like chinease to me which I just don t understand.
Your isssue doesn't have anything to do with any of this, we simply verified it.
In this particular case, enjoying is difficult because walk and follow is a wonderful tool which makes it possible to navigate to every single pixel of the scenery.
I'm sorry, this simply means this scenery is not compatible with DBS walk and follow. Allowing users to check compatibility with their existing addons, is the main reason why we offer a Trial version. Only you can evaluate how it works with *your* preferred combination of addons and then, decide to buy it or not.
For example, none of our sceneries works with the "Instant replay" feature in FSX. That's something that might be annoying, but there's no way around, because it's due to how their are made, but it something people have come to accept, because we have several advantages in exchange.
But the side effect is disappointing, despite the new techniques.
We think that not being able to use Top-down view or DBS without flickering, it's very minor issue, compared to having a scenery unflyable (for *everyone*, not just DBS users), if we had to do old-style FS9 code for ground, which would have killed performances, with an area so large.
-
Umberto,
I just wanted to see if you had any comments to add to what I said above petsumnets post as far as any other altenatives?
I have done a bunch of testing today with enabling and disabling different modules. To some degree of success of I have been able to fly the LDS 767 around here with miminal bleeds and texture flashes, but it requires the removal of the mesh.bgl to do so.
Perhaps that mesh file is causing one too many calls for simconnect when using the LDS 767, I don't know.
Anyways, if you could just reply and let me know about the stuff I asked about in my other post I would appreciate it. I feel like I am pretty close to getting this to work well.
I do have one other thing that I notice sometimes and that it feels like the my a/c want to stick to the surface of the ground a bit more than usual and that they feel like they lurch a little when taxing. Anything I can do about that?
Thanks
-
Perhaps that mesh file is causing one too many calls for simconnect when using the LDS 767, I don't know.
No, the mesh file it's a plain standard .BGL, it's not handled or affected by Simconnect. But the hi-res photoreal ground can and, from your report, it seems there's a difference if there are many other modules active.
-
OK, so are you able to provide any alternatives that I could try?
-
So it seemed that when I started at DFW with the LDS 767 I had problem, but when I started at another airport and flew here no problem and this was done with the same settings.
Does it happen with a default airplane and with the Level-d module disabled ? Sorry, but there are no shortcuts, as soon as you find a possible issue, there's no other way, than isolate items one by one.
Having said that, what if there is no way to have all the modules turned on or some of them turned on and still get the ground to work ok because sim-connect is getting flooded?
First, we need to discover what module is flooding (if this is the issue) Simconnect. Once you know that, you'll have to decide if that module is worth more or less KDFW, and decide which one to use it.
I have a decent computer E8400 at 3.85 ghz, GTS 250 OC 1GB, 2 GB ram at 1088mhz and all the other FSDT sceneries work ok and I am getting good FPS here.
If Simconnect is really getting flooded (we still are not 100% sure), it's not really depending on hardware capabilities, it can happen with any system. Other FSDT sceneries doesn't have anything in common with KDFW, with regard to this issue.
Would it be possible to have some type of alternate ground textures that would work seperate from Simconnect so that for some of us who have lots of info going thru simconnect we can avoid this problem?
We don't use Simconnect for the ground just for run: until now, NO FSX scenery was ever be able be drawn using fully native FSX code, because it would simply flicker like mad. The Addon Manager use Simconnect just to solve that problem and without it, it wouldn't been possible to do that kind of ground in the first place, which is the one and only thing that makes KDFW running and looking so good in FSX, compared to all other sceneries (including our previous ones), with the aggravation than KDFW is so large that, if we had to use FS9 methods, it would looked far worse (blurrier than JFK, at least) and it would have been almost unflyable.
Prior to having all the stuff in the dll.xml and exe.xml turned off, I did have a marked improvement in the ground bleeds with the mesh.bgl removed so maybe a flatten would work better for some of us even if it means the PAPI's dont work correctly all the time?
The scenery can't just use a flatten, because it's not flat! It's fully 3d, a simple flatten would kill the mesh, which makes possible the elevated taxiways.
Frankly as much as I love this airport, I am scared that if I cant pinpoint which module or the amount of modules running that I and maybe others will be having this problem with the ground textures.
You CAN, if you simply follow my advice, and test every module one by one. DO NOT remove mesh.bgl, if you keep changing multiple variables, you'll never find the solution.
The problem these days is there are so many items running thru simconnect for me like Active Sky Advanced, Ultimate Traffic, Addon Manager, LDS 767, and maybe other things that I dont even know about that rely on simconnect.
What uses Simconnect, it's either in DLL.XML or EXE.XML so, it's no difficult at all finding it out. If a product uses Simconnect without being listed in the XML files, it's a module that requires the user to manually launching it so, it's not difficult to find either.
One last thing. Is there any particular order that the different addons should be listed in dll.xml that may make a difference as far as priority.
It doesn't make any difference in regard of Simconnect usage. There might be differences in compatilibility: some modules simply don't run if another module is loaded first. But that would simply kill one module. If they work, they will work just the same, regardless of the order.
-
OK, much appreciated reply.
I will go back and start one by one with the dll.xml first then move to the exe.xml all with having that mesh.bgl back in place and see what happens.
-
Umberto,
I have just completed running the tests in the last two day by doing what you said amd starting with only the basic exe.xml and dll.xml and Addon Manager and Couatl running, then adding back in dll modules one at a time. Below are the results.
1st test
DLL.xml - Enabled Modules
-Addon Manager
EXE.xml - Enabled Modules
-Couatl
Result: Everything worked fine, no bleeds but a few little flashes where others have reported.
_______________________________________________________________
2nd test
DLL.xml - Enabled Modules
-Addon Manager
-Level D Simulations <- Added
EXE.xml - Enabled Modules
-Couatl
Result: Everything worked fine, no bleeds but a few little flashes where others have reported.
_______________________________________________________________
3rd test
DLL.xml - Enabled Modules
-Addon Manager
-Level D Simulations
-VistaMare Core <- Added
EXE.xml - Enabled Modules
-Couatl
Result: Everything worked fine except I did notice that after changing a/c the PAPI's didn't work right. I also did a scenery refresh and that didn't reset them.
_______________________________________________________________
4th test
DLL.xml - Enabled Modules
-Addon Manager
-Level D Simulations
-VistaMare Core
EXE.xml - Enabled Modules
-Couatl
-UT2 (Ultimate Traffic) <- Added
****Left the dll.xml alone and added the Ultimate Traffic back into the exe.xml
Results: Started getting the really bad texture flickering and bleeding on the ground again. Although it was intermittent. I did 6 seperate flights all from scratch, meaning I completely restarted FSX each time. Only 1 time did the ground textures not bleed, all the other times I got the bleeding and flickering one the ground.
****Also disabled transparence AA in nHancer
Also note that with UT2 running while getting the texture flickering/bleeding on the ground texture I was getting good performance otherwise.
_______________________________________________________________
5th test
DLL.xml - Enabled Modules
-Addon Manager
-Level D Simulations
-VistaMare Core
EXE.xml - Enabled Modules
-Couatl
-EZdok camera addon <- Added
****Left everything the same but disabled UT2 since it was shown to cause problems. Enabled EZdok camera instead.
Results;
1st flight I got lots of flickering and bleeds when flying around. Rebooted computer and tried a 2nd flight. In the second flight everything worked fine and had only minor flashes once in a while and no bleeds. Quit FSX and restarted a new flight. Next flight and the few remaining tries the flickering gound textures and bleeds were back again.
_______________________________________________________________
Conclusion: I didn't even bother doing a test with Ultimate Traffic and EZdok camera both enabled since either one by itself causes the problem.
I did note that disabling the Transparence AA in the nVidia control panel did make a slight difference, but when using UT2 or EZdok I still had the major problems. I also did notice that even when things were working correctly having only the necessary dll's loaded that sometimes if I switched camera postions for example the LDS 767 has a wing view or tail view I would sometimes get the flickers. Those cameras were set at a zoom of .80.
So based on this testing I can agree to live without using EZdok when I fly into/out of KDFW. However I hate to have to fly with no AI since I would have to turn it off in the dll.xml prior to the flight. So that means either going to DFW or leaving DFW I will be unable to run my traffic program.
Having said all that, I have a proposal for you.
Since you said you can work to solve stuff like this on a case by case basis I will ask.
Since you have all the stuff for the ground textures can you make me a ground texture that is either .bgl based or runs independant from Addon Manager/simconnect since this is the only part of the airport that is giving me problems?
They can be:
-Lower res if needed
-No speculars or bumps
-Not able to support rain
-Not able to support a/c shadows
I am willing to give up all those features if it means I can get a solid ground that will work by itself. Frankly, as neat as the speculars/bump maps are on the ground, rain effects and aircraft shadows, and super high res ground are really not that important to me and I can live without that since the terminal and all the other stuff looks great. I know its all ground breaking stuff, but I am satisfied with a ground like that of Zurich, Geneva, KORD, etc.
Since you guys are busy and I now it will take time from your schedule I will offer to do the following as a thank you for the extra work.
I will either:
-Pay more for your time
or
-Buy another scenery that I dont already have to help compensate you.
I know anyone who read this probably think I am nuts, but this is how important it is to me to enjoy this airport and I am just about willing to do what ever it takes.
I look forward to hear what you say.
Regards,
Sean
POST EDIT: I did the last few test with the 1.02 update installed.
-
Conclusion: I didn't even bother doing a test with Ultimate Traffic and EZdok camera both enabled since either one by itself causes the problem.
The issue is, I can use UT2 just fine, with no problems whatsoever, and not different *at all* regardless if it's installed or not.
I am willing to give up all those features if it means I can get a solid ground that will work by itself. Frankly, as neat as the speculars/bump maps are on the ground, rain effects and aircraft shadows, and super high res ground are really not that important to me and I can live without that since the terminal and all the other stuff looks great. I know its all ground breaking stuff, but I am satisfied with a ground like that of Zurich, Geneva, KORD, etc.
You haven't fully grasped the problem: it's NOT just the "look", it's the fact that, using an FS9-style ground at KDFW, in FSX, would impact the fps dramatically. Just for comparison, the FS9 version runs at about the same fps, IN FS9! (meaning, it's running its own code), you can imagine how bad it would run the FS9 code in FSX...and no, KDFW can't be compared to smaller sceneries like Zurich and Geneva, and it's as large as KORD+KJFK put together. If we haven't used this method, it would never been doable in FSX to begin with. If you think the *default* KDFW runs worse than ours, with the poor detail it has...
So no, there's no way we'll do this work, which will basically mean porting the ground layers of the FS9 version in FSX. And it gets even more complex than you think, since FSX has a round earth and FS9 not, we can't even "port" the FS9 version in FSX because, to compensate the fact FS9 has a flat earth, ALL the coordinates of the ground tiles in FS9 had to be manually adjusted, one by one, so they wouldn't match in FSX.
There's simply no way we can do such work, just for a single user (remember, you are the one and only having THIS specifc problem, that you are tied by Simconnect performances), it would be way more cost effective to refund you. You'll eventually reinstall your system sometime, or maybe change hardware, so I'm sure the problem will go away, and you might be able to purchase it again.
-
Thanks for the reply Umberto, I really appreciate all the help you gave me to try to get this sorted and I understand your points.
Now, since you are running UT2 and aren't having the issues I am with simconnect getting flooded, can you point me towards things I can look at as far as that? I guess I will be looking at the UT2 forum and asking them about it as well, but I thought maybe you may have some insight into the workings of simconnect? I am using FSX SP2 and I know from one of the devs who worked on UT2 that there are a few different versions of simconnect floating around. I had some issues with UT2 at first until they gave me the correct version. Infact I think I have 3 simconnects installed on my computer from what they said.
Also is there any chance that I could some how have a corrupt version of either Addon Manger/bglmanx? I haven't tried reinstalling the scenery, not that it would help, but I guess it could be worth a shot?
As far as a refund, I can understand your point that it would be more cost effective since only one person has this trouble. Frankly, I am surprised since my setup was done by Michael at FS-GS and I keep a pretty clean machine, that I am the only one with this issue so far. I think I will wait a little longer on the refund to see if I can get this squared away first.
Thanks again.
POST EDIT:
Can I do something like this for Addon Manager? I found this in another post when I googled simconnect getting flooded.
Try this:
Open the Notepad and type the following on a new blank file:
logFile=couatl.log
Save the file as couatl.ini in the FSX\fsdreamteam\couatl folder, so it stays at the same level of the couatl.exe
Run FSX, go to Zurich, then quit FSX after the airport has been loaded. Check if you have a couatl.log file in the FSX\fsdreamteam\couatl folder and post its content here.
-
I guess I will be looking at the UT2 forum and asking them about it as well, but I thought maybe you may have some insight into the workings of simconnect? I am using FSX SP2 and I know from one of the devs who worked on UT2 that there are a few different versions of simconnect floating around. I had some issues with UT2 at first until they gave me the correct version. Infact I think I have 3 simconnects installed on my computer from what they said.
Yes, there are 3 different versions, one coming with FSX RTM, the other with FSX SP1 and the most recent came with FSX SP2/Acceleration.
They can normally be installed all at the same time, because they used the Windows Side-by-side loading mechanism.
A 3rd party module can be programmed to work with a specific version, or can try to support them all. The main difference in efficiency, is that the FSX SP2 version (the later version) is programmed using the more performing "Named Pipes" method, while older version used TCP, which has far worse performances, and can be blocked by firewalls too.
The Addon Manager use only the FSX SP2 version, it will not work with a previous version so, it theory, it should always use the faster method.
One thing to try, is that Simconnect has a config file, named Simconnect.cfg, which is usually placed in the "My Documents" folder, but might also be in the FSX root folder, it looks like this:
Check if you have this file somewhere because, with this file, it's possible to ALTER the Simconnect behaviour, with the Protocol parameter, to use TCP instead of Named Pipes. Using TCP is mandatory if you want to run Simconnect applications over a Network, but on a single machine, it's best to use Pipes, which is the DEFAULT
So, if you have a Simconnect.cfg file anywhere, and it looks like this (there might be other lines, but this is the one that counts)
[SimConnect]
Protocol=IPv4
Change it to read
[SimConnect]
Protocol=Pipe
- Don't worry about having a corrupted version of Simconnect or the Addon Manager: if you were in that situation, NOTHING would work (no scenery, no menus, etc.)
-
Ok, I have Active Sky Evolution running on a networked computer, which is the same computer I am on now.
I have 1 Simconnect folder on my desktop and inside it sits 3 folders:
-Flight Simulator X Files folder contains a file called SimConnect Configuration Settings and looks like this when opened.
[SimConnect]
level=verbose
console=0
;RedirectStdOutToConsole=1
;OutputDebugString=1
;file=c:\simconnect%03u.log
;file_next_index=0
;file_max_index=9
-FSX.CFGs folder and it contains a file SimConnect.xml which looks like this when opened.
<?xml version="1.0" encoding="Windows-1252"?>
<SimBase.Document Type="SimConnect" version="1,0">
<Descr>SimConnect</Descr>
<Filename>SimConnect.xml</Filename>
<Disabled>False</Disabled>
<SimConnect.Comm>
<Disabled>False</Disabled>
<Protocol>IPv4</Protocol>
<Scope>global</Scope>
<Address>192.165.0.105</Address>
<MaxClients>64</MaxClients>
<Port>500</Port>
<MaxRecvSize>4096</MaxRecvSize>
<DisableNagle>False</DisableNagle>
</SimConnect.Comm>
<SimConnect.Comm>
<Disabled>False</Disabled>
<Protocol>Auto</Protocol>
<Scope>local</Scope>
</SimConnect.Comm>
</SimBase.Document>
-Last folder is called HiFi and contains a Simconnect.cfg which looks like this.
[SimConnect]
Protocol=IPv4
Address=192.165.0.105
Port=500
MaxReceiveSize=4096
DisableNagle=0
I also have a simconnect.cfg in this computer in the "My Docs" folder but not in the "My Docs" folder on the FSX computer. The one on this computer reads.
[SimConnect]
Protocol=IPv4
Address=192.1655.105
Port=500
MaxReceiveSize=4096
DisableNagle=0
The only two instances of Simconnect I can find on the FSX computer is inside of my C:Docs and settings/sean/aplication data/microsoft/fsx. Inside this folder I have a simconnect.xml that reads the same as the Simconnect.xml I post above. Inside the "My Document" folder I have a folder called Flight Simulator X File and I have a simconnect.ini file which reads the same as the one above.
So since I have a networked computer for the weather addon its is not possible to change the Protocol=IPv4 to Protocol=Pipe, is that right?
And you are saying also that it is not possible to have a bad version of simconnect. So if simconnect is fine and I cant change the protocol but your UT2 is working fine then maybe I have a problem with UT2? What are you using in the settings menu of UT2 for max altitude ground a/c visible,distance to spawn,max a/c to spawn? I have mine set in the same order as 10000 feet, 25 miles, and 50 a/c. Not sure if any of these settings would make a difference in how it send info to simconnect however.
-
So since I have a networked computer for the weather addon its is not possible to change the Protocol=IPv4 to Protocol=Pipe, is that right?
I think we found it: TCP/IP is probably too slow to deal with UT2 AND our scenery (and all the rest of your stuff that works with Simconnect), all at the same time.
I cant change the protocol but your UT2 is working fine then maybe I have a problem with UT2?
I'm not using TCP as protocol, I'm using Pipes, which how FSX defaults to (if there's no Simconnect.cfg file). You have to use TCP, because you need to run the weather module over a network, but normally Pipes are used, because they are much faster.
So, we can probably say that, since your issue happens ONLY when using KDFW together with UT2, is that UT2 put lots of stress over Simconnect, that other modules like ours, can't work properly becase they don't get enough time to send their commands, since the channel is constantly busy, IF you use the TCP protocol, which is slower, and it's not what is used by default.
Not sure if any of these settings would make a difference in how it send info to simconnect however
I guess that, everything that lowers the number of airplanes to be handled by UT2, will lower the burden over the network (even if the machine is the same, once you enable Simconnect via TCP, it will run over the internal network of your computer).
-
HI Umberto.
I just got off of the messenger with Michael at FS-GS.
We are having a problem locating the simconnect.cfg on the FSX computer. The only reason I had those settings I posted is because I have the FSX SDX installed on my Active Sky computer, but in my FSX computer I only have a simconnect.xml folder in the same folder folder as my FSX.cfg.
So there is some confusion on where and how to change this because according to Michael if you have just the stock FSX,SP1, SP2/Accel simconnects installed then there is no simconnect.cfg to change.
Is there any way we could speak over Messenger Live so that maybe you could assist me easier than messages back and fourth? We can talk for free using that.
POST EDIT
I just re-read your post where you say "I'm using Pipes, which how FSX defaults to (if there's no Simconnect.cfg file)."
In that case how can I reset my simconnect stuff temporarly to test this without Active Sky? Do I need to just remove the simconnect.xml folder from the fsx.cfg folder?
POST EDIT #2
Just as a test I removed the simconnect.xml file from the folder where my fsx.cfg folder is. It seemed like it was working better maybe, but once in a while I was getting double terminals being drawn which were causing the terminal buildings to flash and flicker. On one terminal I could tell is was being renderend twice because the light fixtures on the outside of the terminal were shown twice as well as the roof area. I took a few screen shots to show if you want to see. Could this still be an issue with simconnect getting flooded?
I wish there was some sort of error checker I could run to see what is going on here. Plus I am still not sure if I got simconnect reset back to =Pipes just by removing the simconnect.xml file.
One other thing I noticed in the Addon Manager is that Altitude Cull is now set to 1 instead of 0. If I remember right, in the older versions of Addon Manager it was always set to 0 which I had never changed. Does this make any difference in what I have going on?
I will wait for your responce in the morning.
-
On one terminal I could tell is was being renderend twice because the light fixtures on the outside of the terminal were shown twice as well as the roof area. I took a few screen shots to show if you want to see. Could this still be an issue with simconnect getting flooded?
Possibly. Since every object is created and destroyed when you enter/exit the scenery area, it might be possible that, if Simconnect commands can get through, some objects are not being removed.
You can activate the Simconnect diagnostic mode, this way:
Open notepad, and copy the following text:
[SimConnect]
level=verbose
console=1
RedirectStdOutToConsole=1
OutputDebugString=1
; file=c:\simconnect%03u.log
; file_next_index=0
; file_max_index=9
Save the file as SIMCONNECT.INI in this folder:
Documents And Settings\YOUR LOGIN NAME\Documents\Microsoft Flight Simulator X Files
At the next FSX launch, you should see a text window with diagnostic message, on the FIRST lines, you'll see a message stating which protocol it's in use.
-
Thanks Umberto I will give it a shot to see
BTW, I just noticed that there was a newer update of UT2. I downloaded it a seems like it maybe working slightly better but still some small issue.
Let me ask you this as well. I am guessing that the way the scenery interacts with simconnect can explain why sometimes I can fly around the airport with no graphic problems from the air, but when I land and everything still looks fine, I will notice, especially over at Ternminal A that some of the static ground objects seem to move while I taxi past them and some of the other moving vehicle are 1/2 way under ground including AI depending on which direction I look at them.
-
I did what you said. I was unprepared because the log comes up and then starts to log stuff so fast that it was hard to get a screen host of it.
I posted two pics that say #1 and #2.
In pic #1 it shows IPv4 and Pipe on a few differnet lines. This was with the simconnect.xml file in my folder where my FSX.cfg is. If I remove that file you get what it in pic #2.
So I am afraid since I dont really know what I am looking at, which I am using, Pipe or IPv4.
I also dont know what else to disable or remove to just get pipe.
-
Umberto, did you get a chance to look at my log?
BTW, would it be possible to get this thing to write a text file log some where and I could do a flight over the airport and you could decipher what it says?
-
I was only interested in the first lines, #2 looks fine, my log shows several server lines and some using tcp protocol, but I don't think it's used, unless a client will connects. In #1, your tcp was tied to an actual IP address (instead of 127.0.0.1 which is the local host) so, it was probably using the network.
In any case, you said it looked better with #2 so, this seems to confirm, the real problem is lots of traffic over Simconnect, which is aggravated if running in TCP mode.
As a test, I had a look at the diagnostic with and without UT2, and I must say UT2 generates a *lot* of events, if you disable it, you'll see way less events scrolling down.
Yes, it's possible to enable a file log, but I don't think it could be much of use, if the issue is simply too much data sent over Simconnect, because of all the addons put together, there's not much that we can do, we are sort of trapped because:
- If we reduce the frequency of our commands, they'll probably get even less chances than now of being executed
- If we "play hardball" and increase the frequency of our commands, it will only worsen the traffic so, we *might* get the chance to control our own stuff properly, but we might affect *other* modules, just like UT2 is affecting us.
If you want to try with the log file, just uncomment ( remove the ; ) the last 3 lines of the Simconnect.ini example I've posted, and it will create a log file on your C:\ drive.
An interesting test would be:
- Running the sim for 2 minutes, with KDFW but without UT2, exit and check the log file size
- Running the sim again for 2 minutes, with KDFW + UT2, exit and check the log file size again
This might give an idea how much data UT2 is sending to Simconnect.
Have you tried playing with UT2 settings, to reduce the amount of airplane/data ?
-
- If we "play hardball" and increase the frequency of our commands, it will only worsen the traffic so, we *might* get the chance to control our own stuff properly, but we might affect *other* modules, just like UT2 is affecting us.
Would you be willing to send me a "custom" bglmanx.dll with more frequent commands that I could try? Maybe I could just replace my existing module and give it a shot, without having to download a whole new Addon Manager. You could PM it to me if you want so that it doesn't fall into other peoples hands by accident and I could test it and see if that makes it better. I wouldn't rather have it mess with my UT2 commands than with the airport rendering. Plus if you could give me a one with stronger commands I could use it only when I am using flights into or out of DFW and all the other times I could use the regular bglmanx.dll.
IHave you tried playing with UT2 settings, to reduce the amount of airplane/data ?
I have them pretty low already. It is set to 100% airline traffic and 0% GA traffic and in the "in game settings" box in the UT2 UI I have the Max Traffic to Spawn set at 50 aircraft. Frankly even though I have it set at 100% there are not that many AI here since they only render the AI 20 minutes prior to take off and 20 minutes after landing. I could try reducing it to 75% or 50% and see if that makes a difference.
IAn interesting test would be:
- Running the sim for 2 minutes, with KDFW but without UT2, exit and check the log file size
- Running the sim again for 2 minutes, with KDFW + UT2, exit and check the log file size again
This might give an idea how much data UT2 is sending to Simconnect.
Have you tried playing with UT2 settings, to reduce the amount of airplane/data ?
I may give this a try and see what the difference is. You know where in the c: drive the log file goes once it is generated?
-
I may give this a try and see what the difference is. You know where in the c: drive the log file goes once it is generated?
it's were you want it to be, in the example it was set to:
; file=c:\simconnect%03u.log
This generates a log file in the C:\ root folder, but you can put it in every other folder you want. Probably, it's best if you create a temp folder yourself on C:\ and tell simconnect.ini to create it there, becasue you might not have permission to write in C:\ directly.
Don't forget to uncomment the lines with ;
-
OK I made a new folder in the C: drive called Simlog and made the .ini like this.
[SimConnect]
level=verbose
console=1
RedirectStdOutToConsole=1
OutputDebugString=1
file=c:\Simlog\simconnect%03u.log <----- Added Simlog
file_next_index=0
file_max_index=9
Should this work? I will give it a shot.
-
It should work.
-
It worked I was able to make 2 different txt logs.
I set both flights exactly the same. I used a stop watch and started it as soon as I clicked on the FSX icon, and followed the same route each flight.
-Click icon, start stop watch
-@3:00 min selected the LDS 767, KDFW 18L, 13:45 PM todays date, Fair weather and clicked fly now.
-Took off from 18L and flew a complete circuit around the airport and landed on 17R
-@16:30 minutes I exited the sim completely
I duplicated each test almost down to the second on when I took of and landed and exited the sim to provide as close a test as possible.
In the first log called simconnect000 was with UT2 and the the total size when I right click on the files properties was Size on disk: 11.5 MB (12,103,680 bytes)
The second log called simconnect002 was with no UT2 and the the total size when I right click on the files properties was Size on disk 13.0 MB (13,684,736 bytes)
Surprisingly the one with NO UT2 created a larger file, so I am not sure what that means.
BTW, the reason I have a log called 000 and one called 002 was because when I started the second flight I forgot to turn UT2 off in the exe.xml so I had to start over and deleted the one called 001.
The files are too big to attach and too long to post, you want me to email them to you to look at?
-
Surprisingly the one with NO UT2 created a larger file, so I am not sure what that means.
It might means several things:
a) you did something wrong when recording the log
b) the effect of UT clobbering Simconnect, is showing on the log as well so, you are seeing a smaller file with it, because other addons couldn't get a chance to issue many commands
c) some events are based on frame rate, they happen at every visual frame so, if your fps was lower with UT2, less of thise events will be generated, so the log was smaller for that reason.
In fact, I've tried the same test, running for 90 seconds, and got similar results, the UT2 version of the file is about 20% smaller. However, I've also counted all the events tied to the frame rate and, guess what, they are about 20% less in the UT2 version, because the frame rate was lower so, I guess this case c).
In the log, it's also possible to check the error conditions (EXCEPTIONS), which are all the errors that Simconnect logs, whenever any 3rd party module send a wrong command or a correct command in the wrong situation (like, for example, trying to destroy an object that is no longer there).
In my test, with LVLD.DLL, UT2Services.exe and Bglmanx.dll + Couatl.exe running, I've counted the following exceptions:
- UT2Services.exe generated 185 exceptions in 90 seconds
- LVLD.DLL generated only 1 exception
- Both bglmanx.dll and Couatl.exe, haven't generate ANY exception
If you can zip your log file (the one with everything in) you can send me via email (use the address on the "Contact" web page), I can check yours, and have a look at the errors.
MAYBE, the handling of too many error conditions, might also contribute putting a lot of strain over Simconnect.
-
Ok, I just emailed it to you.
When you said the one with everything in it I wasn't sure if you meant everything as in with UT2 or everything as in the larger file, so I sent both to be safe.
Thanks
-
Got your files, the errors are as follows:
module 0 = Couatl = 0 exceptions
module 1 = Addon Manager = 0 exceptions
module 2 = LD767 = 68 exceptions
module 4 = UT2 = 24 exceptions
Since you ran the program for 900 seconds (I ran it for just 90 seconds), it doesn't look like an amount of errors as big as being potentially able to slow down Simconnect. Of course, having errors is not nice, but your log doesn't look worse than mine.
Other than that, I don't see anything strange in your logs, just that you were running at 14.5 fps average with UT2, and 21.8 fps without it, but that's to be expected. Interesting how many thing one can derive from a log file...
I'll try tomorrow having a look with different strategies, like increasing or decreasing command frequency (I need some time to do this) and will send you something to test.
-
Thanks a lot for looking at the data.
Judging by the amount of exceptions with the LDS 767 I wonder if I have something wrong with it and should reinstall it. The LDS is on its oringal install from 2+ years but is up to date with its service packs and patches.
As far as the average FPS seems to show worse on the log than in real time. When flying with out YT2 it seems that the FPS stay around 29 and with UT2 around 20. Either way though the performance feels good and smooth and I have never had any issues with the airport as far as that goes.
BTW, you probably noticed with the log that these were both run with the simconnect.xml file removed from my fsx cfg folder.
Thanks again for all the help and taking more than average time to help me with this issue. I can say that not many developers would do this at all, so thanks very much and I will stay tuned to see what you come up with for the different strategies.
Regards
Sean
POST EDIT
In case I ever need to look at these log in the future how do you spot the exceptions and average FPS? I looked thru the logs and didn't see anywhere that all the info is rolled up.
-
Umberto, in addition to the post above this one, I made a few interesting observations tonight I though I would share with you that may help you in helping me with my situation.
I tried turning down the slider in the UT2 UI in the "In Game Settings" menu where it says Max A/C to spawn. I put it in the lowest setting of 10. Now even keeping the traffic level of 100% airline and 0% GA I still get all the traffic but it just takes longer for it to be injected into FSX, which is ok for me and since it loads less a/c at once its actually smoother that having it set at say 60 or 100 ai to inject.
So I tried a few flights and here's what is happening. If I start at runway 18R and takeoff turn east and make a left handed traffic pattern and land back at 18R everything works as it should, no bleeding or flashing ground textures and no double drawing of buildings, PAPI's work right, plus none of the moving service vehicles are 1/2 way under ground. So this is working good.
Now if I taxi back to runway 18R and take off again and fly the same left handed traffic pattern to land back on 18R I start getting some bleeding/flashing ground textures on the north 1/3 of the airport. When I land the Terminals A and B are double drawn and flickering. However I tried this twice and on the second time when on approach they were flickering but once I got closer to land everything snapped back into place the the terminal were ok. So I think I am on the right path.
It seems like the airport if divided into 3rds, a south section and middle section and a north section. When I am having issues it seems like its usually just one or two of the sections that isn't being redrawn properly.
Anyways, I thougt this info maybe of use since I can make one pattern around the airport and I am ok, but if I land and do it again things sometimes go bad.
Talk to you later and a big thanks for everything you've done to help me so far.
Regards,
Sean
-
One last thing. I know you probably think I never sleep.
Can you confirm this is correct. About an hour ago was the first time I ever fly around the airport at night. Everything was working well and then I noticed when I landed on runway 18R the landing lights weren't showing on the ground, then suddenly they turned on, but when I was taxing over by gate A16 they went off and were only reflecting part of the runway.
Just to be safe I turned off everything in the dll and exe.xml off just to be sure it wasn't something simconnect related like my other problems. Sure enough I had the same issue where some parts of the runway 18R and the taxiway over near that area would only show the landing light in some areas.
I figured this had something to do with the fact that the ground isn't flat in this airport and that this was similar to the reason progressive taxi doesn't work here. Anyway I attached a couple of shots to show what I am talking about. I didn't test on the other side of the airport but I would assume the same would happen over there.
Thanks
-
Runways and taxiway lights are tied to the hires ground so, they should appear if the hires ground is appearing. They are NOT standard FSX lights, even the runway lights and PAPIs are custom so, they are under our control.
Have you installed the 1.0.3 update ?
-
Umberto, I wasn't talking about the runway lights or taxiway lights of the airport, those work fine and I have no issue with them.
What I mean is that if you look at the screen shots I attached, the part of the runway and some taxiway dont reflect or show my landing lights of the plane. The runway lights and taxiway lights of the airport work fine, Look at these two shots and you will see that there is like an invisible barrier that is cutting of my landing light on the ground.
Yes, I have 1.3 installed.
-
Here's a better pic of what I am trying to show.
The areas I circle in red is the halo light from my planes landing light. It stops in one area then in the red circle at the top of the screen my landing light is visible again. Like an invisible barrier blocking the light from displaying.
It happend like this on runway 18R also in various areas.
Maybe some type of reflective texture is missing from that area?
-
Ok, now I see what you mean.
The good news, is that it's not a problem with your installation, because I can see it as well. The bad news is, we need to look into it, but I'm not sure it could be fixed, it might be a side effect of making the ground in that way, will let you updated...
-
OK, thanks.
Glad to know that it wasn't just me this time.
BTW, there are a lot of areas like that, but the most noticable is on the runways when you are landing and all of the sudden you can't see the ground then suddenly your landing light illuminates the ground again.
If you need me to document all the areas let me know and I will taxi all over the airport at night and find them.
-
Umberto,
Believe it or not I think I can report some good news for a change ;D
In all the testing and fiddling around I have been doing in the last week, you will probably have noticed that in all my tests I had been flying circuits around the airport, always staying in the vicinity. If I had all the modules like UT2 connected everything would be fine from take off until I flew the circuit and landed again. Then once I took off, flew another circuit around the airport and landed again things would go haywire if I had UT2 running.
So, tonight I though I would try something different. I enabled all modules including UT2 and started a fresh flight with the LDS767 from an airport about 100 miles away. I set UT2 traffic at 100% with the max injection at 10 a/c per time. When I got to DFW and landed everything was fine, no problems, PAPI's worked, etc.
Then I closed FSX, reloaded another fresh flight from the same airport 100 miles away. This time when I got about 50 miles out I hit the hot key to kill UT2 traffic. Once again I landed and everything was fine, then as I was pulling off the taxiway I hit the UT2 hotkey again to bring traffic back up and everything remain as it should be.
In conclusion I guess the only time I will be having the simconnect problem is if I continue to fly around the airport, land and take off but never get outside of the boundry where the airport actually shuts off so to speak. I seems like for me the only way it will work right with all my modules is when I get a completely fresh load up of the airport.
This I can live with because generally, I will not be flying around the airport like I was when I was testing it. Usually it will be a single takeoff and then landing somewhere else very far away, then maybe a return flight later, in which hopefully the airport will start again from a fresh load and I will be ok with no problems.
Later today, I will try a flight from DFW to an airport at least 100 miles away then once I get there I will fly back to DFW just to make sure it works and I get a fresh reload, and if so I will leave it at that.
In the past I tried using the scenery refresh key when I could get corrupted, but for some reason it doesn't seem to work at this airport.
I guess the only thing left that will make it perfect is if you can get the other issue that we both have with the aircrafts landing lights not showing on the ground in some areas which you said you were working on anyway.
I will let you know how it works out doing a round trip to and from DFW later on today. If it goes ok we can call it case closed and never return to this thread.
Thanks again for all the help and support up to this point. I have really learned a lot about trouble shooting. If I am ever in Milan, Rome, or wherever you live in Italy I owe you a Peroni, Moretti, or what ever your drink of choice is.
-
Try the new 1.0.5, it should fix the landing lights issue.
-
Try the new 1.0.5, it should fix the landing lights issue.
OK, I will give it a shot in the next few hours and let you know if it fixed my problem.
-
I finally got a chance to test it out and it fixed the landing light problem, except now there is a bump that extends across the aiport. Its not that big of a bump, but its enough to make a sound when you cross it and enough for the AI to smoke their wheels when the go over it.
However, if you cant fix it, it's not that big of a deal.
BTW, can you tell me exactly how far I need to fly from the airport to have bglmanx.com completely drop it out of scenery, that way when I fly back to it I will know its been completely reset if I have UT2 turned on.
Thanks
-
I finally got a chance to test it out and it fixed the landing light problem, except now there is a bump that extends across the aiport. Its not that big of a bump, but its enough to make a sound when you cross it and enough for the AI to smoke their wheels when the go over it.
That is what *fixed* the landing lights...we raise the elevated platform above the airport just a few cm, enough to fix the light and the wheel that was slightly sunken.
BTW, can you tell me exactly how far I need to fly from the airport to have bglmanx.com completely drop it out of scenery, that way when I fly back to it I will know its been completely reset if I have UT2 turned on.
After 16 nm, the whole scenery will be unloaded.
-
Just when I thought I had it all working ok I was wrong.
I hadn't had much time to use FSX in the last 2 days, but as you recall in the last post or two I said that the airport was working ok if on the initial load I started at DFW and flew somewhere or started at another airport around 60 miles away and flew to DFW with UT2 running. In both of those scenarios the airport loads fine with problems.
Today I got a chance to try what I said I was going to do the other day, start at DFW with UT2 running, fly to another airport around 60 miles away, land and return to DFW.
Unfortunately it didn't work out when I returned to DFW the ground on the west side was elevated and the AI were 1/2 buried.
Really I am stumped since I had gotten well outside the 16m range to get the airport to reload. For the life of me I dont know why I can start fresh at another location and fly here with UT2 running but if I start here and then return I cant get it to reload like it was when I originally started.
I put a few pics to show what I mean.
BTW, this was with the stock FSDT ADE file installed.
-
That's clearly the same problem, with UT2 overflowing Simconnect with commands.
We ARE investigating the chance to make the ground using the same method (so, fully 3d, with shaders, etc) but not dependent of Simconnect, but we are still working on it, because it would require some hacking, but it might be possible that the "hacked" version might end up being more reliable than the "official" Simconnect.
-
That's clearly the same problem, with UT2 overflowing Simconnect with commands.
We ARE investigating the chance to make the ground using the same method (so, fully 3d, with shaders, etc) but not dependent of Simconnect, but we are still working on it, because it would require some hacking, but it might be possible that the "hacked" version might end up being more reliable than the "official" Simconnect.
That's good news. Let me know if you want me to test anything for you since I am willing try about anything.
-
That's clearly the same problem, with UT2 overflowing Simconnect with commands.
We ARE investigating the chance to make the ground using the same method (so, fully 3d, with shaders, etc) but not dependent of Simconnect, but we are still working on it, because it would require some hacking, but it might be possible that the "hacked" version might end up being more reliable than the "official" Simconnect.
I figured it was simconnect related.
The thing that I never understand with simconnect however, is why I can start at another airport with everything running and fly to DFW and its fine, but if I start at DFW fly somewhere outside the 16nm range and then return its not ok. I would assume that it would reset like it would if I had started else where. It's almost as if simconnect isn't letting go of the old informantion or something.
Oh well, I will wait and see if the other version your working on works better.
Thanks again.
-
That's clearly the same problem, with UT2 overflowing Simconnect with commands.
We ARE investigating the chance to make the ground using the same method (so, fully 3d, with shaders, etc) but not dependent of Simconnect, but we are still working on it, because it would require some hacking, but it might be possible that the "hacked" version might end up being more reliable than the "official" Simconnect.
I'm watching this with interest. Hope yet for a reinstall of KDFW.
Andrew Dixon
-
Umberto,
For the heck of it, I started a thread over at the UT2 forum http://ultimatetraffic.flight1.net/forums/forum_posts.asp?TID=7969 to see if they have any ways I can test UT2 to see why it is clobbering simconnect.
In the mean time, I know it hasn't been that long, but how is the other idea comming that you mentioned to render the ground without being dependant on simconnect? If you want me to test anything let me know.
Thanks
-
In the mean time, I know it hasn't been that long, but how is the other idea comming that you mentioned to render the ground without being dependant on simconnect?
We are working on it, as soon as we have news, we'll surely post it.
-
We are working on it, as soon as we have news, we'll surely post it.
Ok, thanks ;D