Pete Dowson

Yes. Pete

WideFS consistes of two parts -- the WideClient, which is tthe same program for any version of FS, and the Server. WideServer is a separate module on FS9 and before, but in FSX it is built into FSUIPC4. You don't buy "WideFS 6.78", you buy a Registration key -- there are separate Registration keys for WideFS7 (the FSX Server) and WideFS6 (the FS9 version. This is perfectly clear in all the documentation and on the purchase sites. Regards Pete

I must be that you ran the 4.40 installer AFTER the 4.53 one. It wouldn't have replaced the later version. There's no other answer. no. I believe it must be some corruption in FSX somewhere. You SimConnect installation is definitely awry in any case. If you want to fix all this I think were pretty much at the point of at least a full repair if not an install, as I mentioned before. Regards Pete

Unless they#ve messed it up in a recent update, I'm pretty sure the normal SB/Roger Wilco PTT facility works with SB4 as it did with SB3. At least it did when I tried SB4 many months ago. I was planning to do some on-line flights, but they've not (yet) implemented a way of operating the Transponder mode and ident from hardware buttons -- in SB3 it was easily possible via FSUIPC offsets. I suggested a method for this which wouldn't involve SB4 linking to FSUIPC, but that was over a year ago -- and they said they would "discuss it". Never heard or seen anything since. So, if I eventually do decide to try on-line flying I think I will investigate the FSInn route, as they seem to be a little more aware of cockpit-builders needs and FSInn still seems live. Last time I looked SB4 was still in Beta, or has it actually been officially released by now? Regards Pete

I don't know. There are a number of offsets related to hydraulics. You'd need to experiment. Not many are writeable in FSX, but I don't know about FS9. Search for "hydraulic" offsets in the offsets lists. You can try to make failures happen by symptoms (consequences). See offset 32F8. And in FSX (only) there's a hydraulic switch at 341E which apparently can be controlled, so you could try forcing that off. Regards Pete

You only showed half of the information, the Client part -- WideServer also produces a Log, and both logs tell the complete story. However, this looks suspicious: Is the IP address of your FS PC really 199.201.28.10? Most unusual if so -- it looks like an Internet address. i think when this has happened before it's been something to do with a router, mapping or disguising IP addresses. Or sometimes the network drivers. I don't think anyone who had it happen really found out why, or if they did they never came back and told us. But there is a work-around. If you find out your FS PC's IP address (best to fix it so it doesn't change), then add the line specifying the actual IP address in the WideClient.INI file's [Config] section: ServerIPaddr=n.n.n.n Protocol=TCP The protocol needs specifying as well as you are overriding the Server's broadcasts with the IP address. You can select UDP instead if you prefer, of course. Regards Pete

Okay, the new offsets for Seat Belt and No Smoking signs are available now in FSUIPC version 4.544, from the Updates Announcement above. See the update notes in the Announcement for details. [LATER] Ouch! It seems there were already longer-standing offsets for both these functions, documented at 341C and 341D, so I will be removing the new ones. My mistake! Please use the original offsets. Regards Pete

Okay, the [Auto] facilities are available now in FSUIPC versions 3.939 and 4.544, from the Updates Announcement. See the update notes in the Announcement. Regards Pete

No, I only created the C/C++ interfaces, and I do not have a "site". The C# interface uses programs and other bits kindly supplied by other users. C# is a managed language and does weird things which I do not understand. Others will be able to help. If you are using the Client DLL from Mr. Henty then you will see a sticky thread above. I can help if you show me things I understand and for which i provide the tools for you to use -- the logging primarily, but also FSInterrogate (kindly supplied by Pelle Liljendal). Finally, even the FSUIPC C/C++ interface was not created/invented by me, it was one Adam Szofran who invented it back in FS95 days. I merely provide the continuity and ever-going expansion. I honestly do not know how you expect me to check you code in any case, even if I did understand it, without seeing the two values you are reading. All you supplied was the result -- fat lot of good that is, don't you think? And even not knowing the language I did point out your obvious programming error, that of the wrong size for the MagVar. Regards Pete

You posted this twice. I responded to the first one I saw. Pete

What are the values? Where in the World are you? And why are you reading 4 bytes for the Magnetic Variation, which is only 2 bytes? You'll be picking up whatever is in the following two bytes as well! Please note that I do not debug code for folks, especially not code in a language I don't know using an interface I didn't create. If you want help with understanding what you are getting, use the facilities I provide -- FSInterrogate for comparisons, and FSUIPC logging (IPC read logging in this case) to check what you are reading. I can help you understand the log if you find that confusing at all. Regards Pete

