Jump to content

CFD Feedback & Suggestions


legordian

Recommended Posts

Dear all,

a friend of mine and myself were giving the connected flight deck a go yesterday and managed to connect after several hours of trying around. I would like to share some feedback with you of what worked and what did not:

  • Getting the connection to work was not too much fun. We set up a VPN connection (not Hamachi, but with a VPN-capable router and Shrew Soft VPN) and tried to connect and got a connection error. We spent several hours trying to debug the connection and in the end it turned out that the connection was fine, but one of our installations got somehow corrupted. After switching to FSX Steam Edition and both re-installing the Airbuses, we got the connection to work. The important message is, even if it says connection error, it does not necessarily have to be one.
  • We observed several problems once we got the connection to work:
    • Slave only sees the throttle for engine 1 moving, throttle for engine 2 stays in idle throughout (this led to some strange behavior of the auto-throttle for Slave).
    • The flight directory of Master disappeared at some point and could not be convinced to show back up again even by cycling the FD button on and off several times
    • The lower ECAM display was flashing and flickering between screens for one flight. Slave disabled his joystick input (Ctrl-K) as per this thread http://forum.aerosoft.com/index.php?/topic/94106-mcdu-navigation-display-are-not-synchronized-lower-ecam-flashing/ on a second attempt, however, the lower ECAM was then locked and we could not change it anymore
    • The brake temperature for the left MLG was showing as ~900C for Slave, Master saw it ok.
  • A big problem is the left MCDU: we have the same problem as mentioned in this thread: http://forum.aerosoft.com/index.php?/topic/95157-fmc-not-synced/ We tried to both switch to the Init page before connecting and then tried to enter FROM/TO, which did not work because the letters which were entered differed between Slave and Master. As soon as one of the page buttons is clicked, there is a page desync: Master presses Init, Slave goes to Take-Off and vice versa.

We both have Hotfix 1.30e installed and use the default Navdata.

I am suspecting, that either the Add-On installation or the Hotfix was not correctly installed/applied in one of our installations. Is there any way to check that? Do you have a file list of files which should be identical on both systems? Then I could hack together a quick python script which calculates the hashes for these files so that we can find out where the problems lies...

Another suggestion which is probably more long-term: Is it not possible to send the Master's aircraft state to the Slave and update the Slave's aircraft state so that they are in sync? That would make it a lot easier to get a proper synchronization at the beginning (I guess there is a reason that this is not done). Probably easier to do: check the compatibility of the connection partner's installations, i.e. same hotfix, DLL versions, important settings, etc. at connection time which could lead to something like a "VRSN MSMATCH" error.

EDIT: I forgot to thank you for this great feature! I think proper multi-crew top-of-the-line add-ons have been missing for far too long and I very much hope that your push in this direction will encourage other developers (*cough*PMDG*cough*) to start similar projects. And I very much prefer to have the connected flight deck now and deal with some bugs and room for improvement than have a perfect product in the distant future (*cough*Majestic*cough*). The addition of connected flight deck lead me and my friend to buy the buses, so there are two sales which are a direct consequence of the introduction of this feature. Again: thank you very much!

Cheers,
Charly

PS: I seem to have a ASInput.ini file in MyDocuments/Aeorosft, my friend does not have this file. Is there a reason for this?

Link to comment
Share on other sites

Dear all,

a friend of mine and myself were giving the connected flight deck a go yesterday and managed to connect after several hours of trying around. I would like to share some feedback with you of what worked and what did not:

  • Getting the connection to work was not too much fun. We set up a VPN connection (not Hamachi, but with a VPN-capable router and Shrew Soft VPN) and tried to connect and got a connection error. We spent several hours trying to debug the connection and in the end it turned out that the connection was fine, but one of our installations got somehow corrupted. After switching to FSX Steam Edition and both re-installing the Airbuses, we got the connection to work. The important message is, even if it says connection error, it does not necessarily have to be one.
  • We observed several problems once we got the connection to work:
    • Slave only sees the throttle for engine 1 moving, throttle for engine 2 stays in idle throughout (this led to some strange behavior of the auto-throttle for Slave).
    • The flight directory of Master disappeared at some point and could not be convinced to show back up again even by cycling the FD button on and off several times
    • The lower ECAM display was flashing and flickering between screens for one flight. Slave disabled his joystick input (Ctrl-K) as per this thread http://forum.aerosoft.com/index.php?/topic/94106-mcdu-navigation-display-are-not-synchronized-lower-ecam-flashing/ on a second attempt, however, the lower ECAM was then locked and we could not change it anymore
    • The brake temperature for the left MLG was showing as ~900C for Slave, Master saw it ok.
  • A big problem is the left MCDU: we have the same problem as mentioned in this thread: http://forum.aerosoft.com/index.php?/topic/95157-fmc-not-synced/ We tried to both switch to the Init page before connecting and then tried to enter FROM/TO, which did not work because the letters which were entered differed between Slave and Master. As soon as one of the page buttons is clicked, there is a page desync: Master presses Init, Slave goes to Take-Off and vice versa.
