Pete Dowson

Yes, same. In root folder. Please make sure you are using MakeRunways version 4.82 which has been adapted for new scenery formats. AND do read the ReadMe document included in the ZIP. It does tell you about installation and use!!! Pete

It's always been there. Sorry, perhaps I should have edited it out in the latest edition (converted from TXT file to PDF now). Pete

The SDK blurb seems to imply that %LOCALAPPDATA% might be used too, making 4? Right. So Layer=1 will come before ALL of the default layers? This system seems very clunky to me. Does it to you? That's very kind of you, thanks! It would help users of MakeRunways until I can get to making the right changes to it. Could I include it in the MakeRunways download, and auto-execute it before doing my thing? I am away next Wednesday till the following Tuesady, so I cannot really get down to doing anything serious with my program for a while yet. petedowson@btconnect.com is the email for any attachments, please. I'm not good with PMs and they are difficult to refer back to at a later date. Would email be okay? Don't post yors here, but if you send me your file and will have it. ;-) Thank you very VERY much! Pete

I asked this over in the L-M Support Forum, but no one is answering. I assume no one can explain? This is delaying my updates to MakeRunways to handle the new complex add-on structures. =========================================== I've been trying to get my head around the new (complex to me) system for add-on sceneries. Does any one have an idiot's guide I can use please? What I haven't yet grasped is where I start (Add-Ons.cfg in the PROGRAMDATA folder?), and the priority (layering) of each Scenery add-on package. I assume they all follow on from an existing SCENERY.CFG file, but then the SDK lists the order as LOCALAPPDATA then APPDATA then PROGRAMDATA Add-On.xml files. Are the respective supplier folders in those always pointed to by the Add-Ons.cfg file, and if so is the order in that cfg file then irrelevant? And then what is the use of the Add-Ons folders in the user's Documents folder? Finally, if Layer parameters are explicitly given in each package, as they can be, are those absolute or relative? i.e. is Layer=1 then the very first (lowest priority, base) processed scenery, or is 1 the first add-on after the default scenery layers, or even after all those in the existing SCENERY.CFG? And what if there are several packages stating Layer=1? Are they considered 1, 2, 3, in order, or does each take 1 and push the others up? I'm sure all this must be written somewhere, but finding all the bits in the SDK and trying to put them together is a nightmare. Maybe it's my failing aging brain? Thanks in advance to anyone who can help me here. i was planning on revising my MakeRunways freeware program to cope, but I was about to start planning the changes when I realised I didn't know even where to start! Processing in that program must be done in the same order that P3D now does it. Pete

You'll need to in order to keep FSUIPC up to date. There have already been 12 updates these last 10 days to deal with all sorts of problems, so it is now up to version 5.101k. Here's a link you can use for now (but it will no doubt not be valid in a day or so, whenever the next one is released): FSUIPC5101k_TEST.zip Both P3D4 and FSUIPC5 are ongoing developments, so expect P3D4 updates too. It's just that I bring them out daily (though I'm away for a week soon) whilst Lockheed-Martin and quite so fast. ;-) The link on the Sales site and on the Schiratti "Dowson" page only ever points to the latest main version, the one built into an Installer. I shall be releasing a full Installer version including all the updates to date, probably onmonday morning if things go to plan. It will still be labelled 5.1 but will install 5.102. As for a beginner's guide, it really depends on what you want to do, why you are getting FSUIPC5. Mainly, FSUIPC is an interface for other programs, so you need to do nothing other than install it. With the purchased version you effectively get a bag of tools, most of which are simple on their own but may look daunting when presented to you in a big bag. Just use the Content list near the beginning of the User Guide to look up the things you are after. If you don't know what you want to use it for, don't buy it yet. Just install it and read the User Guide first, then decide. Pete

You need FSUIPC 5.101g and the latest PFC DLL -- PFCcom64.dll for serial port, PFChid64.dll for USB HID. See my support forum. Everything is there. Pete

Very nice! How about I buy that chunk of code from you to build into my (free) MakeRunways? :-) Or of course I could tell everyone they MUST buy an FSDT product! ;-) Thanks! Pete

Strange, then, because my normal editor (UEDIT32) which CAN read either, definitely shows it as 8-bit ASCII. I can check it in binary in any of sevceral ways, and it is defintielly ASCII. Well, this is the same on 3 different PCs, two Win7 one Win10, which have had P3D4 installed on them from scratch and no scenery.cfg editing as yet on two of them. Perhaps the early betas of P3D4 set them so? But they've certainly not been replaced. But, true, I do not delete these things each time i do an update. Okay. Thanks. And is that the priority order which P3D uses, with the last entries as highest, and layer numbers withing each one (r if omitted, just the order listed?). This answers some questions about things I don't understand in the SDK Help. It's all getting too complicated for my 74-year old brain! I grew up programming valve computers! Like Abacus's compare to todays stuff, where, as if the hardware wasn't complicated enough, everyone insists on adding more and more complex file and library structures on top of it all. Ugh. Pete

Well, that's odd. UIt isn't here, and my MakeRunways is working fine on the file with no change apart from locating in in ProgramData\Lockheed Martin\Prepar3D v4. Ah, perhaps you are saying that these additional CFG files are in Unicode? Currently MakeRunways doesn't know about these, so its files will be missing add-on airports which use this new method. I'm afraid i won't have time for a while to modify the program. Too much to do with FSUIPC and ancillaries. Pete