Okay, but that's more wire than you need. You can edit the FSUIPC INI file and put almost any number of actions on the same button. It can't be done only from the options tab, so what you do is: 1. program the first function (your mouse macro) 2. ok out of the FSUIPC options 3. find the button entry in the INI file (e.g. some line number=P joystick number, button number, ...), and put a ";" in front of the line to keep it but temporarily make it non-effective, 4. back in the options, program the second action, the one to set a bit in an offset 5. ok out of the options again 6. find the new line for that button, and renumber the line so it doesn't clash with the other (or any others), 7. remove the ; from the front of the previous line, so making both active together 8. back in the options, press the "reload all buttons" button .. and you are done! Note that once you have more than one assignment to a button, you can't edit it in the options. that's a safety measure, as you have no way of selecting which will be changed. However, once you get the hang of editing the INI file you'll cut those 8 steps right down to 2 or 3! ;-) Regards Pete

Is the button doing anything else? If so maybe SIOC can check for what the button does? Otherwise, you can use the User offsets, 66C0-66FF as you like. assign one of the Offset controls to the button -- there are offset byte controls "set" (to set a value), "setbits" (to set one or more bits), "clearbits" (to clear one or more bits) and "togglebits" (to toggle one or more bits), so you have complete flexibility. These offset controls are in the drop-down list in the button assignments, ready to be assigned like any others. Regards Pete

Erno, in your quote it says apply for allocation -- which is exactly what application writers who need offsets do! And how old is that offsets list you are reading? It must be very old, as those offsets were assigned and reserved a long time ago. The current one actually marks all of 6700 to 6D60 as "reserved". Please do keep up to date if you want to use FSUIPC effectively. :-( What on Earth do you mean, "not available"? It was assigned to SA_WXR years ago. It is used by SA_WXR for the purpose defined in its own documentation, as you have in fact shown me! Please refer to the SA_WXR offsets list which defines SA_WXR's use of those offsets. I do not list, in my documents, all of the private uses of offsets such as those made by SA_WXR! You NEVER EVER "add" offsets to FSUIPC. The offsets range from 0000 to FFFF and always have, right since version 1 and FS98. The all exist. You don't "add" or "Subtract" them! They just "are"! Regards Pete

Erdoes it say that's a problem or is it you saying that? I've no idea what this is about -- the offsets SA_WXR uses were applied for and allocated years ago. By assigning buttons, switches or keypresses to the Offset controls, with the offset value (eg x6D00) in the offset field, and the value in the parameter field. As I pointed out, there are facilities for BYTES (like 6D02, as it states in the doc you found), and for WORDS (like 6D00, in thge doc you found), and you can set complete values (by the Offset byte set ot Offset word set controls) or change bits (by using the setbits, clearbits or togglebits controls). You can use any of the facilities you just listed by such assignments. What is it you don't understand? For help with SA_WXR itself (a program I use but don't really understand it all), you'd be better off talking to the author. I can only help clarify any issues you have with using FSUIPC. Regards Pete