We both have Hotfix 1.30e installed and use the default Navdata.

I am suspecting, that either the Add-On installation or the Hotfix was not correctly installed/applied in one of our installations. Is there any way to check that? Do you have a file list of files which should be identical on both systems? Then I could hack together a quick python script which calculates the hashes for these files so that we can find out where the problems lies...

Another suggestion which is probably more long-term: Is it not possible to send the Master's aircraft state to the Slave and update the Slave's aircraft state so that they are in sync? That would make it a lot easier to get a proper synchronization at the beginning (I guess there is a reason that this is not done). Probably easier to do: check the compatibility of the connection partner's installations, i.e. same hotfix, DLL versions, important settings, etc. at connection time which could lead to something like a "VRSN MSMATCH" error.

Cheers,

Charly

PS: I seem to have a ASInput.ini file in MyDocuments/Aeorosft, my friend does not have this file. Is there a reason for this?

regarding

1 - I use hamachi with a friend was quick and works well.

2 - Not experienced any of tose bugs other than the ecam flashing sometimes.

3 - I know what your saying but my friend and I occasionally have desync if we rush typing on the MCDU. we just take it slow and comfirm all before we do anything. before we connect we each select C&D state and only place batteries on for power. we dont even touch the MCDU until were connected. maybe try it?

Link to comment
Share on other sites

Hi Matty,

thank you for your response and suggestions! We tried starting from "Takeoff State" but we will try Cold and Dark next time. I will check out your videos and see if I find something which we might have done wrong.

Cheers,

Charly

Link to comment
Share on other sites

Thank you for your feedback.

It appears as if the bugs you sited are a result of software installation rather than the software itself. Also important to know what the latency is between the two computers. That said, our test team has not encountered this issues, and we're runnning smoothly post 1.30e.

The CFD software updates most all of the switch positions periodically, in essence this prevents or can correct most desyncs, We are working to fine tune this (remember that CFD is a test for how it will be implemented in the A330, with likely back fit to the A320 series).

Mathijs deserves a tremendous amount of thanks and enduring praise for having the vision and forwarding thinking in bringing this incredible feature to the community, and Joshua for the knowledge to bring it to life in the Airbus series.

Please let me know if there is anything at all I can do to help.

Link to comment
Share on other sites

Dear Dave, dear Matty,

we found the issue: the LVars.cfg, which is updated in hotfix 1.30e, differed between our installations: one of us had the original file sans hotfix, the other had the updated file. This happened because when applying the hotfix, one of us put the "My Documents" part to his user directory, where an old Aerosoft folder from a previous installation existed, while the folder which was actually used by the FSX add-on was in his admin directory. After applying the hotfix in the admin's "My Documents", everything works as intended.

@Aerosoft: I would like to mention again my suggestion that you compare the content of this file at the connection initialization. I do not have experience with the programming of add-ons, but you should have access to the content of the file at the moment you initialize the connection, shouldn't you? Also, obviously you are transmitting the values in some kind of ordered value list where the position in the list determines which value is being sent/received. Wouldn't it be better to send key/value pairs so that the order of the file does not matter and you can log if you receive keys which are not understood by the other party (btw: a timestamp in the SharedConfig.log would be useful).

Thinking about this, that is probably the reason you cannot send the hash in the beginning, because you cannot transmit arbitrary keys and values but just information pertaining the LVars.cfg? Ok, no point in trying to make smart suggestions without actually seeing the code and understanding the framework, but I thought maybe this might be useful. If not, disregard.

Cheers,

Charly

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy & Terms of Use