Pete Dowson

Those look wrong. Please refer to the WideFS Technical document, search for "TeamSpeak". You will see you need: Notice the commas (,) not points (.), and that 24 is to release, not another 16. Also note that for TeamSpeak you must have: UseSendInput=Yes. Don't forget to make sure TeamSpeak is set to use F12 too. Regards Pete

Yes it it. Any use of a button in a profile overrides any use of the same button in the generic section. Any other system is simply too complicated not only to program but also to unravel when you get it wrong. Regards Pete

Hmm. It appears to be due to a callback from ViMaCoreX.DLL after FSUIPC4 has closed that handler. In fact the FSUIPC4.DLL has already closed and its memory freed. Very odd. It's the handler for the new AES default vehicle deletion. Looking for a solution now. Seems the disconnection isn't working, or not working in time. [LATER] Okay, fixed in 4.751a, in the Download Links subforum now. It appeared to be a timing problem FSUIPC disconnected and terminated. I moved the disconnection to an earlier point in the closing tidy-up sequence. Regards Pete

As I said earlier, I really can't do anything about the latter. It must be due to the way they've programmed the NGX. BTW version 4.749e is a few versions out of date. We got as far as 4.749i in that range, but the current version is 4.751. Now the the odd calibration issue has disappeared (?), I cannot really diagnose that 00 the INI data looks fine, except that there's an error. At some time it looks like you went to create a Profile but pressed "enter" instead of providing a name or using ESCape to cancel. In recent FSUIPC versions I detect that and don't create a null profile, but you must have created one some time ago, as witnessed by these sections of the INI which you should certainly delete (notice the '.' in the header which should be followed by the profile name): Regards Pete

Yes, it can be done in C. I doubt that it can be done in XML. Gauges written in C are merely DLLs like FSUIPC with a different name which serves to indicate that instead of loading and staying loaded they are loaded as required according to the panel. Naturally this can present a problem when hooking into a function in FS because if the gauge then unloads the hook will cause an FS crash. I've not written gauges myself, but it would be okay to undo the hook if the gauge is guaranteed to be called before being removed. If that cannot be guaranteed then it would not be advisable to insert hooks. Another way to implement it in C (or most other languages except XML) is to use FSUIPC. Offset 0400 contains the filename of the last flight (or situation) saved, as an ASCII string with a zero terminator and the counter at 3BD2 is incremented when this has changed. This technique is used by some, especially external programs of course, like Radar Contact, so they can also save their state. Regards Pete

It sounds like something else it contributing something there. Perhaps you could show me your INI file for this, and tell me which version of FSUIPC you are using. Actually, first, if it isn't 3.998m or 4.751, could you update and check with the latest first, please, so when I check it i know I'm using the same. There's a different NRZ checkbox option for each group of controls -- i.e. 4 throttles, 4 mixtures, 4 prop pitches. They can be separately selected, but It wouldn't make sense to have one engine with a completely different method of control to another. In the INI file the NRZ settings are part of the encoding in the calibration, in the number at the end after the /. The only INI file option with "NRZ" in the name is the one stating "UseAxisControlsForNRZ" hich should be in the same JoystickCalibrations section as the calibrated axes it relates to. Regards Pete

I'm afraid your code bears little resemblance to anything I have suggested. To start with, since the return from ipc.elapsedtime() is always an integer, a number of milliseconds, the lines like this if (time2 - time1) < 0.5 then[/CODE] will only be true if time2 actually equals time1, which is hardly ever likely to be true, or nearly always true. I can't tell. Your code might actually be equivalent to: [CODE] function AltDisp(offset, value) gfd.SetDisplay(GF166, 1, 0, string.format("%2.2f ",(value/16)*0.0295302)) end function AltRotary(model, unit) gfd.GetValues(GF166,1) Dial1 = gfd.Dial(1) if Dial1 == -1 then ipc.control(65884) end if Dial1 == 1 then ipc.control(65883) end end event.gfd("GF166",1,"AltRotary") event.offset("0330", "UW", "AltDisp")[/CODE] If you are happy with the results you are getting you might as well simplify it like that. Either way you might as well strip out the timers and elapsedtime calls and either include your many incs and decs or only one as you wish. You seemed to have missed the points I was making entirely. Recall what i said. Here, I break it down a bit: [b]"Don't assign the dial "button" returns in FSUIPC. Instead use the [b]event.gfd[/b] function to get your function called when something changes on the device, then [b]gfd.GetValues[/b] and [b]gfd.Dial[/b] to read the dial to see if that changed."[/b] Okay, you've done that well. [b]"Use the change to update a value you are reading for the radio ([b]event.offset[/b] for the radio offset) and send that back to FS [b]ipc.writeUW[/b] to the same offset) and also send it to the GF display ([b]gfd.setdisplay[/b]), as you are doing now."[/b] You aren't doing any of that. You are simply sending a single INC or DEC to FS and letting it change the radio value, not you. The method I'm talking about requires your code to maintain the radio value, work the increments and decrements yourself, and update the display AND the FS offset, yourself. You are not doing any of that. [b]"Also read the time ([b]ipc.elapsedtime)[/b] 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."[/b] Instead of this you are setting time2 on entry to your dial change detection and setting time1 at the end. What do you think the difference in those times is supposed to indicate? At best it tells you how fast your PC is at executing the intervening lines. The point of having times at all was to stop your other routine, the one setting the display, from updating the display at all when you, the user, are supposedly updating it directly on the dial changes -- which you are not. You aren't even testing the time in the display routine! I'm thinking this is far too complicated for you. Is that right? You are using gfd.Dial(1) at present. Why '1'? Have you tried other numbers? The logical first one would be 0, as in gfd.Dial(0), of course. Surely if there's a 1 there must have been a 0 as they are numbered 0-7 as documented. I really doubt they are being executed. Or, possibly, they are always being executed. I'm not sure if the two times are always the same or always different, but it could be a near random chance. Pete

