Pete Dowson

Because FS is automatically assigning them, thinking it's a yoke. You should never have the same things assigned in both FS and in FSUIPC. If you are assigning everything in FSUIPC, disable the controllers in FS. Pete

So you also had to manually change the 255 to 1? Well that is completely weird, because all using the Server Name does is ask Windows for the IP address instead of reading it from the INI file. After that the code is common. It uses whatever IP address that was supplied either which way. All I can imagine happening is that there is some glitch in Windows + Ethernet driver which only "wakes up" to the correct existence of that IP address when Windiows has already prompted. How that could be I'm afraid I haven't the foggiest. I've never seen such a thing reported before! Version 6.615 of Wideclient is pretty old now and unsupported for a long time. Version 6.86 is current. Have you thought of letting it all connect automatically, as it is really designed to do? You just have to make sure that all your PC's are in the same WorkGroup, as stated in the Dox. Then you don't need ServerIPAddr, ServerName, or Protocol lines in the WideClient INI file at all. It is all controlled from the Server. Regards Pete

If you haven't set fixed IP addresses for your PCs and let them get them automatically instead, then the router is very important for the IP addresses as it is probably that which is assigning them. it is almost always better to set the Server's name rather than its IP Address as then WideClient obtains the IP address from Windows, which should of course keep track of changes and of dynamic assignments if you leave the system to those. No, it's normally the other way around -- Server Names are more reliable. The facility to provide the address is there to override Windows in certain strange cases (which no one has ever explained) where Windows sometimes seems to provide Internet IP addresses instead, generally one the ISP might assign. This peculiarity seems to be related to ceretain router types and settings. The IP address is what is actually used, so if you give the exact same one as Windows gives for the Server Name, then there is absolutely no difference. Evidently that is not 192.168.1.55. In fact it seems most unlikely that when you changed the router it changed the subgroup address from 192.168.255 to 192.168.1 but coincidentally assigned 55 like the previous router. That's actually very difficult to understand. Why 55? Where did it get that from? Just check the WideClient log file. It will show the IP address it uses, even if you set a Name. Regards Pete

All that is indicative of a really badly jittering joystick. It should never, or only rarely, send different values for a lever you aren't moving. Check your power supply, USB connection and state of the joystick -- dirt et cetera will play havoc. Where are you seeing those numbers? Can you be a bit more precise in your observations, please, not "more like" but "exactly"? If there are parts where it is decreasing and parts increasing you have two assignments on the same axis with one reversed. Have you disabled controllers in FS? If not you probably have dual assignments conflicting. How are you assigning in FSUIPC? Which method, "direct to FSUIPC calibration" or via the FS control? And in each case which control, exactly? And where are you calibrating -- i.e. which page in FSUIPC's tab, and what have you set there? Maybe, with more information. I also need to know FSUIPC version number, not simply "newest", the number is needed. "newest" could be anything from 4.70 to 4.742. Regards Pete

Yes, sorry. Fixed now. I'll never get used to this new Forum software! Pete

According to the logging, and assuming you haven't removed the relevant lines, it never executes any lines between 53 and 79 inclusive. In other words, in this test: -- See if any changes occurred: Diff = logic.Xor(Buttons, PrevButtons) PrevButtons = Buttons if Diff ~= 0 then ii never seeing buttons change. If it never sees any buttons change there's something drastically wrong. Don't do "Luadebug" any more, just add logging to the Lua to find out more. In this case, after Diff = logic.Xor(Buttons, PrevButtons) PrevButtons = Buttons insert if (Buttons ~= 0) or (PrevButtons ~= 0) then ipc.log("Datalength=" .. n .. " Buttons=" .. Buttons .. " PrevButtons=" PrevButtons) end This will show which, if any, of the first 32 buttons are setting or not. Just run it without the Luadebug part and operate your dials. Where's the Lua debug log showing buttons 64.0 and 64.1 then? All you said you omitted was loads of lines that were the same, so presumably never any button changes! Something isn't making sense in your report. Please do this. Find the Example Lua Plugins ZIP in your Modules \ FSUIPC Documents folder. Extract the "HidDemo.lua" file and place it into the Modules folder. Edit the lines Vendor = Product = Device = to match your device, and change the line Logging = false to Logging = true Then run the Lua by assigning a (working) button or keypress to "Lua HidDemo", and run it. Operate the switches or dials or whatever on your device and check the log. Show it to me if you like. Regards Pete

