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

[Britjet]

Mine does the same, Carl.
Peter

[cavaricooper]

Mine does the same, Carl.
Peter

Ta Peter!  Can you confirm or refute? I believe this is new behavior...

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

[Hardy Heinlin]

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.

[cavaricooper]

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

[Britjet]

Carl, I have always had this. As Hardy says it isn't a problem..
Peter

[Hardy Heinlin]

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

[cavaricooper]

Brilliant- Ta!

C

[Hardy Heinlin]

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

[Garry Richards]

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,

[Ivo de Colfmaker]

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

[Garry Richards]

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,

[Ivo de Colfmaker]

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

[Garry Richards]

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.

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.

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,

[cavaricooper]

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

[Garry Richards]

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,

[cavaricooper]

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

[Ivo de Colfmaker]

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

[cavaricooper]

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

[Britjet]

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

[cavaricooper]

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