Pete Dowson

wideFS is only using simple, standard TCP, UDP or IPX protocol, about as simple as you can get, copied from Microsoft examples. something is certainly blocking it completely. There's nothing I can see wrong with the INI files or Logs. There's simply nothing getting through. Have you tried UDP at all, just in case it's only the TCP side that broken? I think windows Explorer uses UDP, idf it is Explorer you mean by " thru my home network". Certainly sounds like hardware put like that. Software doesn't normally behave like that. Regards Pete

You have two axes assigned to the same function: I expect one is preventing the other from being seen in calibration because of arbitration. If you download the latest Update from the Announcement above the arbitration is now switched off during calibration. However, if you don't want both axes operating and possibly conflicting in FS, you should renmove one of those assignments. Pete

You do if the broadcasting isn't getting through. That needs both PCs running WinXP or later, and both to be in the same named workgroup. Wireless routers are general pretty good these days, but if they are used in a room with lots of metal and electrical equipment (like a kitchen!) they can prove problematic. I need two access points in my house because of thick walls made with some sort of old fashioned brick which seems as hard as metal! Well i don't use firewalls BETWEEN my PCs -- I have a good setup on my ADSL modem/router. But you certainly should simply be able to give permissions -- FS and WideClient, ports 8002 and 9002. Nothing at all as far as WideFs is concerned. It isn't a disk access program, it sends data only by Ethernet. However, some programs you run on the clients may want to read or even write data on the Server. That's something you have to find out from the application documents. Typical things are scenery file access for planners building databases, flight and Plan files folder access for planners and other programs which need to read plans, etc. Regards Pete

Hmm. All that shows is that nothing is arriving at all from your client. So, it has to be either firewall, or a selected name or IP address which is incorrect, or simply that your Network isn't working. Have you checked the actual network? I've had network cards/ chips fail before, and switches/hubs come to that. Check the INI files again. In fact better that that, show me them, both of them, Server and Client. There's nothing else to go on here. All the logs indicate that the two PCs aren't communicating, full stop. No, it just means you haven't installed that protocol. Microsoft made it optional a while back now. Regards Pete

That's only half the story. Where's the Server's log file? Well, someone has, obviously! ;-0 Pete

I've done one which should work, for those two aircraft, and I've done it in a way you should be able to add to it quite flexibly. There will be as many ways of doing this as there are programmers, but i am a beginner in Lua, so this is as good as I can do it in a short space of time: aircraft = { "747", "737", 0 } -- needs to match somewhere in the aircraft title macrofiles = { "747 EFIS", "PMDG737", 0 } -- the macro filenames for those aircraft -- Lists of macros for each aircraft, followed by 0 then the control to use then the message to use Actions747 = { "BARO_ON", "FPV_ON", "TFC_ON", "STA_ON", "FD1_ON", "FD2_ON", "VOR1_ON", "VOR1_ON", 0, 65584, "EFIS -- SET\nQNH -- LOC SET" } Actions737 = { "EFIS_1", "EFIS_2", "EFIS_3", "EFIS_4", "EFIS_5", "EFIS_6", "EFIS_7", "EFIS_8", 0, 65584, "EFIS -- SET\nQNH -- LOC SET" } -- table of those actions for indexing the same way as the aircraft and macrofile names IndexToActions = { Actions747, Actions737 } -- read aircraft title Name = ipc.readSTR(0x3D00, 256) ipc.log("Name = " .. Name) -- identify aircraft by substring from "aircraft" list above i = 1 j = 0 while aircraft[i] ~= 0 do if string.find(Name, aircraft[i], 1, true) ~= nil then j = i break end i = i + 1 end if j > 0 then -- found it! ipc.log("found it at " .. j) -- use action list actions = IndexToActions[j] i = 1 -- first all the macros while actions[i] ~= 0 do ipc.log("Action" .. i .. "= " .. macrofiles[j] .. ": " .. actions[i]) ipc.macro(macrofiles[j] .. ": " .. actions[i]) ipc.sleep(500) i = i + 1 end -- now the control i = i + 1 ipc.log("Sending control " .. actions[i]) ipc.control(actions[i]) ipc.sleep(500) -- and lastly the message i = i + 1 ipc.display(actions[i], 5) end The parts you'd need to add to for other aircraft are: Aircraft list aircraft = { "747", "737", 0 } Identifying the aircraft by substring in its title. You may want these to be more specific -- they'll catch the default 737 and 747 too. Just make sure there's a 0 at the end of the list, so stop the loop. Macro file names used macrofiles = { "747 EFIS", "PMDG737", 0 } A one-for-one relationship to the aircraft list. If you need more than one macro file for an aircraft list you'll need to do it differently. i just separated the file nmae from the macro name to save space and typing! ;-) Action lists Add a list of the actions for the aircraft, naming it what you like, and adding the name to the correct place in: IndexToActions = { Actions747, Actions737 } Note that I've adopted a format with a list of any number of Macros, ended by 0, then the control you want to send (if it is always the same, take it out of there and use it explicitly instead at the end of the code), and the message you want displayed (same consideration). You'll see "ipc.log" calls in there -- that is for testing, so i could see that it worked okay, even though i don't have the aircraft nor your macros. Take them out when you've done, as you like. Regards Pete

