Pete Dowson

Ah. Well I'm pretty sure FSUIPC can actually detect that. I'll have to find an offset to put a flag in for you. No one had asked before (most things FSUIPC provides got there by request! ;-) ). I'll add it into the next interim release, probably 4.938f. Not sure when. This week for sure though. If I find it and add it, then the same offset, when written, will operate the switch too, so a non-toggle action could be implemented. Pete

I don't know. It works fine here in 2.4. It has been adjusted ready for 2.5 (I've also got a 2.5 Beta installed). Can you supply any information, like the FSUIPC4.LOG fie contents, and the Windows Event Viewer details for the crash, please? Without details I can't really do much -- as I say, P3D 2.4 is okay with 4.938d here. [LATER] Best try version 4.938e first please -- there's some other changes. I don't think any will affect this, but you never know Pete

Why would you want an offset? There's an assignable control, "Antiskid brakes toggle". Pete

You do realise that you can assign keystrokes to buttons in FSUIPC as well, don't you? Pete

Do NOT use the FSUIPC_Loader! Why on Earth are you using it? Delete it and re-run the FSUIPC Installer. As I'm pretty sure the documentation states, the Loader is only to get over a SimConnect trust-checking timing bug which was prevalent in FSX RTM and SP1 and hardly occurred later in SP2 and ACC. I don't think P3D even operates the trust checking system which was in error! As for difference between night and day, FSUIPC cannot possibly care or be affected by such a difference. The problem will be something in the scenery, lights or textures which are different at night. The likely reason it seems okay without FSUIPC actually running is going to be because of minor differences in the way the PCs memory is being used, so different things get corrupted by bad scenery files. These sorts of errors are notably difficult to track down. You'd need to do it by a process of elimination -- geographically and scenery layer-wise. [LATER] As well as removing the loader, and re-running the installer, please try version 4.938e first -- there's some other changes. I don't think any will affect this, but you never know, especially with odd things affecting memory locations. Pete

Sounds like you've simply not calibrated all the flap positions. It's easy enough if you just follow the steps. I don't know about any tutorials about this, though. Try pressing the "Reset" button in the FSUIPC calibration section for the flap assignment. You'll need to do that in any case to start calibrating again, doing it properly this tim. If these are the only settings you made in FSUIPC and you don't care about losing any others, the easiest way is to simply delete the FSUIPC4.INI file from the FS Modules folder before running FS. FSUIPC will make a new, default one, with only basic settings and no assignments at all. If you are using Profiles and the J41 stuff in all set within its own profile then just delete any section in the INI file which has a title which ends with the <profile name]. Seems drastic though just to fix one badly calibrated axis! You'd then go into FS options and re-enable controllers there. (You should have disabled them if using FSUIPC assignments). Pete

Sorry, I don't know what the Saitek software does. I suppose you could try it and see? Pete

Well, I'm off to Sri Lanka (yes, for steam trains), but not till the 13th. I'm working with the 2.5 Beta now. Provided the release itself is within two weeks or so it should be okay. Pete

Please find the log files and paste them into a message here: WideServer.log in the FS Modules folder, and WideClient.log in the Wideclient folder on the client PC. Close FS and WideClient down first. Also see if you can work out what changed after three days. Pete

Sorry, I don't know anything about VS2013 (I'm still on 2010), nor C# nor FSUIPCClient. I think you might need to ask Paul Henty. He runs the subforum dealing with the .Net Client DLL, just above. (I'm sure you've used it before?). Pete

There's no change in how the registration is checked. You are making a mistake. The checking has not been changed for years. BTW your FSUIPC is out of date and unsupported. You should be using 4.938 (the latest is actually 4.938c). And why did you delete your registration of two weeks ago? Pete

How weird! Do you hold S3 down then? If so, why so complex? Why not simply hold down S2 whilst you press S1? The way you've programmed it, the input for #5 MUST be seen by FSUIPC before it sees #6.Maybe it may work if you reverse condition and actuator roles, but I couldn't guess and it might not be consistent in any case. No matter that they appear to go on together, internally there will be a sequence. Have you logged buttons in FSUIPC so you can see? I don't think anything in real life is ever truly simultaneous, and even if they were, FSUIPC is going to be told about one before the other. I don't understand why you'd even want three buttons to do the job of two. Anyway, use the logging facilities so you can see why you are getting whatever it is you are getting. Pete

Sorry, you have WIRED the buttons so they always both press together? Really, with actual wire? Obviously, if you've done that, there's no way you can have separate functions on them. If you actually mean that you have tried to PROGRAM them, or ASSIGN them to only do something when pressed together, then let's look: 57=CP(+G,5)G,6,C66623,0 ;GPS enter - Compund: button 5 + 6 together This line will operate if you first hold down button 5 then press button 6. It won't necessarily work the other way around. the CONDITION is button 5, so it must be first. 58=PG,6,C66624,0 ;GPS cursor This line will always operate when button 6 is pressed. It must dop as there's no condition stopping it! 59=CP(+G,7)G,5,C66612,0 ;GPS procedure Like the first line, this one operates when button 7 is held down wilst button 5 is pressed. 60=PG,5,C66611,0 ;GPS terrain This line always operates when button 5 is pressed because there's no condition telling it otherwise. Regards Pete

