Pete Dowson

does your code work? I'm concerned that the copy of SB4 I've installed might be faulty, but I can't find another. Here's why: I enabled the loading of the SB4 transponder DLL with SimConnect logging enabled, and got this: 49.42971 DLL Loaded: Path="E:\Squawkbox\sbtrans10.dll" Version="" > 55.19912 [253, 1]Open: Version=0x00000002 Name="SquawkBox_Transponder" > 55.19914 [253, 2]SubscribeToSystemEvent:EventID=0, SystemEventName="1sec" > 55.19915 [253, 3]MapClientDataNameToID:szClientDataName="SquawkBox Data", ClientDataID=0 > 55.19915 [253, 4]AddToClientDataDefinition:DefineID=0, dwOffset=1, dwSize=1, dwReserved=-1 > 55.19916 [253, 5]AddToClientDataDefinition:DefineID=1, dwOffset=2, dwSize=1, dwReserved=-1 > 55.19916 [253, 6]AddToClientDataDefinition:DefineID=2, dwOffset=17, dwSize=1, dwReserved=-1 > 55.19917 [253, 7]AddToClientDataDefinition:DefineID=3, dwOffset=18, dwSize=1, dwReserved=-1 > 55.19917 [253, 8]AddToClientDataDefinition:DefineID=4, dwOffset=19, dwSize=1, dwReserved=-1 > 55.19918 [253, 9]AddToClientDataDefinition:DefineID=5, dwOffset=20, dwSize=1, dwReserved=-1 > 55.19918 [253, 10]AddToClientDataDefinition:DefineID=6, dwOffset=21, dwSize=1, dwReserved=-1 > 55.19919 [253, 11]AddToClientDataDefinition:DefineID=7, dwOffset=22, dwSize=1, dwReserved=-1 > 55.19921 [253, 12]AddToClientDataDefinition:DefineID=8, dwOffset=24, dwSize=1, dwReserved=-1 > 55.19922 [253, 13]AddToClientDataDefinition:DefineID=9, dwOffset=25, dwSize=1, dwReserved=-1 > 55.19922 [253, 14]AddToClientDataDefinition:DefineID=10, dwOffset=26, dwSize=1, dwReserved=-1 So far, so good. But then: > 55.19923 [253, 15]SetClientData:ClientDataID=0, DefineID=2, Flags=0, dwReserved=1, cbUnitSize=1, pDataSet=177838692 < 55.19924 [253] >>>>> EXCEPTION=31, SendID=15, Index=5 <<<<< which error is, I think, "parameter out of bounds", pointing to the dwReserved value of 1 (the SDK says it should be 0). Then, repeated every 9 or 10 seconds: > 75.76645 [253, 16]RequestClientData:ClientDataID=0, RequestID=0, DefineID=0, dwReserved1=-1, dwReserved2=0 < 75.76647 [253] >>>>> EXCEPTION=25, SendID=16, Index=-1 <<<<< > 75.76647 [253, 17]RequestClientData:ClientDataID=0, RequestID=1, DefineID=1, dwReserved1=-1, dwReserved2=0 < 75.76648 [253] >>>>> EXCEPTION=25, SendID=17, Index=-1 <<<<< > 75.76648 [253, 18]RequestClientData:ClientDataID=0, RequestID=2, DefineID=2, dwReserved1=-1, dwReserved2=0 < 75.76649 [253] >>>>> EXCEPTION=25, SendID=18, Index=-1 <<<<< > 75.76649 [252, 5]RequestClientData:ClientDataID=0, RequestID=0, DefineID=0, dwReserved1=-1, dwReserved2=0 < 75.76650 [252] >>>>> EXCEPTION=25, SendID=5, Index=-1 <<<<< > 75.76651 [253, 19]RequestClientData:ClientDataID=0, RequestID=3, DefineID=3, dwReserved1=-1, dwReserved2=0 < 75.76651 [253] >>>>> EXCEPTION=25, SendID=19, Index=-1 <<<<< > 75.76652 [253, 20]RequestClientData:ClientDataID=0, RequestID=5, DefineID=5, dwReserved1=-1, dwReserved2=0 < 75.76653 [253] >>>>> EXCEPTION=25, SendID=20, Index=-1 <<<<< > 75.76653 [253, 21]RequestClientData:ClientDataID=0, RequestID=6, DefineID=6, dwReserved1=-1, dwReserved2=0 < 75.76654 [253] >>>>> EXCEPTION=25, SendID=21, Index=-1 <<<<< > 75.76654 [253, 22]RequestClientData:ClientDataID=0, RequestID=7, DefineID=7, dwReserved1=-1, dwReserved2=0 < 75.76655 [253] >>>>> EXCEPTION=25, SendID=22, Index=-1 <<<<< > 75.76655 [253, 23]RequestClientData:ClientDataID=0, RequestID=8, DefineID=8, dwReserved1=-1, dwReserved2=0 < 75.76656 [253] >>>>> EXCEPTION=25, SendID=23, Index=-1 <<<<< > 75.76656 [253, 24]RequestClientData:ClientDataID=0, RequestID=9, DefineID=9, dwReserved1=-1, dwReserved2=0 < 75.76657 [253] >>>>> EXCEPTION=25, SendID=24, Index=-1 <<<<< > 75.76657 [253, 25]RequestClientData:ClientDataID=0, RequestID=10, DefineID=10, dwReserved1=-1, dwReserved2=0 < 75.76658 [253] >>>>> EXCEPTION=25, SendID=25, Index=-1 <<<<< where error 25 means "illegal operation"! It does not bode well for any code I might add to FSUIPC if the module itself cannot set or read its own ClientData, does it? Do you get these results? If not could you possibly ZIP and email me your SBtrans10.dll so I can see why there's a difference? petedowson@btconnect.com [LATER] I think I may have found the answer to my questions, but I could do with confirmation. There's no call to "CreateClientData" in my SimConnect log. I assume this is because I haven't run the main SB4 program? It probably explains at least the Error 25's, though the error on the SetClientData looks like a real one. Thanks! Pete

