Sabretooth78

member
  • Content Count

    187
  • Joined

  • Last visited

Community Reputation

49 Excellent

About Sabretooth78

  • Rank
    Flight Student - Solo
  • Birthday July 7

Recent Profile Visitors

1957 profile views
  1. Sabretooth78

    [Bug tracking] Managed Speed issues

    I've reinstalled several times in the past several weeks and at least one of those times I tried deleting those "User" folders (and then restarting) but to no avail in stopping the problem, so apparently it's one of those "your mileage may vary" things that happened to work for you... I also don't run A/V - I don't use my sim PC for anything besides simming (and the attendant downloading that goes with it) so unless SimMarket, ORBX, Aerosoft, etc. get hacked; well, suffice it to say I haven't used A/V on any of my PCs (Mac and Windows) in at least 15 years and haven't got burned; I'm tech savvy enough and back up early and often enough that if I did get a virus I'd just assume wipe clean and restart. But I digress... One area where I differ from your process is that I tend to run P3D and load up whatever particular add-on (particularly in the case of aircraft) immediately after running the installer and rebooting. I'm not sure if that makes a difference. I guess I do it as sort of a holdover from the FSX days, where you had to run FSX on the clean install in order for the sim to create its cfg files and such before installing the service packs, otherwise you could potentially run into problems. All that said, I now almost ALWAYS get the managed speed bug on climb when hitting crossover altitude. Always, as in, at least the last 7-8 flights (beginning around New Year's Day). Before that, it hadn't been happening at all (in that situation). Fortunately, George still seems to obey the "proper" climb speed, and the bug is easily eliminated by either pushing or pulling the altitude knob. As for the random occurrence of the bug during flight, I still get that only sporadically. Say maybe once every 5 flights. For instance it happened to me last night fairly early in cruise on a 4:45 flight; it seems to have a propensity to occur on longer flights (which makes sense; longer flight = greater chance of it happening eventually) at some random point in between waypoints. The first time it ever happened to me was on November 5; about midway through a 5 hour flight. Naturally, that was while running P3D v4.3, and the problem has persisted through the P3D update to v4.4 (for which I updated all components and have since reinstalled the Bus a number of times). Also consider I just performed a clean install of Windows in mid-August 2018 when I effectively rebuilt the PC. I don't know if that rules out the state of my P3D install as a cause or not. My virtual money is on it being an unintended side effect caused by a VNAV update to the Bus sometime in late October/early November, but that's just a hunch and I don't intend that as a dig at the developers; --it happens. So, regarding the upcoming update. The change log for 1.2.2.2 said that the logging would be triggered when the managed speed dropped below 120 kts. Unfortunately, this would not trigger in the vast majority of my situations where it is occurring during climb, where it typically shows up at about FL260, calling for a speed of 180 kts and slowly decaying as the climb progresses. Could I make the suggestion that the logging instead be triggered say when the managed speed drops below 200 while in climb or cruise phase? Or perhaps any situation above say FL200? Naturally it would have to be coded in some way so as best to avoid instances in initial climb with lower speeds such as SIDs with speed restrictions, etc. Of course I may well be the only one having this issue during the climb. At this point I'm sick to death of reinstalling things and I'm content just to throw it into selected speed until the issue is teased out and squashed, which will happen eventually. I have no problem doing some investigative work as part of my normal flying, but I'm done with the reinstalling for now. There's enough to do as it is just in the normal course of updating, regardless of trying to tease out bugs. I have no regrets jumping ship to P3D, but this is why I clung to FSX for as long as I did, why I would still be using FSX were P3D still only 32-bit, and why with most gaming I've usually been a hold out; I appreciate the maturity and stability in the platform!
  2. Sabretooth78

    T/D

    Those efforts, in and of themselves, are appreciated - unfortunately as with most things on the internet, it's the complaints that outshine the praises. In that light I apologize for any offense I may have implied. That being said; however, my experience of repeatedly failing to achieve a fully up-to-date (albeit nominally "working") 1.2.2.1 shows that they do not fully address the fact that there are certain files which were updated under the 1.2.1.2 through 1.2.1.5 updates; update packages which are still considered experimental and which are not inclusive in the now non-experimental 1.2.2.0 and 1.2.2.1 updates. What tipped me off to this was losing the KG/LB switch in the options as well as noticing I had outdated FMGS.dll files after following those provided instructions. Surely Aerosoft (and our fellow forumers) have better things to do than spend time trying to figure a potential upcoming spate of issues with things we could swear had been fixed; things that were fixed were it that we weren't all unaware that what we were running was not truly a supportable up-to-date copy of the software? Short of officially endorsing all updates from 1.2.1.2 through 1.2.2.1 as gospel by including them in the base download version, and/or pulling the 1.2.2.2 update from the servers, the method devised by CFG874 is the best possible end to this regrettable situation that we all find ourselves in. The fact that Aerosoft has not so much as acknowledged this, despite significant evidence, is what I have a problem with. The fact that my last prior posting was deleted also isn't doing anything to allay my disappointment, something which I can tell from other postings I have read are views not solely held by myself. They were not meant to be malicious; I have previously refrained from posted anything inflammatory or non-constructive nor is that anything I do in the first place. I don't know. Maybe I should just be directing my energies somewhere else. Delete this if you see fit.
  3. Brilliant!!! A clever solution that appears to work! (Why couldn't I think of that!!!!!) It also confirms my suspicions about the Updater. If you do a clean reinstall of 1.2.1.0 and update without experimental updates enabled, you will not receive the following updates and needless to say will not have an up-to-date version and all the potential bugs and support issues that such may entail: 1.2.1.2 1.2.1.3 1.2.1.4 1.2.1.5 Therefore the preferred method, should not be to clean install but to fake out the Updater to overwrite the 1.2.2.2 update with 1.2.2.1 as Bernd suggests. If you clean installed, then update allowing experimental updates and then proceed with Bernd's process from that point. I've noticed by the logs that doing this will not replace the 1.2.2.2 MCDU2b.xml and MCDU2C.xml files, but I'm not expecting that to be much of a problem.
  4. Have you checked your file modified dates? Mine "works fine" too, but who knows what unsolvable support issues will pop up when you are missing several interim patches. I'd rather not find out!
  5. Are there any thoughts as to why when using the Updater a total of 5 times (3 "clean" reinstalls and 2 "attempts at fakery"), I don't seem to be getting all of the updates? Perhaps by not checking "Show ... experimental updates...", I'm only getting the 1.2.2.0 and 1.2.2.1 updates on a clean install and not the incremental updates between 1.2.1.0 (the store download version) and 1.2.2.0? I can't know that for sure since the Updater application isn't very transparent in terms of settings. In the absence of any guidance as to something I may be doing wrong, this seems to be exposing some general limitation of the Updater application regardless my situation. If that is the case, perhaps 1.2.2.0 and 1.2.2.1 should have remained "experimental" and 1.2.2.2 pulled altogether. Perhaps those interim updates are considered experimental, and successive update packages are incremental and not cumulative? I haven't tested this on a clean install since allowing experimental updates from the start and updating straight from 1.2.1.0 to 1.2.2.2 otherwise appears counterproductive as it does nothing to solve my initial problem (rather it represents exactly what put me in this situation), nor does it follow the official guidance recommended by support in this forum. (I did, before one of my clean install attempts, try an experimental update from 1.2.2.1 to 1.2.2.2 after not allowing experimental updates to update to 1.2.2.1, and was still missing features, so clearly the 1.2.1.0 to 1.2.2.0 increments were not picked up then, which would make sense since the Updater must have thought I already had those since the version was marked as 1.2.2.1.) Maybe it would be a good idea for the Updater to have a backup and/or rollback option for the files it is proposing to update with a given package, given the real potential for something to go awry with both experimental and supported updates. Yes, I'm kicking myself for not fully backing up the working 1.2.2.1 setup, but given that official support has identified a way around it wouldn't seem that such a hangup I am experiencing should be possible or acceptable.
  6. I've done that a total of 3 times already; each time has resulted in the same. Changing the version number in the text file in the Updater\Products folder back to 1.2.1.0 also triggers the same faulty update (tried that twice). Are there files or registry keys that I should be removing after running the uninstalls? (Or a way to manually update?) Throwing those old files in there fixes it, but unfortunately they are 1.2.2.2 so I can't just copy the whole batch right in and run from there, at least until (presumably) a fixed 1.2.2.2 or 1.2.2.3 comes out. I had also experimented with deleting prepar3d.cfg (same results) and toyed with a client reinstall but it's pretty clear to me that P3D itself is not at issue unless it's somehow impeding the Updater.
  7. Attached are my log files for the most recent update attempt, in case they are useful. Aerosoft A318-A319 Professional_1.2.2.0_Log.txt Aerosoft A318-A319 Professional_1.2.2.1_Log.txt Aerosoft A320-A321 Professional_1.2.2.0_Log.txt Aerosoft A320-A321 Professional_1.2.2.1_Log.txt
  8. Sabretooth78

    KGS vs LBS

    I believe I've found the cause of the problem!
  9. I updated to 1.2.2.2 shortly after it was released but after seeing the problems others were having (and confirming at least some of them myself) I decided to roll back to 1.2.2.1. Prior to rolling back from 1.2.2.2, I saved the entire "Aerosoft" add-on folder, as I typically do to preserve my liveries and aircraft.cfg edits. As a result, and after installing v1.2.1.0 as downloaded from the Shop, I've found that although the Updater did download and install some files and now claims that I have the latest version (1.2.2.1), I have discovered at least a few files where my currently installed files are older than my backup files. It seems as though the Updater is installing outdated packages? What led me to discover this was the absence of the "Weight Unit" setting under MCDU3 > Options > Aircraft. For that instance, restoring my backup MCDU2a.xml and MCDU2b.xml files restores the feature. I've also found some other files which aren't being updated (see below). I haven't searched exhaustively, so there may be more? ...\Aerosoft A318-A319 Professional Base\Panel_Fallback\AB_MCDU2\ Backup files: Current "up-to-date" files: ...\Aerosoft A318-A319 Professional Base\Panel_Fallback\DLLs\ Backup files: Current "up-to-date" files: The A320-A321 installation is an identical situation, except MiscD2D.dll has a matching date.
  10. Sabretooth78

    KGS vs LBS

    I have (twice) uninstalled through the Windows control panel (both packages), restart, installed both (re-downloaded Sunday), loaded into sim (wasn't there), restarted and then ran the Updater (excluding experimental; feature still missing). Either it would seem there was some obscure step I may have missed or the Updater is missing it somehow (I don't recall exactly when the feature appeared). After the first attempt I did update to 1.2.2.2 only to find the same problems others were reporting and the option was not present then either. It doesn't bother me so much in and of itself as much as what else might be messed up that I don't even know.
  11. Sabretooth78

    Steep dive after initiate decent

    This happens to me as well and it appears to be exclusive of wind and direction (i.e. headwind/tailwind). There seems to be two causes (which are not necessarily exclusive of each other): (exclusive of TOD calculation) The aircraft will either be in level flight or descending at -1000 fpm (depending on how you've initiated descent) and doesn't begin to follow the vertical path until after the little pink circle on the PFD drops below the present altitude. So the aircraft is immediately high and will then attempt to regain the profile. (apparently factored into TOD calculation) Especially problematic when above crossover altitude. The speed target will continue to rise faster than the aircraft's indicated speed can actually catch up to it, causing pitch down and v/s rate of ~ 5000 fpm until target speed is eventually reached (causing your copilot to yell at you, if you use FS2Crew), after which (usually after reaching crossover altitude) a more reasonable v/s rate of 2500-3000 fpm is sustained. It almost feels as though there's too much drag on the aircraft during its [indicated] acceleration into the descent, i.e. it feels like it almost struggles to pick up speed. My solution is generally to descend slightly early (say 20 nm or so) in v/s mode and/or select a target speed somewhat less than the managed speed while in open descent (often the latter is required by a STAR anyway). I will say that this behavior is better than it was at release, somewhere in the course of updates to the climb performance it seems to have been muted somewhat - I was getting descent rates ~ 6000 fpm prior. Still, this all seemed to be much better tuned in the FSX version; but then again not being an A320 pilot I can only go by what others say as to what "feels right".
  12. Sabretooth78

    KGS vs LBS

    Prior to installing (and then rolling back from) the v1.2.2.2 update, my MCDU3 had an option Options>Aircraft>Weight Unit (LSK 5L) under which KGS or LBS could be selected. After rolling back to v1.2.2.1 (by installing from the downloaded v1.2.1.0 for both the A318-A319 and A320-A321 packages and then using the updater to bring both up to v1.2.2.1), I now no longer have that option and in fact I notice on the "What's not available, what's wrong?" thread that the option to change between units is no longer struck through. Would I be correct in assuming that this feature has been rescinded and for some reason past updates did not remove it? I feel like I'm going nuts, because I know it was there and I have screenshots to prove it!
  13. Sabretooth78

    Engine ECAM - Fuel Used

    So, funny thing - I had updated to 1.2.2.2 and upon seeing all the problems people were having, decided to downgrade back to 1.2.2.1. I re-downloaded from the store (1.2.1.0) and updated through the updater (non-experimental), and now the MCDU #3 option to change weight units no longer exists!
  14. Sabretooth78

    Engine ECAM - Fuel Used

    I changed [International] MEASURE=1 (Hybrid) to =0 (US) and it didn't seem to have any effect. I'll try metric the next time and see if that makes any difference.
  15. Sabretooth78

    Engine ECAM - Fuel Used

    Yes, in the MCDU#3 >Options>Aircraft Options>Weight Unit P3D itself is set to hybrid; so were I to load via the menu system I would input in kgs.