This upgrade has "behind the scenes" changes that improve the robustness of all three versions of all three applications.
Happy flying!
The Garry Richards Award... goes this time to ....:
Garry Richards
Thanks Garry for your super add-on !
Hessel
Garry-
Thrilled to read this... Will grab the dl tonight! May I ask if there is anything I can do to improve my method of "saving and re-applying" the exact offset so that there are less "altitude differentials" when picking up where I left off?
Usually, I fly my 744 from A-B, and then B-C, C-D and so on.
I typically cut engines, wait for low N1 and then turn the beacons off, open the doors whilst actioning the other items. Then I close TrafficPSX & VisualPSX before saving the PSX .situ and the P3d flight. Despite this, I sometimes get an issue when re-engaging beacons on my next flight. My Runways file is recreated religiously after any scenery change.
Can I do anything different? Is there a better sequence that will result in more consistent "altitude" saves? The position is fine- the issue is with the difference between PSX and P3d field altitude.
Thanks for a truly indispensable program suite!!
Best- C
PS- Garry- just downloaded and tested- very happy to report that the suite works brilliantly- I am back with VisualPSX and TrafficPSX on a secondary support machine, with JUST P3d on the main computer. Silky smooth 90 degree turns on taxiways- :-) Ta!
Thanks Hessel and Carl!
Hi Carl,
The short answer is that you should ignore elevation and altitude differences between P3D and PSX. The long answer is:
If you fly from A to B then you will probably have a lateral offset in place for the landing runway at B. That will remain in place while you taxi and park.
When PSX is stationary with the park brake set and the beacon and runway light switches off VisualPSX will go into lock mode. The P3D aircraft will remain where you parked it and the lateral offset, if any, will be removed by moving PSX to the same location as the P3D aircraft.
You can now save a PSX situation for this location if you wish a future flight to start from the same position. You do not need to save the P3D situation because VIsualPSX will reposition the P3D aircraft for you (but you could save it if you wish).
A vertical offset is always active and changes from moment to moment when PSX is moving. This is necessary because airport and runway elevations usually differ between PSX and P3D. For instance at KDEN P3D has an airport elevation of 5431 ft which is reported on the scenery display as 5448 ft because it is the altitude of the centre of gravity of the P3D aircraft and that is about 17 ft above the wheels when on the ground.
P3D airports are flat so every runway threshold will also have an elevation of 5431 ft and zero slope. Runways in PSX use real world threshold elevations and slopes. At KDEN those elevations are 5350, 5355, 5354, 5294, 5350, 5354, 5322, 5327, 5328, 5370, 5378 and 5434 ft.
VisualPSX applies a continuously changing vertical offset when PSX is moving on or near the ground so that the P3D aircraft will always be the same height above its surface as PSX is above its. This ensures that both aircraft travel along the surface when taxying and both liftoff and touchdown at the same moment.
So you can safely ignore any elevation and altitude readings from P3D while you are using PSX.
Cheers,
Many thanks, Garry. Integrating P3D into your suite is very much appreciated. I know it would have been much easier for you to simply say "FSX only"..
Peter
Garry-
If I might presume upon your kindness a bit further.... I would love to ignore P3d readings (and do- as I cannot see any instrumentation in P3d). The issue is that occasionally when actioning the beacon switch on the subsequent flight, I "see" the P3d aircraft aloft, and then there is a crash with FATAL DAMAGE in PSX. Sometimes this "altitude" is only a few feet, and then I see the aircraft settle, sometimes seeing red flashes as though the nose wheel were slinging up furrowed dirt, the nose oscillates a couple of times, I get the 80kts call, and then it all calms down to the point where flight flows resume.
The last time I departed MMMX, actioning the Beacons resulted in P3d visuals that showed the a/c about 5000agl (coinciding with the field elevation), with the resultant FATAL DAMAGE crash. Oddly enough, for the first time I had the startling clarity to simply restart the PSX .situ- which then resulted in everything marrying up fine....
The first indicator that something may be amiss with the particular session is that the TDZ does not line up correctly despite correctly set QNH, and that the VS needle oscillates +/- 50'.
All that rubbish aside, VisualPSX has TOTALLY transformed my simming, and I remain greatly obliged. To echo "our Peter", the additional P3d effort is most appreciated.
Best- C
A general tip for add-on developers:
The Qi "CrashInhib" can be used to inhibit the fatal damage detection in PSX (except for traffic collisions). It's a millisecond timer. E.g. if you inject 30000, the detection will be inhibited for 30 seconds.
Maybe it's of some use. PSX uses this internally in the network when an instructor or a situ file is repositioning the aircraft.
Cheers,
|-|ardy
Hardy - thanks. I don't know if I will need CrashInhib yet. For other developers the variable is Qi225.
Carl, another surprise! I have been able to reproduce this unwanted effect when repositioning PSX from YSSY to MMMX but have not found the cause yet. Thanks for your detailed description of the problem. (And to think I was just daring to congratulate myself on having squashed the last bug!)
Cheers,
Garry-
Immensely pleased I can help in some small way. Your suite is just brilliant and I couldn't imagine doing without it ever again :)
Best- C
Hi Hardy,
While investigating the anomaly reported by Carl I tried his scenario using PSX alone, that is without VisualPSX being connected, and obtained unexpected results.
I loaded a situation with PSX parked at YSSY (elevation ˜21 ft) then used the instructor to reposition to various holding points and runways at MMMX (elevation ˜7300 ft), using Alt-S to reload the YSSY situation from time to time.
Everything worked normally while there was only the PSX server running, but not when I added a PSX client. I used the server to reposition as above and saw that the client followed. But on several occasions while repositioning to the higher airport the client would display the correct altitude then the vertical speed would drop to -9999 and the aircraft would plunge downwards for several thousand feet before ascending again and stabilising at the airport ground level. On one of these tests it took more than twenty oscillations of a few thousand feet before it settled.
I then tried using the client to reposition to KBOI (elevation ˜2800 ft) and resetting the situation to YSSY. This time the client behaved normally while the server plunged and ascended before stabilising.
When these oscillations occur while VisualPSX is connected it usually leads to fatal damage to PSX, probably because PSX appears to be both airborne and below ground level at the same time.
Do you think this behaviour is due to a bug in PSX or to some other cause?
Cheers,
Hi Garry,
I'll recheck it. But I think this depends on the harddisk performance; when the data from the terrain file reader comes in too late while the start-up elevation stored in the situ is already applied, there'll be a temporary elevation disagreement that will be handled by the normal aerodynamics model and no longer by the repositioning process. I.e. the harddisk performance on the PSX client may be slower than that on the PSX server.
Cheers,
|-|ardy
I get this happening quite frequently. Having set up a situ carefully on gate somewhere I find if I reload it from scratch there is often a loud thump and (I assume) nosewheel collapse with huge descent rate etc.
I usually find that after several pushes of the situ "reload' button it settles down.
Peter
Quote from: Hardy Heinlin on Sat, 27 Feb 2016 09:01
Hi Garry,
I'll recheck it. But I think this depends on the harddisk performance; when the data from the terrain file reader comes in too late while the start-up elevation stored in the situ is already applied, there'll be a temporary elevation disagreement that will be handled by the normal aerodynamics model and no longer by the repositioning process. I.e. the harddisk performance on the PSX client may be slower than that on the PSX server.
Cheers,
|-|ardy
ABSOLUTELY MY CASE- the server PC runs SSDs whilst the clients are all platter drives.
Also, would it be possible for the clients to connect WITHOUT reloading P3d with each connection? I believe this is something NEW, introduced after one of the more recent updates (perhaps to VisualPSX)....?
C
My PSX client lives on the same 'platter' HDD inside the same PC as the PSX Server & I also get this behaviour - when I re-position PSX from one ARPT to another it will almost always occur, if I load a saved scenario (say parked at my last parking spot) it rarely occurs, & if this scenario was the last one running when I closed PSX last time it never happens.
I am not so sure its an SSD vs HDD or network issue.
My 'top tip' has been to have the PSX Server>Instructor>Situation>Position window handy.
If the aircraft is 'bouncing' I place my mouse cursor into the 'Alt' window at the bottom right of the Position pane & click it there, the 'bouncing' stops.
Then its a quick hawk of all the PSX Server>Instructor>Situation>Malfunction tabs & she is good to go again.
If you are an A to B to C flyer (like me) obviously save a scenario(s) as you go, clearly this is not a practical solution for all users.
It doesn't matter if the PSX instances are on the same disk. Each instance reads the terrain file from its disk. Terrain data are not transfered via network. The harddisk cache may help though. But on certain operating systems it may also be locked so that only one file read access can happen at a time.
It's just a theory anyway. I'll look into it next month.
|-|ardy
By the way ... if you have PSX 10.0.7 and you load the old situ files from the PSX 10.0.0 DVD, the loading process will take several seconds. It gets longer and longer with every modification I make through the series of updates from 10.0.1 to the present version. This is because the old situ files don't include variables that I added in later versions. The situ loader cannot find them at the normal place, and so it searches the whole situ file from the top; it does it for every missing variable. Normally, situ loading takes only a fraction of a second. To "refresh" your old favourite situ file, just load it in 10.0.7 and resave it in 10.0.7. This will make it a true 10.0.7 situ file with all the latest features and variables.
Quote from: cavaricooper on Sat, 27 Feb 2016 10:51
Also, would it be possible for the clients to connect WITHOUT reloading P3d with each connection? I believe this is something NEW, introduced after one of the more recent updates (perhaps to VisualPSX)....?
This effect is not due to changes in VisualPSX. It reloads P3D when PSX indicates it has loaded a new situation, so if it is happening at times when it didn't before the cause will be changed behaviour in PSX.
Hardy-
Clients should just "read and sync"....? Perhaps I always started all clients before VisulaPSX before.... But clients ought not to SEND non pilot-induced inputs... Ja?
Best- C
Clients can send to the server ...
• Client's USB signals
• Data changes on the client Instructor's Situation pages
• Data changes on the client Instructor's Model pages
• Mouse or keyboard or touchscreen induced switch and lever actions in the cockpit
|-|
Quote from: Garry Richards on Sun, 28 Feb 2016 21:54
This effect is not due to changes in VisualPSX. It reloads P3D when PSX indicates it has loaded a new situation, so if it is happening at times when it didn't before the cause will be changed behaviour in PSX.
Hardy- yes, but why then is this P3d reload upon client join occurring?
Best- C
I don't know, I'm sorry. I have no P3D.
Mine does the same, Carl.
Peter
Quote from: Britjet on Mon, 29 Feb 2016 12:56
Mine does the same, Carl.
Peter
Ta Peter! Can you confirm or refute? I believe this is new behavior...
Quote from: Garry Richards on Sun, 28 Feb 2016 21:54
This effect is not due to changes in VisualPSX. It reloads P3D when PSX indicates it has loaded a new situation, so if it is happening at times when it didn't before the cause will be changed behaviour in PSX.
Hardy- From the above, it doesn't really matter if you have P3d or not... is there any reason that PSX would reload the .SITU when a client connects? There really ought not to be.... IMHO....
Best- C
When a client connects, the client receives all current situational data from the server in one snapshot. This is the same process as loading a situ file. A situ file contains a snapshot. The client doesn't load a situ file during net connection -- if you mean that.
The server sends "load1" etc. when a client connects, so that the client processes the data as if there was a situ loading in progress.
The add-on receives that "load1" etc. too.
Is that a problem? Normally, you just start the network only once per session. Even if it's a problem, just connect the PSX clients first.
Quote from: Hardy Heinlin on Mon, 29 Feb 2016 14:24
The server sends "load1" etc. when a client connects, so that the client processes the data as if there was a situ loading in progress.
The add-on receives that "load1" etc. too.
Is that a problem? Normally, you just start the network only once per session. Even if it's a problem, just connect the PSX clients first.
Hardy-
Yes, I believe that is the crux of the issue. As stated, I can just start all PSX clients BEFORE VisualPSX. That is in fact what I used to do, however, I recently revised my network flow. Time to revert. Ta!
C
Carl, I have always had this. As Hardy says it isn't a problem..
Peter
Back to the repositioning problem on the Instructor ...
I don't mean the net connect effect that requires clients first (which isn't a "problem" per se).
I mean the repositioning problem on the Instructor ...
Garry, Steve, when you say "repositioning", do you mean the repositioning buttons for take-off, holding points, gates etc. only? Or does this include "repositioning" by mouse drag on the map and by lat/lon entries and by injections from add-ons?
I can reproduce the problem when using the repositioning buttons, especially when setting the aircraft on the higher threshold of an extremely sloped runway. At SLLP Rwy 28 the take-off position button sets the aircraft ca. 90 ft too high for some reason. The slope there makes a difference of ca. 200 ft!
Edit: OK, problem isolated. Since version 10.0.0 there has been a special inhibit timer that keeps the repositioned, non-moving aircraft at the desired target elevation for 20 seconds, until the local terrain elevation is read from the world file and smoothly stabilized. The problem was that this inhibit timer was started only on that PSX instance on which the repositioning button has been pressed (any client or the server). Instances that received the repositioning data got no inhibit command and so they were -- in some cases -- dancing Pogo and doing Heavy Metal headbanging during that 20-second stabilization process. Now in version 10.0.8 all instances receive this 20 second inhibit command.
Cheers,
|-|ardy
Brilliant- Ta!
C
Hi,
the jump problem is now solved in PSX version 10.0.8, see item 0.8.0003:
http://aerowinx.com/board/index.php?topic=3462.0
Cheers,
|-|ardy
Quote from: cavaricooper on Mon, 29 Feb 2016 11:55
Hardy- yes, but why then is this P3d reload upon client join occurring?
I tested this today. When a PSX client starts it has to receive flight data from the server so that it can synchronise. Addons also receive these data which VisualPSX interprets as a situation load. Therefore it re-initialises and resets FSX/P3D. I don't think this is new behaviour from PSX; it has always been the case. The solution, should one be needed, is to start all client instances before starting VisualPSX.
Cheers,
Hi ,
did some landing training in KCOS, Colorado Springs , and tried 2 different runways.
Landing at 17 L went perfect in Prepar3d v3.2, right on the money. this runway has the same threshold elevation as the aerodrome elevation 6187 feet.
However 35L is at 6045 feet, ending at 6173 feet, and here I ended up in to the ground way before reaching the threshold.
Is this because P3D can not render sloped runways?
I looked at the VisualPsx window and there was no offset.
is there something I do wrong or miss?
thanks for any help
ivo
Hi Ivo,
Sloping runways in PSX and level runways in P3D are not a problem for VisualPSX which handles them routinely. The slope correction is shown in the VisualPSX status display when an offset is in place.
I tried an auto landing for KCOS 17L from a left intercept and all went normally. VisualPSX applied the correct offset and touchdown was at the correct point.
I repeated this for 35L with a similar result to you, the P3D aircraft touching down well before the threshold.
I observed that VisualPSX had applied the correct offset which disappeared from the display after touchdown but then reappeared. There was no lateral movement of the P3D aircraft so I assume this is due to a bug in the displaying of the offset, not in applying it. In other words the offset may be in place even though there is no indication in VisualPSX.
The Analysis/Profile tab in the PSX instructor showed that there is a slight rise in the P3D terrain just before the airport boundary and this is higher than the glide slope. VisualPSX sends the P3D ground elevation to PSX resulting in an anomaly with PSX having touched down on the P3D terrain before it has descended fully along the glide slope.
I'm not sure how to deal with this. Perhaps below a certain altitude VisualPSX should send the PSX threshold elevation to PSX instead of the P3D ground elevation. I could also then keep the P3D aircraft at the same height above its ground as PSX is above the threshold. Both would then touch down at the same point on their runways.
So I'm left with a display bug to fix and a revision to try. Regardless of the fix, the occasional oddity is inevitable when trying to match flat P3D runways to sloping ones in PSX that better match the real world.
Cheers,
Hi Garry,
Thanks for your quick replay .
I am glad you made this available for us, so no problem when the occasional oddity happens.
what I noticed was that landing on 17L was spot on, like I said, and the barometric setting on the PFD stayed green.
When landing on 35L this turned amber upon landing and boxed. This however also occurred when using PSX stand alone. Do not know why this is ?
With VisualPSX on 35L I noticed that when landing some ballooning seems to occur.
the "50"40"30"20"10" callouts are very rapid and the PSX view of the runway is to high, although on the ground.
Also noticed that the baro setting in Prepard is different , but changing it to the actual setting did not made any difference.
Hope this helps, and sorry to bother you with this .
ivo
Quote from: Ivo de Colfmaker on Fri, 1 Apr 2016 17:17
what I noticed was that landing on 17L was spot on, like I said, and the barometric setting on the PFD stayed green.
When landing on 35L this turned amber upon landing and boxed. This however also occurred when using PSX stand alone. Do not know why this is ?
As this happens when PSX is used on its own it will be a PSX feature. It may be mentioned in the PSX manual or, if not, then Hardy could supply an answer.
Quote from: Ivo de Colfmaker on Fri, 1 Apr 2016 17:17
With VisualPSX on 35L I noticed that when landing some ballooning seems to occur.
the "50"40"30"20"10" callouts are very rapid and the PSX view of the runway is to high, although on the ground.
When the P3D aircraft struck the hill about 100 ft above the runway elevation VisualPSX informed PSX that it was on the ground. PSX then accepted that elevation as its ground level so the landing roll and taxying all occur 100 feet too high. This behaviour is part of the mechanism that Hardy and I worked out to enable VisualPSX to synchronise PSX and P3D at touchdown and liftoff. Normally users wouldn't notice this. The fix I proposed in my previous post will overcome this anomaly.
Quote from: Ivo de Colfmaker on Fri, 1 Apr 2016 17:17
Also noticed that the baro setting in Prepard is different , but changing it to the actual setting did not made any difference.
The baro setting in P3D is irrelevant. VisualPSX turns off the P3D aerodynamics so that the P3D aircraft becomes just a graphics object being pushed around the sky by PSX. It has no physical properties. If the weather in P3D was a severe hurricane it would have no effect on the P3D aircraft when VisualPSX was running.
Cheers,
Garry-
After lots and lots of tinkering, I have to turn to you yet again... mea culpa. What is your RECOMMENDED best case setup for smooth P3D performance with build 5898 of VisualPSX? After lots of experimentation with my setup, I ended up running P3D v3.2 and server PSX on one box, with 2 other client PSX's on other machines. This results in me running P3D in WINDOWED mode.... with PSX below P3D. The other way with an additional PFD/ND monitor is just too cumbersome (for me).
Is it then BEST for me to run Visual and TrafficPSX on the same machine as P3D and PSX? Does it matter, or is the P3D performance the same regardless of VisualPSX location? I run on a wired network, however, I have not optimized the TCPIP stack (jumbo packets etc.) ... do I need to?
For some reason, the "smoothness" using VisualPSX with the default FSX 744 is worse than the smoothness running a native HIGH PERFORMANCE (read PMDG 777 or NGX) a/c in P3D alone. I have just built a 6700K box with M2 drives and and am thrilled with my "native" P3D performance. Keep in mind, I run ASN on a client machine in both cases. Why then, would the "simple camera a/c" perform worse than a complex add-on in P3d? What could I be doing wrong? Yes, I suppose I could start moving sliders left, but atm I am very pleased with my "normal" P3D performance.
Is my experience unique? Are others seeing similar performance when using 8.7? Any thoughts would be greatly appreciated (as is your dedication to this immensely important facet of PSX usage).
Best- C
Hi Carl,
I don't have a best case setup. There is a huge variety of setups used by members of this forum, ranging from single laptops to multiple computers, each dedicated to a single function. Perhaps other members could offer advice on getting everything to work smoothly together.
You can use the Windows task manager to monitor cpu and network performance and memory usage on each PC. That might point to the bottleneck.
To reduce the load on the P3D/PSX server PC try running VisualPSX on another PC and also use a PSX client to run the boost server for VisualPSX, turning off the boost server on the server PSX.
You might also specify processor affinities in order to to separate applications if VisualPSX has to run on the same PC as P3D.
If I recall there has been some conflict in the past between VisualPSX and ASN, but I'm not sure. You might like to test this.
Network speed has always been more than sufficient for VisualPSX so I doubt that using jumbo packets would improve things, but of course you could test it.
I understand your frustration in not getting the smoothest possible graphic performance and hope you can find a combination that works with your setup. Hopefully other forum members will have good ideas to enhance your system's performance.
Cheers,
Garry-
First, thank-you! Despite this "tiny" issues, VisualPSX has totally transformed my PSX experience. That is paramount. The smoothness issue is but a ripple in a beautiful pond.
I will try each of your tips in turn, especially the idea of moving the boost server.... I never considered that! Additionally, I just turned off HT and set an Affinity Mask. I'm sure there is a way to solve this issue... Which I suppose most would see as a non-issue.... A bit of stuttering in 90 degree turns on the ground. In the big picture it's nothing.
Last, thank-you!
Best- C
Hi Carl,
You can read my system specs here
http://aerowinx.com/board/index.php?topic=3528.msg36246#msg36246
I use P3D v3.2 and sometimes EFB data provider on my pc, all other things on my PSX machine, tried VisualPsx on the p3D pc, with PSX as client on this pc and boost server from this client.
Dit not noticed any difference in performance.
i get a smooth ride and very happy with it using the above settings.
The stutters in 90 degree turns on the ground I never got rid of, when using P3D stand alone these turns are always smooth, regardles what plane I tried.
Even in flight sometimes there is a microstuter in turns
Something I accepted as " can not be helped" , resulting in a peace of mind.
In the years after PS1 and before PSX used FSX with the level D 767.300
90 % tweaking , 5% crashes, and the rest fun!
I am a happy customer now.
Ivo
Hello Ivo-
Read your specs... I just built a 6700k box w/ m2 drives... and yes, most if not all of my fretting about the very occasional stutter on the ground would be resolved with a change in mindset... as 99% of my flighting is flawless (please understand I am NOT referencing my technique, rather just the machine's performance;) ).
Perhaps, as one of my mates told me, I ought to just shut up and fly :).
Ta!
C
Hi Garry,
This is probably me, but I find that when I try to skew using VisualPSX, most of the time, it doesn't work.
I am using the P3D version, move to a position in PSX, (usually a runway but not always), then with Nav lights on, beacon off, turnoffs on - I get the orange message telling me which keys will slew, but they don't....
I am puzzled because sometimes it works....
Would you have any suggestions please?
Thanks,
Peter
Peter-
This happens for me as well... Cycling the turn-off 3-4 times usually starts it working... Interested to see if there's a reason why this occurs as well...
Miss your videos..... Your sparrows continue to look for crumbs ;)
C
Thanks Carl. Interesting..
Sorry about the videos - there's been a lot going on and a bit of sickness to boot.
I will get a "roundtoit".
Peter
Folks,
I was noticing this behaviour quite often. I found a procedure that helped most of the time.
1) Make the required NAV and R/W turnoff light selections in PSX.
2) Then select the Visual PSX window so that it is the `top/front' window displayed on your PSX machine. I usually also then click on the VisualPSX window header bar to make sure it is the window in `focus'.
3) Confirm that the VisualPSX screen is displaying the orange message re slew keys etc.
I have found that if I run this process that slewing seems to then work consistently.
Hopefully of help.
Scud.
Peter-
Hope you are on the mend.....? I just got through a bout of Bronchitis... yech! No apologies or hurry needed, I have lots to learn just re-watching what you already have produced.
Best- C
Quote from: Britjet on Thu, 14 Apr 2016 14:57
Thanks Carl. Interesting..
Sorry about the videos - there's been a lot going on and a bit of sickness to boot.
I will get a "roundtoit".
Peter
Hi Carl and Ivo,
Aircraft within P3D, either native or addon, are part of P3D and are being controlled by its aerodynamics engine. As I understand it, P3D can adjust its resource usage to give priority to the aircraft over scenery generation, allowing smooth turns on the ground.
In contrast, VisualPSX has to turn off the P3D aerodynamics engine and simply moves a graphics object around in the P3D scenery. With the aerodynamics engine turned off P3D sees the user aircraft as just another graphics object.
During development I tried using VisualPSX with the P3D aerodynamics engine turned on. The result was that both P3D and PSX tried to fly the aircraft according to their own algorithms, leading to constant vibration as P3D continuously adjusted the position, attitude and speed that PSX was sending.
Turns on the ground occur when P3D is working hardest redrawing nearby buildings and objects that are constantly changing their position, orientation and size as seen from the cockpit, and that's when the P3D graphics processing is likely to become overloaded.
If someone knows a workaround that would overcome this I'm open to suggestions.
Cheers,
Hi Peter,
I appear to have introduced a bug in a recent update to VisualPSX. The lock mode doesn't work at present.
Slew mode does and as Scud has just pointed out, for slew mode VisualPSX has to have the focus. I think that info is buried in the manual somewhere.
Cheers,
Hi Garry,
Thanks for the quick reply. Interesting stuff!
Nice suggestions from Scud - like him I ensure that VisualPSX is in focus..
Peter
Hi Garry,
did some testing,
In LGAV made some turns on the apron , default scenery in P3D nice weather
GPU load +/- 70%
mem use about 75%
all sliders to the left,.
Fly Tampa Add on , much detail, give or take the same result, around 70% all sliders 1 notch from the right.
adding shadows 99% load
thunderstorms or much clouds, 99%
but, no matter what load , the little jerkiness in close taxi turns remains the same.
Thus, in my opinion , when the load and memory use is at +/- 3/4 of the GPU capacity , my card should handle this , only 1 thing left then, that's the speed of the GPU right?
solution ?
buy a fast expensive card
be happy with what you got.
I vote for the last option!
It's already so nice!
ivo
I'm no expert, but I guess this doesn't depend on your GPU and memory but on your harddisk cache and speed. The scenery it has to load is on your harddisk.
Hi Hardy,
It is an SSD drive, but the cache and speed I do not know.
Ivo
Had an issue today flying into MMMY which i think maybe to do with offsets.
I was established on the ILS and the PSX view showed me lined up correctly with the runway, however the runway on P3D was offset quite a way to the right. I manually flew over to the right to line up with the p3D runway at about 50 feet above the runway the P3D visuals jumped me from being 50 feet above the runway to about 200 feet above and the PSX and P3d runways now alligned correctly.
Why would the offset be so slow to update? Ive had no issues like this in the past.
I have VisualPSX set to apply offsets to all airports (default setting)
Thanks
Thanks for your report on MMMY. Here's what I think:
VisualPSX locks any offset that is in place when PSX descends below 1000 feet to prevent last minute changes such as you experienced. So there must have been no offset in place before then. That would explain why the PSX and P3D runways were misaligned.
I suspect that you captured and became aligned with the ILS further than 15 nm from the runway threshold. VisualPSX ignores runway data from PSX if the runway threshold is more than 15 nm away. It does this to prevent setting offsets for runways at nearby airports that PSX thinks are possibilities for landing.
When you turned away from the PSX runway at 200 ft to move over to the P3D runway PSX would have assumed you were no longer intending to land there. So when you subsequently aligned with the P3D runway PSX would have assumed that you were intending to land on that runway and therefore sent the runway data to VisualPSX again.
Since there was no offset in place VisualPSX applied the offset for that runway and suddenly both the PSX and P3D runways were aligned correctly.
Perhaps VisualPSX should not ignore runway data when PSX is more than 15 nm away from the threshold, but remember it and apply it if no other runway data are sent by PSX when it reaches 15 nm. I will investigate this but because of other commitments I will not be able to do so for several months.
Hi garry,
Thanks for the explanation. I did capture the ILS further than 15nm. I noticed when i was about 5nm from the threshold (still captured to the ILS and aligned with the psx runway) that visual psx was showing an offset for the correct runway but it was in orange not the usual green text. The runways were both on the correct heading but the p3d runway was about 300m to the right of the psx runway. Is 300m enough to make visualpsx think you are not landing on that particular runway?
Not sure if this makes a difference, i was flying this flight on vatsim along with another PSX user who was about 20nm ahead of me. They had no issues with any sudden jumps in height with their P3D visuals.
Hope all that made sense
Thanks again
Had this issue again today at MSLP.
I was etsablished on the ILS, visual PSX had the offset in green and visuals from PSX and P3d looked identical. However as I got the 40 feet callout the runway in P3D "fell away" from me and I ended up about 100ft above the runway.
Was flying with another PSX user who was in another aircraft on Vatsim and he had no issue.
Hi,
I suspect that there is something unusual about your system.
Cheers,
Garry-
I am reading this thread (http://aerowinx.com/board/index.php?topic=3629.0) with much interest, especially re. the "smooth movement" of the scenery generator view. VisualPSX however, has several more indispensable features, so I am less than keen to abandon this path. Is there a way to integrate the rich feature list that VisualPSX provides, with this "Plug-In" type of positional information? I understand that VisualPSX uses some type of camera positioning already, but to my addled brain, this seems to be a different approach? Obviously that would require a joint project effort that may not be possible or desired, but with the sheer genius of the PSX platform, and the comprehensive ability of VisualPSX, conquering the last hurdle of "silky smooth" integration would indeed be the icing on the cake.
We, the beneficiaries of the PSX ecosystem have much to be grateful for and I remain obliged.
Best- C
Hi Carl,
The "sheer genius of the PSX platform" as you aptly describe it has proved its worth again with Mark producing what looks like the missing link for VisualPSX. We would have a near to perfect PSX world if the strengths of both could be combined.
It is early days yet and Mark has a daunting task in making his app work with everyone else's system. Public betas tend to be a hair tearing time for any developer. When everything is stable we can start considering whether some form of integration is possible or desirable. But whatever happens, Mark has produced a great PSX addon and I wish him all the best with it.
Cheers,
Garry-
I am thrilled to read your post. Patience is a virtue, and I am happy to wait with the current setup- it is very good as is. Once the other "camera positioning" is fully sorted, some type of full integration would be just brilliant!
The future is bright :)
C