The problem is that your registration appears to be counterfeit. There's one legitimate explanation for that, which is that the date of the registration is later than the date set in your computer -- registrations aren't valid until the date of issue. Sometimes this happens because the systems date on the PC has been reset, e.g. after some sort of failure, but it has occurred very infrequently with keys purchased and issued in Germany (SimMarket's base) after midnight there, but used the "day before" in America. If the date is not the problem, and you believe you have a legitimate key, please Zip the FSUIPC.KEY file and send it to me at petedowson@btconnect.com and I'll check it here. Regards Pete

Sounds like something on of their Gauges is doing, then. Only if that key or button or whatever is stuck and continually signalling -- and then, if it only occurs with that one aircraft, you must have done is as "aircraft specific" or "profile specific" so it isn't programmed with anything else. Just look at the assorted [Keys] and [buttons] sections in your FSUIPC INI file -- or temporarily remove that file from the Modules folder before running FS, as a simple way of eliminating such a possibility That seems a lot more likely, yes. On your log it looks even less likely to be anything you've assigned: There's a repeating sequence of 4 different events there -- on 4 different Panels! Isn't there a Support forum for the aircraft. Maybe they can explain what they are trying to do with these events? Incidentally, there's a list of FS pre-defined PANEL ID names against numbers in this thread: viewtopic.php?f=54&t=74623&p=458356&hilit=GPS_PANEL#p458356 Regards Pete

That is not a "problem with Event Logging", that is a problem with something sending all those presumably unwanted events. There's no problem with event logging -- you just turn it off if you don't want it!! Of course something is doing it --- you need to find out what it is which is doing it and get rid of it, as it will potentially be interfering with other things and certainly not doing the performance of your FS installation any good! The Open one opens (i.e. displays) the panel which has that ID, if there is one, and the Close closes it. The ID is provided in the "parameter" part of the event. There are a number of pre-defined IDs and any number of others added by folks who make FS aircraft panels. They are defined in the PANEL.CFG file. Regards Pete

I'm pretty sure SA_WXR uses FSUIPC for these settings. Have you checked? I've not got access at present to my copy -- I can look tomorrow, but it would be quicker if you can find the documentation and therefore the offsets concerned. You can then simply assign button actions to the relevant Offset control (Offset Byte, probably) to set it, increment it, or decrement it, depending how you wanted to use your switch. I don't know what a "rotactor" switch is, but an encoder normally only gives increments or decrements so it really acts like a two-way centre-off sprung toggle. It is more complicated to program if it isn't one of the easy types which look like two buttons, pulsing on one for one direction and on the other for the other direction. Regards Pete

I'd follow the original FSUIPC ini file structure, including a common LUA section to list every threads to run everytime FS is "ready to fly", and specific LUA sections for each aircraft which would be started "on specific aircraft load". They are "[Auto]" sections, and can list macros and/or Lua plug-ins, not just Lua ones. Aircraft- or Profile- specific ones folow the same method as for Axes, Buttons and Keys -- the name after a '.' character. All that side is standard as it is common code. Actually that's the way it has to be without a lot more work. that's the way the Profile and Aircraft-Specific actions work. The common threads, those in the base [Auto] section, will be killed and restarted. I think that's okay. Thanks & Regards Pete

Good! I see you quickly got the hang of elementary Lua! ;-) I will definitely be implementing a facility to automatically execute a specified sequence of Lua plugins or FSUIPC Macros when an aircraft is loaded. It will be done by adding sections to the INI file like this: [Auto.] 1- or , 2= ... I am currently not sure whether it should run these on every loading of the aircraft, if it is the same aircraft, or only when the aircraft is changed. Normally these things are only looked at on aircraft change. What do you think? For consistency I might also have a global section: [Auto] ... which is run initially (after ipcReady) and on every aircraft load, before the aircraft or profile-specific section. One of the things I'd need to remember to do is kill any still-running Lua threads which were started by one of these Auto sections when lookinbg at executing another, as otherwise those in loops like yours will proliferate! None of this is hard to implement, so expect it in an interim update within a week or so. Regards Pete

Sorry, I don't know the product you are asking about, nor how it gets its weather. Are you sure it doesn't simply rely on you selecting the relevant weather mode in FS? Both FS9 and FSX will automatically download weather if you set that mode, though it does seem that the Microsoft /Jeppesen site it relies on is down on occasions, which might explain your results. Many folks these days use improved weather control from products such as Active Sky. If that "adventure" add-on is supposed to provide the weather, you might get more relevant answers in its own support forum if there is one. Regards Pete

I'm afraid I don't have such a device, so I can't confirm the hardware side of things, but there are threads here from folks who have got the GPSout facility in FSUIPC4 to work with that model GPS. Try this one: viewtopic.php?f=54&t=73148&p=457243& Regards Pete

That's what I've always done. ;-) Pete

FSUIPC does not calibrate joystick axes. What it calibrates are the values being sent to FS via the specific controls. The calibration section knows nothing about HOW those values arrive, it merely allows you to spread whatever range you can achieve, by whatever method you can find, across the correct range for FS -- with the "centre" in the place you choose and possibly a response curve or other frills added. The source of the values going to FS, which FSUIPC intercepts and "calibrates", may be from joystick axes assigned in FS, joystick axes assigned in FSUIPC, values from certain supported PFC serial port devices, or values written to FSUIPC offsetrs for this purpose by external programs (even via wideFS) or internal FS modules. So, the one and only aileron is calibrated from whatever sources you have for it, same with elevator and rudder, and so on. Since the values seen are those of the FS control (aileron control, rudder control, whatever), there's no differentiation for different simultaneously attached and assigned axes. For multiple axes assigned for direct calibration in FSUIPC there is an arbitration procedure carried out to determine which of two potentialy conflicting inputs will "win" -- and the arbitration favours the one providing the largest deflection from "normal" (wherever "normal" may be, which varies fro control types. The latter. As I said, you aren't calibrating joysticks, but controls. For dual controls you do really need reasonably well calibrated axes in the first place, ideally well matched of course. To calibrate axes you use the Windows "game Controllers" control panel application. YTou should certainly be able to match centres there. Without FSUIPC you'd find that was the only place you could do it in any case -- FS itself offers nothing, it relies on the Windows calibrator. There is the possibility of manipulating the input values before they are passed onto FSUIPC's calibration == multipliers and addition values which can be added to the assignment lines in the INI file -- but this is a bit of a sledgehammer for your application. Regards Pete