• Content count

  • Joined

  • Last visited

Community Reputation

1 Neutral
  1. 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
  2. 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).
  3. 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
  4. 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
  5. TheFiddler

    One last time...

    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.
  6. 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.
  7. 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...
  8. Excellent, thanks Steve! Cheers, Martin
  9. 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
  10. Also v.2.9 directly on top of v.2.7 (skipping 2.8)? (I know, asked above already, but no reply so far.) Cheers, Martin
  11. Hello All, sorry if this perhaps spoils the party a little after everyone seems to be happy -- but I am still unable to get the radar gauge to work. I have read and worked through this thread at least three times, but none of the solutions reported have helped in my case. As Lucas and others above, I do see the gauge background (dark square), with perfect Alpha transparency, and with the cursor changing in certain places to "hand" with + or with - sign, but all "content" is missing: no blue text (if ASN is not running), no dotted distance arcs, and of course no radar echos. With the "Bendix" variant, I do see the bezel, too, but again, no "content". The setup: Win7 Home Premium, FSX Gold (classic DVD; thus not SE, not P3D), ASN newest version (B5589), running on the same machine as FSX and working fine. all three SimConnect versions (RTM, SP1, SP2) are there as they should (I have the full SDK installed). And I have multiple-checked and tested the SimConnect configuration. VCredist x86 2013 was already in place, but just in case I re-downloaded and re-installed it. Panel.cfg is definitely ok (I do a lot of panel fiddling), as is also proven by the gauge actually appearing, just not with "content". I tried the default C172, both the standard and the "G1000" variant. And I have so far aimed only for the 2D popup gauge version (from v.1.0 of course), not any VC integration. Thus: [Window Titles] Window00=Main Panel ... Window06=Roland Weather Radar ... ... [Window06] size_mm=100,150 position=2 visible=1 Window_pos=0.05,0.65 zorder=4 background_color=16,16,16 alpha_blend=0.75 // ori .55 gauge00=RolasnRadar!oRadGauge, 0,0,100,150, sweep|beam|icing As said, I have carefully checked and tried to apply all solutions reported earlier in this thread, but all to no avail. The older Bryn's gauge and the ASN XGauge work fine, though. I noticed one thing when ploughing through several thousand lines of SimConnect log; it may or may not be significant. But I do not know enough to draw any conclusions. I got only as far as looking up (in the SDK doc.s) that an Exception #9 stands for "SIMCONNECT_EXCEPTION_EVENT_ID_DUPLICATE". (In case it's related: as advised, I did not try to make a panel.cfg entry for the gauge both under 2D and VC windows; I just tried the 2D popup.) Those big negative numbers for RequestID and DefineID also look a little suspicious to me. Here are the lines in question from the log (the last four are perhaps irrelevant): > 59.49728 [70, 1]Open: Version=0x00000004 Name="Rolby ASN-weather radar" > 59.49731 [70, 2]SubscribeToSystemEvent:EventID=0, SystemEventName="SimStart" > 59.49745 [69, 2345]RequestDataOnSimObject:RequestID=-536870912, DefineID=-86050082, ObjectID=1, Period=4, Flags=3, origin=0, interval=0, limit=0 > 59.49828 [70, 3]SubscribeToSystemEvent:EventID=0, SystemEventName="SimStart" < 59.49829 [70] >>>>> EXCEPTION=9, SendID=3, Index=1 <<<<< > 59.49829 [70, 4]AddToDataDefinition:DefineID=0, DatumName="PLANE HEADING DEGREES TRUE", UnitsName="radians", DatumType=4, fEpsilon=0.000000, DatumID=-1 > 59.49830 [70, 5]AddToDataDefinition:DefineID=0, DatumName="PLANE LATITUDE", UnitsName="radians", DatumType=4, fEpsilon=0.000000, DatumID=-1 > 59.49831 [70, 6]AddToDataDefinition:DefineID=0, DatumName="PLANE LONGITUDE", UnitsName="radians", DatumType=4, fEpsilon=0.000000, DatumID=-1 > 59.49832 [70, 7]AddToDataDefinition:DefineID=0, DatumName="PLANE ALTITUDE", UnitsName="feet", DatumType=4, fEpsilon=0.000000, DatumID=-1 One other thing: In the thread, an as_srv.dll is mentioned several times, but I do not have one in the as_srv folder (not even after a full re-install of ASN which I also did). There is only as_btstrp.dll. (Actually, I have also seen as_connect.dll earlier, but that seems now gone after the ASN re-installation. Or is it installed ad hoc, only when required?) Does as_srv.dll perhaps refer to older ActiveSky versions? (I also asked on the HiFiTech forum, but have not yet received a reply.) I realize that it is very difficult or indeed impossible to help from afar with what is clearly a "local" problem, but in case anyone has any other ideas beyond the suggestions already in this, thread, please share. Cheers, Martin
  12. Greetings, I missed v.2.8 and it is now no longer available (Fastspring site) -- can 2.9 be installed directly on top of 2.7, too ? Cheers, Martin
  13. Thanks anyway, I do appreciate the will to help! :smile: From what I have read, I could understand that EZCA does not work with a specific aircraft (probably due to forgetting to run the config tool indeed), or even that EZCA is missing from the add-on menu. But what stumps me is that even though FSX prompts me for, and gets permission to run it (which proves exe.dll is also OK), it is then actually not even loaded. Cheers, Martin
  14. Yes I did, and then checked that an EZCA camera definition ("Title=EZdok Aircraft Universal camera") had indeed been added to the aircraft.cfg of the plane. But could that utility (or failure to use it) do anything else at all which might go so wrong that EZCA doesn't even load? Thanks for the reply! Cheers, Martin
  15. Hello All, I have used the splendid EZCA a.k.a. EZdok (v. for a long time now, and cannot imagine flying in FSX without it. Unfortunately, precisely that seems now to be the prospect. :unsure: So far, never a problem, and EZCA has worked just fine for all aircraft and with all setups I created. Yesterday, I installed a new add-on plane (the Aerosoft DA20 Katana). I then conducted a first short test flight, using EZCA (and even creating a new EZCA profile for this plane), and all still was perfectly OK. Later I discovered various issues with the DA20 (it turned out that the installer did not do its job properly). These are now more or less fixed, but at some point I discovered that EZCA was actually no longer loading when FSX started. This makes FSX in effect unusable for me, as no plane can be controlled any more unless I re-assign all joystick input etc. directly in FSX again -- which I don't want to do, I'd prefer to stick with EZCA. Some details: exe.xml checked; the EZCA entry there is still OK (compared with known good backup copies); file validated as well-formed XML. dll.xml also checked and found OK (just in case; I don't think it is really relevant here) fsx.cfg entry for EZCA in the [Trusted] section was the same as before, when everything was still OK: Now I changed it minimally, so that I am currently prompted each time on FSX start if it is OK to run EZCA (to make sure that FSX at least tries). I then give permission, but refuse permanent Trusted status (so that I am prompted again next time.) It seems clear that EZCA really does not load at all: Not only is the FSX Add-ons Menu entry missing, but there is also no EZCA icon in the taskbar (Windows 7), nor can ezca.exe (which has admin privileges) be found anywhere in Process Explorer. I have of course searched this forum (and others) for info, and have seen references to SimConnect issues. However, that is something I really don't want to touch: -- Firstly, I really don't think it is the issue here (it would perhaps be if EZCA were loaded and then didn't work, but apparently it does not even start.) -- Secondly, messing with SimConnect seems quite dangerous, so I would first have to see a different proof that it really doesn't work before I even consider fiddling with it... For similar reasons, I would not consider re-installation of FSX, SP1, SP2, or indeed Windows 7... :o Re-installing EZCA might be an option, but can it be done without running into "activation counter" issues and such? (I do have a backup of the F1 Installer as downloaded, not just the unpacked installer; and I haven't installed it more than once so far. But still...) As said, without EZCA, FSX is practically dead for me, so all ideas and tips would be greatly appreciated. Thanks in advance! Cheers, Martin