Jump to content

Graeme_77

Members
  • Content Count

    32
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Graeme_77

  1. @andrey458You said you’re quite new to this, so one of the things that is often very confusing is the misleading concept of a “stall speed”. In short, there really is no such thing without a lot of other parameters also being considered. I reported the stick pusher issue after spending a good few days flight testing the Saab model, and while it does kick in too soon, it should not affect you at all when flying normally. Make sure you do not have the experimental flight model select (this makes the situation worse). It’s worth having a look at this video, you can start at about 9 minut
  2. Excellent, glad you got it fixed, and thanks for letting everybody know too! Hope you enjoy the TBM now.
  3. 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?
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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?
  9. 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?
  10. 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
  11. 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 engag
  12. 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 m
  13. 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)
  14. @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 v
  15. 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.
  16. 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 final
  17. Hello Javier, The normal way to do this on a single PFD+MFD G1000 is to use the Bearing pointers for the VOR. Click the "PFD" softkey and click the BRG1 and BRG2 keys to cycle through pointer options until you have pointers for NAV1 and NAV2 displayed at the same time. It's easy enough to fly a VOR "on the needles" rather than with the CDI presentation. Hope this helps!
  18. I've got lot less VRAM than that, but even with textures set to low and most of the internal and external textures resized down to 2048 there was no framerate improvement. I think It's all in the 3D model itself. If I go to external view and zoom far away or view forward with no panel the frame rates are fine and the pages like engine parameters are fine. From the TBM glareshield.obj POINT_COUNTS 470814 From the IXEG fuselage.obj POINT_COUNTS 81633 In the objects folder the IXEG has 137MB of textures vs 149M in the TBM - I don't think that's a huge difference for the GPU,
  19. I’ve got a relatively old PC, I5-2500 and a 1GB HD6850 Graphics Card - and I know it’s probably well below what the developers had in mind when they developed the TBM so this isn’t a criticism of the product. However, I’m getting frame rates of less than 12 with the TBM, compared with 35 on the IXEG 737 with otherwise identical settings. I had a look in the objects folder and the objects are huge, the largest obj is 45MB for a glareshield. In total the IXEG objects are 56.5MB, with the TBM at 327MB - so I’m guessing this is where the frame rate hit is coming from. Changing the forwar
  20. I bought the MU2 in the recent sale, and it's certainly a tricky beast to master. The torque reaction seems a bit severe but I understand this is an MU2 trait and with practice not a issue. However one of those "little things" that looks a bit odd is how the digits move on the altimeter drum counter. Most commonly the digits are arranged on the drum so that as the altitude increases the digits move down in the drum counter window, just as they would move down the screen in a PFD display. However on the MU2 this is reversed so when climbing the numbers rotate up. Although there are undou
  21. Jan, I've had a look in my earth_nav.dat file, and I have two lines for the ROVANI VOR. Line 9997 in the file, with a value of 6.0 before the ROI identifier, and another line 25306 with a value 0.0. At a guess I'd say one was the VOR, and the other the DME? I've checked my charts as well, and the inbound course is the reciprocal of the radial, so as far as the charts go the VOR should be correctly aligned with Mag North. Do you have an example of an instrument approach where the VOR is not aligned to mag north so I can have a look at how it's represented - I'm ashamed to admit I'd n
  22. As far as I'm aware I'm using default data supplied with the Steam version of X-Plane. I've got the HD Mesh v3 and also the EFRO Scenery Gateway airport. I'll have a look at the dat files.
  23. Hi Kneighbour, Thanks for your suggestions. Flying a circuit in a 737 is not unknown, it's how pilots new to a jet transport learn how to land the aircraft before being released to fare paying passengers. That said, it's a very specialist kind of operation so I'll have a look and see if I can find any information on how it's done on the 737. It's a great idea though, should hopefully make for an interesting video. i've never seen the glideslope fail to capture, the only thing I can think of is it won't capture the GS until after the VOR/LOC has engaged. Also, I have a vague recollect
  24. Jan, Thanks for all your input on this matter. I've been doing a bit more investigation and based on the attached composite screenshot the VOR North value is exactly the problem. I don't see any problem at all with your Mag Vars and understand they're based on a 2020 epoch. Pictured is the default 172 tracking towards ROI VOR on Radial 180, so inbound 360. Nill wind and aircraft stabilised on track for a few miles. Note the Mag Compass value shown in the data output and directional gyro is 354.2, Almost exactly what the VOR North value for ROI is. Now what this means is the VOR
  25. Sorry Jan, just to add I tried resetting the VOR North value of the offending VOR to 0 and it seemed to be a much closer match. Is the VOR North value the MagVar? ROI has 10.8E published but the VOR North is around 354. Do you know what the VOR North value is designed to reflect? - the notes I found say it lists the *Magnetic* Heading of the 360 Radial, if this is the case the VOR North value would not represent MagVar but rather the "shift" in real MagVar since the VOR MagVar was last reset? Thanks, Graeme
×
×
  • Create New...