WorldFlight 2015

[Hardy Heinlin]

You never know; there might be a clue in what I captured above, Qi225 and Qi130 (undocumented) look interestingly relevant...

Qi225=2000 : Crash inhibit for 2000 ms - that's normal at situ/net start

Qi130=1 : Malfunction read trigger - that's a normal check at situ/net start


|-|ardy

[Hessel Oosten]

15.04 UTC
The same.
H.

[Mark]

Hardy,

Do you have any hints as to what I should be looking for in the variable log as a clue for why Fatal Damage occurs?

I've got a capture here:
https://gist.github.com/macaba/3fe178e81cdbb38cd3aa#file-psx-capture

[Hardy Heinlin]

The first things I would check is your server's output of these variables at net connection:

Qs121 PiBaHeAlTas
Qs122 StartPiBaHeAlVsTasYw
Qi198 Elev


|-|ardy

[simbro]

17:15 UTC  Same problem with 'Fatal damage' here as well

Cheers
Simon

[Hardy Heinlin]

I just connected and got a fatal damage for a fraction of a second; then it continued normally.

(PiBaHeAlTas: Pitch, Bank, Heading, Altitude, TAS ...)

First I got an update from PiBaHeAlTas:

8267;1;0.8753796392546063;5987460;237025;0.9613730114675537;0.6636398963080636

Then two updates from StartPiBaHeAlVsTasYw:

0;0;0;2670;409;0;0;0;0.9338837975398461;0.8752664249479771;4090
0;0;0;2670;409;0;0;0;0.9338837975398461;0.8752664249479771;4090

Then further updates from PiBaHeAlTas:

8298;6;0.8753820400361585;5986035;237014;0.961375125857377;0.6636458811434656
8331;12;0.8753842601243287;5984635;237004;0.9613772496519366;0.6636518945882006
8373;18;0.8753860915111797;5983265;236994;0.9613793728597297;0.6636579082853005
etc.

In both variables, the 4th value is the current aircraft altitude (in PiBaHeAlTas in feet x 1000).

In PiBaHeAlTas it's ca. 5980 ft.
In StartPiBaHeAlVsTasYw it's 2670 ft. And the elevation at the start is 409 ft (x 10).

Lat/lon disagree as well:

0.9338837975398461 << Lat in StartPiBaHeAlVsTasYw
0.961375125857377  << Lat in PiBaHeAlTas

0.8752664249479771 << Lon in StartPiBaHeAlVsTasYw
0.6636458811434656 << Lon in PiBaHeAlTas

Normally, the network starts with one output of StartPiBaHeAlVsTasYw, followed by the 5 Hz updates from PiBaHeAlTas.

The values in both variables at the start should be nearly equal. The client internally dampens the injections from PiBaHeAlTas to keep the motion smooth. The client applies injections from StartPiBaHeAlVsTasYw directly without any dampening. StartPiBaHeAlVsTasYw is to be ejected at situ/net start, or when the aircraft is repositioned on the Instructor.

Is your router caching ECON mode variables only?


|-|ardy



I don't use any add-ons. Are you guys, who are getting continuous fatal damage, are you using any add-ons?

[Robert Staudinger]

I get "Fatal Damage" without add-ons.

Robert

[simbro]

If it's of any help with the fault-finding I've found that if I pause/unpause PSX (press 'P' twice slowly) after getting the Fatal Damage screen everything seems fine and my PSX seems synchronized with what I see via Twitch (disregarding the slight lag).

Cheers
Simon

[Hardy Heinlin]

Aha. I must add: My PSX was paused when I pushed the client start button. Perhaps that's why my fatal damage lasted just for a fraction of a second.


|-|


"Fatal damage" is simply the status when motion is frozen (M key) and all is paused (P key). You can continue by pressing M and P.

[Hessel Oosten]

Bingo after Hardy's explanation !

Both start scenario's did work:

* Starting with the fatal damage (and accepting that) and than M and P.
* And also starting the connection after -before- having pressed P or M (these functions disappear themselves, after connection).

Hessel

Edit: So, to avoid mis-understanding: connection OK without add-on's (VisualPSX).

[cagarini]

No add-ons here too.

In one of the landings I saw yesterday, and the one today, the aircraft appears very displaced from the rw, and only in the latest seconds it progressively aligns with it. Today it even landed to one of the sides.

This is using PSX *only*, no external visuals at all.

Also, I also notice the effects of the application of toe brakes - they still feel / look overdone to me. Yes the real thing must present a heavy force to the pilots to overcome, and most of our rudders are cheap, low quality, but I believe some sort of smoothing algorithm could be used ...

[martin]

Hmmm,

for a few minutes I was correctly connected while still on the ground at ULLI.
(I am using "PSX pure", no add-ons whatsoever.)

After that, I got the FATAL DAMAGE screen every time on connection.
(and on each connect get the two "paper" slips from the printer :-))

I can get around that and back into the cockpit  with the PAUSE key as described above, but still seem to receive no data whatsoever, although I am connected: PFD, ND, EICAS are all static and show a status from long ago (during pushback).

