Jump to content

TheFiddler

Members
  • Content Count

    106
  • Donations

    $0.00 
  • Joined

  • Last visited

Everything posted by TheFiddler

  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. 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...
  13. 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
  14. 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
  15. This topic has been moved by the moderator of this forum. It can be found at:http://forums.avsim.net/dcboard.php?az=sho...topic_id=140082
  16. Problem solved! :-)A duplicate object/GUID issue, as suspected. :-scatterDuring this adventure, I have finally taken ObjectManager into use (the .NET 2.0 requirement so far had stopped me), so I can now do a proper inventory of what is where and using which textures.Thanks again for your help, Jim!And as a big bonus, I had a look at your web site (very nice design, BTW!) found ch_pnl.zip and then learnt about ch_plus.zip. I have so far used some very old similar tool, but it was rather simplistic; this combo is much nicer and more useful. Thanks for making it available! :-beerchugCheers,Martin
  17. Yes, a typo indeed, sorry. I had checked just this "tyre vs. tyres" issue multiple times with the actual file names in the sim, and then still got it wrong in the message. Stoopid.Thanks, Jim, for spotting it, it's just the kind of thing that can bring one down if one doesn't get support from a different pair of eyes...I can also report some slight progress. I noticed that this TNT trailer model and texture (yes, it's the one you refer to) are used by several other sceneries I have installed on the new box, but not on the old. So on a hunch I disabled all add-on sceneries except my own, and bingo: textured wheels! How can a scenery suppress texture rendering of another scenery?Now remains just the puny task of re-activating about three dozen sceneries one by one (with an FS9 restart after each!) to find the culprit :-) I had another strange effect: Leaving no stone unturned, I took away the main texture file for that trailer, but to my surprise it was happily rendered anyway. Can a scenery use (on its own accord) textures from texture folders other than its own??(I checked: It was not available in any of the "general" texture folders which are always active, such as ...FS2004texture, ...FS2004Addon Scenerytexture, etc.)I think there is also some sort of texture cache from which it can perhaps come, but in this case I hadn't been near any of the other sceneries where that trailer texture was also used.May be both textures and model are not really coming from my test scenery at all, but from some other scenery (I had something like that happen once, when I got my test folders mixed up.)Curiouser and curiouser. But we're getting there.Thanks again for the support!Cheers,Martin
  18. Hello,this one perhaps, for city to ICAO (and IATA) code and vice versa:http://www.airlinecodes.co.uk/aptcodesearch.asp(yes it has airports, too :-) )Another good starting point for all sorts of everything:http://www.landings.com/(check the index at the bottom of the page)For charts (collection of links, partly Real World, partly VATSIM sites):http://usa-w.vatsim.net/charts/Hope this helps.Good luck!Martin
  19. Hello All,another one which is driving me crazy:I made a small scenery using some RWY12 gmax objects, among which a trailer ("13m Trailer TNT").On my old machine, all is well, everything including the trailer looks as it should.On my newer machine, the tyre textures for the trailer are not rendered. And ONLY those -- the main texture of the trailer (and of all other elements used in that scenery) are fine.Both machines have exactly the same BGL file and texture files, I have checked multiple times that the correct texture file (tyre.bmp, DXT1 512x512 16bit) is present on both; I even deleted all other scenery elements again to exclude any possible "cross-effects".What can be the reason that -- in an identical scenery installation -- one specific texture does not render on one machine, but is OK on another? Display settings are the same on both machines too. The graphics cards are different, though (ATI on old box, NVidia on new), but I can't see how this might be the reason to fail on one single texture.Thanks for any tips!Cheers,Martin
  20. (veteran newbie alert! :D )Greetings,coming back to FS9 scenery design after a loooong break, I find that I have forgotten my basics. Can someone please refresh my memory?The case: I wanted to do a trivial and quick (or so I thought) job of creating just one building (an extra hangar for Gatwick EGKK) in gmax, then exporting to XML/MDL, then converting to BGL. Very simple. it doesn't even use textures.And it actually worked out just fine.The problem is that I see the building in FS9 only when located in certain places, in others I don't. The latter including the one (of course) where I want it :D.Everything is equal except the coordinates in the XML file (as exported from gmax and manually edited, no ObjectPlacer or such involved). So it must be some external factor, not an issue with the building itself.I have disabled all non-default scenery, and the scenery.cfg entry for my BGL is at the end (i.e. at top priority in the Scenery Library).Still, I find that the building is not visible e.g. near the Heathrow EGLL and the Gatwick EGKK airports (whereas London City EGLC vicinity is fine).Could this be an Exclude issue?But my (vague) memory is that Exclude affects autogen, not gmax/XML based scenery. Or?Or could it be an AFCAD file effect? But even if I move the building quite a bit away from e.g. the actual EGKK airport area, it still doesn't turn up.So, what am I overlooking here?Under what other circumstances will a functioning BGL scenery item not be visible in FS9? Thanks for all pointers!(I tried Google and FAQ, of course, but can't find the right search terms, it seems.)Cheers,MartinThis is where I wanted the building:N51* 9.05' W0* 11.77' not OK, at EGKK(moving outside the actual airport area did NOT help)Here are the other coordinates where I tested.Latitude was always N51* 30' E0* 30' OKE0* 00' OK, near EGLC! W0* 30' not OK, near EGLL W1* 00' OKW1* 30' OKW2* 00' OK
  21. Thanks for your replies, gentlemen. The interesting thread mentioned by Jon (even if it is about trapping, not generating, keys) is just the continuation of the old discussion I was unable to find.Looks like I'll have to go hunting "unused" events. As I am thinking about jet airliners, may be all those PROP and MAGNETO events will help, or the KOHLSMAN events (whatever that may be) :-)Thanks for your help!Cheers,Martin
  22. Greetings, I was wondering if it would be possible to "emulate" arbitrary keypresses from within an XML gauge. (The idea being to have something more convenient than umpteen key assignments for handling e.g. the various doors etc. of more complex aircraft, such as PMDG 744F. Note that more key comboes would be needed than just the usual "Wingfold" and "Tailhook" ones). A little search showed that, as usual, Arne (Bartels) and Rob (Barendregt) have been there years ago :-); see the old thread [a href=http://forums.avsim.net/dcboard.php?az=show_topic&forum=122&topic_id=19532]"key access for XML gauges"[/a]. (Gentlemen, I really do appreciate all your hard work, and almost even more so the time you spend actually passing on all this valuable knowledge. Thank you!)[p class=dcmessage]At the time some questions were still open, it seems; but I couldn't find a continuation of the discussion, and the subject seems not to have made the FAQ here on this forum.Open questions were e.g. (according to Rob):The "raw" method apparently can not handle key combinations (such as SHIFT-ALT-X), or?Will this method in fact "intercept" the keypress, so that it never makes it to the actual FS9?Also, Arne supplied an XML example, but unfortunately that is no longer attached to the thread. Any other place to get it?My question:What is the current wisdom: Is it possible to generate arbitrary "key(combo) presses" from within an XML gauge?"Arbitrary" meaning that they are not tied to any standard events such as TOGGLE_AFTERBURNER4 etc. (I am aware that "door opening gauges" are available e.g. for the LevelD 767 and the PMDG 737, but I think these use "just" pre-defined events, not arbitrary key press combos.)Ideally, the generated output should be indistinguishable from a real keypress, so that add-ons which use their own key assignments, e.g. PMDG, can also be "fooled".Can it be done at all?Thanks in advance for all info, pointers to same, or examples!Cheers,Martin
  23. OK, you're there, Damian, Chris, and Jim: Finally no longer distinguishable from The Real Thing ! :-halo [p class=dcmessage]Fantastic! (or rather, Real!)Thanks for your work (and SU2) !Compliments, congratulations,and best regards, Martinfrom the southern coast of Finland,a Great Place For Clouds(meaning this AS praise comes from a connoisseur! :-))
  24. Hello Damian,WOW! Nine (9) minutes response time, and that during a critical update period -- fantastic service! :-halo As to ASV vs. ASv6: I do see your point and most certainly will now upgrade. I was inclined to do so anyway, of course, just hadn't had time to look into the matter. Now with this first hand info, nothing is going to stop me!Thanks for your fast and informative response, I am looking forward to transitioning to ASv6!(And today is a holiday here in Finland, too :-) )All the best,cheers,Martin
×
×
  • Create New...