There are currently no mouse-specific facilities implemented in the Lua libraries. What were you thinking of here? There's already some work done of working out the ways to control the mustang. not seem anything on the autopilot, but this item in the User Contributions section might be of use: http://forum.simflight.com/topic/63155-flight1-mustang-commands-upd-15th-mar-2010/page__hl__mustang__fromsearch__1 so it looks like examining the local gauge variables (L:Vars) used in that aircraft may prove fruitful. There is an FSUIPC control which will list them for you, and a Lua plug-in to monitor them. Regards Pete

You'd need both together, not one or the other. They are both treated identically, so it sounds as if you didn't recalibrate throttle 2 after changing the options. You would need to do that. Regards Pete

I assume you tried the NRZ option with the INI file change I mentioned (UseAxiscontrolsForNRZ) ? Odd that if this is a general problem no one else has mentioned it. However, there really isn't anything i can do about it if PMDG have programmed it in such a way that they only take account of throttle controls arriving from SimConnect at the top priority, which sounds like may be the case. You see, in order for FSUIPC to receive the values, calibrate or sync them, and send them back, it has to receive them from SimConnect at one priority level then send the changed ones back at a lower level. It cannot send at the same or higher level because you'd then get a never-ending loop and no one would ever see the throttle values. Regards Pete

Thanks. I spotted that the other day, but I was part way through some other changes so couldn't replace the upload. It'll be okay in 3.998m, probably tomorrow or late tonight. Regards Pete

You've only provided one half of the story -- the Client logs. The WideServer.log (from the server -- the Modules folder in FS) would have been useful too. However, in this case the reason is pretty obvious: That IP address is certainly not the one for your PC. It appears to be something to do with your ISP: 204.232.137.207 IP address location & more: IP country code: US IP address country: United States IP address state: Colorado IP address city: Denver IP postcode: 80202 IP address latitude: 39.7525 IP address longitude: -104.9995 ISP of this IP: Rackspace Hosting Organization: Sandvine (USA) Please see the FAQ subforum. There's a thread about this very problem, caused by Router settings I believe. It is called "WideFS Server names translating into incorrect IP addresses" Regards Pete

Ah. I can't use that for an automatic save because it would just prompt for a name. I call the FS API directly. I think those aircraft which save their own files at the same time must hook that too. Regards Pete

Well you are lucky I spotted your message, then. You not only posted in the FAQ subforum (which is for answers to Frequently Asked Questions), but then added it to a thread entitled "Useful websites for FSUIPC users"! I've had to create a special thread in the Support Forum in order to move your message. Sorry, but I have no idea how that's anything to do with any of the programs supported here. Are you sure it isn't an FS9 aircraft rather than FSX? Most aren't compatible. Not many FSX aircraft use any of my programs, but a few FS9 ones used FSUIPC (version 3, not 4). A "link"? what "link". Sorry, I've no idea what you mean. And what manual? The one for this aircraft you installed? Or do you have the FSUIPC4 'manual'? If so what part are you quoting? What's the context? How? I really have no idea, sorry. By "game" do you mean Flight Simulator, or the aircraft you purchased? I'm really not following you, sorry. You pay for FSX, and you pay for commercial add-ons if you want them. If you have problem with some product or aircraft you've installed, please find the support forum for that product. There must surely be one if its a commercial product? I cannot undertake to support everything you can possibly do with FS. If you have any specific questions about FSUIPC4 or any of my programs I'd be happy to answer, but i don't know anything about any anonymous "links", and without any real information I can't tell what you are talking about at all, except that you've bought an aircraft and it doesn't work. Regards Pete