Will there be a 64-bit version of GFDev.DLL, which I can use with P3D4? FSUIPC's GoFlight programming facilities depend on it. Pete

Yes, thanks -- but not when I posted. I've already downloaded and tried the latest, but after a couple of crashes which seemed to point to the video drivers I've gone back to the ones I had before! No VAS leak anyway (on a 1080Ti). Pete

Aha! Good. Thank you! Pete

Yes, I know it is okay for lots of folks. Not here. I've had to make changes in FSUIPC because some Windows APIs it uses causes crashes -- of those programs you use there are probably more than just FSUIPC that have had to be modified to suit W10. It is most certainly not a fully backward compatible version of Windows at all -- in fact it seems more different than even moving from XP to Vista to W7. The problem API in FSUIPC which I had to avoid has up to now caused me approaching 4 weeks of solid work, and i still haven't reached the "fully working in all cases" solution, one which worked fine on Win7. And it is definitely a standard, documented Win32 API function which is crashing and I am having to find work-arounds for. I have similar problems with different API functions on my assorted drivers which are written by me, and for me, for additional hardware in my cockpit. I use Flight Illusion, Cockpitsonic, Sismo and PFC equiipment and all with my drivers only, not theirs. I like to be in full control of what is going on hardware-wise. I expect documented Windows APIs to work properly on Win10 as they always have on XP, Vista and Win7 -- unless they are marked as no longer supported, which these most certainly are not. And, yes, I am using the most recent on-line referenced available for them.. Carry on happily with W10. I am not decrying that. I just have very good reasons to hate it! Pete

No. I hate it. It is on my Surface Pro 4, which I use to test my programs on for Win10 compatibility. But Win10 is incompatible with several utilities my working environment depends on (they crash randomly), and also my own drivers for parts of my cockpit. On the latter I can find no reason for the crashing other than incompatible Windows API functions. Win7 is easily the best operating system MS ever made. It is on all 9 of my PCs (7 of which are to do with the two cockpits). I have Vista on an old Sony notebook, and Win10 on the SP4, as I said, both for testing -- though I don't do much on Vista as I don't think anyone is still using that OS, probably the worst one MS ever did! I can't see nVidia abandoning us Win7 users -- there will still be plenty around, especially many businesses who are very reluctant to move on, and for good reason IMHO. So I find it rather shocking and annoying that this release is labelled for Win10 only. Maybe it will be made Win7 on its subsequent WHQL release. Pete

I need the Win7 version. Have nVidia abandoned us old guys sticking with the best O/S Microsoft ever made? Pete

Only for Win10? Can't find one labelled for Win7 anywhere! :-( Pete

Actually, for normal length cables, that's just a selling non-fact to make you pay more. For longer cables (10m for sure, but best >5m) better quality cables are needed for any resolution. It's to do with signal strength loss not frequency of data transmitted. For the more usual distances the cheapest cables will do fine for any resolution. The shielding is always good enough on them all. Pete

Did you have it working on the same PC before, with the menu visible in the Sim? If so we know that end of SimConnect is set up ok. Have you set up SimConnect on the networked PC? Does ProATC/X connect? Pete

Yes, I use it this way. The main thing to do is run MakeRunways from your FS folder on your FS PC, whenever you change scenery or get new AIRAC data, then in ProATC/C import new AIRAC without using the Read Scenery button. Assuming you've already given ProATC/X the pasth to your FS folder (shared), it will read the MakeRunways data you've already created. Pete

You can use 3000MHz or even 3400MHz RAM in the Z170 motherboard. Pete

Actually, there's an announcement on the Forum that a release will be made on 19th March which fixes all known issues. Of course, I am away on holiday then! Typical! ;-) Oh, one thing: it does say "Monday 19th March" , and the next Monday 19th March is in 2018! But I assume he really means Monday 20th March. Pete

Actually that is not necessarily true. One of the techniques which can be used in scenery BGL files is resorting to Assembly Code in order to do rather clever things. I know there are several scenery designers who do this on occasion. Such code will crash in 64-bit mode -- assembly code is very different. Add-on aircraft which use only XML gauges will probably be easily ported, but the original panel tools provided in the Microsoft SDK actually encouraged the writing of C/C++ gauges -- they are effectively DLLs just like the ones loaded by DLL.XML entries, except loaded by PANEL.CFG declarations. I don't know much about aircraft MDL files, but I suspect that they, too, may sometimes carry machine level code. If and when it happens it will be interesting times, that's certain! ;-) Pete

It's really horrible. Pete

Speech synthesis from text would cover everything. I think that's what VOXATC uses. And synthesis can be very good these days. BUT good quality voices for synthesis are expensive -- each one has to be purchased for all the different controllers and AI pilots you might want, with varying world accents (if enough of those are actually available). The free Windows ones and other cheap ones are very, er, robotic. Also, some preparation of the text often has to be done to make sure the synthesiser actually uses a reasonable pronunciation. As you know, words are often not pronounced as they are spelled (or rather vice versa). Phonetic spelling would work provided the phonemes used match what the synthesiser understands. Pete

I've relented on this matter somewhat. I've made available a test version of FSUIPC with planned departure/arrival airports treated differently if you wish. I don't want to release it generally until those who are interested have tried it on real flights. Please see this thread on my Support Forum for more details and a download link: traffic-limiter-option-for-planned-airport-ground-lmiting Pete