There is no separate WideServer DLL for FSX, nor a separate INI for it. You evidently aren't reading the documentation! Delete them both. In what way is FSX "not responding". Is it loading up? Is there an Add-Ons menu with FSUIPC listed? For WideFS to work? Register wideFS when you install FSUIPC4, then with FSX running, go to the FSUIPC options and enable wideFS. There's no change to the Client end, that is identical for FS98, Fs2000, FS2002, FS2004, FSx and ESP (and CFS1 and CFS2 for that matter). Regards Pete

Okay -- though i don't see that as relevant. It most certainly has nothing to do with any FSUIPC offsets, nothing whatsoever. And how do you know which? Shouldn't you watch all? It is easy enough for you to test if you have even only a single thrlttle. Simply assign it to Throttle 1 instead of the generic Throttle. Maybe you are simply not recognising that the user has twin throttles and you are not looking in the right places? Regards Pete

Correct. All the analogue axes on the Serial Port PFC devices (as opposed to their USB devices) are connected to a controller board which supplies all switches and axes in PFC's own protocol, which is handled, for use in FS, by my PFC modules. However, they operate via FSUIPC, and are thence handled in the same way.

Button activated reverse can only be done by assigning the button to the appropriate "DECREASE" control, probably THROTTLE_DEC for throttle and PROP_PITCH _DEC (or something like that) for prop pitch -- whatever way you do it on the keyboard, it would be the same control. Have it repeating. You probably also need a cancellation control, to set IDLE or zero when the button is released. I don't really know -- ask other Saitek users. FSUIPC's reverse zone facilities are for proper axes with real reverse zones or reverser levers on them. Your Saitek's take the cheap way out by having a button instead. FSUIPC will simply see that as a button, it is up to you to decide what to do with it. I'm really amazed that Saitek don't provide documentation or help on this. What, the Saitek manual? Or FSUIPC? FSUIPC's manual doesn't deal with specific equipment. It is not possible for me to purchase and document the best way to handle each item of equipment you can possibly connect. Regards Pete

This is running SB on the Client PC or the FS PC? In that case you certainly have a registration problem. Either the keys you've got are illegally made, or your system date says they are not valid yet because you purchased them AFTER today's date. I expect it is the latter. Correct your PC's date and it will be okay. Pete

Well, I can't do that off the top of my head like that. I'll try when I have half-an-hour or so to spare. Can you post details to petedowson@btconnect.com, please? Then it'll go in my "pending" list -- nothing here does. Pete

Neither FSUIPC nor PMDG create weather in FS. You need to look at where your weather is coming from if the 124 knot tailwind isn't correct. if it is correct and you are complaining about the flight model (it isn't clear from what you say), then you'll need to talk to PMDG. FSUIPC isn't controlling anything there either. For any steady wind the PMDG model should fly fine -- there's something wrong with it if it doesn't. Pete

