The first step is to admit you were born a bus driver. Then you tell your family, and finally the shame will turn into pride ;)
Printable View
The first step is to admit you were born a bus driver. Then you tell your family, and finally the shame will turn into pride ;)
It looks great in my cockpit! But I found one bug:
The window options of the FO PFD window (hide border, always on top and lock position) are not saved and after restart I have to check these 3 manually again.
The framerate problem is caused by my cockpit computers. If I run just 1 PFD without NDs the framerate is approx. 10 fps. The more windows I open (second PFD, NDs) the more the framerate is decreasing. I will look for a new computer.
You added this FSUIPC offset where I can read the state of the FBW module but I need an option where I can turnoff the entire module so that my software can take full control. And for this I need a value where I can read if your FMGS has control (in my case by AP) or not.
Example: I turnoff the entire input-module by a checkbox or something else. Then I start my FBW software. We are on ground so AP is off and because the input-module is offline the value (lets call it X) is 0. My software knows that your FMGS has no control. Then I take off with my software and shortly after initial climb I activate the AP. Then X changes to 1 and my software knows that your FMGS has control and my software will stand by.
X should also be 1 if the input-module is active. It doesn't matter if FBW or raw input is choosen but your software has control. X should only be 0 if AP is off and no input-module of your software is controlling the aircraft.
Hello Chris,
I will correct the FO PFD issue.
For your FBW problem:
Maybe we do not understand each other on this one :) but right now here is how the software works:
if offset $66D9 is 0 the AP/FBW module has control (whether because AP or FBW is ON)
if offset $66D9 is 1 the AP/FBW module does NOT have control: FS receives directly the joystick input, without any intermediary (so AP and FBW are both OFF)
the offset $66D8 allows you to switch FBW ON/OFF without having to click the checkbox, but I did change the handlign of the joystick in the AP/FBW module: with AP OFF and FBW OFF, my software sends nothing to FS.
Alright, thanks, that's exactly what I need.
Maybe I'm a little bit confused by all those FBW, joystick and AP things :P
What came to my mind what is important for my homecockpit:
I need to transfer the sounds on another computer than the FMGS server (flightsim) computer.
So it is possible for you to add a sound application which communicates with FMGS server and plays the sounds on another external computer?
Hello,
I had this idea already, but I haven't had the time to implement it yet. Since at least one more person is interested, I guess it's a nice one ;-)
Maybe not in next version, as it seems B10 is quite not as stable as it should, I will soon release B11 to correct some big bugs.
JL
Thanks :)
For the use of your FMGS at my summer event in mid august this is very important but more important are some new bugs in B10.
I made a testflight an hour ago but had to cancel it on approch due the AP and ATHR problems.
The aircraft was luffing again but at a long period of time. One period took about approx. 30-45 secs. Don't know if it's caused by the coefficinets as before or by a problem in the software itself. Furthermore after activating the AP my VS increased dramatically and I got a stall. I recognized this VS problem in OP CLB, OP DES and when VS is set manually. All the times I overshot my selected flight level by 2000-3000 ft. This happens on climb and descent. Record of VS was 13500 ft/min :D
I used iFDG A320 with the same overall config as in my test with B9.
Some other problems, errors and suggestions:
- Landing weight lower than ZFW (MCDU)
- SD error: "'-9223372036854775808' is not a valid integer value." (I think this occurs if FS is paused)
- Status page on SD would be nice
- EFOB calculated to -1.4? (Fuel available at least for 2 testflights)
- Pitch trim increases during taxi
- MCDU sets new CRZ ALT to FL240 but FL230 was entered and selected
- Moving of VOR and ADF needles would be nice (as in real and like in vasFMC)
- MCDU: Arrival time was calculated to 00:02 UTC which is about 12 hours after my estimated landing time :D
- GW in FS9
But nevertheless: Thank you for that software and for working so hard on it! :)
I made some screenshots for you: http://www.christophpaulus.com/files...creenshots.zip
That's weird. Have you ever had that in previous versions?Quote:
Originally Posted by kikigey89
For all of the other problems, I have already identified them and corrected most of them. I hope the new version will be out this week!
Only the VOR/ADF needles, what do you mean by "moving of the needles"?
JL.
No, B9 was perfect. I will take a look on the config if something's wrong there. Maybe I can perform a second test this evening.
I mean that the needles are not fixed and pointing exactly to the VOR or NDB. As in real the heading to the station is deviating a little bit by some degrees.
So the needle is not pointing at let me say 240° (which is the correct heading) but a few seconds on 238° then maybe some secs on 241° one sec an 237° a few on 240° and so on.
Ok I see for the needles, but I think we have some more important suff going on such as pitch problems ;)
By the way, I think I pinned that problem, but what is weird is that it should have occured on earlier version as well, I think it is related to FS9 version of FSUIPC which doesnt "protect" the offsets the same way as in FSX...