Pete Dowson

You aren't a programmer then? Sorry, you didn't explain any context. I have to assume that someone using offsets is a programmer unless they say otherwise! I have no idea, sorry. I do not know SIOC at all. Doesn't it come with any documentation or support? If it can't handle floating point values then, no, it cannot handle that value. Most users of the glideslope variable find the 255 graduations provided by the single byte (i.e. length 1) value at offset 0C49 to be sufficient for their needs -- it is what all Fs gauges use to regulate the GS needle, after all. The main use of the floating point value you seem to be keen on using is for autopilot programs using the glideslope feedback with utmost precision (32-bit precision -- so over a million possible values) for better feedback control. Pete

Yes, it is length 4, it is a FLOAT32 -- i.e. a standard 32-bit floating point variable. In C you define the type as "float" (64-bit floats are called "double". If you read it as an integer you will get ridiculous results, as you've found. It is clearly documented as a float. If you don't need such accuracy, using the single signed byte integer value at offset 0C49. BTW why not try using the Logging facilities, or even FSInterrogate, to check your work? Pete

It has never been bundled with FSUIPC, it has only ever been part of the FSUIPC SDK, and it is certainly there in the current release! It is actually called "FSInterrogate2Std" and works with the FSUIPC.FSI file also supplied. The program called just "FSInterogate.exe" was the original one and long superseded. Note that the data it uses is not fully up to date (there aren't enough hours in a day!), so it shouldn't be used for reference to offset functions. For information on offsets, and details of them all, you should use the two reference documents in the SDK -- the programmers guide (for FS9 and before), and the offset status for FSUIPC4 (when using FSX, ESP or Prepar3d). Pete

Many of the more sophisticated add-on aircraft implement their own subsystems for many aspects of an aircraft. They often don't operate using standard FS controls. This is not a new problem, it has been happening for many years over many versions of FS. Sometimes the add-on writers provide other means -- often keyboard short cuts which then of course can be assigned to buttons in FSUIPC. Others, such as the Wilco 767, provide a Software development Kit (SDK) which allows others to implement interfaces which in turn can either use FSUIPC or do their own button or switch assignments. Sometimes the answer is to use FSUIPC's mouse macro facilities, which work with aircraft panels written using the Microsoft FS C/C++ gauge SDK, or the "Local gauge variables" ("L:Vars") assignment and access facilities also provided in FSUIPC. I can't tell you how to do things on those particular aircraft, but those are the avenues to investigate. If you browse the SubForum here called "User Contributions" you will find lots of examples of solutions for an assortment of add-on aircraft. One more widely encompassing solution, which is one I've used for my 737NG cockpit, is to discard all of the add-on's panels and systems and use one of the "free-standing" complete systems, such as Project Magenta, FlightDeckSoftware, SimAvionics, or ProSim737. Regards Pete

There's absolutely no difference in saved flights no matter how they are initiated. There cannot possibly be. All AutoSave is doing is calling the same routine as the Save Flight menu entry or the ; shortcut. You've got something else going on. None of my software creates flight files, they just call the menu item at the interval you specify. Maybe there's a lot more stuff going (complex scenery, complex weather, engine settings, whatever) on in the AutoSave flights that the others you are comparing with. Why not simply compare the files? All FLT files are simple text files. Pete

I don't know the syntax so I can't comment on the error, but you do realise that offset 0AF4 merely provides the conversion faction, to convert pounds to gallons or vice versa? Regards Pete

FSUIPC had to be completely rewritten for FSX after Microsoft changed everything and introduced SimConnect. So, it is a new product, FSUIPC4, with new purchase required. FSUIPC1 and FSUIPC2 were free, covering a six year period whilst i lived on savings and a few dividends. When they were gone it was either give up doing FS software or start charging. Hence FSUIPC3 then FSUIPC4 were payware. It is still a full time job. Regards Pete

According to my contact at GoFlight, the bug is now fixed in the latest version of GFDev.dll, version 2.0.0.1 dated 8th June 2011. This should be included in the latest SDK issue, but meanwhile I have placed in in the Download Links subforum here. I didn't get back to you about this yet because I haven't had a chance to test it, and in any case it now supports some other things which I should add and test too. If your friend is using 2.0.0.1 and it still doesn't work, let me know, but it should have been fixed according to GoFlight. Er ... only in Lua, or do you mean in FSUIPC? Because I never had a problem in FSUIPC. I can check this in Lua if that's what you mean. Regards Pete

Do you have FSUIPC4 installed? If so, which version? Does the AddOns menu show FSUIPC okay? I cannot really support other folks' programs, and I've no idea what that add-on is doing, so really you need to go to their support. But if you tell me more about the FSUIPC part, and especially show me the Install Log and FSUIPC4 log files (which you can find in the FSX Modules folder), then I might be able to help with that part. You can paste the files into a message here. Close down FSX first. Pete

I'll have to leave it to Paul to tell you what type a signed byte is in this language (mine in C or ASM), but usually the term "Byte" used as a type refers to 8 bits treated as unsigned, so ranging from 0 to 255 inclusive. The data is the same, it's the interpretation that will be incorrect because of the type you are declaring: 255 unsigned is -1 signed, 128 unsigned is -128 signed, etc. Regards Pete

All the Buttons and Values getting functions do is call Windows routines to decode the data already read and provided as a parameter. They will assume that the data is from the correct report, so when it isn't it will be wrong. The answer is the same as before -- I need to work out which reports are which and use the appropriate definitions for each, or simply filter off reports not relevant. I'm sure I can do all that but I need the devices. I really HATE working in the dark, and guessing things. Sorry. It will be done, but I can't say when. I've had no reply yet from VRi. Regards Pete

Yes, especially the WideServer and Wideclient log files, which are produced explicitly so we can tell what is happening. Pete

Good, then? ;-) Pete

There are 3.28084 feet in a metre, not 3.048. And it would be more accurate when arriving at an integer to multiply by 65536 before dividing by 3.28084. 0.2 in 3.2 is 6% error. FSX and FS9 work in the same way in this area. Do some logging -- Monitor 07D4 on the right side, as type SIF32, to "normal log", and enable IPC write logging on the left side. Regards Pete

Aha! I see. Oh dear. I've asked for "an MS/TT Panel"! Oops! I think maybe the HidScanner results are really only for the MS part. I'll sort it, but I think I'm going to need one or both devices. Can you hold out with your interim solution? Pete

Our replies are crossing. I added more to the last one so please re-read it for me. ;-) (Save me re-posting) Ah. So why do you need the rather inferior Lua library facilities. I can't hope to compete with "proper programming"! I wouldn't really want to. But why? Regards Pete