For the visible rudder, the control surface, to move, you mean? Are you checking this from outside the aircraft? How do you operate the pedals from outside? ;-) No, there is no way to make the rudder control surface move when the rudder control in FS isn't operated -- unless Level D have a trick they can operate for you. If you have the tiller driving the rudder, as you said you have, check your rudder with that. Otherwise use the rudder for steering and disable the tiller. Regards Pete

Thanks for that. Very interesting. But you might be better off combining some of them. For example: 1. You could also use the event facilities to put all of the little button-activated sequences in one pre-loaded Lua file. Each would be a "function" declared inside that Lua file, and a sequence of "event.button" calls would tell FSUIPC which one to execute on each of those buttons. This actually would be very efficient because the Lua file would be loaded and compiled just once, and be sitting in its own thread just waiting for the calls. The disadvantage would be that you couldn't have more than one of those sequences operating at the same time, as they share the one thread. Preloading is done using "ipcInit.lua" or "ipcReady.lua" depending on when you want them loaded. Those can load other Lua files using the ipc.macro function. 2. Surely there's a lot of commonality between the various planes? Those which are similar or the same could be using the same Lua files. 3. You could have single Lua files per action despite plane differences by testing the plane name -- the name string can be read, and significant substrings (like 767, 747, whatever) checked within them using the extensive and powerful Lua string library. Just some ideas to get over the 127 limit and to make things a little more controllable, tidier, efficient? Please keep me informed on progress. Maybe I could use some of your best results as examples for later updates of the package? Regards Pete

This is true. The files show me nothing useful at all. The excessive number of EVENTs are being generated automatically by your Aircraft panel. If you test again, after you have your joysticks working properly in FS, be sure to run with a default aircraft. I cannot deal with add-ons initially. you must get things working by default first. Your main problem at present appears to be nothing to do with FSUIPC, and it certainly cannot be just due to changing from 4.4xx to 4.5xx. You've had something else change. I repeat, FSUIPC CANNOT stop FSX seeing joystick buttons, only YOU can do that by disabling them in FSX. If neither FSX nor FSUIPC can see them, then you have something else wrong, presumably with the joystick's drivers. (I'd love to be able to stop FS seeing joysticks I'm controlling, as it would save a lot of problems supporting folks who get things duplicated, but I cannot do so). Don't forget to test your setup with a default aircraft. Sophisticated add-ons like the Level D 767 make things much more complex to resolve. Pete

FSUIPC takes control of nothing unless you tell it to! And there is absolutely no way it can take control away from FS -- this is why you have to disable controls in FS when using them via FSUIPC, or else you get duplicate actions! There is no way I know for any program to stop FS reading joystick axes or buttons. As far as I know it is just not possible. You evidently have disabled them in FS. From what you now say, I really don't think they will be of any use at all to me. You have something else wrong which is absolutely nothing whatsoever to do with FSUIPC! Get your controls working in FS, leave out FSUIPC4. When you have them working, only then look at FSUIPC again. Pete

WideClient, on your Networked PCs is the same. You don't need to alter those. WideServer is gone, not used on FSX. The WideServer functions are built into FSUIPC4 and need registering separately with a WideFS7 key. You can purchase FSUIPC4 + WideFS7 as a bundle from SimMarket. Pete

In FS the steering tiller controls the rudder (there's no nose wheel control), so one way is to check the rudder using the tiller instead. There is another offset I provided for Project Magenta to read for the rudder, which reflects the rudder input even when it is the steering tiller controlling the rudder. I don't know what software you are using to display the controls but maybe it can use that too? It was suggested by one user that I could let the pedals control the rudder whilst stationary, and suddenly change to 100% tiller as soon as there's any ground speed, but I fear this will give odd results (the changes won't be instantaneously coincident) whilst taxiing and braking, and in any case most experts I've talked to say that these checks are most often performed WHILST taxiing, so that wouldn't be any good after all. Regards Pete

