Pete Dowson

Sorry, I've no idea. I'm really just another user like yourself, with a few of extra functions I can use. They change the forum software more often than I can keep up. I've only just got used to ways of editing the subforums. Regards Pete

They should work, but I must admit to never having tested this. Try it and let me know, please. Regards Pete

Not on general release yet, but try FSUIPC 4.749g Offset 0x1140, double, G-Force direct from SimConnect. Regards Pete

You too, and I'm glad the problem was really so simple! ;-) Pete

Sorry, I don't understand how you get this from what I said? You didn't read my reply on this? Seems I need to repeat myself: :-( All this suggests that you probably have the toe brakes reversed. Most pedals have the toe brake input at maximum when they are released and minimum when fully pressed. If this is the case you need to select the REV (reverse) option and re-calibrate. In addition you should always calibrate the toe brakes with a good "dead zone" so you don't inadvertently engage them when using the rudder. Press both in a little before setting the minimum point during calibration. Pete

So, is the value in 3068 the wrong value? Have you determined what the differences are? (Sorry, I thought it was a difference in 11BA which concerned you). Only "slightly" different? But enough to result in completely erratic behaviour? I don't understand how that could be classified as 'slight'. ;-) So, is the "slight" difference a matter of sign? Does the sign need reversing? Okay. I'll find one. But I'd like to know if we had the wrong mapping for 3068 in FS9 and before, or SimConnect is providing the wrong value for this in FSX. Can you tell? Most of the values in FS9 and before were discovered or confirmed by Hervé Sors, and I've always relied on him for things like this which are all beyond my understanding of FS. Regards Pete

I don't think there's anything in Lua very usefully related to this. I've used the methods I described in C programs, not Lua -- all the hardware I've ever programmed were programmed long before I had even heard of Lua. But you can still do it in Lua, there's no difference from any other programming. What is it you don't understand? Don't assign the dial "button" returns in FSUIPC. Instead use the event.gfd function to get your function called when something changes on the device, then gfd.GetValues and gfd.Dial to read the dial to see if that changed. Use the change to update a value you are reading for the radio (event.offset for the radio offset) and send that back to FS ipc.writeUW to the same offset) and also send it to the GF display (gfd.setdisplay), as you are doing now. Also read the time (ipc.elapsedtime) and store that in a variable which you can check in the event.offset function for the radio -- simply do not update the display if the time now is withing N milliseconds of the last write by a dial change. The value for 'N' will bed to be determined by experiment, but something in the order of 300 - 700 is normal. You want to be reasonably sure that either the user has stopped turning the dial, or at least has definitely hesitated. Regards Pete

All this suggests that you probably have the toe brakes reversed. Most pedals have the toe brake input at maximum when they are released and minimum when fully pressed. If this is the case you need to select the REV (reverse) option and re-calibrate. In addition you should always calibrate the toe brakes with a good "dead zone" so you don't inadvertently engage them when using the rudder. Press both in a little before setting the minimum point during calibration. Er, hold on. Aren't you calibrating in FSUIPC? If not, forget what I said above. But if you are, then even if you can't get the Windows calibration working well FSUIPC's calibration should still be able to give you good results. It doesn't care what the numbers are providing the change, and in the right direction. Pete

Where and how you assign things does not affect FSUIPC calibration -- if you've enabled calibration then it works on the controls no matter where or how you assign. FSUIPC assignment facilities were added a long time after calibration. The latter has been possible for FS axes since FS2000 times I think. If you aren't assigning in FSUIPC, or are assigning to FS controls not direct to calibration, and you are not calibrating in FSUIPC, then FSUIPC doesn't touch the controls at all. It only intercepts them if it needs to. If you switch off the calibration then the INI option is irrelevant. You only need to try that if you actually want to use FSUIPC calibration. Pete

But presumably by cables via the router? So another possibility is a block there? Well, it's usually a way of connecting when the computers are in different workgroups, but it has also come in handy when the IP address supplied for one of the PCs is wrong -- see the FAQ about this. You could try setting the IP address in the INI instead of the ServerName. That's good, in a way, because it proves again that it isn't a change in FSUIPC's Server that's doing it. Let me know, please. I assume you've checked the IP address that the Client is logging? (192.168.1.36). It looks like the right sort of IP address (unlike the ISP host addresses sometimes returned by routers in strange modes), but it bears checking. Regards Pete

I would rather have seen a description of what was actually going wrong. Having read through the referenced thread the only detail of what you thought was wrong was this: The only other useful tidbit was this: all of which implies that the throttles are calibrated in FSUIPC. The place of assignment would then make no difference -- the FSUIPC calibration will normally make the AXIS_THROTTLE controls change to THROTTLE controls, and that probably bypasses the check in the NGX code. You either need to turn off the FSUIPC throttle calibration (press the Reset button), or set it for NRZ (no reverse zone) operation and with the "UseAxiscontrolsForNRZ=Yes" option in the appropriate [JoystickCalibration] section of the INI file. The same sort of need applies to the Wilco airbus. You can of course make this Profile or Aircraft specific. Regards Pete

Is it an XML gauge? If so you may even have the source at hand. If not, then, no, sorry. You might get into it with a debugger and/or disassembler, but you'd need to be proficient with assembly level code and know the assorted parts of FS fairly well. For gauges written in C/C++ start with the FS9 SDK on this. I think the FSX SDK only deals with XML. It might be quicker (even cheaper in the long run) to invest in one of the third party GPS systems. I'm afraid, though, that none of them are in my areas of expertise. I either fly very simply in a relatively poorly equipped Piper Arrow III, VFR and relying on good maps and basic navaids, or, more usually these days, a 737-800 cockpit with full FMS etc courtesy of Project Magenta and IFR with Radar Contact. Regards Pete

Oh, I'm sorry if i came out "annoyed". That really was not the case. And please do not feel stupid. It happens to everyone, that things in front of you don't register. Please do not be concerned and i apologise if my words came over as so critical. I get annoyed more at myself when i think I am not explaining things properly! Regards Pete

Probably the action is local to the gauge. Pete

I've programmed lots of hardware devices like radios and so on, and there are rules I always follow: 1. When adjusting the value, stop processing changes from FS and display the update directly, locally. 2. Only display a new value from FS after n milliseconds has passed since the last change was sent. If you don't do this you will ALWAYS have lag. In order to do what you want you need to process both the input and output in your Lua. Yes, exactly. Because they program it the way I suggest. The HidDemo logging uses "ipc.log" to log the data. The logging goes to the FSUIPC log unless, in the FSUIPC logging options, you check the Lua log option -- that makes each Lua write to its own log when ipc.log is used. Well, your line 130 has an error now, with :cool: in there, but both the original lines are fine. I don't know this "LuaEdit" (is that from the Lua website?), but it evidently doesn't check syntax correctly! Maybe you should send them a bug report? Regards Pete

You are using the older Advanced Weather Interface? Why did you ask about the NewWeather header file, then? If you plan on doing more than one FSUIPC_Read you should do them all in a batch then call FSUIPC_Process, as the latter switches processes every time. I don't know VB at all, but are you sure "Integer" is the same as "short" (i.e. 16-bits)? Check that. Otherwise, please do try using the FSUIPC logging facilities to see what data is actually being sent. There are options for logging both reads and writes. For the AWI interface you probably need to log weather too. I can't remember much about that -- it was originally written for FS2000 or FS2002. The NWI is more usually used nowadays. Regards Pete

The NewWeather.h merely describes the structure of the data. Yes, it is in C/C++ terms and can be used directly in a C/C++ program, but surely you can define a similar structure, or at least use it to pull a read memory block apart to get what you want? If there are any terms, like WORD, DWORD and so on you don't know (these are Microsoft defines rather than C or C++) then let me know and I'll explain.. Otherwise it should be pretty clear. Regards Pete

Er, which were, exactly? He never explained even after I told him there were no changes on my side. I find it quite frustrating when folks complain about something, with no details, then just disappear. How can things ever be fixed or improved like that? He also said the changes were on both FS9 and FSX, just between different versions of FSUIPC despite me not changing anything in regard to those offsets. No one has ever documented what units offset 11BA was in. I tried to make the FSX one compatible to those preceding it. If you know more about this I'd be grateful if you could reveal the secret. I only arrived at the value to place in 11BA by experimentation and comparisons with FS9. You are saying i made a mistake? If so, what, please? No, 30D0 should be the vertical acceleration. That surely is not the same as G-force -- the largest G-forces in most flying are those in tight curved flights with steep back. G-forces may be in any direction, not just vertical. If you need the raw value from SimConnect I'll find a different offset for it. But I'd like you to explain the difference between FS9 and FSX with respect to 11BA, because I tried to make it compatible and you have me concerned now. Regards Pete

Sorry, I've no idea what you are doing now what you want to see or do. Maybe if you showed what it is you've done and what you are trying to do I might be able to advise. There is no reason why a Lua program accessing devices can't be as efficient as you need it to be. It doesn't need to be fast. Even if it only operated at 1000 Lua lines per second (though it is never anywhere near that slow), with the typically small number of lines needing executing can outpace any dial you are trying to adjust. So it must be all in the way you are programming it. BTW "GFDev.DLL" is used by FSUIPC for GF button assignments, and is accessed by the Lua gfd library. But the "HidDemo" you refer to is all about accessing USB HID devices directly, via the Lua com library. There's no GFDev.DLL involved then, it is bypassed. If you are only wanting to program GF devices I'm not sure why you want to go down that route. You can, but I don't think there's any big advantages. The HID facilities were mainly added to access other USB HID devices, which either could not be seen directly in FSUIPC (not being joystick or GF), or have more facilities than can be accessed using the normal methods. Regards Pete

Well, apart from you calling bits 0-7 "1-8", yes, essentially that is correct. You only affect the bits in the value you provide. Please see the FAQ about numbers, in the FAQ subforum. You should think of these numbers in BINARY, then you'll se what is going on. 65 in a binary 8-bit byte is 0 1 0 0 0 0 0 1, reading from high to low (as you do in decimal numbers of course). So your "bit 1" is the last bit, your bit 8 is the first. But really they should be numbered from 0 -- because then their numeric value corresponds to the power of two, as I already explained but you missed (?): bit 0 = 2^0 = 1, bit 1 = 2^1 = 2, bit 2 = 2^2 = 2x2 = 4, bit 3 = 2^3 = 2 x 2 x 2 = 8, and so on. No it isn't. That would happen with "ipc.writeUB". The whole point of the "setbits" and "clearbits" functions is to only set and clear the bits you specify! That's exactly what "setbits" does, and what it is for. How on Earth did you derive that from what I said? My English must be atrocious! :sad: The documentation doesn't teach you basic things about numbers, bits and bytes, which is clearly where you are fundamentally misunderstanding things. Please check that FAQ I mentioned, to start with, and please read what I've actually written in my replies -- don't make assumptions and skip over things so much! I really can't understand how you've ended up where you have from what I've said. I think I might give up trying to explain simple things. I am obviously not very good at it. :sad: Pete

No. The first two are correct, but evidently not for the reasons you think. The setbits and clearbits functions deal with multiple bits -- you can set and clear any of the bits in one call. so the values are not bit numbers (if they were you'd be wrong on all three, because bit numbers are always counted from 0 -- the power of 2 represented, 2^0 = 1, 2^1 = 2 etc). So, bit 0 is represented by 1, bit 1 by 2, bit 2 by 4 (2^2), and so on, up to bit 7 by 128 (2^7). In binary each next bit doubles the value, same as in decimal each next digit multiplies by 10. If you had 8 indicators in one BYTE, you could set them all by "setbits" with 255, and clear them all with "clearbits" with 255, because 255 = 128 + 64 + 32 + 16 + 8 + 4 + 2 + 1. Regards Pete

Yes, they are 'reserved' for general use by anyone. I don't know the OpenCockpits software, but if it is capable or reading specified offsets and operating indicators according to the values it reads then, yes, that will work. If you are going to have a lot of indicators driven in this way, and if the OC software can handle bits not just bytes, then you might want to consider using the ipc.setbitsUB and ipc.clearbitsUB functions instead. You'd get 8 switches per byte then. Regards Pete

Something else must have changed apart from the FSUIPC version if restoring your previous version didn't help. And there have been no changes in WideFS except for the new broadcast mode which is separate code and would need explicitly enabling. So something must have changed by itself? Not that it should matter, but is there any reason you set these specifically instead of allowing it to connect automatically? Could you try a more recent one, please, like the version 6.90 posted at the same time as the FSUIPC update? These logs certainly indicate a block, probably at the Server end -- the client is sending messages but the Server never sees any at all. I think it must be your firewall. Have you disabled it both ends, or at least allowed WideClient through on the client and FSX through on the server? If you need the port number it is the one shown in your INI files -- 8002. If you didn't change the firewall settings yourself, maybe it happened through some automatic update? Regards Pete

Not sure why you posted those. Do they illustrate any specific problem? If so, can you tell me what they illustrate so I know what to say about it? There are no transmission errors recorded, no missing blocks, nothing indicating any sort of problem. Note that the FSUIPC version 4.703 was replaced by 4.745 as the main release version a while ago, and there's an even later one here in the Download Links subforum. Also, if you are going to supply logs please always close FS down first. This is particularly important for the WideServer log where performance summaries are then added before it closes. But as it is the WideClient log does show performance summaries each time you closed FSX (seens you did this several times whilst WideClient was still up and running): 501750 Reception average whilst connected so far: 17 frames/sec, 478 bytes/sec 18999109 Reception average whilst connected so far: 19 frames/sec, 62 bytes/sec which is certainly respectable though not excellent, but good enough to handle any sorts of button pressing transmission and interpretation, as indeed the FSUIPC log shows being enacted: 3108351 Button changed: bRef=0, Joy=67, Btn=19, Pressed 3108351 [buttons] 242=P67,19,C66781,0 3108351 FS Control Sent: Ctrl=66781, Param=0 3108351 *** EVENT: Cntrl= 66781 (0x000104dd), Param= 0 (0x00000000) G1000_MFD_PROCEDURE_BUTTON 3108554 Button changed: bRef=0, Joy=67, Btn=19, Released 3120410 Button changed: bRef=0, Joy=67, Btn=21, Pressed 3120410 [buttons] 252=P67,21,C66785,0 3120410 FS Control Sent: Ctrl=66785, Param=0 3120410 *** EVENT: Cntrl= 66785 (0x000104e1), Param= 0 (0x00000000) G1000_MFD_GROUP_KNOB_INC 3120519 Button changed: bRef=0, Joy=67, Btn=21, Released 3124310 Button changed: bRef=0, Joy=67, Btn=20, Pressed 3124310 [buttons] 251=P67,20,C66783,0 3124310 FS Control Sent: Ctrl=66783, Param=0 3124310 *** EVENT: Cntrl= 66783 (0x000104df), Param= 0 (0x00000000) G1000_MFD_ENTER_BUTTON 3124419 Button changed: bRef=0, Joy=67, Btn=20, Released and your FS frame rate matches that achieved by WideClient, so there should be no problems. Regards Pete

And have you been doing that continuously since my last answer four days ago? If you can pretend all that you must also be able to pretend everything else works splendidly. So why post here for a pretend system? Surely you shouldn't need to pretend such stuff. He or you could actually read the documentation as I suggested, rather than merely search through Forums, as you said he did. This shows you didn't even read my last reply, where I clearly said: "If you want help with my products I need to see the logs from my products -- the WideServer.log from the FS PC and the WideClient.log from the Client PC. That's why such logs are produced, so you can help me help you!" What is the point in my replying and asking for more information, if you ignore it, then come back days later talking about dead horses and pretensions? No, all that's irrelevant. Providing you are using Windows XP or later on all systems -- I can't support Windows 2000, NT, Me, 98, 95 or earlier. Not with current versions anyway. You aren't helping me help you though, are you? Wouldn't it be better if you got the person who you say knows what he's doing talking here, rather than relaying things so awfully slowly and with no useful information the way you are doing it at present? Regards Pete