Jump to content

Graeme_77

Members
  • Content Count

    31
  • Joined

  • Last visited

  • Days Won

    1

Graeme_77 last won the day on May 9

Graeme_77 had the most liked content!

Community Reputation

10 Good

About Graeme_77

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Excellent, glad you got it fixed, and thanks for letting everybody know too! Hope you enjoy the TBM now.
  2. So your experience is apparently unique with the TBM. Therefore we need to understand what is different on your system compared to everybody else. Any Plugins? What Axis bindings do you have?
  3. OK, so I’ve seen something similar with another model, only once or twice on 11.50b9. It seemed to have the trim snap to the full aft position and stay there. However, I was never able to replicate it and haven’t seen it with the TBM. What plugins are you running? May be worth hopping onto the Hotstart discord as there’s a lot of TBM experience there.
  4. I’ve never heard of anything like that before - Is it possible you have multiple controls bound to the same pitch axis? Actually, I have an idea. Let me do some testing.
  5. No idea about the X-Plane C.G. as I only use the built in payload manager. However on my version it’s set to -7.1 centimetres and a payload weight of 95 kg on the initial w&b screen, before loading the flight. If I use the load manager to push the C.G. forward X-Plane reports -11 cm, and fully aft +11cm. could you have some other plugin affecting it? the only time I get a pitch up is if I deliberately fly beyond Vmo and even then it’s a gentle pitch up.
  6. Really just to see if anything at all is out of place or unusual. I’d be looking at power settings, pitch attitude, trim positions.
  7. I can’t say I’ve ever seen either issue, although I’ve heard of pitch issues with aircraft damage. I’m sure the developers will be along soon, but in the meantime can you post a screenshot of the PFD and MFD when you have the pitch up problem?
  8. As you mentioned it’s worth checking both the payload and maintenance screens. If the flight control surfaces are damaged then you will have issues. Also, what was your indicated airspeed when you experienced the steep climb out of nowhere?
  9. Ozz, the usual cause of a "snatch" during AP engagement is the X-Plane flight director handing. Do you use flywithlua? If so, perhaps this little script will help you. It creates a keybinding called "Smooth AP engagement on Torquesim Islander". It works best with a long keypress, around 0.5 - 1.0 seconds. On the keydown it activatesthe (hidden) flight directors and resyncs the VS target, then on key release activates the autopilot - you should get a smooth engagement with ROL/VS every time. If it snatches, make sure your are in trim before attempting to engage the AP, and hold this keybinding for just a little bit longer. function activate_BN2P_autopilot1() command_once("sim/autopilot/servos_fdir_off") command_once("sim/autopilot/fdir_on") end function activate_BN2P_autopilot2() command_once("sim/autopilot/vertical_speed_sync") end function activate_BN2P_autopilot3() command_once("sim/autopilot/servos_on") end create_command("FlyWithLua/autopilot/BN2P AP On", "Smooth AP engagement on Torquesim Islander", "activate_BN2P_autopilot1()", "activate_BN2P_autopilot2()", "activate_BN2P_autopilot3()" )
  10. Thanks Ozz, I had the Carenado B58 in XP10 with the REP - I'm afraid to say I hated it - the logic was nowhere near realistic. The Islander is at least trying to do something like what the real thing does, the Carenado was behaving like a modern fully digital autopilot. The AP engagement logic isn't right at the moment as it remembers the previous VS rather than syncing. If you bind "Autopilot VVI Sync" and use than just before engaging the AP with "Servos toggle" the behaviour is acceptable. This has already been fed back to Torquesim - and all it really needs is a pitch mode engagement, then everything else would be more or less as per the real thing. In the absence of pitch mode "Autopilot VVI Sync" then "Servos toggle" immediately does the job. Further work on the ROL/HDG mode on approach shows the AP will drop from NAV mode to HDG when there is a VOR/ILS tuned, and from NAV to ROL when there is no VOR or ILS tuned. This is not correct, it should simply go to ROL when swapping between GPS and VLOC CDI. However, I feel that as the LR 530W does not show the required prompts that Garmin put there specifically for the KFC225 that the most useful behaviour may be to work on the basis the "swap and ROL" shouldn't be there, and allow the AP to maintain NAV mode provided there is a valid VOR/ILS source. This, after all, is what Garmin were trying to achieve anyway, within the limitations of the KFC225. Alternatively, if Torquesim would implement "external GPSS" where the AP would use the HDG mode (with a switch to swap between HDG bug and GPS) and simulate a fully analog control system then that may be more practical and more realistic given the constraints with the LR 530W.
  11. Having done hours (literally - it's 03:55AM!) more research on this, the KFC225 does support a form of GPS Steering. With the GNS530W in GPS mode it signals to the KFC225 to use the GPS ARINC 429 information to steer with rather than the analog HSI deviation, although it must use analog guidance for GPS approaches - see the link below. The KFC225 effectively can work in an analog or digital mode, and that mode is triggered by a pinout on the GNS530W. Now, for reasons apparently from the 1990s, when the GNS530W is changed between GPS and VLOC mode, the KFC225 will, IRL, drop back to ROL mode. So when the GNS530W is used with a KFC225 the auto-switching between GPS/VLOC must be disabled by the installer so it's always a pilot action to change over. You can read about here: https://www.twincessna.org/pdf/KFC-225-Internal-GPSS.pdf In the sim model, the GPS/VLOC swap is causing the KFC225 is going to HDG rather than ROL, but only in certain circumstances, as has been observed in this thread. That's not ideal - however setting the HDG bug to the inbound track during or just before intercept is a really good idea anyway, so by doing this you can mitigate the problem. I've got a bit more research to do and will update my bug report accordingly, but that will need to wait for a week or so.
  12. The GPS should not be able to “auto-slew” a mechanical HSI, the pilot must always set the course bar on the HSI to the GPS DTK value. Likewise flying an ILS it must have the course set on the HSI. The GPS drives the HSI, and the autopilot “reads” from the HSI, not the GPS. The BN2 as implemented currently does not require this (I’ve reported as a bug) but in general it’s a good idea to operate the HSI correctly. (That’s the reason the GNS gives you the next course and a countdown timer approaching the waypoint)
  13. @Goran_M i5-2500k clocked to 4.2GHz, 8GB 1600Mhz DDR3, 1GB Radeon HD 6850. P8Z68-V LE. (It was a good spec in 2012!) Test 1 :- All four sliders on the graphics settings to minimal, 1x AA. Loaded to an airfield outside the available scenery (runway and water everywhere) TBM Cockpit view 14.3fps, External view 23fps IXEG Cockpit view 30fps, External view 40fps Test 2 :- Visual Effects: High(HDR), Texture Quality: Medium, Number of World Objects: Low, Reflection Detail: Minimal, AA: None EGPH Runway 24, default X-Plane scenery TBM Cockpit view 10.5fps, External view: 14.2fps IXEG Cockpit view 27fps, External view: 29fps Default C172 G1000 Cockpit view 33fps, External view 30fps You've built a really, really beautiful model - but at the moment it's very heavy on system requirements.
  14. Thanks @skiselkov - I know your priority is making the model run well on new hardware and these older machines are a fringe case for you. Regardless a low poly model would be much appreciated. What I’ve seen of the model is really fantastic and hopefully in 6 weeks or so I’ll have a new machine to run it on.
  15. Skyguider your GPU is miles better than mine, but your CPU is of a similar age (I've got an i5-2500k 3.3 with a slight overclock). I've tried all the same things you did and can't get a significant improvement. I don't think it's textures as although they are 4K the total texture size is only around 200MB, My suspicion is it's the size of the obj files that is the issue, and perhaps that's loading the CPU rather than the GPU causing the whole sim to slow down. The obj files are enormous. 6 times larger than the IXEG, 5 times larger than Felis 154, 3 times larger than the FF A320 and finally only slightly smaller than the Rotate MD-80 which is virtually unusable on XP11 for me - although it ran OK on XP10 - again suggesting perhaps that the CPU load is the problem rather than the GPU. Here's a extract from an IXEG object:- POINT_COUNTS 7222 0 0 28056 VT -0.7237 0.3741 2.0096 -0.165 -0.439 0.883 0.6316 0.874 and from the TBM:- POINT_COUNTS 470814 0 0 470814 VT 0.00841901 0.09876074 0.00741016 -0.99862665 0.05215613 -0 0.894862 0.79924899 I don't know how the X-Plane engine works, but the sim appears to be being asked to draw a massive amount of polygons apparently to a higher precision with the TBM model. I'd be keen to see how your system performs if you swap the forward view to the X-Plane HUD view? For me this instantly doubles the FPS. No textures are unloaded, but the sim simply performs better without the cockpit view hence my suspicion it's the objects themselves. I've also tried pulling the CBs for all the G1000 screens but that has no improvement. As a last resort, I made a copy of the .acf then removed references to glareshield.obj, seats.obj, cargo.obj and cabin_rear.obj - this improved my FPS from 15 to 18 - a 20% improvement.
×
×
  • Create New...