Jump to content

TheFiddler

Members
  • Content Count

    106
  • Donations

    $0.00 
  • Joined

  • Last visited

Community Reputation

5 Neutral

About TheFiddler

  • Rank
    Member

Flight Sim Profile

  • Commercial Member
    No
  • Online Flight Organization Membership
    none
  • Virtual Airlines
    No

Recent Profile Visitors

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

  1. Hello, a few hours after I made a post the FS2020 forum, I found this is now in "Hangar Chat", presumably moved there by a moderator. It's fair enough; I have no objection. Just for my information, I'd just like to know what the procedure is: I could find no notification (either in the post itself ["Moved to..." or some such], or in my Messages) that this had been done. Is this normal forum protocol indeed, or am I just not looking in the right place? Cheers. EDIT: Sorry, there is actually a pointer, namely in the list of posts of the original forum. This is what I was expecting, I just had missed it (had looked only at the post, not the forum content list).
  2. Disclaimer: The Man from The Outside, Looking In here: I do not own FS2020 (a.k.a. MFS a.k.a MSFS2020), and do not plan to obtain it. I did spend a lot of time reading the fora, though* (this one and the official one). Depending on your personal preference and party affiliation (Whiners a.k.a. Negativity Spreaders, or White Knights a.k.a. word not allowed EDIT: Interesting: starts with F and ends with bois), you can thus freely choose to argue, with equal justification, ¤ either that therefore I do not know what I am talking about; ¤ or that as a non-partisan outsider with no horse in the race, I may have a more detached and objective view of things. Anyhow, I like Balance, and to restore it in the FS2020 context, I had an idea which I herewith present to the Community for their kind consideration. It goes like this: I buy FS2020, let's say the "Premium Deluxe" variant (purchased directly, not via Game Pass). So I now owe Microsoft/Asobo (MS/A) the sum of USD 120. The payment will be made as follows: I pay 60% (thus USD 72) up front. (Depending on your FS2020 experience, perhaps 50% or 70% may be more appropriate, but it's only about the principle here.) I make an honest commitment that in ten years from now (to be precise: on August 18, 2030) the full sum of USD 120 will have been paid. (With no interest or extra fees, though.) So I still have to pay USD 48. These will be paid according to the following scheme: I shall not pay directly in USD from my bank. Instead, I shall make available "credits" *) which MS/A can download from my website via a special downloader application called "SpecDow". These are small encrypted and securely authenticated files; my bank has my corresponding program which will convert them into equivalent real money which is then transferred to MS/A's account. *) Note: This is not to stoke the hornets' nest of discussion about the "credits" system! It's a mere technical ruse: I cannot control how the bank operates, but I can control how my website operates. When a new batch of credits is available, this will be announced. It will require an updated version of SpecDow (always to be downloaded first, from a different UI). But only a certain (variable and non-predictable) amount of credits will be available per (variable and non-predictable) time period (aiming for once per month, but no guarantees). Sometimes a batch of credits can be obtained and converted to USD without difficulty. Sometimes a batch can be downloaded only at the rate of 0.1 credit/hour. Sometimes the download of a credit will fail completely and/or "loop" (occasionally many times). It may be necessary from time to time to completely uninstall and then re-install the SpecDow application (it's quite big because of my 1.4 GB logo). (It may occasionally seem that even re-installing Windows 10 from scratch is necessary, but that's a bit of a myth.) When attempting to convert downloaded credits to real dollars, quite a few of those credits may turn out to be broken in various (variable and non-predictable) ways, e.g. mis-coded encryption, or a faulty authentication part. Some credits may work, but cause the SpecDow application to slow down, sometimes considerably so (e.g. no more than .001 credit/h). Any of the above may depend on which specific computer with what specific hardware/software configuration MS/A is using to obtain credits. Some machines may work flawlessly while others, working on the same batch, may not. In the case of difficulties as above, I shall in due course (say after 4-6 weeks) offer an update to the SpecDow application to fix things. (Hotfixes, within 2-3 weeks, only in special cases.) These updates then may or may not fix the issue under consideration. They also may or may not revert, or indeed nullify, previous features and/or earlier update fixes. But, to re-iterate: On August 18, 2030, the full payment of USD 120 will have been made! (This is not a scheme designed to shirk or even to merely reduce the amount paid. Eventually.) What do you think? (I'm hoping to see opinions split along the same lines of Whiners ("Payment system doesn't work! Unusable!") vs. White Knights ("Be patient, it's a brand-new scheme! Give it a year or four, and almost all money will have been paid!") as mentioned above, but will myself refrain from any further comments. It would not do for an outsider.) Cheers!🙃 * Having flightsimmed since Bruce Artwick on the Apple ][, one does have an interest to see down which hole the rabbit is running these days.
  3. ..and even if you have an account, you're not yet out of the woods. I do have one (reluctantly and for other purposes than FS2020 which I don't own; nor do I have an Xbox). So I logged in to the forum and was promptly confronted with the next demand, namely to give permission to "let this app access your info": "Flight Simulator Forums needs [sic] your permission to: Access your Xbox Live profile information and associated data, and sign you in to its services. Flight Simulator Forums will be able to access basic properties about your Xbox Live profile, including your gamertag, friends list, activity, stats and rankings, settings and content you share. ..." [red colour added by me] All this to read a forum...
  4. Just FYI and for "closure": Even after long and instructive (to me at least 😄) discussions with Jean-Luc, no proper solution of that "LoadLibrary error 126" could be found, alas. However, the work-around reported by others in the earlier threads works fine for me, too, namely to use an older version (6.21.0) of the Garmin Trainer instead of the current v.6.62.4. That older Trainer version (from Sep.2016) will even work with most databases of the newer (Nov.2019) one. The one exception is a file "card" in v.6.21.0 (I think this is the airport charts). This file is not in v.6.62.4, which instead has a file apt_dir.gca. But this latter file will not work in the older Trainer: the GTN then reports "Charts: not available". So I have to stick to the 2016 charts. With that, I "can live", however. Cheers, theFiddler
  5. Hello All, just so no one thinks this thread has gone dead: Jean-Luc and I are working "behind the scenes" on this. Excellent support by RXP! Unfortunately, so far not much progress to report; it really looks as if currently the only way to get Comodo (just the firewall in my case) out of the equation is to uninstall it completely (as has been reported before). Just disabling or even exiting it will not suffice. Obviously uninstalling a firewall is always risky "surgery", which I can't try currently, for fear of risking more fall-out on a computer I need to be working. But others have done that and reported success, see the earlier thread linked above. If you try, do remember not to run without any firewall, though! Cheers, theFiddler
  6. Hello All, having today purchased and installed the RXP GTN 750 for X-Plane 11 (and of course also the Garmin Trainer for the GTN 750, but not for the other devices), I have been promptly hit by the non-fatal but extremely annoying errors described in an older long thread on this forum. (Moderator: As the last post there is from March 2019, and versions etc have changed since then, I thought it best to start a new thread here, instead of adding to the old one; I hope this is acceptable.) This message is mainly for the record (problem persists in current versions). I am aware of the various other threads about the problem (and specifically the Comodo issue); and I'm trying to find out if anything new has come up in the meantime which I may have missed. I have also found what might be a new twist. Versions: XPlane: 11.41 RXP GTN750 plug-in: 2.5.26.0 (dated 06.06.2020) (GNS plugin, PFCHidReports64.dll, is version 3.2.5.109) Garmin "Aviation Trainer Launcher": 2.7.10 Garmin GTN 750 Trainer (GTN Simulator.exe) : 6.62.4.0 (dated 28.05.2020, thus earlier than the plug-in -- so this is probably not simply another case of Garmin getting ahead of RXP, Or?). The problem is exactly the same as described by others before: After clicking on the "Power on" button in the "Aviation Trainer Launcher", I get 12 to 16 pop-ups with "LoadLibrary failed to load XXXXX.dll. GetLastError: 126", where XXXXX apparently (as per the older thread) is a series of DLL files for the Garmin Trainer program. Those files are all present in the same directory where "GTN Simulator.exe" lives (...\GTN_Trainer\Packages\GTN\bin). But after clicking OK on each of those 12-16 pop-ups, the trainer then seems to actually work as expected (I have so far only tested the most basic functions), which has also been reported before by others. (OK, three or four clicks to get rid of those pop-ups would perhaps not be a real problem, but a dozen or more is...) This happens both with the stand-alone Trainer and in XP11, via the plug-in. Even after reading the 9 pages of the old thread, it is however still not clear to me if this should still be happening also with the latest versions over a year later, hence this post. Perhaps I have missed some more general information/solution which has been found in the meantime? I can also add one new twist, just to increase the confusion: Like some earlier posters I am running a Comodo firewall and have tried the following: telling the firewall to "Allow" all applications to do with the Garmin Trainer: this did not help; temporarily disabling the firewall: this did not help either; The new(?) twist: When I exit the firewall application completely, I can start the "Aviation Trainer Launcher" (as stand-alone thus), but after clicking "Power on", now nothing at all happens any more: the actual Garmin GTN 750 window does not even come up. After closing the Launcher, I am then stuck with a roar.exe process (router to database, or something like that) which cannot be killed even with Process Explorer ("Access denied" even though I am the admin. Impressive!). Subsequent efforts to run the Launcher again then fail, with a message "Preflight error: The data router is already running from a different program." The only "solution" at this point (to get rid of roar.exe) is thus to reboot the whole machine... Some people apparently had success with uninstalling the Comodo firewall completely and/or replacing it with another one. But while I am willing to try (for testing) temporarily disabling or even exiting it, a complete uninstallation cannot really be considered a "solution", in my view. Besides (see above) without the firewall running (even if disabled), I cannot even get to the GTN 750 window. I also realise that this is almost certainly a Garmin rather than an RXP problem. I did try the Garmin "Support" site, but so far was not even able to find any links relevant to the Trainer (as opposed to their hardware). Whereas the RXP support is excellent, judging by the patience and persistence displayed in that older thread. And after all, the RXP product does rely completely on the Trainer, so... 😉 Any hints or ideas would be much appreciated. Cheers, theFiddler
  7. Thanks again for the prompt response! There could actually be a problem here, and if so, it has nothing to do with MCE: My keyboard is not connected directly to the computer, but is part of a "KMV switch" setup (to be used with more than one box). As a side effect of that, the NumLock indicator LED on the keyboard and the actual state of the key occasionally get out of sync, and perhaps something similar confuses MCE, too. I'll do some more testing, and will also check the other items you advise, before the demo time runs out. Thanks again for your help! Cheers, The Fiddler
  8. Some additional info: I just tried again to do the tutorial flight (LFML-LSGG), this time using the default LearJet 45. Same thing happened as described above: For some time (long into the climb phase), all running perfectly, then CP for no apparent reason stopped to respond and react to any command, while speech recognition was still working fine. Two additional observations: 1. I had been wondering if MCE had perhaps somehow slipped silently into Dialog Mode (even though I did not hear the voice-over which was otherwise active). However, in the MCE context menu it was not possible to have "Force Flight Mode" checked, presumably because MCE was already in Flight Mode (as it should be). So, not an issue of accidental switch to Dialog Mode. 2. Another strange detail: I noticed that the destination airport (LSGG) was no longer displayed in the MCE window; it had been replaced by "????". After I had reloaded the flightplan (in MCE, not in FSX), "LSGG" was duly shown again, but a minute or two later it was lost and replaced by "????" again. Not sure what this means; my impression (!) is that MCE has in fact lost the connection to FSX (while the speech recognition side is still working fine). What I forgot to mention (in view of other posts here): I am so far using only the default FSX ATC. The only "extra-FSX" add-on running is the AivlaSoft EFB. (But as MCE uses neither SimConnect nor FSUIPC; any external add-ons shouldn't be relevant anyway, I suppose.) Cheers, The Fiddler UPDATE As a final report: I tried the same flight again, but now skipped all ATC communications. This time, all went well and the destination was reached with fully co-operating CP. I don't quite see why using ATC comm.s might incapacitate the CP (and lose the flightplan in MCE), but who knows. Maybe things got just mixed up somehow, possibly due to user error, or perhaps due to some (mis)behaviour of the FSX ATC itself (it seems to get out of sync sometimes).
  9. Thanks for the impressively prompt reply! I never knew that. Sounds like another case where Microsoft knows best what's good for the user... That may also explain why the problem occurred in midsession and not from the very beginning. But I found that I had this option already set to "Do nothing", so no luck there. [BTW, just for the benefit of people reading this thread later: In my Win7 Home Premium, the tab in question, on the Control Panel > Sound applet is called "Communication", not "Compatibility".] More importantly: This option (and also the volume level) might only explain why I could not hear the CP; but the problem is not just about volume loss: Even when "muted" for some reason, shouldn't the CP still have operated buttons and switches? As reported, not only did he become quiet, but he also ceased to do anything at all. Yes, I had noticed; it is a very good idea. That other monitor was still running only from old habit. :-) Cheers, The Fiddler
  10. Hello All, my setup: classic FSX "Gold" (i.e. not Steam); under Win7 "Home Premium" 64bit , Today I decided to give the MCE demo a go. Installation, microphone calibration, and speech training all went perfectly smoothly. But during the tutorial flight (LFMN-LSGG) I ran into a problem. Initially all went very well. Copilot (CP) listened and responded to commands exactly as advertised and expected (except for some minor newbie blunders caused by myself ). Which proves that the setup as such is OK, mic calibration and speech training have been done properly, etc. "Monitoring" was switched off, though (but appropriate comments were still made, e.g. when I deviated from the checklist, or wrongly confirmed items which were not yet OK.) So far all very well, thus. But then in mid-flight the CP suddenly stopped responding to and executing any commands, or making any comments at all. (This was in a normal cruise situation, nothing special going on with the flight; and ATC not "crowded" or unusual in any way. VAS memory was also monitored and was more than sufficient.) Important: (because it's different from many other problem reports) There was no crash and no "freezing" either of MCE or of FSX. Both kept running OK. In particular, speech recognition continued to work properly (as proven by the red text in the MCE window). Just that the CP did no longer react to anything; he neither did nor said anything any more. The problem is thus not with speech recognition or badly calibrated mic etc. This situation could be "solved" by exiting and restarting MCE. After that the CP worked fine again for a while. Then he stopped responding again, for no apparent reason.. Obviously, I tried (and am still trying) to look through this forum for hints, but it is difficult to find the right search terms, and most people with problems seem to struggle with more "low-level" issues which I do not have (so far). Besides, the demo period is very short, hence my hasty asking for tips and pointers in which direction to look with this "higher-level" problem. Thanks in advance for any tips! Cheers, The Fiddler
  11. Be advised that some people seem to have run into trouble* when they installed regions without having Global. If you already have Global anyway, it may be better to install that first, as the "general background", so to speak, and then add the more "specific" OLCs and regions later as required. Good Luck! the Fiddler * I don't remember how severe, though; and it may have been solved by now.
  12. It is. It is also not the point at all. I don't expect Orbx to fix my specific setup. (In fact I keep wondering if some of the migration-induced problems are fixable at all, technically, without dumping the whole "unified" idea. But what do I know...) I would however insist that Orbx make available some more options to deal with the problem, options which could easily be offered. At the moment the way forward is blocked by the maxim "Get unified or you're out" (with regard to future products and support). OK, Orbx have of course the right to define their business strategy as they see fit. But if you have been migrated already, and landed in a mess, the way back (to the pre-migration status, with the products you have already purchased) is also blocked, because files (libraries, FTX Central) from earlier versions are no longer available, and instructions are missing how to get cleanly out of the post-migration mess (if you are in any), and how to go back to the earlier state. (We can't figure it out ourselves as we don't know what exactly the migration has been doing behind the scenes, with or without success.) Both of these necessities (access to the earlier files, and the guidelines) could be easily made available, at practically no extra cost to Orbx, as far as I can see. We just want to have the option of rolling back if we so choose, that's all. Surely that can't be so hard? And yes, as things stand it would mean exclusion from all future Orbx products, which make the "unified" framework compulsory. But to accept that or not is then our (the customers') right to define our business strategy, so it's not a problem either.
  13. Hello Roland, now it works! :smile: :smile: :smile: After ploughing through the respective SDK chapter for about the 17th time*, I ended up with these settings: [Window06] size_mm=200 . . . gauge00=RolasnRadar!ShellRadGauge, 0,0,200,200, sweep|beam|icing|nogps|starton ...and everything is now fine. And a great gauge it is indeed! If I may make one suggestion: For me (may be it's my monitor settings, may be it's my eyes) the "darkblue on black" numbers on the display (for tilt, range, etc. values) are very hard to read, at least from my normal eye-monitor distance. Any chance of making those a little lighter? Unfortunately we don't seem to have a foreground_color parameter to simply take care of this in panel.cfg. Those numbers are important information and feedback, of course, especially as the buttons are currently not animated and thus cannot indicate current settings. Now on to the non-bezel variant and the VC. Although that won't really be that important to me, because the "Shell" version looks very good. Thanks for producing this splendid gauge, and for the support. Best wishes for more vacation! Cheers, Martin * Maybe I am just dense, but I find sentences from the SDK like this one hard to parse: "size_mm: Specifies the design size of the panel window, in design units. These are not necessarily millimeters [hence the name!?], but this value and the value for pixel_size [which is not documented...] gives the ratio for the size of the panel to the size it should be rendered at ." To be fair, at the very end of that chapter they do give a hint: "However, if you have set size_mm to be 1024, these values are also the pixel values, which can be much easier to deal with." Only if you really use 1024 for the radar gauge, you end up with all of the instrument panel being covered...
  14. Hello Roland, many thanks for your reply and the suggestions! But first of all, let me emphasize there is no hurry at all -- so do enjoy your vacation at your leisure! B) Next, I think we may be on to something. I had already tried most of your suggestions, but I went diligently through everything again, to be on the safe side. Most of what I am reporting below may turn out to be irrelevant eventually, but I'll write it up here anyway, for the record (and in case some serious issues are still discovered and have to be analyzed and eliminated). So here goes: 1. I checked my dll.xml (again), and found that it has indeed this entry: <Launch.Addon> <Name>as_connect</Name> <Disabled>False</Disabled> <Path>as_srv\as_btstrp.dll</Path> </Launch.Addon> So, except for the <Name> (which should not matter), it is just the same as you suggested. On a side note (probably not relevant): I also found a second entry <Launch.Addon> <Name>ASN server</Name> <Disabled>False</Disabled> <ManualLoad>True</ManualLoad> <Path>as_srv\as_srv.dll</Path> </Launch.Addon> but still don't know (see post above) what this mysterious as_srv.dll is supposed to be. It is not in my as_srv folder, and the SimConnect log thus (correctly) reports it as missing file, but seems otherwise not disturbed. Perhaps a left-over from AS2012 (which I had before ASN)? 2. I experimented with the gauge size, as per your recommendation, and here is what I found. Note that my monitor is still a "4:3" one, i.e. not "widescreen", running at a resolution of 1280x1024, i.e 5:4 aspect ratio. In panel.cfg I changed not only the gauge= W and H parameters but also the window's size=... entry accordingly. Results: (Note that the FSX C172 with default panel has a [Window00] with size_mm=640, whereas the one with the G1000 panel has [Window00] with size_mm=1024, which may explain that the actual gauge sizes are different even when the panel.cfg entries are the same. Or?) a) default gauge size: [Window06] size_mm=100,150 ... gauge00=RolasnRadar!oRadGauge, 0,0,100,150, sweep|beam|icing ---> actual gauge size on screen (give or take a pixel) FSX C172 with default panel: 200x300 FSX C172 with G1000: 125x188 B) "doubled" gauge size: [Window06] size_mm=200,300 ... gauge00=RolasnRadar!oRadGauge, 0,0,200,300, sweep|beam|icing ---> actual gauge size on screen (give or take apixel) FSX C172 with default panel: 400x600 FSX C172 with G1000: 252x377 (let's call it 250x376 :smile: ) Conclusion: Doubling the W and H parameters in panel.cfg results in doubling (linearly) the size of the gauge, as expected. Absolute sizes are (of course) still different between default and "G1000" variant of the FSX C172, but that must have to do with the different basic setup of the panels. 3. As per your second post (seen after the Avsim forum was back online again), I now tried the "ShellRadGauge" version of the gauge again (had done it before, but so far with the same result, i.e. no "content"). I also now added the | starton option (undocumented? or had I missed it before?). I had always tried (as per advice you gave earlier in this thread) to click on the gauge clickspots in order to turn the gauge on, but somehow that hadn't helped. And now things got interesting: The gauge window is filled up by only a small part of the whole gauge (the upper left corner) in "over-size", consisting mostly of bezel and only a very small slice of the actual radar display. This had in fact been the case before already, but I hadn't paid attention, thinking that I could fix the dimensions later, once I had managed to get some "radar content" into the gauge. But now I can see something moving very quickly through the "display" part of the gauge, which must be nothing else but the "radar beam" (see arrow). Naturally, as I see only a tiny part of the gauge, I see it sweeping through only for the fraction of a second with each turn, but it is definitely there. It became even clearer once I had set the Alpha transparency to 1.0 (i.e. full opacity). So close to the edge, I still don't see any radar echoes, of course, but I am sure they will be there once I can see the whole display. Naturally in the "bezel-less" other gauge (oRadGauge) I could not notice this "scaling problem", because there are no clues indicating that only a very small corner of the whole gauge is visible. And I didn't see the sweeping beam perhaps because only adding the |starton parameter activated the whole device. In fact, I can currently still not see the beam on the oRadGauge, but that may be because here all that is visible is perhaps just some "dead corner" which the beam never crosses. Once the "Shell" gauge has been fixed, it will probably be easier for the oRadGauge, too. Conclusion: It now looks as if the actual problem I have is "merely" one of inappropriate scaling of the gauge -- always a can of worms in FSX, in my experience. Still, that should be fixable (I haven't tried yet). It may need some trial and error, though -- unfortunately I have never fully grasped the correct relations between all those different coordinate systems for panels, a rather confusing mix of millimeters, pixels, percentages, and the respective actual resolution of one's monitor... (Bonus Question: Why does the ShellGauge have no W and no H parameter at all?) So, we'll have to see... (literally). But in any case, do enjoy your vacation first, one must have proper priorities! :wink: And thanks again for the advice so far! Cheers, Martin
×
×
  • Create New...