• Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Sabretooth78

  • Rank
    Flight Student - Groundwork
  1. No change in handling other than what you might expect from having slightly more weight. I've found you sometimes maybe have to pay a little more attention on climb out if flying manually, especially around the acceleration altitude after a steep climb, as it can be a little sluggish picking up airspeed if you're not careful. Or maybe that's just because I'm accustomed to flying the lighter A320 much more often, or I may have messed something else up... Not sure about the ACJ as I don't have it, but my guess would likely be in the aircraft.cfg under the [Fuel] header as well.
  2. You may find this helpful: I've applied this "fix" to my A321s as it reflects the additional optional fuel tank Airbus offers, which jetBlue (which I fly virtually) uses on their aircraft. Long story short, in bold are the lines I've edited (I think I caught them all!) - make sure you save a copy of the originals in case you mess something up! The following updates the physical capacity available in the fuel dialog: The following edit updates the capacity in the MCDU for "automatic" fuel loading: The following edit updates the capacity in the fuel planner: Hope that helps!
  3. You may need to take a look in aircraft.cfg and make sure everything is consistent. Also FYI, there is a good collection of jetBlue A320s and A321s in the avsim library. Counting the variations available in the library here, I have 55 A320s and 10 A321s - nearly half of their actual fleet of 'buses. Serves my Virtual Blue needs quite well. Now if only somebody would crank out a few updated E190s for the Wilco/feelthere model.
  4. It never overshoots the selected FL, at least not for me. It just spikes at the initiation of the ALT* mode and then quickly decays back to something more reasonable and then level flight. There is also no engine spool-up. Just a little hiccup in pitch barely enough to affect airspeed, really (like a bump of turbulence). The tricky thing is it doesn't always happen, so my guess is it's caused by just the right balance of variables - perhaps FL selection, relative winds, cost index, CLB vs. OPEN CLB, or maybe something else? I'll see if I can gather any shots of it happening. It's one of those things that bothers me more just to know what's causing it than any affect it has on usability. For what it's worth, FPS isn't an issue. I'm typically getting a smooth 40-50 FPS once I escape any cloud cover. I bottom out at between 20-30 FPS with minor occasional stutter on the ground or low altitude near FSDT KJFK and Orbx SoCal KLAX. Those are by a long shot the most FPS/VAS unfriendly add-ons I use.
  5. I've experienced this on the IAE versions as well. Doesn't always seem to happen, so I haven't quite figured out how (if possible) to prevent it myself other than that It seems to happen at the initiation of the ALT* vertical mode.
  6. Seems there are scenarios where there can be a variance to either side of ambient - it might make the most sense to just split the difference and use that. However...thinking out loud here as I'm not a programmer so I haven't a clue as to the level of effort that would be required... Perhaps for the "power users", a set of options could be added to the Configurator or Load Manager (assuming you'll be sticking to the current A32x format) allowing the user to select a few variables such as those which have been mentioned already. You could "hide" it in a fly-out similar to the current simple vs. advanced modes in the Load Manager. If loaded before the sim, a base value could be estimated from the departure ICAO and the date (user-selectable but default to system date). Depending on the options selected (say underground vs. aboveground/truck; morning vs. afternoon, etc.), a deviation from the base can be calculated. This would be an estimated or expected fuel temperature for rough planning purposes, and could also be constrained to min/max acceptable values. Once the sim is loaded, it takes the actual ambient temperature and applies the calculated deviation to get the actual temperature (within acceptable range). If it's done in a similar format to the load manager, the user could also override with their own value, which would be directly used in the sim without regard to actual conditions, i.e. "hard-coded". And just what is it that makes -40 degrees Fahrenheit incorrect?
  7. I've run a few more flights in the meantime and the pattern of "corrupted" estimated arrival times certainly seems to fit the pattern of only occurring during flights spanning UTC 00:00. Here's my latest, showing a flight within the same UTC day: jetBlue 1412 TNCA-KFLL; TOVOL UA315 JOSES A315 ZBV WAVUN2 I guess the only thing left to test now is to see if a flight originally within the same UTC day "corrupts" if the ETA drifts past 00:00 (for example due to wind)?
  8. Played around with it a little more and found that it does indeed scroll - except when I have just selected the "Select a flight plan" dropdown, after which the scroll wheel "gets stuck" on cycling that menu. Not really a big problem!
  9. Just a little bug I've noticed - I wouldn't even call it a nuisance, but an observation. The ECAM display pushbutton "ALL" sometimes requires more than one press to advance to the next page. I haven't been able to find any patterns regarding which status screen is displayed initially, etc. And sometimes, it seems to work perfectly fine.
  10. If I hover the cursor in the main field of the frame (Main Settings tab of the Flight Control Center/opening window) and roll the mouse wheel, nothing happens - unless I have just selected a dropdown menu (such as "Select a flight plan") in which case rolling the wheel will cycle through those available options. To get to the bottom of the window I have to manually drag the scroll bar. There may be others but I think this is the only page on which I've noticed this behavior so far.
  11. Hi, Just wanted to bring to your attention that there are some configuration options which appear to be missing from the Active Sky Configuration Manager in SimStarter NG. There probably isn't much merit to being able to change them all on the fly in SimStarter (for instance, the audio settings and such which would likely remain constant across all profiles), but there are a few which it might be useful to add. Wind Options (and effects) "Random light chop turbulence percentage" Visual Fix Options "Cloud pop fix" "Repeating overcast texture fix" Also, is there a possibility that the ability to scroll with a scroll wheel might be added to the "Main Settings" window in a future update? Thanks for a great program! -Chris
  12. I've noticed this periodically myself and in fact today it happened again. It would indeed seem to be some math error being caused by the time of day. Flight plan was jetBlue 711 KJFK-KLAS; JFK3 GAYEL Q818 WOZEE KENPA CESNA Q138 DKOTA RAP J158 DDY J107 MLF GRNPA1 Just before UTC 00:00: and just after: Note that the MCDU PERF CRZ page reflects the same erroneous time for both arrival and T/D (taken earlier than the above): I'll make sure to check it the next time I fly within the same UTC day (which is most of the time, to be honest).
  13. I've experienced this periodically, including before I started using GSX. To my knowledge, GSX does not affect the refueling of the AS Bus but rather takes its cues from the Bus - i.e. it completes its refueling "routine" once the right MCDU reaches its set loading. Typically, once it's done I'll click the "instant load" (LSK4R) button because quite often it won't read back a quite completed refuel; for instance it'll say 10.98 when you specified to load 11.00. Ultimately I do this so that the GSX passenger and cargo loading functions are based on the correct PAX weight, but I've noticed this to also tend to clear up the "REFUELG" message. On a slightly unrelated note, I've noticed refueling with the APU on takes much longer, so I typically tend to avoid doing that.
  14. Over the past year or so of using the A320/A321 package, I had noticed a subtle difference between some of the different repaints I keep. Eventually I figured out the problem: The CFM models sound "better" on the ground - lots more rattling and bumping, etc. (compared to virtually none on the IAE models), especially on takeoff and landing and when taxiing more than about 10 knots or so. So last night, along with using the cough drop mod posted elsewhere to eliminate the FO's sneezing (the coughing I don't mind but the sneezing can be startling!) I decided to see if I couldn't "fix" the IAE ground roll sound. I was able to by copying the TSS_Rollout.wav and the appropriate section of the CFM sound.cfg into the Sounds_IAE folder. (I believe those are the folder/file names; it was late last night and I didn't have time to post while I had the files handy.) All after making backups, of course! This worked as expected and now my IAE A320s sound like [I think] they should. My question is, is there some reason why the IAE models have a different sound? There's a marked file size difference between each models' corresponding rollout wav file and the sound.cfg section is also different. For what it's worth, I didn't notice such a difference within the A318/319 package. This has also been repeatable over a few installs - I last reinstalled per the guidelines about 3 weeks ago to chase down another problem - installed as admin, no virus scanner, etc.
  15. Hi, sorry for not following up sooner as I had lost track of this thread after posting. I uninstalled and reinstalled according to the guidance but the issue persists. The good news is that I've isolated what I did to cause it: As I run FSX on wide-screen monitors, I've gone through and edited all of my panel.cfg config files. Reason being is that by default (both default and 3rd party aircraft), the pop-up panels tend to be stretched horizontally as we all know the game was developed for 4:3 aspect ratio monitors. So, I've gone through and fixed them, with only positive effects (circular buttons are no longer ovals!) and to no apparent ill effect until this one. By default, the configuration (excluding the gauge info) of the MCDU popup window reads: ...which yields this on my monitor: My modifications are the following - on four lines below as shown in red and bold: ...which yields this: Unfortunately now it gets those artifacts. Changing the "window_size" attribute alone seems to be all that is needed to cause it. Not sure if such a modification is "supported", but it would be an appreciated fix!