So what was this part about? On the one hand you imply that there's something wrong with registration process, and on the other that you didn't even try! Which is actually correct? Yes and he never replied to questions for clarification, because nothing made any sense. I've no idea what "leave flight to main screen" means, but all of those symptoms are typical of video driver problems. none of that can possibly have anything to do with FSUIPC except insofar as ANY additions to FS makes it behave slightly different in terms of timing and memory usage. But it is FREE for your needs, as you've already determined by not paying for it! yes, there is. FSX is notoriously unstable reagarding video modes and video drivers. First you need to be sure FSX is fully updated, then you need to keep it stable by avoiding switching modes too much. It simply does not like it. And this is especially true with multiple monitor setups. There is absolutely nothing in FSUIPC related to any video modes or graphics. Without registration it is merely sitting there receiving data from SimConnect. Nothing else. It has been doing this now for various versions of FS and CFS since FS98 and it is perfectly stable. Any differences in FS behaviour with it installed or not are indicative of other major problems in your installation which will surface in any case at some time or another with any add-ons. Regards Pete

You have not calibrated them correctly then. When setting the "minimum" (off) point you should have the pedals depressed somewhat, so you can be sure they always go back passed that point when released. You should do this in any case to avoid accidental pressing of brakes when using the rudders. Check the BrakeReleaseThreshold parameter in your INI file (read its description in the Advanced users guide). By default that releases Parking Brake when both toe brakes are over 75% pressure. So, it sounds as if you've not calibrated theat end of the brake travel very well either. Set the maximum calibration point well before the end of the brake travel. Regards Pete

There's nothing in FSUIPC on its own which will do that. You have something else going on. Strange. I don't know about it nor why it would need FSUIPC. And didn't you think that maybe it's the installation of that add-on which is causing the crash? How have you "tried" and how is the lack of success indicated? Not sure what being a "tech" has to do with anything, but if you want to use any of the facilities, as many folks do, then it is surely worth it. If you don't, then why did you purchase it? You could have read all about the facilities it offers first, and then made up your mind. Saying it's "pricey" without even knowing what it can do seems rather ignorant, don't you think? If you want help at all then some information would be in order, like version numbers, update state of FSX, and log files -- install log and FSUIPC logs can be found in the Modules folder. And for the "fatal error", some description of when and how this occurs might help -- what did you do leading to this, for instance. Without information no one can help really. Regards Pete

It sounds like you are forgetting to press the "confirm" button before exiting. Pete

Where do you get this document from? It isn't one published by me. Sorry, but you need to find out who published it and tell them. I do not even have it. If you want the correct information on FSUIPC offsets you need to refer to the official documents included in the FSUIPC SDK. Regards Pete

I'm afraid the attachment never happened. If you have difficulties making an attachment you can just include the file as text in the message, and tell folks to "save it as ...". Enclose it in "code" tags (the <> button above the edit area) to retain formatting. Regards Pete

No, sorry. Right:. so the weather is set by FSX, not by or through FSUIPC as you kept claiming. FSUIPC has nothing to do with "setting the winds". Nor will it produce any short-lived "little window". You need to find out what is making that mysterious little window. If it only appears when FSUIPC is installed it will be some program or add-on you are using which is using FSUIPC as well, and so doesn't do that when you don't have FSUIPC running. You need to identify what program, gauge or DLL that is. Regards Pete

Did you search the offsets list for it? It is there -- I can search for you, but i don't remember all of them off by heart I'm afraid, and you'll need the detail the list provides in any case. If you don't find it, get back to me by all means. Pete