I did actually answer in the other thread first, but to keep things tidy: FSUIPC's inbuilt support for GoFlight equipment is only as a source for buttons and switches. It has never provided any display facilities. To do that it would need an intimate knowledge of each type of device which can display anything, and that's not not viable in a generic support-everything program. However, late last year I did add full Goflight programming facilities to the plug-in Lua facilities. Using short Lua programs you can send values to GoFlight digital displays and light or extinguish GoFlight LEDs. There are examples provided in the Lua package. There is one "gotcha". Whilst the Lua library facilities for Goflight are written cooperatively, in that a Lua statement written to light or extinguish a single LED will only affect that LED and no others on the same GF unit, the GoFlight software itself isn't so friendly and assumes it is the only one using the unit. Thus, if you take over one indicator on a GF unit you really have to take them all over. I have written to the author of the GoFlight software about this but I think he's rather busy on other matters these days. Regards Pete

FSUIPC's inbuilt support for GoFlight equipment is only as a source for buttons and switches. It has never provided any display facilities. To do that it would need an intimate knowledge of each type of device which can display anything, and that's not not viable in a generic support-everything program. However, late last year I did add full Goflight programming facilities to the plug-in Lua facilities. Using short Lua programs you can send values to GoFlight digital displays and light or extinguish GoFlight LEDs. There are examples provided in the Lua package. There is one "gotcha". Whilst the Lua library facilities for Goflight are written cooperatively, in that a Lua statement written to light or extinguish a single LED will only affect that LED and no others on the same GF unit, the GoFlight software itself isn't so friendly and assumes it is the only one using the unit. Thus, if you take over one indicator on a GF unit you really have to take them all over. I have written to the author of the GoFlight software about this but I think he's rather busy on other matters these days. Regards Pete

Of course. My own little grey cells are fading too these days. Not sure whether it's my age or the beer! ;-) I'd like to know where you got 4.57 only two days ago because the only valid places for it have all got 4.60 and have had since early March. I should like to chase up this other place you found, if you can remember where it was? Regards Pete

Not that I know of. This works for me: function flaps_inc(controlnum, param) ipc.display("Flaps increment", 2) end function flaps_dec(controlnum, param) ipc.display("Flaps decrement", 2) end event.control(65758, "flaps_inc") event.control(65759, "flaps_dec") Does yours look like that? Ah. I've not tried is via any axis assignment. I'll test that too. Did you test with the normal keyboard assignments? It works okay with those here, and with keys assigned in FSUIPC. I'll need to attach a joystick to test buttons and axes ... ... It works too here for button and axis assignments. I am using a later interim update than the one in the Updates announcement, but I don't think that will be any different. Sorry, I don't know what you have different there. You have checked that the Lua program is loading and not being logged with some error, haven't you? Try mine. Regards Pete