It's included in the FSUIPC SDK package. Pete

Not sure what you mean by "scan", but FSUIPC has good logging facilities and you can log all reads and writes (separately) to offsets from applications and add-ons. You can also use the utility FSInterrogate, supplied in the FSUIPC SDK, to read and write offsets and to watch for changes. Pete

Have you checked it using other ways. For example if you add the offset as a U16 in the FSUIPC Monitor facility (in the Logging tab) it will log that value and the original SimConnect value it is derived from. You should also be using FSInterrogate to check these things. That's why it is provided as part of the SDK. How can it be negative? It's a 16-bit unsigned value (range 0-65535) and needs to be treated as such! You might find it easier to use offset 0918, which gives you the value directly in pph as a 64-bit double floating point value. Pete

Ok. I'll use the same offset. It'll be in the next interim update, probably this weekend. 4.938d. Pete

Without FS running, you mean? Looking for the DLL in the FS Modules folder, I suppose, and hoping they have installed it correctly. Pete

You must have enabled it. Just go to the AddOns - FSUIPC menu, select the Logging tab, and uncheck the Console Log option. Pete Hi Ian, No, you can't turn off logging altogether. FSUIPC always makes a log. Pete

Yes, another version of FSX, just like FSX-RTM, FSX-SP1, FSX-SP2, FSX-ACC. Do you need further resolution? I could indicate the more detailed version level in another offset, same as I do for P3D 1.1-2.4. So far there's been FSX-SE1 and FSX-SE2 (builds 62607 and 62608). Pete

No, it indicates FSX, because the offsets etc should be the same as FSX. I was considering having the Steam version indicator available separately, as I've done for P3D 1.1 - 2.4. Do you need to differentiate FSX and FSX-SE? Originally, in my first release for FSX-SE (build 62607) it was indicating that FSX-SE was ESP, because I put it into the vacant ESP slot in my tables. But this wrecked compatibility for a number of programs. Fixed that quickly. Best if it still indicates FSX, as that is really what it is. After all, I never indicated FSX-RTM, FSX-SP1, FSX-SP2 and FSX-ACC. Pete

I don't know VB at all so I can't advise on the programming. - Write or WriteS (?) the string "GLOB" to &HC808, 8, - Write the command parameter NW_GLOBAL=3 &HC800, 8 - Call FSUIPC_Process Several points here: 1. I think you want to first do the clear (one write), then set Global mode (you MIGHT be able to get away without clearing -- it was needed in FS2004. May not be needed in FSX). 2. You do NOT write the command to C808! Please PLEASE do refer to the SDK data. The header file clearly shows that uCommand is a short integer (ie. 2 byte, or 16bits) at C800. It's the very first element of the NewWeather structure. How could you miss that? 3. The ICAO 'GLOB' is 4 bytes. there's no zero terminator as there would be for a string. I tend to write such values as a 32bit integer instead. i.e 0x424F4C47 (in C/C++ notation). 4. Where are those 8's coming from? Do you think everything is 8 bytes long? It isn't. Please look at the NewWeather structure again. 5. The clear, then the global mode requests are separate commands and need their own Process, and may even need a pause between them. Try first without the clear, but have a short pause after the process for the global mode setting. These things take time in FS. Writing the GLOB ICAO can be done in the same process as writing the METAR, but should be fore it in sequence. The most important thing in programming is to be precise. Garbage in, garbage out. Please be more careful when referring to the details. You seem to go headlong into things without actually looking at what is written. Pete

In FSX or FS9? Usually, and especially in FS9, you first need to clear all weather. Because if weather has been set in any weather station beforehand, the global weather you are setting only applies to stations not yet so set. However, in FSX there is a GLOBAL mode supported, so first you set that. Have you referred at all to the "New Weather Interface" ZIP in the FSUIPC SDK? That really should tell you most of what you need to know. There you will see about NW_CLEAR, and, in the Header file, NW_GLOBAL, which you need to use to set global mode. The use of the METAR strings is only described in the Offsets Status list. To set weather using SimConnect's special format METAR strings (and you need the SimConnect documentation for that), you first write the pseudo ICAO ID "GLOB" to C808, the chICAO element in the "NewWeather" structure. You need to do this before writing the full METAR string to B000. Pete

Ralph, excuse me from being off-topic here, but I've been viewing your excellent video tutorials, I've got through to the MCP ones on VNAV, and I'm having a discussion on ALT INTV with the author of ProSim737 (the cockpit system I use), because he thinks it is different to what you say. Do you think you could contact me on petedowson@btconnect.com, please, so we could discuss this? I'd like to understand fully. Best Regards Pete

Aha! That's good news! In FS2004 and before, changes in payload and fuel loading didn't affect things like the CofG. You had to go into the FS payload menu and OK out to get the right routines called to do the recalculations. Seems they fixed that when adding the official Simconnect support for writing those values! Pete