VisualPSX Suite upgrade to versions 6.7, 7.7 and 8.7, build 5898 released

[Garry Richards]

This upgrade has "behind the scenes" changes that improve the robustness of all three versions of all three applications.

Happy flying!

[Hessel Oosten]

The Garry Richards Award... goes this time to ....:

Garry Richards

Thanks Garry for your super add-on !

Hessel

[cavaricooper]

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!

[Garry Richards]

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,

[Britjet]

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

[cavaricooper]

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

[Hardy Heinlin]

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

[Garry Richards]

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,

[cavaricooper]

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

[Garry Richards]

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,

[Hardy Heinlin]

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

[Britjet]

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

[cavaricooper]

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

[G-CIVA]

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.

[Hardy Heinlin]

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.

[Garry Richards]

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.

[cavaricooper]

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

[Hardy Heinlin]

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


|-|

[cavaricooper]

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

[Hardy Heinlin]

I don't know, I'm sorry. I have no P3D.