Yes, it is okay. The SimConnect.XML file is only ever used when linking SimConnect on a Network. That shouldn't matter, it should still find it. The AppData folders are always "hidden". No. Why? And don't they work? Sorry, I'm not sure why you are posting here. Do you have a problem of any kind at all? Regards Pete

There's no place I know in SimMarket where you can download FSUIPC. The main releases are found at http://www.schiratti.com/dowson , and version 4.60 has been there now many weeks. What key in what receipt? As I said, I've always had to go to my SimMarket account to obtain keys. Have they put them in the receipts now? And if there was a key in the receipt why should it not work? But it was yours! Don't you remember it? That was your email address when you purchased FSUIPC3 for the second time on 30th July 2007, and that was the FSUIPC3 key you purchased! I expect that is what SimMarket retrieved for you as you may have been a little unclear about it being for FSUIPC4 not FSUIPC3. You now have 2 valid keys for FSUIPC3 and 4 valid keys for FSUIPC4, the two for FSUIPC3 being with that email address you maintain is "not yours". ;-) Okay. I'm glad you are sorted. Please be sure not to ever openly post your keys again. Regards Pete

No, that's just the job. Thanks. Now, can I ask another favour, please? Download FSUIPC 3.987: http://fsuipc.simflight.com/beta/FSUIPC3987.zip and test the changes on the GPS5. You should be able to assign any of the buttons/knobs now. Let me know please. if it is okay I'll make the same change for FSUIPC4. Thanks Pete

