Pete Dowson

How is it looping sending your METAR string? Check your program. Also you could enable IPC writes logging to see the relationship between your writes and the commands being obeyed. Pete

Please see my previous reply! Pete

What's a "running error"? There should be a compiler error as I missed off the & to get the address of the value. Sorry about that. It may be that SimConnect doesn't like the METAR string. I don't know +VCTSRA, and you don't seem to be setting any clouds or the pressure (QNH). Please show the FSUIPC6.log file. You might need to get a SimConnect log too. Instructions in a topic in the FAQ subforum. You could also log weather in FSUIPC to see what FSUIPC tries to do, and also run WeatherSet2 to set your 'thunder' and see what gets logged for that. FSUIPC makes correct SimConnet METAR strings from the binary AWI data. Pete

You can remove axis calibration entries in the INI file by merely going into FSUIPC's Calibration options and RESETting calibration on that axis. You must have calibrated it at some time. Pete

Haven't you just tried adapting your program to set Global mode as well as send the METAR string. To use the NWI fully you need to do a lot more work setting up all of the structures and converting yuor METAR strings into numbers. Here, I've corrected it for you: TxValue = 0x0005; //NW_GLOBAL FSUIPC_Write(0xC800, 2, (BYTE *)TxValue, &dwResult); sprintf(TxBuffer, "GLOB METAR 101208Z 27055KT +VCTSRA"); //Thunder FSUIPC_Write(0xB000, strlen(TxBuffer)+1, (void *)TxBuffer, &dwResult); FSUIPC_Process(&dwResult); Some time in the future, when time permits, we will release both WeatherSet2 and TrafficLook as example projects, complete. But it won't be for a while. Pete

I'll leave it to John to check the FSUIPC7 loading and operating side of things, but one thing you could do to see if Pilot2ATC is even attempting to connect is to enable some logging options in FSUIPC. Go to the Log tab in the FSUIPC options and enable the IPC Reads and the IPC Writes options. Make sure MSFS is ready to fly. THEN and only then, run Pilot2ATC. The log will show whether it is even asking FSUIPC for any details. If it isn't, and assuming you are correct that both FSUIPC and P2A are running at the same privilege level, then I'm afraid it would back to Dave to sort out. FSUIPC cannot make the connection, it is always up to the client program. One other thing, separately, would be to run some other FSUIPC7 client applications -- for example TrafficLook (as listed in the "Download Links -- Useful additional programs" subforum). Use the link TrafficLook. If that connects okay then it is definitely a P2A problem. Note that this program connects even without MSFS running. With IPC Reads being logged the FSUIPC7 log shows it reading these (and getting only zeroes of course): 319594 16888 READ0[4756] 02A0, 2 bytes: 00 00 .. 319594 16888 READ0[4756] 0560, 24 bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 319594 16888 00 00 00 00 00 00 00 00 ........ 319594 16888 READ0[4756] 02B4, 4 bytes: 00 00 00 00 .... 319594 16888 READ0[4756] 02C8, 4 bytes: 00 00 00 00 .... 319594 16888 READ0[4756] 034E, 2 bytes: 00 00 .. 319594 16888 READ0[4756] 0580, 4 bytes: 00 00 00 00 .... 319594 16888 READ0[4756] 736C, 4 bytes: 00 00 00 00 .... 319594 16888 READ0[4756] F000, 4088 bytes: 28 00 60 00 00 00 00 00 00 00 00 00 00 00 00 00 (.`............. 319594 16888 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ... etc (4088 zeroes altogether -- no traffic without MSFS running. plus more after this big batch (1980 bytes from D840). Pete

Okay. I think I know what is happening. My Windows 10 used for MSFS must have been set by some program or other to allow Long File Names, because although, like you, I have the install separate from the default, MakeRunways doesn't get into trouble with long file paths. The separate install has a longer path because of all that weird guff after the D:\WpSystem part. Just 25 characters extra, but enough to make some of the subfolders paths way over the limit accepted by some Windows file functions. I looked this up using Google, and found two ways to handle it. One seems to be to pre-pend the path name with \\?\. So i've done this in this version for you to test: MakeRwys.exe Please try this. I'd still like to see the Runways.txt, but if this test works it will be a very large file, so please show me only the lines up to the "Reading MSFS scenery" line. The other way is to set Windows to accept long filepaths in any case. But that's a Registry change. So we'll try this way first. Pete