Yes, providing they aren't overridden in the applied profile. There is a clear priority order there. The [buttons] section is all loaded first, then the relevant profile section, with buttons already assigned from [buttons] being replaced. Pete

Ah, you want advice about programming, not the FSUIPC interface facilities. Sorry, I can't help with anything other than C/C++ or ASM. Are you using Paul Henty's interface? I think that makes things easier. The payload section of offsets is a simple array of structures, so you'd need to know how to handle those in your language. Alternatively of course, if you know the payload sectors you need to change, you can simply address the weight variables directly -- the double at 1400 for the first station, 1430 for the second, and so on. They are spaced at 48 byte intervals, of course, because each entry takes that much space. Regards Pete

Sorry, no. The matching process finds the entry with the longest match. It would make things far too complicated to do what you ask, though I do understand it very well. It would involve all sorts of questionable decisions, like which takes precedence when there are assignments to the same button? Also, the code in this area has already grown far too complex and I can't risk introducing errors at this stage. I am still adding new facilities, where existing code isn't unduly affected, but that's about it. FSUIPC has been growing like topsy for many years now. I have to be very selective. Obviously it doesn't matter with different buttons, but i assume you are re-using the same buttons for different things? If the things they do have a null effect on the wrong aircraft, you could get away with multiple assignments to the same button -- so that all of its meanings are sent when you press it. However, if that's at all harmful for the wrong aircraft that is obviously not on. Regards Pete

What are you finding wrong? Have you read the details of the 1400 offsets, where it says that it doesn't seem to affect real weights and balances on FS9, and no one has yet provided any feedback for FSX? What version of FS are you using in the first place? Regards Pete

No, it isn't any different from pressing ";" and entering a name. AutoSave calls exactly the same routine in FS to make it happen, supplying its own generated filename. This has always worked too with other add-ons which save their own data, like the PMDG aircraft and also Wilco and PSS I think. I don't know how Doug's code differs. Maybe he only takes note of the Flight-Save dialogue command, which will of course be a different command and context. Did you check if it saved when using the ';' key? Regards Pete

He is doing similar, it will days a couple of days or so, he says. FSUIPC 4.749i will be up later today. I am working on something else but I'll release that later in the week, probably as 4.751. It's a straight copy of the 64-bit double which arrives from SimConnect as "ACCELERATION WORLD Y" in ft/sec^2 units. Same applies to 31C0 ("ACCELERATION WORLD X") and 31D0 ("ACCELERATION WORLD Z"). You can check that of course using the Monitor in FSUIPC. If you list the offset in the table on the right-hand side of the Logging tab, as FLT64, and check "normal log" below, FSUIPC not only logs changes to the offset but also the SimConnect input, including name, of the related variable(s). If you check "console log" too, and run FSX in Windowed mode, you can see it all in real time. [LATER] Okay, get FSUIPC 4.749i Regards Pete

Herve Sors seems has been checking things and last I knew he believed 31C8 is correct, but thinks that the G-Force supplied by SimConnect (the one I use for 11BA and soon 1140) is suspect. I must admit they both look good to me! I am getting conflicting advice at present. We'll see. I'll pass on your opinion to Herve. I'm not really wanting to do any complex time-based conversions like the one you suggest in any case. Scaling and so on, yes, but nothing like what you ask. Regards Pete

Actually you purchase FSUIP4 and WideFS7, not any specific version. You are merely expected to use the latest, for support purposes, but your purchase covers any version. That's WideClient, not "WideFS" but only the client program. WideFS has two parts -- a Server (now built into FSUIPC) and a Client -- which you run on the Client PC. WideClient doesn't really use a Window -- it can do, for docking applications to if you wish, but mostly all you usually want to see is the title bar, the one telling you when it is connected. If I were you I'd simply resize the Window to the title bar only, and move that somewhere out of the way on your client PC. If you like you can hide it altogether. Please see the documentation for the correct parameters. Once you have installed FSUIPC on the FS PC and registered both FSUIPC and WideFS, and installed and run WideClient on the Client, that's it. There's no more to do for installation, providing your network is working and all PCs are in the same workgroup. Best to read the section in the User Guide about configuring the network if you aren't sure. Regards Pete

That's fine. Glad it works okay. Regards Pete

Hmm. You are better at understanding them and correlating them visually that I, then, as there seems only more detail in FSX, not much difference in where things go up or down. But i bow to your knowledge in this over mine. I'll check. I might have put it with the wrong data group. I have different update rates for different things. Hmm. Shame. Maybe i could have done something about that if it had been pointed out a few years ago. Maybe applications have become dependent on the 'wrong' value now. Regards Pete

Hi Bob. Thanks for all that valuable info. I should of course remember to refer folks to the CH-Hangar for CH info, or is the StickWorks site the better place now? Best Regards Pete