Pete Dowson

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

You are still using the old "aircraft specific" facility, rather than Profiles? Either way, aircraft-specific or Profiles, FSUIPC records the NAME or title of the aircraft. It has no way of telling whether it is simply a different paint job! The best way of consolidating these things and making them automatic is to edit the FSUIPC4.INI file section which lists your aircraft names and abbreviate them. Make sure you have the [General] parameter "ShortAircraftNamesOK" set to "substring" (it has defaulted this way for a long time, but as you are still using "aircraft specific" I assume you are using a pretty old installation). For example, for all Cherokee's you'd set the name to Cherokee. For all A2A planes, to A2A. Whatever abbreviated part of the name which applies to all the aircraft you want treated the same. This isn't covered terribly well in the manuals, but the "Using Profiles" chapter would be worth a read. It's a tidier method than aircraft specific and has been around for years. It's defaulted on all new installations, but you can convert from aircraft specific too. Pete

Oh dear. Did you not read all of my message? What VERSION NUMBER, please? And I need to see the log. What you are saying happens is very odd, but I cannot help without information! FSUIPC4 has not been registered inside FS for many many years! Okay, but not necessary. You could have retrieved your key -- for FSUIPC3 of course, as FSUIPC4 did not exist 10 years ago. The purchase and registration is separate for FSUIPC3 and FSUIPC4. Pete

Yes, I understood that from way back. But you said this: From this I understood you to mean that you had tried using the normal controls and that, because this aircraft "does its own thing", you couldn't operate everything you needed that way, and were about to resort to mouse macros. I then replied saying mouse macros may not work with many aircraft and explained why. You said that the gauges were written in XML which confirmed that mouse macros would not work, so I suggested that local panel variables might (L:Vars), and that if you logged these you might find ones which would do what you wanted. And are those examples of where your aircraft does not obey the normal FS controls? It would be very unusual. Even the more sophisticated aircraft normally use the standard Parking Brake and Prop Pitch controls! Why on Earth include my own documentation in your message? !!!! Yes. You can send 8 bytes, but your "&n" is the address of a 4-byte value!!! Sorry, but if you are programming you need to learn programming. To send 8 bytes containing 2 4-byte values you'd need a structure or an array, for example: int n[2]; n[0] = 65923; n[1] = -16384; FSUIPC_Write(0x3110, 8, &n[0], &fsuipcProxy->dwResult); or, using structures: struct { int control; int parameter; } n; n.control = 65923; n.parameter = -16384; FSUIPC_Write(0x3110, 8, &n, &fsuipcProxy->dwResult); However all of this pre-supposes that your aircraft does, after all, obey normal FS controls, so how did the subject get onto other things like macros? BTW I'm not a good teacher (not enough patience nor time), so won't be trying to tech you programming any further than this! ;-) An easy alternative, if you don't understand arrays or structures, would be to set the parameter in one Write and the control in the next write, then do the Process call. In any case, FSUIPC doesn't do anything when you write the parameter, only when you write the control. Pete

Offset 3110 is for sending controls -- ones having a number and a parameter. "L:Vars" have names. You can only send them either by using Macros, or by Lua plug-ins. There's no place in the control number system for names. You seem to have changed the subject completely since your last message I replied to, above! You code seems to be trying to send control 65923, which is the axis control "Prop pitch1 Set". Not sure why you'd send that. It needs a parameter to tell the prop #1 what pitch value to set. You appear to be addressing variable n, a 32-bit (== 4 byte) value as an 8 byte value. What do you think that will do? If you are trying to send the control and the parameter in one Write, you need a structure. If you don't understand structures just set the parameter first (3114) then the control. Pete

Why not assign in the FSUIPC buttons tab to the controls for this? Depending on the radio type you may need to assign to the COM STBY RADIO WHOLE INCREASE / DECREASE and then swap standby into the USE slot using the COM STBY RADIO SWAP. Some radios don't use standby, though, so then you could use COM RADIO WHOLE INC / DEC controls. Just assign the relevant positions to the FSUIPC-added control "Autobrake Set", with parameters 0 for RTO up to 5 for MAX. Are you having a hard job finding these controls? Not sure why you are asking such simple questions. The controls are listed in the assignments dropdowns -- and in alphabetic order -- not hard to find. Also all the FS controls are listed in the List of Controls document installed in your FSUIPC documents folder, and the added FSUIPC controls towards the back of the FSUIPC Advanced Users guide. Pete

All the controls listed in CONTROLS.DLL are also listed in the List of Controls document installed in your FSUIPC Documents folder! Pete