Actually I think that need is related to the setting of the weather using the Binary structures in the full NWI. I think the GLOB METAR is written in any case, and would apply if Global mode was active in any case. Writing GLOB to C800 does nothing. Please do read the text provided in the SDK. As described, setting GLOB mode is just one of the commands you can send using this structure (see the NewWeather.h header file which you should include in your program. typedef struct _NewWeather { unsigned short uCommand; // C000 C400 C800 CC00 unsigned short uFlags; // C002 C402 C802 CC02 // Not used until FSX - see below unsigned int ulSignature; // C004 C404 C804 CC04 char chICAO[4]; // C008 C408 C808 CC08 unsigned short uDynamics; // C00C C40C C80C CC0C // 0=none, 4=extreme unsigned short uSeconds; // C00E C40E C80E CC0E // FSX only -- see below double dLatitude; // C010 C410 C810 CC10 // LLA zero for GLOB or unknown ICAO double dLongitude; // C018 C418 C818 CC18 int nElevation; // C020 C420 C820 CC20 // metres * 65536 unsigned int ulTimeStamp; // C024 C424 C824 CC24 // mSecs since start of session NewPress Press; // C028 C428 C828 CC28 NewVis Vis; // C02C C42C C82C CC2C // Base Vis -- for upper Vis layers see int nTempCtr; // C034 C434 C834 CC34 // Number of temperature layers NewTemp Temp[24]; // C038 C438 C838 CC38 int nWindsCtr; // C0F8 C4F8 C8F8 CCF8 // Number of wind layers NewWind Wind[24]; // C0FC C4FC C8FC CCFC int nCloudsCtr; // C27C C67C CA7C CE7C // Number of Cloud layers (max 16 in FSX, was 24 NewCloud Cloud[16]; // C280 C680 CA80 CE80 char chUTCstamp[6]; // C380 C780 CB80 CF80 // UTC time stamp on METAR (internal use) unsigned short fWriteback; // C386 C786 CB86 CF86 // Flags for writing back to FSX (internal use only) unsigned long ulSettingTimeStamp; // C388 c788 CB88 CF88 // Timestamp METAR sent (internal use) int nUpperVisCtr; // C38C C78C CB8C CF8C // Number of upper Vis layer (new in FSX) NewVis UpperVis[12]; // C390 C790 CB90 CF90 unsigned short uSpare[8]; // C3F0 C7F0 CBF0 CFF0 } NewWeather; You'll see that you need to write this with a Command in C800 according to // Commands (for set weather area only) #define NW_SET 1 // Set weather via FSUIPC user filters #define NW_SETEXACT 2 // Set weather bypassing user filters #define NW_CLEAR 3 // Clear all weather, but leave dynamic setting alone #define NW_DYNAMICS 4 // Set weather dynamics (from uDynamics value) #define NW_GLOBAL 5 // (FSX) Put FS into Global weather mode // You should write only 'GLOB' weather after this, which will be applied everywhere. So, instead of writing "GLOB" to C800, write NW_GLOBAL or 5 as a WORD (2 bytes). You may also want to change the rate of change value in P3D. To do that you need to set the rate in the uDynamics with the command set to NW_DYNAMICS (4). The METAR string always contains the ICAO for the weather station being set. For GLOBal weather the pseudo ICAO code GLOB is used. If omitted it isn't parsed bty P£d as a valid METAR string. Sources for example projects are pending your next visit here. Or I could send everything to you for publishing in the correct way, when you aren't too busy (!). Pete

I think it's something in your Community folder. This is my last test today, with more logging in the Runways.txt file: MakeRwys.exe There should now be a full path listed for each MSFS and Community scenery layer, till it gets to the one causing the crash. As well as running this and showing the runways.txt, could you please tell me the folder names of each add-on in your Community folder? I'm definitely off-line now, at least for a few hours. Pete

That's even weirder -- it appears to be stuck on something. I'll need to add more logging to find out what it is looping on. Pete

Strange then. Although I don't use P2A with MSFS I use it regularly with P3D. The FSUIPC interface for client programs is identical for both. And of course there are quite a few P2A users having success with MSFS. Maybe having FSUIPC7 registered will make a difference, though P2A shouldn't need it (ask Dave about that). To test this, have a go with the Trial Licence John posted in https://forum.simflight.com/topic/91420-trial-license-for-fsuipc7/ Pete

Not really. This just shows it is something to do with one of the layers. Getting to that is more difficult. Was a SceneryList.txt file produced? It should have been. If so I need to see it please. Anyway, I'm getting more and more convinced it must be related to one (probably add-on) scenery which has extraordinarily long folder names, or just very many subfolder levels. I did have checks on these, but I've added to these in this version: MakeRwys.exe Try that one please, and show me (or attach) the scenerylist file, if there is one, and the runways.txt file. This is about all from me till tomorrow. Pete

You need to state which aircraft you were using. The log isn’t clear on that. In one profile in FSUIPC you have an assignment to STEERING SET. Is that axis assigned in MSFS? Your results do sound like MSFS or FSUIPC thinks you are using a tiller for ground steering. Pete

Ok, thanks. That eliminates quite a lot. Here's another to try -- if it doesn't find it this time then it's a lot of extra logging for each layer of scenery. But since it isn't making a "scenerylist.txt" file I don't think it will come to that. MakeRwys.exe Runways.txt afterwards, please. Pete

The error logged is different this time, and in a Windows library DLL, so it doesn't really help I'm afraid. I really cannot see any reason for it to crash before it really gets to do anything. It is very strange -- and you are the only one reporting this. Desperate measures are called for. Here's another temporary update. MakeRwys.exe The only changes are that it forces some checkpoint lines into the Runways.txt file. Not knowing where or why it crashes I've only put a few of these in at present, to see how far it gets in the initial setup. Please run it and show me the Runways.txt file (you can paste its contents here -- makes it faster and easier). This may take several iterations with different checkpoints being added as I narrow it down. Pete I

Curiouser and curiouser ... ! Can you post the Windows crash data for me again, please. It seems to be crashing before it even does anything except open the log, which makes no sense. Pete

Were you ready to fly? In other words, no yellow prompt to Fly Now in MSFS? I think you have to run P2A only when everything is set ready. Are you by any chance running MSFS or FSUIPC “as administrator”? Or Pilot2Atc? All three should either be run normally or in administrator mode, not at different levels. And check that it isn’t really a P2A problem after all by running one of the example programs like TrafficLook or any other FSUIPC application. (see https://forum.simflight.com/topic/66136-useful-additional-programs/) BTW, do you use a different name on the P2A forum? I couldn't find your discussion there with Dave, the P2A author. Pete

The event.terminate hasn't been cancelled. Maybe its canellation should be assumed, but as it is all events are treated equally. Pete

All offsets other than those protected against being written can be changed by an application program. Reading and writing offsets has always been the long term reason for FSUIPC's existence, right from 1998. What the offsets are used for isn't relevant to that facility. Mappings/bindings within FSUIPC imply assignment to some function or other in the Sim. As I said, assignments in FSUIPC are part of the facilities registration of FSUIPC enable. So you can certainly manipulate the virtual button offsets, but they cannot be used by an unregistered FSUIPC user for assignments. They could just be read by other programs as can any offsets. Pete

That is because you can only assign the one action, L: B747_8_MFD_Range. That's the name of the macro within the file, and using that name only the first entry (or maybe the last depending on how Windows does these INI selections) will be used. Just have the one entry: 1 = L: B747_8_MFD_Range = Set and assign to that with the parameter in the assignment (the "parameter" entry there) in your button or keyboard assignments. Pete

Please refer to the Lua Library document supplied with FSUIPC7. You'll find details of the gfd.SetLight, gfd.SetLights, and gfd.ClearLight functions provided in the comprehensive GoFlight library. Pete

One is the Install log and the other is the run-time log. Thanks. This is making me thing that some of the paths to the files MakeRwys needs is too long: D:\WpSystem\S-1-5-21-2263347563-3261326988-2989552293-1001\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\Official\OneStore\carenado-aircraft-ct182t-skylane-g1000\SimObjects\Airplanes\Carenado_CT182T_Skylane_G1000\aircraft.CFG That path itself is 242 characters long. It wouldn't take much to put it over the normal "MAX_PATH" of 260 characters. I'm not sure exactly how to get over this. I think it needs a Windows registry change to make certain Windows functions, one which MakeRunways has to use, allow longer pathnames when constructing paths for access. however, I've made some small changes as a test. Please run this one and let me know: MakeRwys.exe Whether it still crashes or not, please see what files it generates, if any. Best to delete any older files first, or run this copy in a different, new, folder. If there's a "runways.txt" file, please show me that -- or at last the first 20 lines or so. Pete

Okay. that helps a lot, thanks. I'll look at this later today. Looks like a stack overflow. So I'm now thinking that some of the paths it needs to find the files are much longer than any seen before. Since you reinstalled FSUIPC7, can you please show me its Install Log so i can see what paths it is using? Pete

Attachments should be ZIPped. Unfortunately it isn't "our" file size setting, it is set by the Simflight Forum software, though no one else seems to have any problems attaching normal INI files. It's usually logs with extra logging enabled which are too large and need Zipping. Text files do Zip up really small. In previous versions of FS (FS9, FSX, and even P3D1-3), the "no smoking" and "seat belt" switches on overheads were just dummies, for completeness, except on some add-on aircraft. I see that MSFS has provided controls for these, but whether they work on not is another matter. Unfortunately many of the ones MSFS have published so far are wishful thinking and have yet to be actually implemented in their interface facilities. Or they may work on one aircraft but not another. Each aircraft seems to implement its own subset. An alternative sometimes is to find the L:Var which controls the switch and use that. Best in any case to state which aircraft you are talking about. The answer might even come from another user of that same aircraft, but for that yo'd really need to entitle your post with a more specific heading like "No smoking switch for xxxx". Pete

You can only set GLOB via the facility to do so in the NWI. After that you can set the global weather via B000. Weather set with GLOB otherwise merely sets the default weather for any weather stations for which no METAR report is available. So, unless you set global mode, you are very unlikely see see any result from what you are doing. Pete