Sorry, I'm confused. Is this with my Lua com library? And another thing I don't understand. Looking at the device where folks are selling it it appears to ONLY have buttons and switches. 32 of them? Yet the report is only 7 bytes with these entries: Value Thr at index 0, range 0 -> 255, using 8 bits Value Rdr at index 1, range 0 -> 255, using 8 bits Value Y at index 2, range 0 -> 255, using 8 bits Value X at index 3, range 0 -> 255, using 8 bits Value Z at index 4, range 0 -> 255, using 8 bits Value U/RX at index 5, range 0 -> 255, using 8 bits Value POV at index 6, range 0 -> 7, using 4 bitsThe buttons all follow in your second report which is logged by my program as: Buttons range 1 -> 30 at indices 7 -> 36 "indices 7-36" here gives the position of those bits, apparently using the last 4 bits of the first 7 bytes and 26 bits in the second report. Right? But 30 buttons for 32 buttons/switches on the device? where are the other 2? And what are those Throttle, Rudder, Y, X, Z, U/RX and POV values for if it doesn't have such? It's a bit weird. Anyway, I've asked if they can send me one. I'll let you know. Regards Pete

I've no idea at present. Yes, but what does it mean? How do I select? And I've no such device to experiment with. I've only managed o do what I have done by experimenting with devices using a USB debugging program I purchased for the purpose. How are you interpreting the information you present to give you two and only a second "usage page"? Are you actually referring to "Usage= ..." not "UsagePage" of which there are many? Maybe they can be persuaded to send me one: they did send me one of each of most of their other devices. I'll ask. but it could be a few weeks even if it is okay -- they ship from Korea. Regards Pete

Well if it is commercial and uses FSUIPC they should have contacted me in any case. I'll take a look for sure. Thanks! Pete

I didn't even know PM CDU had such a facility. I'm not sure what it does or how it tries to do it. I use the WideFS facilities and a hotkey assigned in FSUIPC. Perhaps he can explain what that CDU facility does, exactly, then? Doesn't the PM documentation tell you how to set things up to make it work? Incidentally, if all PCs are in the same Workgroup and the version of XP is at least to SP1 level, then you should certainly not need to have the ServerName and Protocol parameters in any INI file, as they should be connecting automatically. In any case, such parameters are not involved in any shutdown procedures. There are no parameters called "Autoshutdown" or "Shutdown" any place in any WideFS INI file. So those would be ignored. User options go into the [user] section in any case, not the [Config] section. Please refer to the WideFS documentation (which I certainly hope you have!) -- the Technical guide contains complete lists. Maybe you are thinking of "AllowShutdown=Yes"? Regards Pete

Strange that I've never heard of them, and that they'd use an offset not allocated to them. The suites I'm aware of include FlightDeck software, Sim-Avionics, FreeFDS, and ProSim737. Oh, and the new suite from Aerosoft Australia. I do realise that mostly these concentrate more on Boeing, though. PM does have an Airbus suite though I've never tried it. All use offsets requested and assigned to them. I can only assume "SWID" stands for "SWitch ID", which could I suppose be the data you are supposed to write to offset 4602. If there's no other data it can only be a toggle switch operation (on/off). Have you tried Offset Byte Set with offset x4602 and parameter 220 (no x if decimal)? Of course it might be a word (16-bit) value they are using, in which case it would be Offset Word Set. Regards Pete

Sorry, I am none the wiser either. And why 4602, which appears to be part of a range assigned to the Canadair RJ-700 Project? I'm afraid I can't help as I don't know this "AST SDK" nor what "SWID" is. To use the FSUIPC offset controls you need to know what size the value is (8 bits = Byte, 16bits = Word, 32 bits= Dword), etc. And what value to write to it. With neither information there's no way you can get an answer. I think you need "AST SDK" support. Regards Pete

The data in those lines tells FSUIPC where in the Gauge code to call to do the programmed action. I am guessing that on single click action is all the particular location does. Either that, or it needs a true "double click". Without the aircraft to try things on I can't really help, but you might experiment with the parameter values you can have (,n) at the end of the line. They are listed in the documentation and relate to different things a mouse can be detected doing. Regards Pete

Ah, but I am a bit of a perfectionist too! I like things to work properly! Okay. Let me know when its available! Regards Pete

No. I've not had any CH devices since way back in FS4 days. I've only got an MS Sidewinder Freestyle, a Saitek P3000 and a few GoFlight units. Stuff i keep around just for testing. All my real flying is done with PFC equipment, with my own drivers. They aren't joystick types at all. So, you mean it hangs? Or always returns null? Ah, so it can't be hanging. Hmmm. I would need o be able to reproduce it, but I don't have time this week to write a multi-device Lua script I'm afraid. Maybe if you have a test one I can use to make it occur? If I can track it down I can fix it -- if it is fixable without closing and reopening devices. Regards Pete