As pointed out in the Interim release notes in the Download Links subforum, Microsoft have changed quite a few of the Windows security arrangements since 3.99 was released and I've had to make changes to get around those. Please therefore try the more recent version -- 3.998e is currently available in that Subforum. Regards Pete

Look in the FSUIPC Documents folder in your FS9 modules folder. All the documentation is there, plus lots of examples. What you want to do is only a few lines -- and event monitoring the speed brakes and a function to play the sound when deployed. Automatic running is only a matter of naming the file "ipcReady.lua", as described. Pete

I moved this from the FAQ subforum (which is where useful information is collected for users) to this, the Support forum. Else it won't get dealt with! Do you think the aircraft designer made the graphics wrong? It sounds like you are misunderstanding the trim. "Nose down" movement is with the visible wheel edge moving up, and vice versa. Think of the trim wheel looking sideways to it. The forward (hidden) part of the wheel moves UP like the nose whilst the rear moves down like the tail. The wheel is moved in the way you want to change the aircraft attitude. Regards Pete

Good. Let's hope you can confirm too. Pete

the first MUST be totally irrelevant, because "ShortAircraftNameOk=Yes" includes the "Yes" setting. It is a superset. And any Lua will work with any profile or aircraft-specific settings, so that is not true. You probably mean following the configuration instructions needs those settings because that's how you are starting the Lua program. But you can get it started in any number of ways. In that case you have nothing set to run the Lua program. The log you provided showed it wasn't running. It only does this (a) if you delete the INI file, or (B) if you have no "aircraft specific" assignments or calibrations in any case. It changes it to Profiles for you as these are far superior. I need to see the INI file you are now trying to use. You must surely have something missing which you needed in any case. It is only running the Lua automatically you are missin -- easy to solve but show me the INI and I can tell you what to do. Regards Pete

The code is completely symmetrical for any number of buttons. It doesn't care about which is which and will work the same with all. It doesn't know about CW or CCW, it just does the same with each listed and connected button -- a pair of virtual buttons for each. Checking the code and your settings I also see that the button 3,31 is set to generate the virtual buttons 64,0 and 64,1 due to the order 31,30 in the Rotaries = { ... line. The first button numbered there will produce virtual buttons 0, 1 the next 2,3 and so on. So, I think you've only got one of the two buttons you have declared working. Button 3,30 is not connected -- which is why you never saw it and had to inhibit it too. Maybe it is a different number you have instead (though then you should see it , so this is less likely)? Check your wiring. Regards Pete

Without any program? How are you managing this? Without knowing how you are trying to update the winds I can't even speculate, but there is no "little window" in FS except the message window which you can program through the FSUIPC applications interface using the appropriate offsets. I'm sorry, but there is no "little unreadable window" produced by FSUIPC, or anything else I know of, just because winds change. It sounds like something your (non-existent?) weather program (the one changing the winds) is doing. Unless you can explain how you are changing the winds through FSUIPC without a program, and can describe exactly what this very strange anonymous unreadable "little window" is, I'm afraid there's no way I can help. Sorry. Pete

FSUIPC doesn't assign anything by default, it only does what you ask. It sounds as if you still have the hat assigned in FS to "PAN VIEW". Pete

What is the FSUIPC3 version number please? Show me the Install log and the FSUIPC log files both from the modules folder. You can paste the text into a reply here. Pete

The button is being seen via the normal joystick interface as well as via the Lua file settings for the virtual buttons, but the former is getting in first. You'll need to suppress it in order to program the virtual buttons in the dialogue -- or else just program those by editing the INI file. Your choice. To ignore specific buttons search for "IgnoreThese" in the FSUIPC Advanced User's guide. Instructions for Button definitions for the INI file are also in that document. Regards Pete

You could try the latest update, 4.734. Sorry, what do you mean "cannot be changed"? FSUIPC never changes them, it only creates them with those defaults for a new INI file, but does not change any set by yourself. Did you delete your INI file? If so, why? You've lost all your settings if you did! The log doesn't tell me anything except you are using a valid version 4.728b. I suspect your problems are that you've deleted all your settings. I hope you've got a backup copy or you will need to make them again. Pete