Jump to content

Kyprianos Biris

Members
  • Content Count

    528
  • Donations

    $50.00 
  • Joined

  • Last visited

Community Reputation

10 Neutral

About Kyprianos Biris

  • Rank
    Member
  • Birthday 12/13/1969

Contact Methods

  • Website URL
    http://hellasga.com
  • ICQ
    0

Profile Information

  • Gender
    Male
  • Location
    Athens, Greece

Flight Sim Profile

  • Commercial Member
    No
  • Online Flight Organization Membership
    VATSIM
  • Virtual Airlines
    Yes

Recent Profile Visitors

3,157 profile views
  1. @Keven Menard is it possible to have this bypass for Flight Sim Labs Concorde ?
  2. @Keven Menard I migrated from OldProp to //42 via ORBX and all works fine. The old files are still in: ...\AppData\Roaming\OldProp Solutions inc\ChasePlane The new files are in: ... \AppData\Roaming\Parallel 42\ChasePlane\ Do I still need to keep the old files ? If not, do I simply delete them or is there an uninstall of some type ? I kept a separate back up of the OldProp Solutions inc\ChasePlane just in case.
  3. I fly P3D in Window mode, not full screen. Off course I'm joking about the Green Flightsimming title but out of curiosity when flying long-hauls and while being away from the PC I have tried minimizing P3D in the taskbar to check the differences. First of all, I never encountered any problems in add on aircraft software by flying this way in the en route section. What I want to emphasize here is that what I observed is what I suspected. When the P3D window is minimized the GPU temperatures, CPU load etc. lower significantly. Below are the numbers of both minimized and full view cases for comparison in a 30*C room. When after 8~10 hours of flying en route minimized I bring the window again in full view, P3D displays the scenery below the aircraft very blurred but within 20~40 seconds it renders it again in proper resolution. So I guess, when P3D is minimized to taskbar/tray the scenery is not fully rendered and this saves resources. When I fly long flights I prefer to fly this way when away from the PC since all this thermal energy is useless to be "spent". I also switch off the Monitor. Am I wrong somewhere in all the above in thinking this is a good practice, why waste this energy in a useless way and also to strain the PC more (in the long term).
  4. I need to design some instrument approach procedure chart for a fictional airport Flight Sim. scenery I work on. I remember a decade or so ago there was one available. I think it was "Final Approach". It was pretty simple and did the job fine but I can't trace it back now. Just found this and it looks like it has developed to a professional software and its interesting when you consider it started from an old Flight Sim application. www.airnavigation.com/products/final-approach/ Question : Any ideas how to make some simple approach plates for flight sim use without professional software ? I have sketched them in plain paper and they're fine but would rather have them in "designed" format.
  5. Is it possible to set PrecipitFX to not affect Flight Sim Labs Concorde ? It automatically amends (disables) some FSLabs effects files that are vital for the specific model. I have "Override existing settings" disabled but this does not affect it and it changes Concorde's effects.
  6. Jay I am on P3D v3 not v4. My Spec's: P3D v3 run in VC view, Windowed mode | PC: i7 3770@4.1 Ghz | NVidia GTX970 4Gb | 8 Gb RAM | Win10 | Prepar3D 3.4.22 | 2048 resolution 2x28'screens at 1920x1080 | Orbx FTX Global Base & Vector, openLC EUR&NAM | AS16+ASCA weather | Chaseplane Camera | vPilot for VATSIM with Mytraffic6 AI For default flight I use the default Piper Cub, engine running, positioned at a remote no add on scenery airport. Then from Scenario screen I choose aircraft and start up aircraft location. I do not have panel serialization enabled. Gregg I have my P3D controllers disabled. I have all axis controlled by FSUIPC and they are sent for calibration direct to FSUIPC. I am continuing the test flights. I did one without running AS16+ASCA for weather at all. My next test will be with MilViz weather radar uninstalled (I don't use it in the Duke but it has a DLL that loads via dll.xml on P3D boot). So these are "just in case" kind of tests. My other test will be without using GTN750 for NAV mode but default GPS and one more with conventional VOR to VOR navigation in NAV mode. I use Chaseplane for camera views presets and I have the Duke view clickspots disabled since I don't need them but I am sure that such views camera issues are not can not be related to the problem.
  7. Gregg thanks for the follow up. I think its not related to my controllers because if it were I would be losing control of them at other aircraft as well. This has NEVER happened. It only happens with the RealAir Turbine Duke. RealAir seem to have some sort of filtering of axis input data before implementing it. I can "see" this by the fact that the aircraft is loaded when P3d completes the launch and it takes 2~3 seconds until control inputs actually start moving the Duke's yoke (regardless if its Cold n' Dark or not). So there must be some filtering there. Yes I tried a flight in HDG mode and it did not happen. I was flying on HDG commanded by FSCommander's GPS leaving the GTN750 progress map only a visual advisory. The problem occurs when the Duke autopilot is in NAV mode fed by the GTN750 after some 30 or so minutes of flight.
  8. 1. OK I changed to schematic for next test flight. 2. This is how I have them, Direct and Calibrated through FSUIPC 3. You mean controllers ? Yes all Disabled and controlled via FSUIPC. Since my last post I tried another 3 flights. Same route outbound and return. The problem occurs each time whatever I do. Sometimes I noted that it occurs when the P3D window is not the windows on Focus i.e. when I open/raise other windows on my extended desktop to see things. For example this happened and in one case I lost the Duke's POWER lever axis and on another case the rudder axis! So its not aileron specific but this is where it happens most often. Then on next flight I tried again and again with (P3D) Window change of focus by opening and manipulating other windows all the time while the Duke was operating in P3D. Nothing happened in that session (beginning) but the problem of lost ailerons happened again in flight. It occurs after 30~32 minutes of flying on autopilot at cruise altitude and GTN750 feeding the NAV mode of autopilot. I tried HDG mode only. I actually you can "feel" when the problem has occurred by the following. You let the Duke yokes to remain in sight so you can see when they roll or not. If you gently push joystick on one side the action gets a reaction by the autopilot which counteracts the move the opposite way and so you see the Duke's yokes move (roll) left right. If the problem has occurred then you do not see this happening since the joystick has no effect and then you know what will happen next time you disengage the autopilot. The joystick test is just to provoke the move of yokes. They still will not move any more if the problem has occurred anyway its just that autopilot moves are minor so you do not spot this. If the Duke yokes roll left-right then the problem has not yet occurred. If you are waiting for the problem to occur its easier to handle it (A/P OFF, immediate keypad 5 press to center aileron and immediate keypad 4 press to counteract the right aileron and then 6 to center ailerons again when needed, A/P engage again). Still though on final approach when you will disengage the A/P you still need to bank left-right with keypad to turn base, line up etc. while using the joysticks for pitch, power and yaw. Totally ruins the simulation. I still continue the tests in hope of finding a probable cause ... My spec's: P3D run in VC view, Windowed mode | PC: i7 3770@4.1 Ghz | NVidia GTX970 4Gb | 8 Gb RAM | Win10 | Prepar3D 3.4.22 | 2048 resolution 2x28'screens at 1920x1080 | Orbx FTX Global Base & Vector, openLC EUR&NAM | AS16+ASCA weather | Chaseplane Camera | vPilot for VATSIM with Mytraffic6 AI
  9. No need for GTN changes and more tests. The problem occurs even on ground at Cold and Dark. Once I opened the P3D menu from top to change my start up fuel and pressed OK I saw at an instant the Duke's yokes move far right instantly. The aileron axis was disabled even though Joystick was sending data to FSUIPC so this is a RealAir Duke specific issue. I changed to another aircraft and the aileron axis was still dead. Back to the Duke, still dead. Shutting down and reloading P3D only brings back the aileron axis.
  10. You describe it correctly. My next test will be by reconfiguring GTN750 (from F1 Config) to command in HDG HOLD mode and not NAV mode and fly again same route. Last flight was with autopilot HDG mode using external (FSCommander) command and GTN750 active for waypoint sequencing on map only (GTN configuration was for NAV mode). For departure (for my tests) after take off after 4.000ft I just turn DCT PIKAD. For arrivals I load VOR W 35 procedure from KRK VOR and I activate it once inbound KRK.
  11. Next test flight: Heading mode only. No problem. All went OK.
  12. No I flew it in NAV mode guided by the GTN750. Ignore my fuel comment. My bad. I now find out I simply landed overweight and it was not a glitch due to the Ailerons problem. Just setting up same (arrival) fuel and payload before departure just gives me the same weights. It was just my bad calculation and ACARS just warns on this. Before departure it does not warn on overweight in regards to MLW since I have not landed yet. Next flight will be a test with same set up but instead of NAV mode I will use just HDG mode to get there. Thanks for the follow up.
  13. Another weird phenomenon I experience during this problem and I found out during the closure of the flight once landed (with the help of keypad for the lost ailerons control). After the problem occurs, when I lower the landing gear the fuel on board is automatically maxed out ! I detect this by the software that tracks my flight for the PIREP that will be sent to the VA I fly for. Not that is really weird ! P3D fuel display up on landing vs fuel display in my PIREP software. Aircraft status upon engine shut down at apron. The yoke seen turned right is where it was (visually) stuck after the problem. Using keypad the ailerons would turn but not the yoke. Using joystick would not affect them.
×
×
  • Create New...