Well, maybebut a problem at present would be to find time to re-design the existing dialogue just to fit another option in, even just for one conditional button. If i have to make the dialogue page bigger it affects all of the pages and they all need more work. It is a much bigger job than it may look to you. If I could relegate some of the options to another page, maybe. For instance, split the assignment to key presses from the assignment to controls (separate pages). But this makes assigning say a keypress for "press" and a control for "release" impossible, or extremely difficult. Don't forget, with just one condition you have to have twice the space, because there could be twice the number of actions per button. And some folks have more than one condition -- each one doubles it. And then why give preference to this feature? What about all of the cases where folks want a button press to do several actions, or the same one repeated several times? According to the feedback I get here I would say this is probably more common. To accommodate that on the same page I have to allow a list of controls or keypresses, or both mixed. And all of this for one or more conditions. And how are the conditions expressed? By pressing another button, or by giving the button number? Button numbers aren't easy without FSUIPC scanning them and showing them, so it would have to have a subscan in the middle of a normal scan. And then there are the Button Flags -- used in conditions probably just as much as the direct button press itself, as you can use the button flag to signify the condition is "latched" -- multiple flags allow one button to cycle all the others through several different modes. How would i deal with that on Screen in an easy to understand dialogue? From feedback over the years all of these things are just as important as each other. I couldn't embark upon a design for a dialogue without taking all of these things into account, and really the mind boggles at the thought. Now, if someone good at designing dialogues which make complex things look simple would volunteer a design, I would certainly consider it, even if it meant having a button on the Buttons page saying "go to BIG options page" which draws a larger dialogue, or possible runs a "Wizard" to get the settings done by questions and answers. Regards Pete

Oh, you mean as a "shift", or "selector" for conditional operation of other buttons! Sorry -- I use the word "Switch" like "button" -- a button is something you push and release, a switch is something you toggle. A switch is usually latching, a button isn't. else they are the same. Yes, I know what you mean. And designing such a dialogue which is easy to use is the hard bit. I'm afraid user interface design is not my area of expertise (as you may have noticed). The versatility of compound conditionals in the button parameters is not very easy to translate into a usable dialogue design, At least it isn't without restricting it too much. There are designs for multiple button conditions, not just one as you have, and there are designs for handling graycode encoders which are even more difficult to fathom out simply enough for put into a dialogue format. It ends up being a question of time spent doing a partial job, which may help one or two folks but not do the real job of making the complex things easy, or a lot (and I mean a *lot*) of time trying to design something easy and flexible. I just feel my time is better spent on doing things I'm good at rather than those I am not. Regards Pete

Er, sorry. What is not possible for a switch at present? I don't understand your request. Pete

What do you mean, "disconnected". Nothing in my code can cause that. 4.432 cannot be supported, it includes some bugs in any case. What is a "Cougar"? I suspect you have something programmed which did not work correctly in 4.432 and you are making use of something which should not happen in any case. Going back does not help. Please reinstall 4.50, and update to 4.506 (from the Updates announcement above), so we are both using the same version. Then, in FSUIPC's Logging options, enable Button logging and Event logging (not Axis). Close FSX and reload it, so it starts off with the logging enabled. Now reproduce the problem (making careful note, please, of what buttons you are pressing and what you expect to happen), then close FSX, and send me all the details -- ZIP up the FSUIPC4.LOG file, and the FSUIPC4.INI file. Send to petedowson@btconnect.com. I will take a look. Regards Pete

Yes, but if you want them retained you need to number them too. e.g. 23=; my comment The number will ensure it is retained and keeps its position. You really need to number them in the order you want them. They can sometimes get re-ordered otherwise. Just edit the oder to what you want, then renumber the lines accordingly. Remember that where you have sequences for one button, the order matters. Regards Pete

Yes. 127. Phew! Are these all for different things? I'm amazed that anyone is finding so much use for this facility. Perhaps you would describe your uses to me some day, please? I'd be most interested. I've not had any feedback till recently, and now this!:-) I'm afraid the limit is fixed at 127. I never thought that would be an effective limit -- seems I'll need to document it. The reason is the way Button and Key assignments are encoded into a single 32-bit word. What with macros (also limited to 127) and all the Offset handling controls, conditionals and so on, I only had 7 bits left to encode the Lua number -- this was by pinching half the range originally assigned for Macros. In turn, of course, this is a result of software growing up bit by bit, adding new facilities, never conceived earlier on, to an existing design. If i started again I'd do it differently! ;-) Regards Pete