If I telnet directly to the server, I get a whole batch of Q var entries and values (e.g. "Qs461=BAW 1 - Sarah")  , then "load3" then nothing any more.

The psxRouter starts up thusly:

Code Select Expand

23:13:01 Connected to the server.
23:13:01 Server gave us ID 307.
23:13:01 Server runs PSX 10.0.6a Navtech, Inc. (cycle 1503)
23:13:01 Unknown network mode N --ignored (Ls325(N)=ApServo)
23:13:01 Unknown network mode N --ignored (Ls479(N)=SurfSpoilers)
23:13:01 Unknown network mode N --ignored (Ls480(N)=SurfAilEleRud)
23:13:01 Unknown network mode N --ignored (Ls481(N)=EngFlameN1)
23:13:01 Unknown network mode N --ignored (Ls482(N)=EngParam)
23:13:01 Unknown network mode N --ignored (Ls483(N)=MiscFltData)
23:13:01 Unknown network mode N --ignored (Li211(N)=ElevFeelPsi)
23:13:01 Unknown network mode N --ignored (Li214(N)=StbyCompass)
23:13:01 Situation file loading phase 1
23:13:01 Situation file loading phase 2
23:13:01 Situation file loading phase 3
23:13:01 Server runs PSX 10.0.6a Navtech, Inc. (cycle 1503)
23:13:02 Unknown network mode N --ignored (Ls325(N)=ApServo)
23:13:02 Number of Lexicon entries: 461
Number of cacheable vars:  443
Number of bitmask caches:  0
23:13:02 Unknown network mode N --ignored (Ls479(N)=SurfSpoilers)
23:13:02 Unknown network mode N --ignored (Ls480(N)=SurfAilEleRud)
23:13:02 Unknown network mode N --ignored (Ls481(N)=EngFlameN1)
23:13:02 Unknown network mode N --ignored (Ls482(N)=EngParam)
23:13:02 Unknown network mode N --ignored (Ls483(N)=MiscFltData)
23:13:02 Unknown network mode N --ignored (Li211(N)=ElevFeelPsi)
23:13:02 Unknown network mode N --ignored (Li214(N)=StbyCompass)
23:13:02 Number of Lexicon entries: 1164
Number of cacheable vars:  1011
Number of bitmask caches:  36
23:13:03 Listening on port 10748 for clients.


Treat this info with some caution, though, I am not entirely sure if I know what I am doing here.

Tips please.

Updatelet Tue 03.11.2015

Just for fun, I now tried to connect PSX (no add-ons) to the WF server via the psxrouter.

The connection is established just fine, but as before, the plane is still sitting at ULLI on the ground, with only two engines (#3 and #4) running. On the whole the situation as such looks normal, except that the altitude as indicated on ND was initially about -140 ft, before it slowly increased to 0 (baro pressure transition?).

Buttons and switches can be operated, but have no effect (as per design, due to the "read-only" nature of the server).

Let me know if further client-side tests are required.

Cheers,
Martin

[Britjet]

The issue of fatal damage etc was caused by the aircraft being crashed on a training circuit at HKG the other day. The read-only server showed as crashed and can't be restarted until we restart the whole PSX system and all the associated add-ones.

When we get back to schedule and have some spare down time tonight we hope to restart everything and it should start working again, although the connection to P3D etc is still a problem.


Sorry about that. Blame Benny. He crashed it :-(

Peter

[Britjet]

Update.....Gary couldn't resist and is rebooting everything now so we hope to have the read-only feed operating at about 1545z today for the sector from LGAV to OLBA.

Peter

[Hardy Heinlin]

Hi Peter,

I just noticed on the leg to Athens that this random problem with the early DES phase activation occured again. I haven't been able to reproduce this effect yet, but I think it has been introduced with version 10.0.6-beta19 (item 0.6.0132). If you restart the whole sim tonight, would it be possible to install another PSX update as well -- in case I'm able to isolate and fix this problem this evening? (No guarantee.)

A temporary solution to get out of the DES phase is to activate the CLB mode (CRZ mode activation won't help because the T/D won't be reset, and the DES phase will reactivate a second later). To activate the CLB mode, descend 100 feet below CRZ ALT and arm TOGA by setting flaps 1, then push TOGA :-)


Cheers,

|-|ardy

[simbro]

I'm afraid the fatal damage problem is still present despite the reboot at 1530Z.
After pause/unpause I'm located somewhere on a taxiway at ULLI - which if remember correctly was used during the departure on leg ULLI-ENGM last night.

Cheers
Simon

[Gary Oliver]

Thats depressing....

We have referred your support call to 4th line support (macaba) who will hopefully resolve the issue.

Cheers
Goli

[Mark]

A quick SwitchPSX reboot occurred at 1722Z. Any luck?

[Hardy Heinlin]

I'm online, client #3.

50 nm to T/D, at FL370.

No fatal damage.

Just had to retract the gear though.

[United744]

Hi,

@Hardy: Do you have any ideas for triggers of the early des? I can run some tests here if you like?