The key you posted openly is NOT a valid FSUIPC4 key, it is an FSUIPC3 key, issued on 30th July 2007 to what must have been another "larry mintz" also of blake st. needham with the attbi.com email address you say is not yours. Your brother maybe? But with the same name? If that really was you too, then it was the second time you bought FSUIPC3, the first time being on 10th January 2005. As far as I can see (and I don't have full records) you bought FSUIPC4 four times in all, with your comcast email: on 21st October 2006, on 21st May 2007, on 5th May 2010 and 24th May 2010. I don't know why you've done this (but thanks for your support!), but the key you posted would not have related to any of those purchases, and they most certainly all used your comcast email address. To my knowledge the current practice of SimMarket is NOT to email any registrations for any product, but only a receipt. It is then up to you to go to your account there and retrieve the key yourself. This is the way it has worked for years and certainly it has operated like this for everything I have purchased from them. BTW version 4.57 of FSUIPC4 is out of date and unsupported. Please download the current version, 4.60, and install that. Regards Pete

Sorry, I can't realy advise on such matters. If no one else here can help I suggest trying one of the other forums specialising more in such things. For example you might find better help in http://www.mycockpit.org/forums or viewforum.php?f=106 . Full information on the FSUIPC application interface is provided in the FSUIPC SDK, obtainable from http://www.schiratti.com/dowson . Regards Pete

I don't know FSInn at all, but if your TCAS gauge reads the traffic data from FSUIPC then you need something injecting the data about the multiplayer aircraft into FSUIPC's data space. FSUIPC itself can only provide data for the AI Traffic in FS, which I think is (normally?) switched off when you fly on-line. I know with SB3 folks used to use Jose Oliveira's "AIBridge" program to perform this function (injecting MP aircraft data into FSUIPC), but I'm afraid I don't know what, if anything, does it with FSInn. It won't be related to whether FSUIPC is registered or not, or any options in FSUIPC, but to whatever program or module is performing the MP traffic injection. Just Flight? You mean for the aircraft? It won't be an aircraft function. It will be FSInn or some accessory program you need to set up or run to do the job. I'm afraid I'm not much further help on this subject as I don't fly on-line and know precious little about FSInn or how these programs provide their data. FSUIPC is only the FSUIPC.DLL. There are no other "bits" of the program. Re-installing is merely putting the DLL into the same place it is now, and uninstalling is merely deleting the DLL. I really think you are looking in the wrong place. You know FSUIPC is okay because everything works when you fly off-line. It has to be FSInn or an associated ancillary program. Regards Pete

KILL terminates the process forcibly, just like using the Task Manager. CLOSE merely sends the processes' main window a standard WM_CLOSE message -- the same as clicking the Close buton at top right in the visible window if it has one. I don't know what they are. Where do you get them from? What are they? Same way as a close, the WM_CLOSE message, upon which yours or a default Window Procedure would issue a WM_QUIT to cause your message processing loop to exit. Maybe yours is not a Windows program? If you never register a Window class and create a Window, even a message window (it needn't be visible), then I've no idea how it gets terminated. Regards Pete Regards, Philipp

That's because I've never seen one. It wasn't in their list of products when I implemented the current facilities. Yes, it would help. but I need a log showing every button pushed and released just TWICE each, in turn. I could do with knowing what button is what too, so please list them as you press and release each twice. If there a knobs on it, turn each both slow and fast in each direction. If they push too, push them twice. And please disconnect the other VRi devices first, else it gets too confusing. From your log I see these inputs, but I need to know if this is complete. Really only a methodical test will do this. Regards Pete

Nope. Looks okay, but this part here: tells me whose avionics suite it is. Maybe Ray will know what's missing, but it looks vaguely as if there should be another component filling in values in those 87xx offsets -- they are assigned to that suite only. ;-) Regards Pete

Thanks Jesus! I'll see if I can add something to the assignment facilities in FSUIPC4. I should have looked myself to see if they were using SimConnect client data for this stuff! Best Regards Pete

Odd that it's the same as mine and I don't get the indication! I even downloaded a fresh copy of WideFS.ZIP from the Schiratti site and still get a clean scan. Maybe you should re-download it in case it's become infected en route or at your ISP? Regards Pete

Yes, it is fine. Sorry, I've no further ideas. Okaygood luck! Regards Pete

I thought you said they jumped from 16k to 0. Is this following statement wrong? If it isn't what you meant, perhaps you could restate the problem so I can understand it better. However, if that is accurate then obviously all you need to do is to set one of the calibration end poits BEYOND the sudden 16383 to 0 jump. Well, you are a evidently very impatient and non-understanding person, for sure. If you really don't want my help, then, of course, don't come back. If you do want help, then at least try to be civil than just post insults and sarcasm. I don't need it and it doesn't help. I do try to be helpful, but I don't expect to have to wipe people's noses for them too. What I advised you to do was completely accurate given the (now apparently inaccurate!) report you posted. Pete

No, nothing. If you had not said this: I might have suggested checking the FSUIPC Log file (a complete one, after FSA is closed), because that might tell me that the system date on the Server was incorrect. A system date set earlier than your FSUIPC or WideFS registration would seem to FSUIPC like an invalid key and it would supply bad data. No. All these programs are 32-bit in any case. The underlying operating system isn't really relevant. Sorry, I don't have any more ideas. If it might help the suppliers of the gauges you can log the data being sent and received by WideClient applications by setting "Log=Yes" in the client INI file. Regards Pete

False positive. The binaries in the ZIP are compressed and there's no real code it can check. It is also rather odd that you get this and I don't, as I also use AVG free. My version is 9.0.819 with the Virus DB version 271.1.1/2893. Regards Pete

No, there's only the one flag saying "on ground" when true, not "on ground" when false. Regards Pete

I've no idea I'm afraid. Your WideFS setup is working fine and you've actually proven to yourself in any case. Seems those gauges need something else, or something switching on, which you've perhaps omitted or forgotten? There's nothing there to decipher, everything is running fine. Do the folks who supplied the gauges have any support at all? What make are they? Some of the third party ones I know of don't use WideFS, but have their own network service. Regards Pete

You didn't follow them correctly, then, because calibration from any value you like to any other value you like is always possible. All FSUIPC is doing is converting the input values from your two limits, chosen to be anywhere on your axes you like, to spread between the whole range of the FS control. It can't possible "not work" if your axis is providing reproducible inputs. Of course it cannot handle an axis which sends random values in random places. That would be a faulty pot or decoder. Huh? How is it rude pointing out how to solve your problem? Why ask if you don't want an answer? Pete

It is because the A/P, or at least its display, operates in 100's of feet. 2316 metres is 7600 feet, which is your 2316 metres -> 7546 feet, rounded to the nearest 100 foot boundary. Maybe this should not happen when using metric displays (perhaps 50 metres should be the interval, I don't know), but evidently the FS aircraft you are using isn't so sophisticated. I don't know if that's innate to FS or only to the specific gauges I'm afraid. Regards Pete

With the current supported versions of FSUIPC (4.60 or later or 3.98 or later) a different email address is accepted for WideFS compared to FSUIPC. But your name must be the same. Regards Pete