Jump to content

Ruby Tuesday

Members
  • Content Count

    22
  • Joined

  • Last visited

Community Reputation

7 Neutral

About Ruby Tuesday

  • Rank
    Member

Recent Profile Visitors

444 profile views
  1. Nick. I Have downloaded and installed the KVUO patch that was eventually issued and have to report that the terrain distortion issue persists albeit over a reduced area. I shall be reverting to the local fix that I posted earlier. RT
  2. ....meanwhile .......In FTX0_AA_KVUO/scenery/ 0_portlandia_terrain.bgl -> 0_portlandia_terrain.off = problem gone RT
  3. Adjust the colour, brightness and contrast in P3D. And if you really want good lighting and weather effects get PTA (P3D Tweak Assistant). RT
  4. Well, both look fairly flat and washed out - so what's your point? RT.
  5. Hi - I'm thoroughly enjoying a trip down south to explore new Global South America. Scenery and detail is impressive. However have just reached southern end of Mexico and have come across what appears to be a local Vector anomaly in the Parque Nacional Cañón del Sumidero. Enclosed screen was shot taken at LAT N17 1.72 LON W93 14.60. Water contours north and south of here appear OK its just this valley where the lake defies gravity. In the real world there is a dam that floods the valley and the spill way drops down considerably so it might be a local mesh inaccuracy. Just for your future attention then the time for a patch comes around. RT 2017-12-12_16-41-26-630.bmp
  6. Try keeping 8xMSAA and switching on FXAA - works for me at 3840 x 2160 with negligible FPS hit. I don't know why it works - perhaps it blurs out the more distant lights and if they don't show they can't flicker. Doesn't spoil the overall effect though - I also use PTA to put I nice natural haze on the far horizon which is great for masking annoying effects like the one you are suffering from. RT
  7. Welcome to the reality of 32bit processing as used by FSX (and P3d v3). A 32 bit program can only address 2^32 memory addresses or about 4 Gig of RAM. Its easy enough to hit this limit with stock FSX scenery, but as soon as you add in the gorgeous eye candy of ORBX or any other graphically advanced add-on, you will hit the OOM wall sooner in your flight. The solution to this frustrating limit is P3D v4 - a 64 bit program (do the math as they say). I have both P3D v3 and v4 on my system. Today in v3 (with admittedly very high graphic settings I flew from ORBX Palm Springs to ORBX San Diego and OOD'd on the final approach. Switched to v4, took off from Palm Springs, landed San Diego, took off again, flew across whole met LA, carried on up coast of California and landed at San Fran .....no OOD and could have kept going if other early business had not called me away from my rig. If you look at these forums (fora?) you will see that ORBX are working hard to get their products converted to a 64 bit compatible state, and they are doing that at no cost to the client. ( !!! ). They already have the region packages and the global packs converted and they work fine under P3D v4. Everyone is now waiting on the critical conversion of the Object Flow system to allow the ORBX airfields to be used in v4. So, yes it is an amazing product, but until ORBX and their army of beta testers come up with the 64 bit magic you will have to shorten your flight plans and or move some graphic setting sliders to the left to avoid (postpone) OOD's....... oh yes and get P3D v4 because FSX is going nowhere soon. (foot note ... in the time its taken me to knock this out on small tablet Triplane has already sent the same message but more succinctly .....still doesn't hurt to reinforce the message) RT
  8. Didn't see John's post until mine had already gone out - crossed wires and a couple of distractions while I was writing that longish post. Good news about time scale. ORBX are doing a great job on these updates for zero income in the interest of good customer relations. But JV's news doesn't actually alter my argument and I stick to the principle of my earlier views. The release of non- O.F. freeware was, in my opinion, a litmus test of customer patience for a potential delay in the delivery full O.F. update - a contingency against possible delay. The consensus of views coming back through this debate is that most users would be happy to use non O.F downloads and wait patiently for the full update. That's fine and it looks like their patience will be soon rewarded. However, if a general release of full O.F. update was guaranteed be that imminent as of last week why, at that time, seek user feedback on accepting updates without O.F.? It looks like O.F. progress is coming through quicker and/or with more certainty than maybe ORBX were expecting a week ago,but that's just my speculation. Anyway it is good news but I'll remain a lone voice on my position that maybe in future we should be prepared to pay a little to keep these upgrades coming in a timely fashion if their development has to compete with ORBX's expansion into other areas. Maybe the big step is behind us with the move to 64 bit, but there will be a steady stream of changes and hotfixes coming from LM. and others and the burden on ORBX will continue. Some developers put a time limit on their software maintenance and after [in one case 3 years] the user pays a modest sum to keep [in this case] the aircraft compatible with the latest versions of the sims. We are currently fortunate indeed that ORBX don't see the need to do this but if in future they need to go down this path to avoid resource conflicts between current product updates and new developments that's fine by me. If anyone from ORBX wants to comment on this they no doubt will.. RT
  9. I'm perhaps going to be a lone dissenting voice on this topic. From my perspective I want to see the pressure kept on ORBX to rework object flow to 64bit compatibility. I note that ORBX are now developing product across a range of flight sim platforms; which is good, because it strengthens the company's product base, gives its customers a choice of flight-sim products and thereby helps, generally, to promote flight-sim development - so in the end we all win. But I believe that every existing P3D v4 / ORBX user who accepts a "halfway house" by using their paid-for airports without object flow may well be diminishing the imperative on ORBX to get object flow fixed; and may, quite understandably, lead ORBX to divert development resource to other emerging market opportunities. I wouldn't blame ORBX for doing this, after all their primarily purpose is to make money and grow their business and new product generates cash while fixing existing stuff doesn't. I see whole purpose of Mr. Correia "seeking feedback" as being to inform ORBX business decisions on how to shape their business plan and development priorities. And this is our opportunity to inform him. Now to make myself really popular. I have always been impressed not to say amazed by the effort invested by ORBX and other developers [e.g. VRS] to keep their add-on products compatible with functional software changes introduced by flight sim platform vendors, and to do so free of charge. In the past this may not have been especially burdensome, but since the advent of P3D and LM's regular beat of hotfixes and version upgrades this sense of fair-play to the customer must have become fairly costly. Now we have a step change in P3D with the issue of a 64 bit V4 which we, the users, have been keen to take-up; so keen in fact that we all paid another $60 [or whatever] for the privilege. But ORBX, bless 'em, have dug in to rework their product for 64bit compatibly without any mention of charging for their effort. While I greatly appreciate that, I don't see it as necessarily fair. I now find myself in the position of wanting my suite of ORBX airfields to work, properly, with all the object flow and seasonal dependant bits and pieces [call me picky but I don't find the prospect of a water base without a pier appealing] and I don't liked the thought of this desire being frustrated by perhaps avoidable slippage in the reworking of object flow. To come to the point, I, for one, am willing to pay ORBX a reasonable sum to help keep object flow at the top of their "to-do" list. That doesn't mean I want to buy all my airfields all over again, but I do think a reasonable and proportional upgrade charge would be fair. Whatever your priorities ORBX - thank you I do appreciate your efforts and your product. Once I get a full 64 bit ORBX world slipping beneath the wings of a VRS F18F/G [64bit pending] I'll be flying. All the best RT
  10. Paul - it looks to me as though you are simply travelling too fast for your system to keep up. There is a finite limit to how fast any system can compute and display the images of the ground that you fly over. Higher slider settings - e,g, higher terrain resolution, higher autogen, more weather detail etc will lower the rate at which the graphics can be displayed. So if you fly too fast over the terrain you will "outrun" the range of displayed graphic detail. When you are near this limit even rapid turns will start to cause autogen popping and perhaps frame rate lag. Example - I've just loaded P3d v4 and am currently trying out the limits of my system. Jump in the P38 and wing around over central LA at <2000 feet and <300 knots - with most sliders set to max and the graphics and autogen are as smooth as silk and the world is beautiful to behold. Swap out the ride for an F35 and cross the 400 knot line and popping starts. Hit the gas and cross 600+ knots and the scenery in front empties of autogen. P3d V4 may have eased the OOM issue but there is no magic bullet to overcome a demanding graphic load other than better / faster hardware. You may not like to hear this but you probably need to ease down your graphic settings or ease off the gas peddle, All the best RT
  11. Ve3ore - First off I'll stress that I'm no expert in these matters so I'll keep this brief and non technical 'cos its the only way I know. I've been using P3D v3 for about 2 weeks now and have been building in scenery etc. to a point where its working more or less to my satisfaction. However in the first day(s) of use I also experienced the sudden reversion to low definition scenery - somewhere out over the San Fran Bay area where the graphics are demanding to say the least. I fly the VRS F18, and through some crude experimentation I thought I found a causal link between changing the range setting on the plane's moving GPS map display [which is quite high definition and presumably demanding on hardware] and the onset of low definition scenery - click the switch, change the map display and down goes the definition in the outside world. I resolved this in a simple way by saying - OK, if doing that with the GPS breaks the scenery - don't do it. But then I noticed that after a time the scenery came back-up to proper resolution and detail - I didn't do anything proactive as you have been doing [with obvious success], just kept flying and back it came. So I figured that since P3D is known to off-load a lot of work onto the GPU [that's a main stay of its growing appeal] perhaps I was temporarily overloading the through-put on the GPU by changing the GPS display, and then perhaps the GPU was catching-up and restoring full service once the bottle neck had cleared. I've read that in P3D the GPU will dump surplus work back onto the CPU and I was catching unexpected OOM's from time to time so that kind-of fits the theory. As the days have passed I have found that I can now fiddle about with the GPS and other graphics intensive elements of the F18 without causing exterior scenery problems. Now perhaps that's because I've inadvertently changed/fixed something by fiddling around with scenery settings [and trust me I did a lot of fiddling!] or maybe the simulator has now mapped and filed more / most of the textures that it uses [i.e. the texture cache is fully populated] and can therefor run more efficiently. - But then again it maybe just a placebo effect. It seems to me that what you are doing is working, although disabling scenery is what we had to do with FSX and is, to my mind, one of the big advantages of P3D that it should no longer be necessary. Also having to turn off the weather is not the way to go. Only final thing I can think of [and you have probably already been there] is stepping down the frame fate to perhaps give the GPU more breathing space. I know I started out with mine "unlimited" but then pegged it down to 30 frames - maybe that helped, who knows? Good luck.
  12. An update on this. I have now tested every airport in my portfolio and boiled the problem down to two locations. Bella Coola and Lake Tahoe both exhibit the problem with ground textures rising or washing over the user's aircraft and other static ground objects. This is visible when using exterior view and panning round the aircraft. I'm using P3D v3 and FTX Central 3. Have ensured that ORBX library is up-to-date, and that all library items are in proper order in hierarchy - but problem persists Issue with ground textures covering rendered shadows has been resolved. Apparently some airport ground textures are set as "buildings" so P3D setting need to have buildings receive shadows. All other ORBX airports working very well under P3D with excellent definition and gorgeous light and shadow effects. Be good to get this last glitch out of the way
  13. An update on this. I have now tested every airport in my portfolio and boiled the problem down to two locations. Bella Coola and Lake Tahoe both exhibit the problem with ground textures rising or washing over the user's aircraft and other static ground objects. This is visible when using exterior view and panning round the aircraft. I'm using P3D v3 and FTX Central 3. Have ensured that ORBX library is up-to-date, and that all library items are in proper order in hierarchy - but problem persists Issue with ground textures covering rendered shadows has been resolved. Apparently some airport ground textures are set as "buildings" so P3D setting need to have buildings receive shadows. All other ORBX airports working very well under P3D with excellent definition and gorgeous light and shadow effects. Be good to get this last glitch out of the way
  14. Hi - This wont be any help to you other than to let you know you are not alone. Installed Central 3 as part final stage of a major migration to P3D v3. I have all ORBX NA regions, NA Global and multiple airfields. Now I have issues with tarmac texture appearing over the top of aircraft and sim-objects shadow layer. Wheels of aircraft appear slightly submerged in tarmac surface, and at certain location tarmac surface "washes" in front of other scenery objects. Curiously it only occurs at some airfields [Bella Coola and Skagit so-far]. Have updated ORBX library through Central 3 but nothing fixed. Am currently doing manual download of latest library to see if that route helps.
×
×
  • Create New...